In this release, we’re updating the engine from SDL to SDL2, and there are many optimizations to go along with it. Aside from the optimizations, SDL2 is also the stepping stone to ports. We have Linux compiling and playable; it just needs some testing.

Moreover, there is now a(n experimental) multithreading option in the game settings that makes the game even faster!

We also have some new individual tree graphics, and an update to grass ramps as well.

This has been mostly the hard work of Putnam! Meanwhile I’ve started up on adventure mode - the long work of updating menus and adding audio has begun! Hopefully we’ll have some progress to show their soon, as we continue updating fortress mode as well.

  • Yes, would be cool to get some technical overview on how they do it. Maybe a lengthy blog post or something.

    Rendering can be multi-threaded if you do it grounds up and use a rendering API made for it such as Vulkan or DX12. I used Vulkan a bit and you can create command-buffers from threads, and assemble them into your queue then. So you could have one thread creating the command buffer to draw all static meshes, and another one doing it for the particle system. And there is the “Async Compute” that allows the GPU to do compute shader tasks while CPU is busy building draw commands etc. I don’t know enough to tell you details as my own work with Vulkan is very basic. But the in-house engine at my workplace uses those techniques to multithread.

    There are systems that can run in parallel to each other. The sound system often needs to be their own threads. Low priority tasks such as wayfinding for NPCs. They don’t need to recalculate their paths in a tight loop every frame, they “interpolate” to the next waypoint in between.

    Parallel stuff is so dang hard to get correct and actually gather speed. Kudos to you that you are doing that. May your data access never be a race condition. :)