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 feel like the idea of fixed-point is under-utilized and very under appreciated. There are loads of applications where this is a better choice, let alone more performant.
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 ;)
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.
It seemed, as a fan of the genre in the 90s, like these Renaissance Engineers were behind every major hit. I remember some of their names, they are true artists.
I have no idea the names of nearly anyone but a CEO or lead Director in the games industry of the past 15 years.
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).
The Build engine didn't use BSP, it treated connections between sectors as portals and rasterized the walls as (90 degree rotated) trapezoids while performing clipping against those portals. This allowed it to have dynamic wall geometry (e.g. moving trains, rotating light fixtures, etc) as well as "room-over-room" setups as long as you couldn't see both rooms at the same time (in both Blood and Shadow Warrior they found a workaround for it allowing to create more "3D" spaces by making identically shaped sectors with the floor of one sector acting as a portal to the ceiling of the other sector - supposedly this wasn't "natively" supported by the engine, but it was flexible enough for the game studios who used it -without even having access to the source- to do it themselves).
The first level of Duke Nukem 3D does use a few Build tricks - e.g. another one is that sprites can be "axis aligned" instead of following the camera and they can also have collision - this can be used to create rudimentary 3D geometry by treating each sprite as an axis aligned quad and in the first level it is used to make a bridge between two buildings (right before the level exit button).
I always loved that the bridge you mentioned could take damage and fall down, screwing you over in the very first level, unless you knew where the Jetpack was stashed.
With regard to floors, afaik even DOOM didn't do them correctly. With vertical walls, the perspective divide needs to be done only once per column of pixels for a given wall segment.
For floors, unfortunately there's no such luxury, and if I remember correctly DOOM subdivided floors into patches, and only did proper perspective at the corners, and interpolated inbetween.
For floors the perspective divide is once per row, just like for walls it's once per column.
The BSP may have led to some floor subdivisions, especially as it needs convex sectors. I don't remember if the engine would coalesce adjacent floor spans into a single one, but I hope it did.
GLQuake introduced the r_wateralpha setting, which allowed transparent water, but the maps were still compiled with visibility calculations that assumed the water surfaces were opaque. You got visual artifacts unless you enabled r_novis to ignore the pre-calculated visibility calculations. Modern computers can handle it, but this was a heavy performance cost at the time.
To work around this, people used an unofficial tool to patch the maps to support transparent water:
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.
Though your extender could make things a little more annoying on that front :-P
(DJGPP and Free Pascal -which use the same "go32" extender by DJ Delorie- do not do a full linear mapping so you need to do a bit more juggling to get stuff on screen there)
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. .·°՞(˃ ᗜ ˂)՞°·.
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).
It's not that rare, is it? Off-hand, and very mainstream; Perfect Dark, Mirrors Edge, Dishonored (don't remember if it's the first or second one), Metroid and more are all kind of "shooters" with female protagonist, although maybe Mirror's Edge is more just "first-person" than "shooter" to be 100% accurate.
Not to mention the large selection of "RPG + FPS" where you can be either man or woman.
---------
Seems the author also realize the thing with the pattern and likely gender of the cat:
> After all, I do need to give the protagonist his fair share. [image] (Yes, I know it's a female, but call it convention rooted in dialect.)
Mirror's Edge has a female protagonist, but it's not an FPS (First Person Shooter). It's a parkour simulator which technically lets you shoot a gun in limited sections of the game, but the protagonist is a pacifist and you get a bonus for decommisioning guns rather than firing them.
So it looks like the two categorisations, for the most part, don't intersect.
Notable counterexamples would include Rise of the Triad, Ion Fury, No One Lives Forever, Wolfenstein: Youngblood and Far Cry 6, but definitely rare. You'd be clutching at straws to describe Portal or Alien: Isolation as FPS (they're a puzzle game and survival horror game respectively), likewise the Resident Evil / Clock Tower / Fatal Frame / etc. games with the novelty option of switching to first-person view, they're naturally third-person perspective. Left 4 Dead has one female character out of four you can play. You might count that one DLC for Bioshock: Infinite where Elizabeth gets a shot (https://www.youtube.com/watch?v=1E1lh-pb6Is). You might count the few FPS RPGs that there are with customisable characters (so yes Fallout, but not Mass Effect as it's third-person). But female protagonists are massively more prevalent in survival horror, metroidvania, third-person shooters (Tomb Raider, Monster Hunter, Horizon Zero Dawn, etc) and other genres besides FPS.
> Reaching back that far for an example just reinforces how rare it is.
Choosing one specific example when I also made more recent ones, isn't such a big dunk you think it is.
> If you tally all the FPS releases in a given year, a supermajority are going to have male protagonists.
Sure, I agree, I'm not saying it's more popular, just that I don't think it's that rare, but I guess ultimately I'm a bit nitpicky (sorry) and we're just disagreeing with the specific definition of "rare".
A lot of boomer shooters nowadays have a female protagonist, e.g. Selaco[0], Supplice[1], The Citadel[2] and its sequel[3], Zortch[4] (and its upcoming sequel[5]), Nighmare Reaper[6], COVEN[7], Viscerafest[8], Hedon[9], etc. If anything i'd say that nowadays there are way more boomer shooters with female protagonists than not :-P (combining the tags "boomer shooter" with "female protagonist" on Steam search gives 143 results, though that includes games where you can either choose your character's gender or you play as a woman for a part of the game even if you play as a man for most of it).
So a bit less than 1/10 of the games tagged with "boomer shooter". With your caveats above about being able to choose a gender, or a single brief segment where you're a lady in a game where you're mostly a dude. Is that a lot? I dunno, doesn't feel like a lot to me. Probably feels like a lot to the people who inevitably show up in the Steam discussions of any successful game that makes you be a lady for most of its length and complain about it being "woke", even one game with a female protagonist seems to be too many for them.
I doubt it was intentional, but in general, I am not impressed by that and don't find any value in that. Same with Hollywood's depiction of women knocking out guys twice their size. Unrealistic, ridiculous, and harmful.
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.
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).
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.
Just a guess: if you want to scale a sprite at anything less than a whole ratio (e.g. 1.5, 0.7, etc), you have to choose pixels to drop out and pixels to repeat , on some pattern that looks good. There are going to be scaling ratios that look like a hot mess, especially at a low resolution like 320x240.
In context, it's talking about sprites that are going to get non-integer scaled anyway (in-game pickups), so it's just about maintaining a consistent detail level. If those specific sprites had their resolution increased, everything else would need its resolution increased to match them.
Inconsistent resolution isn't necessarily a bad thing, e.g. Elite for the BBC Micro changes video mode part way down the screen so it can display both high resolution monochrome wireframe 3D and a lower resolution color map/UI below, but it's not idiomatic to the MS-DOS style this game is going for.
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.
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.
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.
>> 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.
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
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.
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...)
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.
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 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.
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.
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.
>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?
It's the result of the Blender compositor postprocessing, just keep in mind it falls apart once you go low enough in resolution (it's an image space thing after all), so I'm not sure if that helps your case.
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.
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.
How so? Doing this with modern OpenGL would be much simpler than the software rasterizer solution.
I think I'm gonna have to do it anyway, because some players claim they get nausea when playing at such low resolution (320x240), and the only way to give them higher resolutions that perform reasonably is to have it hardware accelerated.
Renderer is abstracted away already, but the real difference would probably be occlusion culling... With raycasting, I get it for free, but if I'd go down the hardware accelerated path I'd have to pick something more clever.
Raycasting and software rendering in general tends to scale poorly with resolution, even with vectorization and all the bells and whistles of modern CPUs.
Unless you plan on rendering the level on some very retro hardware (think S3 Virge, maybe Voodoo 1) you can render the entire level in OpenGL with just zbuffer and alpha tested sprites and it'll run perfectly fine - if anything with such low polycount, chances are you're going to make the renderer slower by trying to do occlusion culling on any GPU released in the 21st century :-P. If you pack the geometry in a few vertex buffers (for each unique texture) even per-frame, you'll get four digit FPS in any relatively modern GPU.
As an example this[0] video shows the benchmark from Post Apocalyptic Petra running on my previous GPU (RX 5700 XT) which all it does is build a per-frame (client-side) vertex-buffer in OpenGL 1.1 (the engine was made for actual retro PCs running DOS and Win9x so it does some rudimentary occlusion culling but that mainly affects 90s hardware, not anything released since 2000 or so). If anything, the rendering has so little overhead that half of the framerate is "eaten" by the FPS counter overlay :-P.
Thinking about modern games, a single character model probably has more vertices than my entire level (and yours probably), so it's definitely reasonable to expect occlusion culling for such simple geometry might actually reduce performance rather than increase it.
Yeah, even this model[0] i made a few years ago for a game i wanted to make for the OG xbox (which has a GeForce3-like GPU) has ~2230 triangles and the entire first level of Post Apocalyptic Petra is ~5800 triangles, so you could say that even a turn of the century 3D character has more or less the same polycount as an entire 90s level (the game i wanted to make would have many characters on screen so i kept the polycount low but i've heard games having 5-6K character or more - e.g. Kingdom Under Fire had ~10K triangles for the main character and a game like Dead or Alive where there are few characters on screen had 15-20K triangles).
Meanwhile more current games have much higher polycounts, easily going above 100K triangles - e.g. Dante from DMC5, a ~7 year old game, apparently has ~190K triangles and that had to run on the more anemic PS4/XBone hardware :-P (though i'm not sure if it used the full 190K model there or some cut down version).
I rendered some Source engine levels on a shitty laptop in 2012ish and they still rendered at perfectly acceptable FPS (30+) just by rendering all the geometry in the level in one shot.
The synthesis technique would be to build the DOOM-style BSP tree and then construct a bunch of meshes for use depending on which portal space you're currently in, but .. as you say, you don't need to do that because it's at most a few hundred polygons.
Sure, but it becomes a question of how far you can push things. Maybe you raytrace the whole thing. Maybe there's some fractal geometry going on. Maybe you use a fisheye lens projection. Maybe your levels are dynamically tesselated. Maybe you have to do a few fancy tricks to achieve equivalent texturing etc.
But ignoring the GPU you have on your system is boring
I don’t know. Em-dashes are normal punctuation. The prose on the site doesn‘t strike me as particularly AI-y, but of course I might be wrong. Generally speaking, if the person wants to not use AI and tell people that, thats fine by me too.
We're getting to the point that building something with AI doesn't really indicate skill. So, for a prestige project, there is great value in avoiding AI use.
From the article they list a bunch of arbitrary constraints...
> If this sounds unreasonable to you, that is because it is.
Those listed, are tame. I don't understand this kind of faux modesty.
> My goal was to build a complete, shippable first-person shooter using techniques that were common in the early 90s
Goes on to explain how they used 3D blender...which wasn't available until 1998.
A vanity cat project being tailored and submitted for nostalgia clickbait. I don't think there's anything useful to take away from this other than some color shade selection ideas.
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 used fixed point math which optimized well.
I feel like the idea of fixed-point is under-utilized and very under appreciated. There are loads of applications where this is a better choice, let alone more performant.
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.
Will definitely play when it's released. Doom is my favourite game and I enjoy playing it at 320x200.
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.
It seemed, as a fan of the genre in the 90s, like these Renaissance Engineers were behind every major hit. I remember some of their names, they are true artists.
I have no idea the names of nearly anyone but a CEO or lead Director in the games industry of the past 15 years.
As a side note, I checked OP's other projects, and looks like he/she was already OK with arts from earlier on:
https://staniks.github.io/articles/inferno/
https://staniks.github.io/articles/worship/
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).
> Duke Nukem as well used a BSP engine
The Build engine didn't use BSP, it treated connections between sectors as portals and rasterized the walls as (90 degree rotated) trapezoids while performing clipping against those portals. This allowed it to have dynamic wall geometry (e.g. moving trains, rotating light fixtures, etc) as well as "room-over-room" setups as long as you couldn't see both rooms at the same time (in both Blood and Shadow Warrior they found a workaround for it allowing to create more "3D" spaces by making identically shaped sectors with the floor of one sector acting as a portal to the ceiling of the other sector - supposedly this wasn't "natively" supported by the engine, but it was flexible enough for the game studios who used it -without even having access to the source- to do it themselves).
The first level of Duke Nukem 3D does use a few Build tricks - e.g. another one is that sprites can be "axis aligned" instead of following the camera and they can also have collision - this can be used to create rudimentary 3D geometry by treating each sprite as an axis aligned quad and in the first level it is used to make a bridge between two buildings (right before the level exit button).
I always loved that the bridge you mentioned could take damage and fall down, screwing you over in the very first level, unless you knew where the Jetpack was stashed.
> Wolf3D didn't have textured floors and ceilings because of performance reasons, but several other similar games had them
Blake Stone Rise of the Triad used later versions of the Wolf3D engine and had textured floors/ceilings
> Doom and IIRC Duke Nukem as well used a BSP engine which was much more flexible
Duke Nukem (Build engine) did not use BSP
https://www.jonof.id.au/forum/topic-137.html#msg1548
With regard to floors, afaik even DOOM didn't do them correctly. With vertical walls, the perspective divide needs to be done only once per column of pixels for a given wall segment.
For floors, unfortunately there's no such luxury, and if I remember correctly DOOM subdivided floors into patches, and only did proper perspective at the corners, and interpolated inbetween.
For floors the perspective divide is once per row, just like for walls it's once per column.
The BSP may have led to some floor subdivisions, especially as it needs convex sectors. I don't remember if the engine would coalesce adjacent floor spans into a single one, but I hope it did.
Later on, in Shadow Warrior, you could even do that, i think they used portals to implement it and i remeber it was a pain to set up in the editor.
Yes, essentially with a second rendering pass. Not cheap to implement which is why the game used it relatively sparingly.
That did give us our first software rendered transparent water rooms though (Quake had the water opaque unless you had 3DFX card IIRC)
GLQuake introduced the r_wateralpha setting, which allowed transparent water, but the maps were still compiled with visibility calculations that assumed the water surfaces were opaque. You got visual artifacts unless you enabled r_novis to ignore the pre-calculated visibility calculations. Modern computers can handle it, but this was a heavy performance cost at the time.
To work around this, people used an unofficial tool to patch the maps to support transparent water:
https://vispatch.sourceforge.net/
I thought at first it was just a skinned Wolfenstein 3D. Which is grossly unfair. A lot of work here.
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.
> A pointer to 0xA0000 was all you needed
Though your extender could make things a little more annoying on that front :-P
(DJGPP and Free Pascal -which use the same "go32" extender by DJ Delorie- do not do a full linear mapping so you need to do a bit more juggling to get stuff on screen there)
Until VGA came along....the story was much more complex.
> 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.
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. .·°՞(˃ ᗜ ˂)՞°·.
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).
> rare shooters with a female protagonist
It's not that rare, is it? Off-hand, and very mainstream; Perfect Dark, Mirrors Edge, Dishonored (don't remember if it's the first or second one), Metroid and more are all kind of "shooters" with female protagonist, although maybe Mirror's Edge is more just "first-person" than "shooter" to be 100% accurate.
Not to mention the large selection of "RPG + FPS" where you can be either man or woman.
---------
Seems the author also realize the thing with the pattern and likely gender of the cat:
> After all, I do need to give the protagonist his fair share. [image] (Yes, I know it's a female, but call it convention rooted in dialect.)
They're definitely rare. Mirror's Edge is almost 20 years old. Reaching back that far for an example just reinforces how rare it is.
If you tally all the FPS releases in a given year, a supermajority are going to have male protagonists.
???
Mirror's Edge has a female protagonist, but it's not an FPS (First Person Shooter). It's a parkour simulator which technically lets you shoot a gun in limited sections of the game, but the protagonist is a pacifist and you get a bonus for decommisioning guns rather than firing them.
If the thread would like some hard data:
- 19,526 games on Steam tagged "female protagonist" https://store.steampowered.com/search/?tags=7208&ndl=1
- 13,578 games on Steam tagged "FPS" https://store.steampowered.com/search/?tags=1663&ndl=1
- 727 games on Steam tagged both "female protagonist" and "FPS" https://store.steampowered.com/search/?tags=7208%2C1663&ndl=...
So it looks like the two categorisations, for the most part, don't intersect.
Notable counterexamples would include Rise of the Triad, Ion Fury, No One Lives Forever, Wolfenstein: Youngblood and Far Cry 6, but definitely rare. You'd be clutching at straws to describe Portal or Alien: Isolation as FPS (they're a puzzle game and survival horror game respectively), likewise the Resident Evil / Clock Tower / Fatal Frame / etc. games with the novelty option of switching to first-person view, they're naturally third-person perspective. Left 4 Dead has one female character out of four you can play. You might count that one DLC for Bioshock: Infinite where Elizabeth gets a shot (https://www.youtube.com/watch?v=1E1lh-pb6Is). You might count the few FPS RPGs that there are with customisable characters (so yes Fallout, but not Mass Effect as it's third-person). But female protagonists are massively more prevalent in survival horror, metroidvania, third-person shooters (Tomb Raider, Monster Hunter, Horizon Zero Dawn, etc) and other genres besides FPS.
> Reaching back that far for an example just reinforces how rare it is.
Choosing one specific example when I also made more recent ones, isn't such a big dunk you think it is.
> If you tally all the FPS releases in a given year, a supermajority are going to have male protagonists.
Sure, I agree, I'm not saying it's more popular, just that I don't think it's that rare, but I guess ultimately I'm a bit nitpicky (sorry) and we're just disagreeing with the specific definition of "rare".
Not a "shooter", but the "No One Lives Forever" franchise is another example of a female protagonist in a first person game.
Edit: I completed forgot Chell from Portal, too!
Unreal actually also has a female protagonist.
https://unrealarchive.org/wikis/the-liandri-archives/Prisone...
If Portal counts, so does Control
Control's not first-person. You are looking at Jesse's back for pretty much every moment of gameplay.
> one of the rare shooters with a female protagonist
No, this isn't a Perfect Dark game
Well done.
A lot of boomer shooters nowadays have a female protagonist, e.g. Selaco[0], Supplice[1], The Citadel[2] and its sequel[3], Zortch[4] (and its upcoming sequel[5]), Nighmare Reaper[6], COVEN[7], Viscerafest[8], Hedon[9], etc. If anything i'd say that nowadays there are way more boomer shooters with female protagonists than not :-P (combining the tags "boomer shooter" with "female protagonist" on Steam search gives 143 results, though that includes games where you can either choose your character's gender or you play as a woman for a part of the game even if you play as a man for most of it).
[0] https://store.steampowered.com/app/1592280/Selaco/
[1] https://store.steampowered.com/app/1693280/Supplice/
[2] https://store.steampowered.com/app/1378290/The_Citadel/
[3] https://store.steampowered.com/app/3371240/Beyond_Citadel/
[4] https://store.steampowered.com/app/2443360/Zortch/
[5] https://store.steampowered.com/app/3807500/Zortch_2/
[6] https://store.steampowered.com/app/1051690/Nightmare_Reaper/
[7] https://store.steampowered.com/app/1785940/COVEN/
[8] https://store.steampowered.com/app/1406780/Viscerafest/
[9] https://store.steampowered.com/app/1072150/Hedon_Bloodrite/
"boomer shooter": 1105 matches
"boomer shooter" + "female protagonist": 106 matches.
So a bit less than 1/10 of the games tagged with "boomer shooter". With your caveats above about being able to choose a gender, or a single brief segment where you're a lady in a game where you're mostly a dude. Is that a lot? I dunno, doesn't feel like a lot to me. Probably feels like a lot to the people who inevitably show up in the Steam discussions of any successful game that makes you be a lady for most of its length and complain about it being "woke", even one game with a female protagonist seems to be too many for them.
143 results means it's relatively rare.
I doubt it was intentional, but in general, I am not impressed by that and don't find any value in that. Same with Hollywood's depiction of women knocking out guys twice their size. Unrealistic, ridiculous, and harmful.
>Unrealistic, ridiculous
So, a videogame?
You don’t need a penis to hold a gun.
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.
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).
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.
Blue: water. Purple: plasma. Red/orange: blood/lava
What does he mean by inconsistent pixel scale when he talks against increasing sprite resolution?
Just a guess: if you want to scale a sprite at anything less than a whole ratio (e.g. 1.5, 0.7, etc), you have to choose pixels to drop out and pixels to repeat , on some pattern that looks good. There are going to be scaling ratios that look like a hot mess, especially at a low resolution like 320x240.
In context, it's talking about sprites that are going to get non-integer scaled anyway (in-game pickups), so it's just about maintaining a consistent detail level. If those specific sprites had their resolution increased, everything else would need its resolution increased to match them.
Inconsistent resolution isn't necessarily a bad thing, e.g. Elite for the BBC Micro changes video mode part way down the screen so it can display both high resolution monochrome wireframe 3D and a lower resolution color map/UI below, but it's not idiomatic to the MS-DOS style this game is going for.
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.
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.
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.
>> 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.
For some reason I irrationally like the posterization effect that's created when something is darkened to almost zero.
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
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.
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?
Everything is perfect here. The hero, the graphics, the title... <3
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...)
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.
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 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.
As a side note, the visual style in the game reminds me a lot of Exhumed / Powerslave :-).
Really cool. It's also something LLM's are ridiculously bad at, so you kinda have to do it properly.
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! :-)
This is beautiful. I wish one day I'll have to time for a project like that. Looking forward to buying it on Steam.
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...
>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?
It's the result of the Blender compositor postprocessing, just keep in mind it falls apart once you go low enough in resolution (it's an image space thing after all), so I'm not sure if that helps your case.
EDIT: Also, your project is very cool!
cool cat game
what's unreasonable about this though?
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.
That's beautiful. I hope it will run on a 486DX2 :D
I hope they leveraged Mode X :)
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.
Unpopular opinion but the author remarks that the cat is female but uses "it" as pronouns. Human garbage.
It'd be more interesting if you made a similar looking game using modern APIs imo
How so? Doing this with modern OpenGL would be much simpler than the software rasterizer solution.
I think I'm gonna have to do it anyway, because some players claim they get nausea when playing at such low resolution (320x240), and the only way to give them higher resolutions that perform reasonably is to have it hardware accelerated.
Renderer is abstracted away already, but the real difference would probably be occlusion culling... With raycasting, I get it for free, but if I'd go down the hardware accelerated path I'd have to pick something more clever.
Raycasting and software rendering in general tends to scale poorly with resolution, even with vectorization and all the bells and whistles of modern CPUs.
Unless you plan on rendering the level on some very retro hardware (think S3 Virge, maybe Voodoo 1) you can render the entire level in OpenGL with just zbuffer and alpha tested sprites and it'll run perfectly fine - if anything with such low polycount, chances are you're going to make the renderer slower by trying to do occlusion culling on any GPU released in the 21st century :-P. If you pack the geometry in a few vertex buffers (for each unique texture) even per-frame, you'll get four digit FPS in any relatively modern GPU.
As an example this[0] video shows the benchmark from Post Apocalyptic Petra running on my previous GPU (RX 5700 XT) which all it does is build a per-frame (client-side) vertex-buffer in OpenGL 1.1 (the engine was made for actual retro PCs running DOS and Win9x so it does some rudimentary occlusion culling but that mainly affects 90s hardware, not anything released since 2000 or so). If anything, the rendering has so little overhead that half of the framerate is "eaten" by the FPS counter overlay :-P.
[0] https://www.youtube.com/watch?v=64ysz5rXkzw
That's really cool.
Thinking about modern games, a single character model probably has more vertices than my entire level (and yours probably), so it's definitely reasonable to expect occlusion culling for such simple geometry might actually reduce performance rather than increase it.
Yeah, even this model[0] i made a few years ago for a game i wanted to make for the OG xbox (which has a GeForce3-like GPU) has ~2230 triangles and the entire first level of Post Apocalyptic Petra is ~5800 triangles, so you could say that even a turn of the century 3D character has more or less the same polycount as an entire 90s level (the game i wanted to make would have many characters on screen so i kept the polycount low but i've heard games having 5-6K character or more - e.g. Kingdom Under Fire had ~10K triangles for the main character and a game like Dead or Alive where there are few characters on screen had 15-20K triangles).
Meanwhile more current games have much higher polycounts, easily going above 100K triangles - e.g. Dante from DMC5, a ~7 year old game, apparently has ~190K triangles and that had to run on the more anemic PS4/XBone hardware :-P (though i'm not sure if it used the full 190K model there or some cut down version).
[0] http://runtimeterror.com/pages/iv/images/1073c7062db40837240...
I rendered some Source engine levels on a shitty laptop in 2012ish and they still rendered at perfectly acceptable FPS (30+) just by rendering all the geometry in the level in one shot.
The synthesis technique would be to build the DOOM-style BSP tree and then construct a bunch of meshes for use depending on which portal space you're currently in, but .. as you say, you don't need to do that because it's at most a few hundred polygons.
Sure, but it becomes a question of how far you can push things. Maybe you raytrace the whole thing. Maybe there's some fractal geometry going on. Maybe you use a fisheye lens projection. Maybe your levels are dynamically tesselated. Maybe you have to do a few fancy tricks to achieve equivalent texturing etc.
But ignoring the GPU you have on your system is boring
Writing a retro-inspired game using retro approaches despite all the modern options is precisely what makes this interesting.
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.
I don’t know. Em-dashes are normal punctuation. The prose on the site doesn‘t strike me as particularly AI-y, but of course I might be wrong. Generally speaking, if the person wants to not use AI and tell people that, thats fine by me too.
We're getting to the point that building something with AI doesn't really indicate skill. So, for a prestige project, there is great value in avoiding AI use.
From the article they list a bunch of arbitrary constraints...
> If this sounds unreasonable to you, that is because it is.
Those listed, are tame. I don't understand this kind of faux modesty.
> My goal was to build a complete, shippable first-person shooter using techniques that were common in the early 90s
Goes on to explain how they used 3D blender...which wasn't available until 1998.
A vanity cat project being tailored and submitted for nostalgia clickbait. I don't think there's anything useful to take away from this other than some color shade selection ideas.