Easy Retro 3D Look With Voxel Displacement Renderer

Voxels are effectively like 3D pixels, and they form an integral part of what is commonly referred to as a ‘retro 3D’ look, with pixelated edges sharp enough to cut your retinas on. The problems with modeling a scene using voxels come in the form of creating the geometry and somehow making a physics engine work with voxels rather than conventional triangular (or quad) meshes.

The same scene in Blender (above) and in the voxel-based renderer (below). (Credit: Daniel Schroeder)
The same scene in Blender (above) and in the voxel-based renderer (below). (Credit: Daniel Schroeder)

The approach demonstrated by [Daniel Schroeder] comes in the form of a Voxel Displacement Renderer implemented in C++ and using the Vulkan API. Best part of it? It only requires standard meshes along with albedo and displacement maps.

These inputs are processed by the C++-based tools, which generate the voxels that should be rendered and their properties, while the GLSL-based shader handles the GPU-based rendering step. The pre-processing steps required make it a good idea to bake these resources rather than try to process it in real-time. With that done, [Daniel]’s demo was able to sustain a solid 100+ FPS on a Radeon RX 5700 XT GPU at 1440p, and 60+ FPS on a Steam Deck OLED.

In a second blog post [Daniel] goes through his motivations for this project, with it originally having been intended as a showpiece for his resume, but he can imagine it being integrated into a game engine.

There are still questions to be resolved, such as how to integrate this technique for in-scene characters and other dynamic elements (i.e. non-static scenery), but in terms of easing voxel-based rendering by supporting a standard mesh-based workflow it’s an intriguing demonstration.

Continue reading “Easy Retro 3D Look With Voxel Displacement Renderer”

Decompiling Sonic Runners

Usually, when you hear about games being decompiled and rebuilt, the games are often decades-old relics, loving and saved from the ravages of time. [MattKC] recently set out to decompile the 2015 game Sonic Runners.

The game was a 2D endless runner released on mobile platforms. Despite getting praise for the gameplay, it received mixed reviews for the pop-up ads and pay-to-play elements. A little over a year later, the game was discontinued. However, the game required a constant online connection, so once the servers were offline, it rendered the over five million downloads unplayable.

A team of developers worked to reverse engineer the server, and with a little bit of binary hacking, the client could be patched to connect to a community-hosted server instead. However, as phones with notched displays came out and suggestions for improvements stacked up, the community realized a new client would bring immense benefits. Compared to many decompilation projects, Sonic Runners was pretty easy as it uses Unity, which means most of the code is in C#. Unfortunately, the build of Unity used by the game is from 2012, meaning many of the tools designed for much later versions of Unity were inoperable.

However, one native code library called UnmanagedProcess was designed to confuse reverse engineering efforts. The library handled AES encryption and communication with the server. Luckily, the library was a later addition, and earlier versions of its functions still lingered in the C# code. Since an open source server already existed, it was trivial to validate the changes. Additionally, all the shaders were in OpenGL Shading Language (GLSL), which meant rewriting them in High-Level Shading Language (HLSL) and checking that they matched the original GLSL when building for Android.

Now the client has new game modes, no ads, and a proper offline mode. The community continues adding new features and refining the game, which is very satisfying. If you’re curious about reverse engineering, [Matthew Alt] can help you get started.

Continue reading “Decompiling Sonic Runners

GPU Programming For Easy & Fast Image Processing

If you ever need to manipulate images really fast, or just want to make some pretty fractals, [Reuben] has just what you need. He developed a neat command line tool to send code to a graphics card and generate images using pixel shaders. Opposed to making these images with a CPU, a GPU processes every pixel in parallel, making image processing much faster.

All the GPU coding is done by writing a bit of code in GLSL. [Reuben]’s command line utility takes that code, sends it to the graphics card, and returns the image calculated by the GPU. It’s very simple for to make pretty Mandebrolt set images and sine wave interference this way, but [Reuben]’s project can do much more than that. By sending an image to the GPU and performing a few operations, [Reuben] can do very fast edge detection and other algorithmic processing on pre-existing images.

So far, [Reuben] has tested his software with a few NVIDIA graphics cards under Windows and Linux, although it should work with any graphics card with pixel shaders.

Although [Reuben] is sending code to his GPU, it’s not quite on the level of the NVIDIA CUDA parallel computing platform; [Reuben] is only working with images. Cleverly written software could get around that, though. Still, even if [Reuben]’s project is only used for image processing, it’s still much faster than any CPU-bound method.

You can grab a copy of [Reuben]’s work over on GitHub.