Wow, this takes me back of making my own software renderer and game engine as a teen in the 90s. Then OpenGL came out and fixed pipelines and some of the cool magic of doing anything with pixels disappeared (until pixel shaders came back). One cool rendering technique you don't see much today is voxel graphics.

> Well, it would work, but the result would look terrible because pixel scale is no longer consistent.

This is my complaint with a lot of "graphical enhancement" mods for games like Deus Ex.

Unless they touch everything, the inconsistent level of detail is worse than consistently low-res meshes/textures.

Every time I think about graphics programming, I think about how we did it in the mid 90s when I was in high school messing around with exactly these things. XOR operations to drive animations, writing directly to memory, etc. (Clearly I do backend stuff now...)

This is a cool project and I really like the author's technical and aesthetic choices of how to limit themselves.

But what really stood out to me is this line.

> a linear frame buffer where each pixel was represented by a single byte indexing into a palette of 256 colors.

Of course this is nothing new, but it just really struck me because I've been working on a blog post about texture representation on modern consoles and it is crazy how complex it has gotten: texture tiles, block compression, non-linear texel ordering (e.g. Morton order), ...

A great writeup of excellent work!

The flight simulator / magic carpet easter egg in Microsoft Excel 97 used that same shaded-colormap palette trick, plus some dithering:

https://rezmason.github.io/excel_97_egg https://rezmason.github.io/excel_97_egg/about.html

I'm impressed by your sprite pipeline and gibs animations. Your attention to detail and navigation of constraints have really paid off, I can't wait to play this sometime

Cool project! How hard was it to get the z levels (height) ??

I made a very similar project [0] in C 2 years ago, a chunked ray caster that could handle multiple height levels. Was one of my first C projects, pretty crappy but was fun.

Anyone have any ideas how to make it more memory efficient?

It’s full of bugs was just a for fun project

[0] - https://github.com/con-dog/chunked-z-level-raycaster/blob/ma...

> The generation pipeline takes several inputs: > a heightmap that defines the surface relief > this is actually just used to generate the normal map, which is then used to bake in simple lighting and shadows

I don't think someone used this approach in 1993. Textures were drawn by hand. But I think it's still fine to use such modern way of generating textures, since it may produce better-looking result.

Everything is perfect here. The hero, the graphics, the title... <3

Nice, i've used similar approach for the lighting in Post Apocalyptic Petra[0] though i did use per-pixel LUT offset calculation[1] because it uses a generic 3D triangle rasterizer (the levels are based on grids like in Tomb Raider but they're rendered as triangles). Later i added sprite support for another gamejam but i never ended up finishing it and the sprite support is very rudimentary (and unoptimized - i just noticed i'm doing the LUT lookup for every pixel when drawing shaded sprites which isn't necessary).

I did write a tool for generating the sprites from 3D models though[2]. It uses plain old OpenGL 1.1 to draw the sprite and grabs the framebuffer directly. It is drawn fullbright so i can paint the lighting directly on the sprite's texture (using a Krita plugin i wrote[3][4] - the model is something i threw together with Blender's default generated UV since i didn't care for the details).

I wonder if doing some sort of postprocessing (after rendering with with shading) like you do with your game would help with the finer details since i also found that rendering from 3D models to sprites creates very "mushy" results most of the time because of all the details getting lost. I notice the colors also become more saturated after postprocessing in your examples, is this after it finds the closest color in the palette or the result of the postprocess? I'd like to keep the overall hue+saturation of the model so maybe doing post-processing on a grayscale render to shade the shadows/dark areas but keep highlights as-is and then multiplying that with the fullbright image would produce results that wont shift the saturation.

[0] https://bad-sector.itch.io/post-apocalyptic-petra

[1] https://codeberg.org/badsector/PetraEngine/src/commit/14ca16...

[2] http://runtimeterror.com/pages/iv/images/95ddebc51e4dfa8a5af...

[3] http://runtimeterror.com/tools/kritaview3d/

[4] http://runtimeterror.com/pages/iv/images/535f0e09e590d8a1731...

Consider a premium, boxed version. I would buy it. And I think a lot other would. Maybe try a kickstarter to see how many are interested?