Street Fighter II, subtile accurate animation (2021) | Hacker News Reader

Street Fighter II, subtile accurate animation (2021)

fabiensanglard.net

118 pointsAmorymeltzer27 comments

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 (https://www.noclip.video/) producing phenomenal content.

Also Fabien Sanglard's Game Engine Black Books (https://fabiensanglard.net/gebb/) are fascinating reads. Both Doom and Wolfenstein 3D sit on my living room coffee table.

Game Devs have always done amazing things like this.

I remember my one and only real attempt at game dev involved the zx spectrum where I got a book from my local library with all sorts of inspiring tricks in it. For people who don't know/remember, the speccy used to output to a TV[1] but didn't have enough graphics juice to actually fill the screen, so you could render into a pane in the center of the screen and the only thing you could do with the outside border was you could set the color [2]. Anyhow, this spectrum game dev book showed how to build a flight simulator game in assembly and one of the incredible hacks they employed was to change the color of the border at exactly the right moments in the scan path of the CRT so it would look like you had a continuous horizon all the way to the edges of the screen. You couldn't actually render any graphics out there but it blew my mind that you could at least make the sky and land stretch right to the edge of the screen.

[1] Which would have been CRT at the time, which turns out to be important for this hack.

[2] You can see this border here. It's the ugly green box. All spectrum games used to have this. https://forums.libretro.com/uploads/default/original/3X/c/9/...

These kinds of tricks were also very common on the NES, to create things like a HUD that doesn't scroll with the rest of the screen by changing the scroll values at the right time. Eventually they even started putting hardware in the cartridge to assist this by interrupting the CPU at the right time

Amiga may have taken this furthest with Copper, a co-processor that was synced with the CRT signal and programmed in a DSL for timed changes of register values in the other chips: https://en.wikipedia.org/wiki/Amiga_Original_Chip_Set#Copper

I'd generalize it. Every time someone finds a creative hack to do something not possible with a device you get a magic moment. The opposite is also somehow true.. people today have unity open infinite world with pb-renderers and it seems quite boring.

I agree with your generalization now that I give it some thought. Even for topics I have little interest in or know little of, creative solutions are enthralling.

Your latter assessment is why even arbitrary limitations commonly inspire interesting gameplay and art style IMO. I quickly grew tired of Assassin's Creed and similar open world games; in contrast, games like The Messenger can pull me in immediately.

The (admittedly few) game jams I've actually completed had limiting restrictions (i.e. 8/16-bit art/gameplay). Two things make me more productive/creative than normal: looming deadlines and limitations.

like the saying: necessity is the mother of invention

I also think there's a balance between the breadth of a tech and its use. I feel weird seeing how much can software do, but all this for games.. it's like having a complete nuclear lab team to help you change batteries on your LED lightsaber...

If you're looking for similar content, I would add Retro Game Mechanics Explained (Alex "IsoFrieze" Losego).

https://youtube.com/@RGMechEx

This is a channel that does deep dives on specific games, often at the level of carefully explained assembly code, for glitches and graphical techniques in 8-bit and 16-bit consoles.

His videos on MissingNo. are a work of art

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

Getting smooth sprites on EGA? That was easy -- make four copies of each sprite image, one per two-pixel offset.

If I remember correctly the hack was in the level design where on each scroll there was a limited amount of tiles that could change, so one would only scroll these specific tiles and pretend the entire screen scrolled.

Then Commander Keen 4 threw that solution out, and simply assumed that video memory would wrap properly if you went past the end, which it did on most cards.

Here is a memory refresher :P

https://fabiensanglard.net/ega/

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.

https://youtu.be/ZWQ0591PAxM?si=VsIbeLAb7mHc_I9V&t=157

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.

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.

One time my Zelda II cart glitched out and the veil was pierced: I could see the life and magic meter sprites including their movement when either gauge was depleted.

This reminds me of something else. When I was a kid I wanted to create my own Mario game. One of the ideas I had was to have an optional, additional sprite I called "The Chunk" that would be used for auxiliary character animation; for example to make Princess Peach's hair flutter when she jumped or ran.

Well, my supposedly kid-genius self wasn't so original after all; in Super Mario Bros. 2 (the Doki Doki Panic derived one), the playable characters do indeed have a Chunk: a small white rectangle that moves around with them, layered behind the character sprite, and provides the sclerae of their eyes.

I'm actually still working on that "Mario" game. It has Mario-like platforming physics but completely different premise and auxiliary mechanics. Something like the Chunk is used to switch the game's terminal screens from red (normal state) to green (hacked state).

This feels a lot like the CSS hacks I’ve worked on around 2012, when CSS was limited and SVG was rare and buggy.

The overlap between CSS tricks and tile based graphics tricks in underapreciated.

Pretty neat. Unicode has the exact same feature in its block elements block.

https://en.wikipedia.org/wiki/Block_Elements

Sadly it seems HN does not accept these things.

> Sadly it seems HN does not accept these things.

Huh?

  ╷ ╒╗ ╓╖╔╤╕  ╼┭┬┮┯┳┱┰┲╸ #
  ╞╦╡╟─╢╠╩╧╛   ┽┼┾┿╉╂╊╋━ #
  │╚╪╬═╣║▲▼◀▶ ┏╅╁╆╈╇╃╀╄╾ #
  ╵ ╘╝╶╨╫╥╴┌┐┎┒┍┓┏┑╹┃┃┃╿╽│││╻ #
  ┌┬┐╷  ╙╜ ├┤┞┨┢┩┠┧╺┹┸┺┷┻┵┴┶┛ #
  ├┼┤│╶─╴  ┝┥┟┦┡┪┣┫           #
  └┴┘╵ └┘┗┙┕┛┖┚   #

Huh. That's annoying and surprising, since it clearly handles box drawing characters just fine.

(@dang: probably-duplicate bug report: HN mistakes Block Element characters for emoji.)

I remember making my first ASCII art game with those ^^

I did something similar in recent months, where I generated separate bitmap tiles for all sub-tile movements and rotations:

https://github.com/uguu-org/ikaruga-snake/blob/master/source...

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.

See also Unicode code points 002588 to 00258F.

Similar idea can be used for progress bar in console using Unicode block symbols.

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.

Reply on news.ycombinator.com