Deprecation of OpenGL and OpenCL (2018)
developer.apple.com
developer.apple.com
Even more hilariously, I’ve heard anecdotes that the quality of the OpenGL drivers for M1 are higher than expected and is pretty heavily optimized!
All that sneering at Macs as "toy" computers is ridiculous. It's the worst gaming platform in the world. Linux is better.
I use a Mac because I need to get work done.
M1 Macs can run the extensive iOS game library. While you won't find many AAA Windows or console games on it, there is no lack of entertainment on the platform.
I personally transitioned from Windows -> Linux -> MacOS, and each switch correlated exactly with how much I was playing videogames at that time. I don't play games anymore which is why I'm perfectly content using a mac. If I wanted to play games again I would go back to linux, or all the way back to windows.
I don't remember their name or know whether they're still around, but I believe that at least on Intel Macs, Wine/Crossover have already claimed that niche, and it seems like there are some promising efforts to go on on Apple Silicon (with a combination of Wine system call translation/reimplementation and Rosetta 2 CPU architecture emulation).
They had some really good games (for the time. They would be a bit old-fashioned, these days). I liked the Marathon games (I think they open-sourced them, and you can actually run them, nowadays).
I know that they started developing Halo as a Mac-only game, but didn't realize that they had shipped it, as such, before being borged.
Personally, I don't endorse any vendor lock-in. If I ever make another game, it will target Steam and whatever Unity or the engine of choice cross-compiles to, maybe Oculus and a few others.
Also mobile ended up being a disaster on multiple fronts. I truly feel that software development lost its magic around the time that iOS and Android forced everyone to use Objective-C and Java. Which also undermined web development because vendors stopped solving actual problems in the browser and passed the buck to frameworks. Now we have the perception that stuff like Electron is somehow bad, which is like saying that higher education or any other quest for a better future is bad. The glorification of ignorance has passed the point of believability.
And yes, I'm a bit saddened that I spent the most productive programming years of my life chasing a dream that didn't pan out. But, I also feel that the world is waking up out of whatever this malaise we've been in is. There's arguably more opportunity to earn a living making software now than ever before.
Just remember that the next recession starts right when you finish your software project, so embrace that idea and build it anyway.
I enjoyed trying to hunt down a bug only to discover that the BT chipset in circa-2015 Macs is defective.
But still, that's a lot of progress for a "toy" OS!
FWIW a new engine i'm tinkering on now and then[0][1] has an OpenGL renderer - and not even that fancy new "modern OpenGL" stuff, it is OpenGL 2 (though not out of any real practical reason, i just noticed at some point that after a couple of fixes it could run on the Athlon64+ATI X1950 Pro[2] i used back when i was in school and nowadays use as a 2000s retro PC and decided to just stick with it as a "lowest end" mode). I'm making it for the purpose of making games and my take is basically, if some platform supports OpenGL i'll support it, if not then whatever (though i'm not against using some compatibility layer as long as i can use it from Free Pascal at least).
[0] https://i.imgur.com/DBaqhMo.png
I guess that means we won't see any new GL versions above 4.1 (TBH: good riddance), but what's there now will probably work for a while.
I would expect though that their new GL-on-Metal thing is a bug-for-bug compatibility layer for existing applications, otherwise it wouldn't make much sense because new apps shouldn't use GL anyway.
So in 3.3-4.1 land, you get to do the exact same things you’d do in 4.3 land, but in more tedious ways programmatically, because the drivers and implementations decide how elegant you are able to make your code and abstractions. The commands that end up on the GPU are the exact same regardless but the developer experience is highly variable.
My point is GL versions do not delineate features nor performance enhancements past a certain point, they delineate periods of programmer happiness. It is solely up to the drivers, not the hardware, not the actual machinery, to determine this metric. GL, being a standard rather than an implementation, suffers for this. I happily await webgpu finalization.
In my personal opinion, 4.2 is like, halfway to 4.3
But sometimes it's more comfortable to go none of the way than half of the way, hence me targeting 4.0 in my most recent library.
That combined with the fact that VAO that came in version 3 is the last feature makes all threats to force you to update weak at best.
As hardware peaks you can stop worrying about new things and write software that never goes bad.
The wheel has not been rediscovered for a long time. Focus on the vehicle instead = bike.
In the end, those strategies will require more work from developers, and those developers become "locked" on apple. It's a shitty practice.
Even MS allows OpenGL and Vulkan on Windows.
It mentions many M1-related stuff so it's impossible that the page dates to 2018.
DX12 may be fine, I have no experience with it.
As an aside, Apple has been pretty good about adding support for WebGL 2.0 and WebGPU to Safari recently. I wonder if this will drive more people to build web apps instead of having to target Metal.
I have been getting into metal, but maybe I should be looking more into Vulcan
Also when WebGPU gets released later this year, it will be a subset of version 1.0 from Metal, Vulkan and DX 12.
If you want state of the art graphics on the Web, only via streaming like Unreal Pixel Streaming, GeForce Now or XBox Cloud.
https://chromium.googlesource.com/angle/angle/+/refs/heads/m...
If you're a gamedev, your engine should abstract all these away. If you're a gamedev, you should be using a commercial engine unless you have a John Carmack on staff.
OpenGL and Vulkan are the worst of all worlds and really only make sense on Linux or Android, which have nothing else.
There is no reason why I should have to use a different APIs to access the exact same graphics hardware depending on whether I'm running Windows, Linux or MacOS.
OpenGL and Vulkan work just fine.
It only took 20 years to have RenderDoc catch up to PIX, and still nothing comparable to DirectXTK or MetalKit in sight.
And in regards to game consoles even worse.
With big fat asterisks for the AMD OpenGL drivers on Windows :-P.
Just recently i read about someone trying Zinc (the OpenGL-on-Vulkan implementation) on AMD hardware under Windows is actually faster than AMD's own drivers (which is on line with what i've observed with my own code between AMD on Windows with AMD's drivers and AMD on Linux with Mesa with the latter being way faster than the former).
Regardless, i've switched back to Linux ever since i could run most of my games without needing Steam and Proton (wine-staging with DXVK and VKD3D-Proton - which works on regular Wine too - seems to work perfectly fine).
My only gripe is VRR under Gnome. I might try Sway out again.
Write your own game engine, it's fun. Other programmers aren't God.
Use OpenGL ES or Vulkan. Windows, Android, and Linux are really the only platforms that matter.
GNU/Linux cannot even get ports from AAA games using Android NDK or Stadia, and has to emulate Windows instead, that is how much it matters.
If supporting Metal means Mac matters, then supporting OpenGL means Linux matters. If Linux having no ports means it doesn't matter, then Mac having no ports means Mac doesn't matter. Either opinion is defensible, but at least be consistent.
You want consistency?
What about GNU/Linux not getting any of the OpenGL ES games from either Android or iOS from the last 10 years.
It's clear now you're just here fanboying for your favorite company, so I'll end it here and leave you alone with your thoughts, the only place where the Mac is considered a gaming platform.
Should I have explicitly mentioned game developers to make you happy?
We are talking about the desktop here, I am the first to admit defeat in UNIX having won the server room, at least until it doesn't get replaced by unikernels and serverless running in type 1 hypervisors.
My favorite companies for gaming are SEGA, Sony, Nintendo and Microsoft, see how you get it all wrong?
Enjoy Proton, don't let it crash too often.
If M1 Macs didn't support running iOS games, remaining Mac ports of games would overlap heavily with games that also have Linux ports (especially after apple killed off all older 32bit Unity titles)
So, at this point, I'd consider mac gaming (not iOS) to start circling Stadia levels outside of Indie games that swallowed the pain of mac port, with things like Valve SteamDeck causing more interest in gaming on Linux than ever.
> OpenGL already has a patina of “old tech” like C, but it will almost certainly still be in active use for various things a decade from now. [0]
[0]: https://mobile.twitter.com/id_aa_carmack/status/131388553587...
https://github.com/floooh/sokol
It has DX11, Metal, and OpenGL backends (with optional shader compilation tool from GLSL to each target), which is probably all you need to get cross-platform support for all desktop and mobile targets. Rewrote my OpenGL code to this, was a pretty nice experience. The subset of graphical features it exposes seems more than good enough for simple 2D games (probably enough for simple 3D ones also). Can't say more than that though, since I haven't seen a shipped 3D game on Steam using it yet.
Though what we ultimately need for the future is a Metal-like API that runs on all platforms (since from what I've heard from other graphics developers Metal's API design is quite nice and finds the right balance between low-level control and high-level usability). The experimental SDL_gpu development (https://gist.github.com/icculus/f731224bef3906e4c5e8cbed6f98...) strives to achieve this, although it's still in the early stages...