Comment by Jweb_Guru | Hacker News Reader

Comment by Jweb_Guru | Hacker News Reader

Parent Full thread

The project is using wgpu-rs (and has actually contributed quite a bit to it). Can highly recommend it for other projects, it really is the way to go if you want to be portable but don't want to sacrifice a ton of performance (as using OpenGL does nowadays). Using wgpu generally means you're getting a fast subset of most of the modern APIs, at the cost of some control and performance in certain cases (though not too much performance--we'd like to shrink that even further), so for us it's the way to go.

The other two choices people usually bring up are OpenGL and Vulkan. The project was originally using OpenGL and was quite limited as a result; theoretically, you can do better by abandoning portable versions of OpenGL, but many modern OpenGL drivers are incredibly poor (particularly on Windows), and a lot of machines support, e.g., DirectX 11 or Metal but not a version of OpenGL with the same feature set. Going with straight Vulkan means you're either going through a (slow) translation layer on many older machines (and Macs), or giving up on them entirely. Vulkan is also incredibly hard to use correctly if you're using it directly and want to be portable across GPUs; the spec has a lot of edge cases that are quite unclear even to experts, and often requires consulting with driver developers to figure out exactly how they were interpreted (to be fair, this has become less of a problem over time, but it's still an issue for corner cases in the spec).

How do you implement all the things the game engine gives you for free? Physics, camera, scene management, lighting, colliders, shaders, navmesh, etc. It seems like an impossible feat to implement all this yourself PLUS build a game on top. Wouldn't just building the game itself be a 2000-20,000 hour project? And I imagine building the game engine would be an order of magnitude more complex, if not more time

It's a lot of work, but there are a lot of tutorials and readymade libraries out there to get you started (which you may end up ripping out if the project grows sufficiently that it's worth doing custom stuff, but most projects never get to that point). It's definitely nowhere near as difficult as it seems like it would be to get a basic game up and running (though it's still very hard)--you're not going to come close to competing with something like UE5, but if you're doing a game from scratch that probably isn't your goal in the first place.

For FOSS in particular, it helps that people are willing to devote massive amounts of free time to programming when the outcome is a video game--it's why a lot of people got into computer science in the first place, after all.

> Using wgpu generally means you're getting a fast subset of most of the modern APIs, at the cost of some control and performance in certain cases (though not too much performance--we'd like to shrink that even further), so for us it's the way to go.

Another cost is that you lose support for older GPUs.

This is an overstated problem, in our experience. Most older GPUs that don't support Vulkan, DirectX 12, or Metal, but would be capable of running the game in the first place, support DirectX 11, which is one of the wgpu backends already. An OpenGL fallback on Linux is coming and will help address the remaining cases, but it won't perform well at all (and we're okay with that, since the percentage of our users who actually need it is quite small; Vulkan support on Linux has gotten really good, probably thanks to Valve's efforts).

Reply on news.ycombinator.com