I’ve been slowly porting Rainboids to C++ using SDL for input/window management and audio, while rendering using OpenGL. My main goal is to have unfettered access to a machine’s gpu/cpu compute resources to support more on-screen objects, particle effects, etc.
Unfortunately, the sandboxed browser environment throttles JavaScript apps for security, so I was always hitting what felt like an artificially imposed limit in the browser. I made some initial stabs at rendering on the browser using WebGL, but I wasn’t able to get that working easily with my existing code.
The cleanest approach would be to start from scratch, build with WebGL from the ground up, then port all the game logic. Nevertheless, I believe the sandbox throttling would still apply even within a WebGL context, so I’m not sure WebGL would help performance that much.
Using WebGL would probably free up some CPU, which might help me side-step the throttling somewhat.
Since I would have to start from scratch anyways, I thought it made sense to remake the game in a language that could be compiled to web assembly + WebGL, but also compiled for other targets, so it could be run natively on machines without having to worry about the browser’s sandboxing. Hence, I’m making an attempt with C++/SDL using OpenGL.
Originally, I was rendering in 2d using SDL_draw, but I wanted to render everything using opengl / 3d geometry for performance reasons: SDL_Draw is CPU compute-heavy; 3d wireframe calculations for asteroids rendering is also CPU-compute heavy; all of these calculations can be parallelized and accelerated on the GPU because it’s matrix math. (this is also why I wanted to use WebGL)
I was initially trying to get this working using the Zig programming language and the Mach game engine (a native Zig game engine) but that stuff is pretty bleeding edge and lacks the same level of documentation and maturity as C++/SDL. I got a basic port working with C++/SDL – not a clean port, but it’s rendering geometry in 3d.
A lot more work is needed in this direction. It currently implements FXAA and SMAA (on top of 4x MSAA) for smoothing – Fast Approximate Anti-Aliasing and Subpixel Morphological Anti-Aliasing. The user can configure which AA algorithms to use for performance (FXAA is faster than SMAA).
I am simultaneously trying to get another build working using the Vulkan API, which is a lower-level cross-platform graphics API (compared to OpenGL). Vulkan is built for performance and more complex than OpenGL. A notable difference is that Vulkan precompiles shaders, whereas OpenGL compiles them on the fly, meaning using Vulkan further reduces CPU usage.
In the meanwhile, I’m continuing to iterate over the JavaScript version of the game to refine the gameplay itself. I’ve fixed bugs (like bullet homing and the shop menu popping up), and added or updated the following:
- added player lives and player respawning,
- updated HUD rendering,
- added new types of drops (money and health drops),
- added upgrades for money/health drop rates,
- added debug mode and cheat codes,
- re-tuning the enemy spawning system,
I’ll be working on a player leveling system, adding skill points, and fine-tuning gameplay balance and performance next.
Leave a Reply