Making Graphics Like it's 1993

If you want to play with software rendering, here's probably the shortest code that will get an ARGB8888 2D array from main memory to the screen efficiently for all platforms using SDL2 in C https://gist.github.com/CoryBloyd/6725bb78323bb1157ff8d4175d... you'll need to do the translation from a 320x200x8-bit palletized framebuffer to ARGB yourself ;)

If you want to get inspired by what can be done with palletized framebuffers check out http://www.effectgames.com/demos/canvascycle/ (click Show Options) and the GDC presentation by the artist https://youtu.be/aMcJ1Jvtef0

With that you can fire up https://github.com/mriale/PyDPainter for that classic Deluxe Paint IIe vibe. Or, https://www.aseprite.org/ for something more modern.

    int s = y*screenRect.w;
    
    for (int x = 0; x < screenRect.w; x++) {
       pixels[s + x] = argb(255, frame>>3, y+frame, x+frame);
    }

This is taking a lot of inspiration from Doom, but the actual raycasting engine is more like Doom's predecessors, the most well-known of which is probably Wolfenstein 3D: perpendicular walls, constant floor and ceiling height. Wolf3D didn't have textured floors and ceilings because of performance reasons, but several other similar games had them. Doom and IIRC Duke Nukem as well used a BSP engine which was much more flexible (walls could intersect at any angle, variable floor and ceiling heights), although the levels were still "flat" (you couldn't have several "stories" inside a level, e.g. you couldn't design a bridge that you could walk over and under).

Great article. I particularly enjoyed the approach to creating gibs. Although it was a tech demo, I created something like this around the mid 90s. One thing I did that I don't see mentioned in this article was I used 8x8 (or 16x16) light maps on the textures, which allowed me to easily have things like flickering torches and rockets that lit up the hallways as they shot down them. Lightmaps can also be used to "bake in" lighting if desired. Since the light map is "only" 8x8 you can afford to do some math on each luxel (each unit in the light map) to calculate distance and line of sight to light sources to determine a brightness value. When rendering the texture, the luxel was used with a lookup table to determine the actual color of the pixel being drawn. The light maps were updated 15 times a second if I recall correctly to help performance. Thanks to DJGPP, I was using inline assembly for the rendering. Since floating point math was slow at the time I used fixed point math which optimized well. The rendering was surprisingly performant on computers of the day.

I find the most interesting things are the internal tools -- like the Python script to generate the gib animation, or the other Python script to generate 2D spritesheet from Blender. OP is definitely a 10x engineer who can also do good arts. This is very rare IMO. I'm very surprised to find that OP has consistent art direction.

Graphics programming in the early to mid 1990s was pretty fun: write pixel data into the memory-mapped video RAM and it appears on the screen! A pointer to 0xA0000 was all you needed - no API or anything. The reason for the non-square-pixel 320×200 VGA mode they mention was that the video buffer took 64000 bytes, which fit into a 16-bit segment, making addressing it easy in 16-bit code/CPUs.

