Rendering Tiny Glades With Entirely Too Much Ray Marching

There is lots of cool innovation happening in game tech still. Look at games like Noita, Dreams and Teardown. Or for an even more recent game, look at Tiny Glade. There’s a recent tech talk about it which is full of wizardry: ▶ this video There is also lots of cool tech happening at the more foundational levels in engines and frameworks, for example Epic’s Nanite/Lumen/MegaLights in UE5.

As you can tell, I'm patient :) A very important quality for any ray tracing enthusiast lol The ability to do irregular sampling, efficient shadow computation (every flavour of shadow mapping is terrible!) and global illumination is already making its way into games, and path tracing has been the algorithm of choice in offline rendering (my profession since 2010) for quite a while already. Making a flexible rasterisation-based renderer is a huge engineering undertaking, see e.g. Unreal Engine. With the relentless march of processing power, and finally having hardware acceleration as rasterisation has enjoyed for decades, it's going to be possible for much smaller teams to deliver realistic and creative (see e.g. Dreams[0]) visuals with far less engineering effort. Some nice recent examples of this are Teardown[1] and Tiny Glade[2]. It's even more inevitable from today's point of view than it was back in the 90s :) [0] Dreams: link [1] Teardown: link [2] Tiny Glade: ▶ this video

TinyGlade's (co)developer said he's very satisfied with Rust and the crate ecosystem. They've used Bevy's ECS: ▶ this video Using individual components instead of the whole big framework isn't necessarily a failure. The components are designed to be usable independently. TinyGlade project started a few years ago, when Bevy's rendering was even more basic. The art style is central to TinyGlade's appeal, so it's not surprising they've built a custom renderer.

> Cell required Assembly programming Demoscene skill level to make good use of them, there was a C sdk, but really you wanted to write Assembly, and relatively tricky Assembly at it. > It is one of the reasons why Playstation 3 is the less celebrated one, and the console generation where XBox was able to pull ahead. In retrospect, Cell was a great architecture. In typical Sony fashion it was simply a few years too early. At the time games were single-threaded and many console games still expected CPU and GPU to be in sync. On the PS2, the difference between using the vector accelerator or not was 1.4x – many developers never bothered. But on the PS3 this was simply not an option, as the performance difference was 6x (!). The big issue at the time was dev tooling. Most existing engines had no support for dispatching jobs or any form of pipelining. Adding that required redesigning the engine from the ground up. On top of that the dispatcher/manager and the jobs use two different µarchs. Obviously, game and engine developers at the time hated cell with a passion.[1] But even on the PC and Xbox, frequency scaling ended with the Pentium 4. Multi-core CPUs became mainstream. As CPUs stalled, most of the performance increase on PCs came from GPUs, that had moved from a fixed-function pipeline to shaders. Slowly, even PC games had to do the bulk of their work in jobs dispatched across multiple cores. Engines that had adapted to Cell got a massive head start. Today, the very textbook