from Hacker News

Street Fighter II paper trails – allocating sprite space by hand

by krajzeg on 12/23/21, 12:36 AM with 76 comments

  • by allenu on 12/23/21, 7:10 AM

    I love Fabien Sanglard's work. I've read through his books on Doom and Wolfenstein and never would've imagined he'd start looking at sprites for Street Fighter II.

    This is really great stuff and I think important as "developer archaeology". The 80s and 90s don't seem that long ago (to those of us who were around), but it's easy to forget people back then didn't have the sophisticated tools we have today. That said, people did have tools, so it's awesome to be able to get a glimpse into the workflow of folks back then.

  • by im_down_w_otp on 12/23/21, 3:46 AM

    I absolutely love learning about the clever tricks and their long-tail effects that came out of dealing with incredibly resource constrained computing environments and/or where some quirk of hardware ended up inspiring a lot of fabulous creative misuse.

    This is a fantastic article!

  • by kingcharles on 12/23/21, 6:20 AM

    I was one of the developers on this game in the 90s:

    https://www.youtube.com/watch?v=lubyi79e6SY

    It was meant to be 100% 2D, and the programming and art went down that path for a few months before it was realized that there just wasn't enough RAM on PCs of the time to store all the possible sprites for the characters in every rotation. The numbers get out of hand very quickly when you have four main characters, each of which can walk in 8 or 16 directions, can also run, walk up stairs, climb ladders, crawl, fire one of 20 different guns etc. The isometric backgrounds are all sheets of 2D tiles, laid out just like in Street Fighter and every other sprite based game.

    So, several months into development it was decided to change all the characters to 3D to save RAM. I switched the entire game over in two weeks, including creating all the tooling to convert from 3D Studio to.. whatever the fuck, because there were no rules in those days. When that game was started there were almost no 3D accelerators, and I don't remember if you needed specific SDK for them. I seem to remember our game couldn't use them, perhaps because of the way the 3D and 2D were composited in the frame, which was very unusual - most games were either 2D or 3D, not a combination.

    Are there any easter eggs hidden in the sprites for SFII? There were various ones in Abomination, mainly written in the graffiti around the cities.

    And then there are ones like this (TFT) that we can't talk about: https://www.reddit.com/r/gaming/comments/3ylmm4/a_staggering...

  • by Waterluvian on 12/23/21, 4:37 AM

    When writing a DMG emulator I thought about how these tiny sprites are often similar. A sprite will be a series of bytes with an address to the beginning.

    It got me thinking about a kind of compression algorithm could find byte overlaps and re-pack the sprites, and then adjust the addresses.

    This got me thinking: are there any compression algorithms that do not require decompression? You pack them once and then just point at slices.

    Then this got me thinking: is that just what unzipping is doing, just eagerly?

  • by rmetzler on 12/23/21, 11:24 AM

    I remember another article where the main developer set aside a big chunk of memory right when they started coding. When they had issues fitting everything in memory shortly before the deadline, he deleted this chunk and had no issue to deliver the project.

    I think this is something we should do more today. Defining a memory budget, and staying inside.

  • by mewse-hn on 12/23/21, 5:50 AM

    I love that we can dig into rom images from 30 years ago and recreate sprite sheets that were originally hand drawn for something that was an important part of our culture. What more I love that Fabien actually does it and shows us how it's done.

  • by ben7799 on 12/23/21, 2:25 PM

    Loved this article. SFII was so huge when I was about 13-20... that game had such a long tail. I remember seeing it for the first time and being blown away, it was rather amazing when all you'd seen up to that point was NES and PC games on a 286 or so.

    Funny thing is I'm pretty darn sure I have no desire to work in commercial game development these days, but would have loved to back then. The creativity around limitations was amazing back then and it seemed like so much care was put into making games fun. These days it seems like addiction mechanisms, getting people to spend more money, obsessiveness with graphics over gameplay, etc.. are ruining everything.

  • by blondin on 12/23/21, 3:23 AM

    would be truly amazing if Fabien can pull it off.

    there is so much secrecy surrounding video game development in japan. especially the 8 and 16-bit era. i was very interested in how they did pixel art back then. they supposedly drew them using special keyboards and CRT monitors.

    there is one page on the whole internet that briefly mentioned the process.

  • by ggambetta on 12/23/21, 8:58 AM

    Another excellent article by Fabien :)

    One thing that surprises me is that in such a ROM-constrained context, the artists weren't asked to save some more. There's some tiles that are empty except for a handful of corner or side pixels; I could imagine going to the artists and asking them to tweak the pose a tiny bit to save a tile.

    Or maybe what we're seeing in these sheets is the result of doing that just enough to fit their game into the available ROM, at which point they didn't need to free any more tiles?

  • by phkahler on 12/23/21, 2:59 PM

    >> Notice how Ruy's top hair for 0x69/0x6A was placed at 0x6F/0x9F in order to not disturb the layout. Why the hair of the top left pose is offsetted is unknown. Could it be that GFX ROM address 0x0000 could not be used? Analyzing other games also showed that tile 0x0000 was never used.

    My guess is that it was easier to encode and use a blank tile than to specify those strange shapes where sprites are non-rectangular. Just tell the hardware the size in tiles and then offer a set of tiles that includes blanks. This could be confirmed or refuted once they find the area in ROM that specifies how to put the tiles together to form a sprite.

    It sounds like a complete sprite had to be entirely on one page, so there must be a list of tile numbers to compose a sprite and they would be 1 byte each. since they know the tile layout for some of the poses, they should be able to write down that sequence of bytes and look for it in the ROM, then check if there are zero tiles in there. Or just check the MAME source code since that level of detail was probably all figured out a long time ago for that project :-)

  • by city41 on 12/23/21, 2:39 PM

    I'm currently writing a tool to package up sprite tiles for the Neo Geo[1], which handles graphics in a very similar manner as the CPS1. I can't imagine composing these tiles manually, what a monumental task.

    The Neo Geo's hardware offers a few graphical features that work by assuming the tiles are ordered in a certain way. It's an interesting challenge to meet those requirements.

    [1] https://github.com/city41/sromcrom

  • by thrdbndndn on 12/23/21, 7:21 AM

    Fascinating read, one question though:

    If they can split an image into multiple tiles at different addresses (as they did in some examples shown in the article), shouldn't they only need to care about the total tile number? Why did they bother to try to fit these postures (more or less) as whole on sheet, or making these sheets at all?

  • by hariswill on 12/23/21, 5:06 AM

    Steet Fighter II, the game I mostly played in my childhood. Always been a big fan of this amazing game.

  • by malkia on 12/23/21, 7:12 AM

    I could be mistaken, if it was SF II or some other similar game, but for PC (back in the DOS game, the sprites for these were not stored rectangular (with transparency) but rather a run-length of here is a line of pixels that starts from here to here. Hence your code can just "movsb" instead of checking (expensive) for transparency).

    ... Could've been another game, but it was fun trying to decode the images :)

    (I think it also makes pixel to pixel collision easier to tackle, but don't remember the details - this might've been Star Control II thing, another game we used (as kids) to decode images/mods)

  • by paulryanrogers on 12/24/21, 2:00 AM

    Reminds me of doing unwrapping of custom models for Quake. After a bit of practice I realized it came out much better if I made the face, head, and front parts larger so they contained more details. Then other bits could be squeezed in or mirrored to maximize those 256x256 pixel skins.

  • by aelphssss on 12/23/21, 3:46 PM

  • by teloli on 12/23/21, 6:34 AM

    What a game they made out of those 6MiB. Constraints foster creativity rather than limiting it.

  • by bluedino on 12/23/21, 3:48 PM

    The sheer amount of sprites caused it to be the biggest ROM at the time on the Super NES. 16 megabits! That also caused the game to be priced at something ridiculous like $75 US

    I wonder if they used this same method on the SNES or not.

  • by HeckFeck on 12/23/21, 10:17 AM

    I just wanted to note this website is very well-presented. It mimics the simplicity of a sheet produced by an old typewriter.

    Eye pleasing and no distraction from the text, as a web page should be.

  • by snarfy on 12/23/21, 9:29 AM

    I recall seeing a video of their software setup, where they would use the console controllers instead of a mouse to draw the sprites.

  • by ZeroGravitas on 12/24/21, 9:50 AM

    Topically, some of these would make for extrmely geeky wrapping paper.

  • by authed on 12/23/21, 4:33 AM

    Street Fighter is one of the the only game that I ever bought... Kali was another one (game related app).