I just noticed that this might be one of the rare shooters with a female protagonist: the cat has a calico pattern, and those are almost always female (https://en.wikipedia.org/wiki/Calico_cat).

This is so great. Another fun trick we used in the 90s was palette animation -- by swapping the palette you can create incredibly cool effects at a low runtime cost.

So refreshing to have this NOT read a few pageS IN; words to the effect of.. “and the I asked Claude to build most of it for me then set to tweaking a few parts at the edges before asking Claude to write up this blog post”

I'm tinkering with a voxel space rendering tech demo as a PlayStation homebrew. After one weekend of work I'm getting decent results (like, 10-15 FPS) and I've yet to use the DMA, the GTE or even polylines primitives.

It's refreshing to dust up trigonometry and good old low-level optimization tricks. When the scratchbuffer has 1 KiB and the stack can only use a fraction of that, it makes me realize how spoiled I'm at work with the microcontrollers we have, with threads being allocated 8 KiB of stack and backtraces with over 50 functions of C++ templates on it.

If there's enough room, you could add special palette indexes that stay constant or diminish more slowly with distance. To give a glow effect for lights, torches, etc. I always appreciated this effect in Quake.

EDIT: Oh nevermind. I guess brightmaps are more flexible.

As a fellow 3d-engine-with-foolishly-unreasonable-constraints developer, I love the detail in the explanations here and seeing the process you went through.

In the final video, it looks like the destructible vases take several shots to destroy. IMO, they should only take one. Real life vases only take one, so requiring more makes the gun feel weak. It seems to be cosmetic anyway, so there's no game balance reason to require more.

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...

This is terrific. I love reading about the creative process involved in a project like this, finding cool solutions to self-imposed boundaries.

I think the mix of highly rational reasoning and "it just feels right" is a killer combo too, it gives a rigorous basis for a lot of the decisions made, while also allowing for a strongly personal aesthetic to emerge. Very cool indeed.

>> What this actually means is, the constraints I have foolishly imposed upon myself are as follows....

Those kind of constraints can lead to increased creativity, and can also influence the overall style of a game. It's part of the reason early 80's arcade games had so much diversity.

The last real graphic programming¹ I’ve done was in the late 80s targeting the Tektronics graphics mode of the Kermit terminal software on the PC.² It was all pretty much clear the screen and draw solid rectangles in 1-bit black and white. One of these days I’m going to join the twenty-first century.

⸻

1. I suppose some hand-written PostScript code might count as well, but I wouldn’t really count things like doing a simple function graph in python to explain something to my son as graphics programming.

2. This was for a DVI previewer running on an IBM mainframe running VM/CMS. As far as I know, this code is completely lost, which is probably a good thing.

I am not even a noob with game development. I dabbled with Godot a couple years ago and was making a funny weight lifter game, some sorta stat management sim. It was actually pretty fun but I didn't get past some pretty early working versions.

I thought I could really level up with Claude and I started working on a boxing game. It's been a total disaster. .·°՞(˃ ᗜ ˂)՞°·.

> 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.

Well here's goes my self-esteem again. I hate you ! :D

(Nice job, seriously)

We randomly chose magenta as our transparent pixel for shareware games too!

I consider 1993 the last "good" year of the pre-internet age. The web didn't go mainstream until around 95, and 94 felt like a liminal year (dunno why). In 93 one could still wrap a plaid shirt around one's waist without fear of ridicule. Grunge and alternative music hadn't quite landed in rural America yet, although we didn't know what we were missing. The Telecommunications Act, Digital Millennium Copyright Act (DMCA), Gramm-Leach-Bliley Act, USA PATRIOT Act, and so many other regressive/draconian laws hadn't passed yet to create the wealth inequality consuming the American Dream today. Although the Grand Upright Music vs Warner Bros decision had happened in 91 in an attempt to destroy hip-hop for racist reasons under the guise of protecting copyright. The Rodney King beating had happened the year before, but the OJ trial was still 2 years away. We were blissfully ignorant of the very ignorance and hate that would put us on this alternate timeline. It was like living in the Shire before the War of the Ring.

I can't stress enough how games like Wolfenstein 3D and DOOM completely blew our minds. They came out about 6-7 years before The Matrix, so the closest conceptual framework we had for it was probably The Lawnmower Man. Virtua Racing and Virtua Fighter came out about that time, but somehow couldn't compare. I remember using a drafting program on a 33 MHz PC with a 16 color monitor in drafting class, and DOOM revealed that even then, computers were running hundreds of times slower than they were capable of (millions of times slower today).

If I could go back to any time with what I know now, it would be spring of 93.

Step 0 is missing: having a great taste. One look at the video example is enough to figure out that the author keeps things in balance and in style. Explanations of why pixel grid mismatch looks wrong, or why mismatch between texture density and geometric complexity (in both ways) looks horrible, or why smoothing does not blend with pixel art are then made in retrospect.

Some details are a bit too cool for 1993, though, and assume high frame rate (won't work that well at low fps). Smooth weapon animations with a lot of frames, tiny per-pixel effects on bullet holes and flash sprites, smooth movement and object position calculations that use precise math instead of fast rough estimates resemble Chasm: The Rift or Quake (the concept of idle animations, e. g. objects moving in the starting view of difficulty selection room, assumes that there is some performance to waste on details that make the world less empty).

Maybe the recent final update to Destiny has already taken over my brain but if Marko is a Destiny fan, he has a great GitHub username.

This is an extremely detailed article on every level and I can’t wait to deep dive into it. Marko really nailed the “old” look but it still looks fresh and new.

For some reason I irrationally like the posterization effect that's created when something is darkened to almost zero.

Genuinely lit. Gives me a whole new appreciation for the games I played as a kid, and John Carmack. Nice project :D

I respect the amount of work that goes into projects like this; I can't wait to be able to play it.

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

Looks really cool, please release episode 1 as shareware! (Or a demo on Steam works too)

@sklopec any chance you have a Mastodon or maybe Bluesky account where we can follow your work? Would love to follow development and buy your game when it's out.

It doesn't say in the blog post, but will this be released for MS-DOS?

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

I really loved that article. Creating games always seemed so daunting to me since I don't know a lot about how it's done, there are so many different processes involved. The solutions described here are so satisfyingly compact and so easy to understand given the simple constraints, and yet they produce an actual game that looks nice.

Much respect -- at first glance when I saw the animated gif I thought this was just a project making assets from scratch for an existing game engine (e.g. Doom or Wolf 3D) but then I realize it's creating all the game code from scratch too! (But using similar techniques from the old days). Amazing work.

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...)

Will definitely play when it's released. Doom is my favourite game and I enjoy playing it at 320x200.

This is a great write-up of your process and behind-the-scenes peek at the making of what looks to be a really fun game! Can't wait to play and delve into the code once you release it.

What does he mean by inconsistent pixel scale when he talks against increasing sprite resolution?

Really cool. It's also something LLM's are ridiculously bad at, so you kinda have to do it properly.

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...

As a side note, the visual style in the game reminds me a lot of Exhumed / Powerslave :-).

