PCSX2 PS2 Emulator: Progress report Q3 2019 to Q1 2020(pcsx2.net)
pcsx2.net
PCSX2 PS2 Emulator: Progress report Q3 2019 to Q1 2020
https://pcsx2.net/292-progress-report-q3-2019-to-q1-2020.html
4 comments
PCSX2 is a really nice piece of software and often gets overshadowed by more popular emulators, it's really nice to see the devs getting some attention. The feats they've accomplished are substantial - I'd go so far to say that it's the best way to play many PS2 games.
From reading this progress report (I'm not an active user of PCSX2), it seems this emulator uses per-game hacks frequently. On the other hand, Dolphin (which I'm a semi-active user and used to follow development) never performs per-game disk patches and only rarely uses per-game emulator-level hacks.
It's true but the PS2 is a much more convoluted system to emulate with more moving parts and undocumented behaviour in the timing and interaction between these parts as compared to the relatively simpler Gamecube. This also made the Gamecube easier to develop for IMO (I developed games on both systems)
The PS2 emulation scene is what ended up driving me to IT and eventually software development back when they hosted their forums on NGEmu. Tons of respect to all the contributors for keeping the endeavor alive - incredible what they've managed to accomplish.
Unrelated, has anyone ever tried getting PCSX2 to run on ARM chips?
Unrelated, has anyone ever tried getting PCSX2 to run on ARM chips?
There's an Android port but unfortunately it's by some company that's selling it and blatantly violating the GPL.
https://pcsx2.net/286-the-pcsx2-team-s-statement-regarding-t...
https://pcsx2.net/286-the-pcsx2-team-s-statement-regarding-t...
I was initially gonna say the GPL permits selling your software, and even says you don’t have to release the code to everyone (just those who own your software), but then the developer said they will open source at 80 million downloads? That’s a violation.
Does anyone know why the Mac port has not been updated since 2012 (but downloads are still being offered)?
From my experience with open source projects: nobody in the team owns a Mac.
I wonder if a forum outside of the silicon valley bubble would have so so many apple apologists like we have in this thread.
---
apple is bullish on metal vs vulkan because they want to lock in apps. and they have the upper hand because by not implementing vulkan, they force everyone to chose between the money on IOS or everything else. it's not a technical decision.
middle ware provide only the minimum common denominator, or expensive translation functions, it is not even close to providing the flexibility and speed modern emulators need.
absolutely nobody plays on apple hardware. specially not the people that are into gaming enough to write an emulator. no matter how much you personally want to believe the opposite.
---
apple is bullish on metal vs vulkan because they want to lock in apps. and they have the upper hand because by not implementing vulkan, they force everyone to chose between the money on IOS or everything else. it's not a technical decision.
middle ware provide only the minimum common denominator, or expensive translation functions, it is not even close to providing the flexibility and speed modern emulators need.
absolutely nobody plays on apple hardware. specially not the people that are into gaming enough to write an emulator. no matter how much you personally want to believe the opposite.
Yes, in game developers forums and magazine articles like Gamedev, IGDA, Gamasutra, EDGE, MCV Develop, MakingGames, GDC talks, Gamasutra, the long gone Flipcode, demoscene discussion forums, the media meetings at many Game Design schools.
Usually I only find this anti-Apple argumentation in pro FOSS forums.
Usually I only find this anti-Apple argumentation in pro FOSS forums.
Metal is pretty nice, to be honest, with MSL being a real treat. And it is not too extra for a company with its custom GPU architecture to have its API too.
I disagree with that. macOS is basically BSD and it’s great for Dev. Most of the devs I work with use it.
Thats a strawman - the poster didnt say macOS is bad for development, just that no one in the PCSX2 project uses it.
You have to define what kind of developers you're talking about.
Do they work with graphics? OSX doesn't really have many native games running on it. So clearly there's a whole group of developers who aren't Mac first.
Like OSX is enjoyed by a lot of developers because it's similar to Linux.
However Apple deprecated openGL, aren't using Vulkan but have their own thing called Metal. So that makes it quite OSX specific.
Edit:
Looks like someone is working on it: https://github.com/PCSX2/pcsx2/issues/18
Do they work with graphics? OSX doesn't really have many native games running on it. So clearly there's a whole group of developers who aren't Mac first.
Like OSX is enjoyed by a lot of developers because it's similar to Linux.
However Apple deprecated openGL, aren't using Vulkan but have their own thing called Metal. So that makes it quite OSX specific.
Edit:
Looks like someone is working on it: https://github.com/PCSX2/pcsx2/issues/18
Apple ditched OpenGL and Vulkan for their own exclusive 3D graphics API. They're a terrible platform to develop for.
Apple ditched OpenGL for their own exclusive 3D graphics API that they had released in production before Vulkan was even announced.
That they don't bother with supporting Vulkan is incredibly frustrating for me personally, but not even remotely surprising given Apple's mode of business.
That they don't bother with supporting Vulkan is incredibly frustrating for me personally, but not even remotely surprising given Apple's mode of business.
Does MoltenVK not do what you want?
For reference:
"MoltenVK is a Vulkan Portability implementation. It layers a subset of the high-performance, industry-standard Vulkan graphics and compute API over Apple's Metal graphics framework, enabling Vulkan applications to run on iOS and macOS." [1]
[0] https://moltengl.com/moltenvk/
[1] https://github.com/KhronosGroup/MoltenVK
"MoltenVK is a Vulkan Portability implementation. It layers a subset of the high-performance, industry-standard Vulkan graphics and compute API over Apple's Metal graphics framework, enabling Vulkan applications to run on iOS and macOS." [1]
[0] https://moltengl.com/moltenvk/
[1] https://github.com/KhronosGroup/MoltenVK
All major middleware already does Metal, even non gaming stuff like Flutter.
Most emulators don't use middleware, because it doesn't afford them anywhere near enough flexibility or performance.
As anyone from Flipcode and Gamedevnet days knows, middleware can be as thin as couple of function pointers with shared libraries loaded on demand for the desired 3D API.
The approach taken by AAA game engines, although nowadays it looks more like a bunch of abstract classes/interfaces, depending on the language.
When you look into a game engine, typically 3D API abstractions are like 10% of the whole codebase.
The approach taken by AAA game engines, although nowadays it looks more like a bunch of abstract classes/interfaces, depending on the language.
When you look into a game engine, typically 3D API abstractions are like 10% of the whole codebase.
The way some emulator use the gpu can be quite different from the way pc games use it.
You can look at this article: https://dolphin-emu.org/blog/2017/07/30/ubershaders/ for an example how console graphics programming differ.
Middleware designed for games don't allow nearly enough flexibility to handle all the possible edge case that can arise. Console gpu (and graphics api) and computer gpu don't map one-to-one and they need all the feature and support from the underlying api that they can get for replicating the console way of doing things, supporting a new graphics backend is a lot of work for this reason. middleware try to abstract common pattern and flows, but every console is quite unique (in some way) middleware are not build for that and often are (a form of) a lowest common denominator for graphics api. Which is fine... for games.
edit: some clarification
You can look at this article: https://dolphin-emu.org/blog/2017/07/30/ubershaders/ for an example how console graphics programming differ.
Middleware designed for games don't allow nearly enough flexibility to handle all the possible edge case that can arise. Console gpu (and graphics api) and computer gpu don't map one-to-one and they need all the feature and support from the underlying api that they can get for replicating the console way of doing things, supporting a new graphics backend is a lot of work for this reason. middleware try to abstract common pattern and flows, but every console is quite unique (in some way) middleware are not build for that and often are (a form of) a lowest common denominator for graphics api. Which is fine... for games.
edit: some clarification
That doesn't forbade loading shared libraries as function pointers though.
Even if you stay, lets say OpenGL only, there are multiple execution paths with driver and graphics card specific code paths.
3D libraries like OpenGL/Vulkan are only portable up to a certain extent.
When you are coding at the ultimate performance level, you are also going into that rabbit hole of graphic card specific code paths and driver specific extensions.
So, it is hardly different than having your own plugable abstraction layer.
Even if you stay, lets say OpenGL only, there are multiple execution paths with driver and graphics card specific code paths.
3D libraries like OpenGL/Vulkan are only portable up to a certain extent.
When you are coding at the ultimate performance level, you are also going into that rabbit hole of graphic card specific code paths and driver specific extensions.
So, it is hardly different than having your own plugable abstraction layer.
If its so trivial, I'm guessing the developers would welcome patches.
Nowhere did I used the word trivial.
I wouldn't mind to contribute if paid accordingly.
I wouldn't mind to contribute if paid accordingly.
Flutter only just did that the other day and it's because iOS is a huge part of their pitch as a cross platform framework.
Which doesn't invalidate the point that anyone that cares has already done the work.
...if you're writing cross-platform games. FTFY
OP is literally asking why PCSX2 isn't cross-platform.
> if you're writing cross-platform games and not using one of the established game engines that wrap OpenGL/Metal/Vulkan
FTFY
FTFY
Even if you're developing with a game engine, you'll soon have to write your own shaders or at least deal with their bugs. And for that, you'll need your users' hardware (there are no nVidia macs anymore), youre users' driver (which is predominantely Windows) and the ability to debug it.
Mac just doesn't make sense for this use-case beyond "I want an Apple logo!". Most people buy a tool to solve a problem, not hammer the problem to fit a brand.
Mac just doesn't make sense for this use-case beyond "I want an Apple logo!". Most people buy a tool to solve a problem, not hammer the problem to fit a brand.
Same applies even if using something like OpenGL, Vulkan, which is why browsers black list GPUs.
Macs tend to lack decent GPUs, and Apple’s approach to backwards compatibility/industry standards (removing 32bit support and with it half of the Mac Steam library, and deprecating OpenGL) is hardly encouraging people to support the platform when it comes to anything gaming-related.
> Macs tend to lack decent GPUs
In 2012, I played through the entirety of Persona 4 in PCSX2 on a Macbook Air with an Intel HD Graphics 4000.
I was using Bootcamp (even back then when it was more current, getting the native Mac version to actually run was a PITA), but clearly the hardware is sufficient. Persona 4 is among the easier games to emulate IIRC, but I'd expect that in 2020 both the hardware and software would be more capable.
In 2012, I played through the entirety of Persona 4 in PCSX2 on a Macbook Air with an Intel HD Graphics 4000.
I was using Bootcamp (even back then when it was more current, getting the native Mac version to actually run was a PITA), but clearly the hardware is sufficient. Persona 4 is among the easier games to emulate IIRC, but I'd expect that in 2020 both the hardware and software would be more capable.
My 2014 MacBook Pro with Intel graphics can play lots of Unity games just fine, including Kerbal Space Program. Can't crank the graphics all the way up on all of them (can on some!) but it's fine. Minecraft's good, maxed out. Any older games, of course. Most of the new wave of Baldur's Gate-alikes and sequels, if I don't max out the pretty, run fine. And that's on 6-year-old Intel graphics. Definitely no problem with PS2/N64 emulation or earlier.
Only reason I do almost zero gaming on it these days is that they killed 32-bit support, and with it most of my library.
Only reason I do almost zero gaming on it these days is that they killed 32-bit support, and with it most of my library.
> Macs tend to lack decent GPU
Are you saying the majority of the emulation calculation nowadays are done in a gpgpu fashion in that emulator? For if that's the case, it would be insanely cool.
Are you saying the majority of the emulation calculation nowadays are done in a gpgpu fashion in that emulator? For if that's the case, it would be insanely cool.
No, it's more that the consoles they're emulating have GPUs, so they emulate the GPUs with the computers GPU.
So it wouldn't be possible to play PS2 games on my MacBook because it has an integrated Intel Iris Graphics GPU?
It would be possible. An Intel Iris Graphics GPU is good enough for a PS2 emulator.
Probably because there were no contributor interested in porting it to macOS.
There is some activity on https://github.com/PCSX2/pcsx2/issues/18 , it seems the biggest issue is that the PCSX2 JIT is 32bit only.
See https://github.com/PCSX2/pcsx2/issues/18
Looks like there's a working build again.
Anyone manage to build a binary from that tree? I'd be interested to try it.
PCSX2's JIT is 32bit only, so that's probably one reason at least more recently.
Is still Mac a relevant platform for gaming?
You can try run it in a virtual machine
You can try run it in a virtual machine
for indie games yup... been rocking mostly indie, rogue like, single player , 2D type stuff. 2013 mac air still going strong!! 500+ hours of darkest dungeon, slay the spire, isaac... serious bang for buck getting hundreds of hours from 3 games totaling like $60 dollars
Even with Catalina, or are you on an older OS?
Catalina just seems to have killed an inordinate amount of stuff...
Catalina just seems to have killed an inordinate amount of stuff...
Can confirm. Most of what ran well on my older MacBook with Intel graphics were indie games and older games, and those are the same ones hit hardest by the Bitpocalypse. I went from something like 150-200 games on Steam that'd run natively on my MacBook, to almost none.
I always wondered why most emulators keep OpenGL/DirectX as renderers instead of porting to Vulkan, I imagine because that would be an insanely tall task to tackle?
Vulkan is also unpleasant to use directly.
If WebGPU takes off, I'd bet that becomes the common API everyone codes against, because it will be everywhere and its a better developer experience.
You can cover most users with OpenGL + DirectX, so it's good to keep them. Vulkan is more rare. Also making software is slow, Vulkan is a new API.
Emulators with Vulkan include RPCS3, Dolphin, Flycast, Yuzu, PPSSPP, Xenia...
Nice, I wasn't aware of those using Vulkan, especially Dolphin. Thanks for pointing out.
If your programmers all exclusively have experience in DirectX/OpenGL, you're likely to stick with what you 100% know works and will be fastest for your team.
Easy, because nobody has written a Vulkan backend yet.
I would expect those emulators would be happy about patches for that.