Rainboids Dev Diary – C++ and SDL Attempt

I’ve been attempting to port 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.

Running an effects-heavy game efficiently on a browser is difficult. 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. Using WebGL would probably free up some CPU currently used for drawing primitives.

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. At first I was using OpenGL, but now I am trying out the Vulkan API.

Initially, 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.

Update

This port has been put on hold and I am trying to create a complete version of the game purely in JavaScript for the browser. I may come back to trying to create a compiled-language port using a lower-level graphics API in the future.

· ·

Comments

Leave a Reply

Check also

View Archive [ -> ]

Discover more from afeique.com

Subscribe now to keep reading and get access to the full archive.

Continue reading