This game looks great I really like the style it is inspiring.

The author seems to consider open-sourcing the engine, I would also be interested in the mentioned scripts for asset creation. Those scripts would make a great toolset for asset creation in this style.

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?

I love this! I have been working on a similar project, recreating the originale BBC Elite but with multiplayer networking. Though I have not limited myself as much (I use SDL).

This is a wonderful deep dive into your project. I'm early days on creating pixel art style procedural art systems, and this gives me plenty to think about.

With the title I was expecting some notes about DeluxePaint, but it was still a nice read nonetheless. Wish you much success with the game! :-)

one of my very first solo projects during high school was writing a wolfenstein-like raycaster from scratch. I still hold some very fond memories of programming it, arguably one of the moments I fell in love with the craft

This is beautiful. I wish one day I'll have to time for a project like that. Looking forward to buying it on Steam.

looks really beautiful, amazing job

cool cat game

what's unreasonable about this though?

it's my birth year

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.

I hope they leveraged Mode X :)

That's beautiful. I hope it will run on a 486DX2 :D

Bravo! Wonderful read.

The comments here are a cesspool unfortunately. People bickering about pronouns used for cats, how many shots it takes for a vase to explode, or whether or not some circa-1993 software was used or mentioned.

[flagged]

[dead]

[dead]

Unpopular opinion but the author remarks that the cat is female but uses "it" as pronouns. Human garbage.

There is nothing wrong with using AI.

What I don't like is to see claims like "no AI slop"

And yet it's riddled with emdashes and language "by hand"

Seeing the skills of the writer, he definitely should be able to, but then I don't understand the claim.

It'd be more interesting if you made a similar looking game using modern APIs imo