Magnum  is a favorite of mine for creating portable OpenGL C++ applications. It also has support for compiling to WebAssembly  and using WebGL2.
0 - https://magnum.graphics
1 - https://magnum.graphics/showcase/picking/
0 - https://github.com/KhronosGroup/MoltenVK
1 - https://blog.magnum.graphics/announcements/2018.10/
It worked pretty OK-ish in my project running OpenGL game on Windows Phone 8. I was using Microsoft's fork .
Another alternative is GLOVE , which is a software OpenGL on top of Vulkan.
Another interesting project is WebGPU  which targets to provide Vulkan-like APIs across various platforms in browsers.
As it's offshoot which is not quite related is GFX-rs, which became a cross-platform Rust library providing low level graphics API (HAL layer).
looking forward seeing ANGLE getting Metal backend, which been just a promise so far.
Yeah, it'd be nice if macOS supported OpenGL 4.6 and even better if Apple wasn't braindead enough to deprecate OpenGL instead of fixing one of the worst implementations (and still the only that has the core/compatibility divide that makes matters even worse), but even with all that taken into account, OpenGL on macOS is still capable enough for almost every game bar the more high end ones.
Dude, you made me think that I've missed the Linux release of the Fortnite!
PSGL was largely ignored by everyone that matters in the game industry and eventually dropped.
"At one point, Sony was asking developers whether they would be interested in having PSGL conform to the OpenGL ES 2.0 specs (link here). This has unfortunately never happened however, as developers seem to have mostly preferred to go with libGCM as their main graphics API of choice on PS3. This has meant that the development environment has started becoming more libGCM-centric over the years with PSGL eventually becoming a second-class citizen – in fact, new features like 3D stereo mode is not even possible unless you are using libGCM directly."
Just like everyone raves around Switch having Vulkan support, when most studios are using Unreal, Unity and the main 3D API, NVN.
As rule of thumb, instead of believing what gets posted on FOSS friendly web sites regarding 3D APIs, GDC Vault, Making Games, IGDA, Connect, EDGE, Retro Gamer, and AAA studio dev blogs are a much better source of information.
Wouldn't the credit belong to Magnum rather that C++ plus OpenGL, given the tremendous amount of work that goes into making things seem portable to the end user of the library?
Needs some optimisation done on that part. ;)
"OpenTTD is a business simulation game in which players try to earn money via transporting passengers and freight by road, rail, water and air. It is an open-source remake and expansion of the 1995 Chris Sawyer video game Transport Tycoon Deluxe."
EDIT: the original, Transport Tycoon.
What occurred to me was "Test to Destruction".
Uncaught RuntimeError: float unrepresentable in integer range
Network stuff, as mentioned in other comments, is futzy because of the limitations of running in a browser environment. A surprising amount of network code "works," in the sense that it compiles and runs translated to web sockets. (Great work from the WebAssembly and Emscripten community.) But, you know, web sockets.
pthreads support landed in Chrome recently: https://developers.google.com/web/updates/2018/10/wasm-threa...
Pipes, select, and unix domain sockets aren't really supported (afaik).
You want the trains from your home country? They are available, and probably up to date to the current year. Just download them from within the game, enable them, and start a new game.
It makes a huge difference between enjoyment and suffering in games.
TT on my 486 took time to generate a map, (TTD is basically the same code I believe). Open TTD when you've cranked up the map size takes time too.
Perhaps you were playing TTD on a relatively powerful pc?
However it's not trivial to get it working at the moment, will hopefully soon come back to this project and finish it :D
The biggest issue is that WebRTC connections do not allow you to send raw data over TCP or UDP.
That being said, it shouldn't be too difficult to just create a WebSocket server that translates between the native network protocol and HTTP WebSockets.
I'd assume that webassembly would consume more but maybe difference is not significant?
OpenTTD isn't as efficient, but it's not that demanding either.
Power consumption is a product of cycles plus memory read/write operations.
Everything old is new again.
Yes it does not escape the sandbox, however triggering stack corruption of local variables opens the door to explore changing the behaviour of function calls, while getting some goodies in the process.
It remains to be seen how secure is WebAssembly at scale, when black hats start actually turning their sights into it.
"In 2013, Adobe open-sourced the Flash Runtime C++ Compiler as CrossBridge, and released it on the GitHub code hosting website"
I don't care, I used to enjoy playing with Flash, gave some sanity to the div/CSS soup pretending to be native UI controls.
All the following games are hardware accelerated on 2010-11 GPUs.
"Adobe Flash Stage 3D demo video by Frima Studio"
"Stage3D - The Demo of Porting Epics Unreal Engine to Flash"
"3D Gaming Powered by Adobe Flash Player"
"Flash Stage3D Demo "BIRTS" by SQUARE ENIX at ADC MEETUP"
For anyone curious how the 3D API actually looked like,