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?
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.
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.
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.
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.
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.
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.
"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]
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.
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.
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'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.
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.
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.
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.
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.
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
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.
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.
