I made a small game prototype when I encountered a simple question: "How would an exploration game with no collisions or boundaries look like?"

The prototype has no actual gameplay. Instead, you fly around, and interestingly looking objects manifest themselves as you navigate infinitely (Perlin mapped looping) space. Another thing you can do is to enter a bright light that would drop you into a "secret" world where you'd have to finish a puzzle to acquire some resource or a key.


zpl.texed is a cross-platform stack-based image generation tool suitable for prototyping textures with pixel art aesthetics. It offers a suite of tools to generate/blend/modify stacked layers and also provides an ability to export bespoke textures into PNG files or packed C header files (a header containing an array of bytes and various metadata).


was a small passion project of mine to build a minimalist retro 3D game engine with a minimum amount of dependencies and a reliance on old Windows API. In fact, the oldest build was compiled under VC++6! However, over time I have upgraded the project to the latest VS toolchain, reworked it to compile for x86_64 arch, and modernized lots of code.

The project is currently in maintenance mode; you can reach it at: https://zaklaus.itch.io/neon-86. GitHub link: https://github.com/zpl-zak/NEON86

Here's also the only tutorial I wrote for the project on how to playback 3D animations: http://zakto.pw/neon/anim_models/index.html

Fully scriptable AI task scheduling


Despite the official Linux NodeJS 18.12 build no longer running on an older distro such as CentOS 7, with some effort, you can still build it yourself and run the binary just fine. You do have to rebuild any deps that rely on native modules manually; however, since there's a considerable chance the pre-built natives you fetch won't run with your custom-built Node binary at all (due to GLIBC mismatch)


The dragon model is finally imported; I had to split it into two meshes due to the I3D index limit being reached.

NPCs can now follow you in !

Dominik Madarasz shared 1 year, 1 month ago
Dominik Madarasz shared 1 year, 1 month ago
Dominik Madarasz shared 1 year, 1 month ago

How to rename imported DLL library

This is a small tutorial on how to rename imported DLLs. This was once required as we've stumbled upon an issue where our Steam SDK loaded module would clash with game's version. To ensure both our launcher and the game can co-exist without having to deal with DLL collisions, we rename some DLLs we import ourselves so they can exist within their own space.

Since many DLLs are linked at load-time (The launcher compiles against their import static library), we need to rebuild the library so that it queries for our newly renamed DLL.

  1. Dump a DEF file from the original DLL

Load into your developer command prompt and run: dumpbin /exports steam_api64.dll > fw_steam_api64.def

This will dump the entire exports table of our DLL into a new DEF file.

  1. Clean up the DEF file

Since this is a dump, we need to strip it of any debug stats or unnecessary information that is not parsable by the lib tool. You can check out steam_api64.def to see how the DEF file should be constructed. Make a note of the LIBRARY entry, this is where we type in the name of our newly renamed DLL.

  1. Create the import library

Now that our DEF file is ready, we can ask libtool to generate a new static import library. Run: lib /machine:X64 /def:fw_steam_api64.def

This will generate a pair of .lib and .exp files.

  1. Link against the newly generated libs

Self-explanatory, your code should always refer to a new module name now.