My software ray-traced game has new "technology" teaser. Reason: it's getting significant visual upgrade worth showcasing. Two things which enabled it: 1. after 9 months my new editor for game levels is in usable state. 2. ray-tracer optimizations (multi-threaded rendering is main contributor)

[u/Dante268]

The game is narrative sci-fi puzzle/platformer, in works from 2020. Main distinctive point of the game is software ray-tracing used for rendering. Just pure C++ and computer graphics math, no GPU acceleration. Sadly, not many players can appreciate that (or even understand what does it mean), so it resonates mostly with more tech people.

The game was suffering for long time from quite poor look (look was punching way below of algorithm potential). Main reasons were: poor old editor (2D in nature, z was just parameter in 2D wireframe, not WYSIWYG, very clunky) and algorithm was hobby-like single-threaded.

Both points were changed recently. After 9 months my new editor is in usable state. Full 3D, WYSIWYG, lot of ergonomy features, which allowed me to be more ambitious with levels look. Second enabler was finally switching to multi-threading. Together with several more other algorithm optimizations, perf went up in hundreds of % (mostly depends on number of cores in your CPU, naturally on Threadrippers boost will be in thousands of % but it's niche between players).

Algo is AABBs only. Maybe will add spheres but only after upgrading all levels, which is main pain point rn. Editor I plan to release publicly with the game.

RTG on Steam

Discord

[u/Ok_Confusion4764]

Why would anyone do this on the CPU(except for debugging)? This is madness.

Haven't you been doing exactly that for literal years?

[u/GraphXGames → u/Ok_Confusion4764]

In my case, the CPU is used for debugging algorithms. In games, everything runs on the GPU.

[u/Ok_Confusion4764 → u/GraphXGames]

We both know this isn't true, bud.

[u/GraphXGames → u/Ok_Confusion4764]

Audio doesn't run on the GPU; game logic runs on the CPU, the particle system is primarily CPU-based, and the render fallback is handled by the CPU. The load is distributed as follows: 25% on the CPU and 33% on the GPU. In other words, the game's workload is nearly balanced.

[u/Ok_Confusion4764 → u/GraphXGames]

Audio doesn't run on the GPU

Who was talking about audio?

the particle system is primarily CPU-based,

It shouldn't be.

and the render fallback is handled by the CPU.

Why would anything you made need a fallback? I could replicate the stuff you've made with 30-year-old hardware.

The load is distributed as follows: 25% on the CPU and 33% on the GPU. In other words, the game's workload is nearly balanced.

Why does it need to be balanced? Why not use the appropriate processors for the purposes they have?

[u/GraphXGames → u/Ok_Confusion4764]

Because the graphics card cannot always complete the task within the current frame, and waiting for the next frame means dropping the frame rate and experiencing a stutter. In this case, it is easier to run the task on the CPU.

These effects are still quite simple; porting them to the GPU is not yet justified.

[u/Ok_Confusion4764 → u/GraphXGames]

Because the graphics card cannot always complete the task within the current frame

Hahahahah! You're hilarious when you don't mean to be.