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?
The other is entropy coding, which means re-writing bytes and pointer codes into variable length values that are optimized by frequency: fewer bits for common codes, more bits for uncommon ones. The most basic approach for this is Huffman coding, which is kind of like variable length binary phone numbers.
Together, these two techniques are how DEFLATE compression works, which is the algorithm used by zip, gzip, and zlib. zlib is then used in many, many formats, like PNG and PDF.
Trivial "look for dupes and subsets and just change pointers" compression is already standard when building C code. If your program has two strings, "foobar" and "bar", the linker will just store "foobar" in the strings section and point 3 bytes into it for "bar", assuming the right compilation/linking options to make it work.
The compressor would create a special font (C64 "charsets" are 8x8 pixels), and slice the picture into 8x8 tiles where each block corresponds to an ASCII character. Although C64's hires resolution was 320x200 (160x200 in multicolor mode), because of repeating blocks it would usually end up using less than 256 characters. The actual background would then be drawn using those characters with the special font. There is no eager decompression involved.
Brute force compare all the ROMs to each other and find "ancestor" with the least amount of changes as compared to any other.
Pick that as an ancestor, re-brute force check every remaining ROM against that one for changes.
It was silly and wasteful computationally but you could store 40 variations of a cart in 50MB instead of 1GB.
Huffman coding would be the simplest algorithm to compress the repeated patterns in sprites, but I think even loading up the dictionary to decompress would run into memory limitations on these old systems. If nothing else it would cause hitching.
https://www.news-medical.net/health/What-is-an-Overlapping-G...
I think this is something we should do more today. Defining a memory budget, and staying inside.
This save them multiple times when issues arose later relating to space availability, even for updating things, etc.
It's fun to think about, but I am not sure if it's the right tradeoff for most projects?
https://www.gamasutra.com/view/news/387227/Gamasutra_is_beco...
—Attributed to Orson Welles (<https://quoteinvestigator.com/2014/05/24/art-limit/>)
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.
That's it.
The mouse with the crosshair is a nice idea!
... 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)
Eye pleasing and no distraction from the text, as a web page should be.
Though were we in a universe where every choice is a cruel dichotomy, I'd pick understated text-align justify over JavaScript bombardments.
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...
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.
Couldn't be further from the truth, especially when it comes to Street Fighter... People complain about microtransactions today and don't even think to consider that the original microtransaction was the arcade machine. Games back then were specifically designed to extract a certain amount of money per hour from players and their difficulties were adjusted to maintain that rate.
It's never been better to be a game developer then today. The number of platforms available to you, distribution options, variety of studios/publishers are much greater today than ever before.
I couldn't disagree more. The arcade machine did not feel like a microtransaction at the time. We were glad to spend the coins on them. Now, even with presumably much more funds than when we were kids, the microtransactions feels very exploitative!
If people "dont even think to consider" then that means there isn't much of a similarity
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.
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?
Also, any given saved tile might not have packed well in the overall sprite sheet, given that they were organizing the ROM by hand.
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 :-)
That doesn't seem to be the case. There are pieces of Chun-Li and Blanka on the Dhalsim sheet.
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.
Email me at fabiensanglard.net@gmail.com
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?
This is a fantastic article!
I wonder if they used this same method on the SNES or not.
