Game developers getting creative due to hardware limitations is a topic I will never grow sick of. Historical gamedev journalism has grown much in recent years, with outlets like NoClip (<a href="https://www.noclip.video/" rel="nofollow noreferrer">https://www.noclip.video/</a>) producing phenomenal content.<p>Also Fabien Sanglard's Game Engine Black Books (<a href="https://fabiensanglard.net/gebb/" rel="nofollow noreferrer">https://fabiensanglard.net/gebb/</a>) are fascinating reads. Both Doom and Wolfenstein 3D sit on my living room coffee table.
One of these days I'm going to find the actual quote because I think about it so often, but in his book "iWoz", Steve Wozniak talks about how great it was to come up during a time when you could fit the entire machine in your mind. The constraints bred creativity, and forced you to come up with ingenious solutions to things.
A lot of people talk about what a genius Carmack must have been to get those smooth animations in Commander Keen, especially considering that the EGA had a planar display wherein each byte represented one color plane for eight pixels, making placing of pixels at arbitrary locations hard. But the clever bit was in the smooth <i>scrolling</i> -- knowing which EGA registers to poke to get a particular horizontal offset and just-in-time fetching of tile data to fill in whatever scenery had just scrolled into view.<p>Getting smooth sprites on EGA? That was easy -- make four copies of each sprite image, one per two-pixel offset.
Here is my favorite video about 8-bit era optimisations. Makes you appreciate games from this era even more. This arcane magic survived in the demoscene to this day.<p><a href="https://youtu.be/ZWQ0591PAxM?si=VsIbeLAb7mHc_I9V&t=157" rel="nofollow noreferrer">https://youtu.be/ZWQ0591PAxM?si=VsIbeLAb7mHc_I9V&t=157</a>
Meanwhile, Zelda 2 used a combination of whole tiles, and a single moving sprite to show a partial value for Life and Magic. In order to hide that there was a moving solid 8x8 block, they added labels to the left of the Life and Magic meter (the little "L" and "M" block), and this label was opaque, and the 8x8 block was drawn behind the background, so it would hide the moving block sprite.<p>Now back to Street Fighter II. That game has a big "KO" sprite in the center of the life meters, which could cover up any moving sprites if drawn at a higher priority. If the devs wanted to minimize the number of different tiles needed for a life meter, they could have also used whole tiles combined with a moving box sprite. This would require drawing two more sprites than the solution in game, but would have required only two graphics tiles rather than the 16 tiles the game uses.
Pretty neat. Unicode has the exact same feature in its block elements block.<p><a href="https://en.wikipedia.org/wiki/Block_Elements" rel="nofollow noreferrer">https://en.wikipedia.org/wiki/Block_Elements</a><p>Sadly it seems HN does not accept these things.
I did something similar in recent months, where I generated separate bitmap tiles for all sub-tile movements and rotations:<p><a href="https://github.com/uguu-org/ikaruga-snake/blob/master/source/tiles-table-32-32.png">https://github.com/uguu-org/ikaruga-snake/blob/master/source...</a><p>This seems like a common trick for tile-based display environments.
The health bar is just a hexadecimal number in a funny alphabet. Is it really so amazing that it can show numbers in between 0x0 and 0xf? That's the bare minimum I'd expect for any display.
This article is so lightweight it can be summarized in one sentence without losing any information. That's not really worth sharing or taking the time to read, IMHO.