It sure would explain the JPEG-like artifacts visible if you zoom into the image.
Thursday, May 31, 2012
Oh, could it really be that simple?
http://en.wikipedia.org/wiki/JPEG#Encoding is not something I've ever been especially familiar with, but as I poke further into the code that processes the title screen "tree" image, the two are looking strikingly similar. Could this entire mess simply be an off-the-shelf JPEG processing algorithm tweaked for SNES?
It sure would explain the JPEG-like artifacts visible if you zoom into the image.
It sure would explain the JPEG-like artifacts visible if you zoom into the image.
Wednesday, May 23, 2012
Title screen
Compressed title screen tiles have been loading for a while, but I'm currently working on how they are assembled into the actual title screen and Squaresoft logo. Looks pretty simple, actually.
See? See? I'm doing things.
Edit: I'm also checking out the tree graphic behind the title screen, since it's been somewhat of a mystery for a while now. Looks like they're doing some sort of peculiar matrix math on 8x8 blocks of data derived (somehow) from around D2E63B in the ROM, which end up becoming the tiles that go off to VRAM.
Funny how slow this loading is - they start doing it while the Squaresoft logo is up, and are still working on it while the little black window opens up and shows part of the background, which loads from the bottom up. Once it finishes (~20 seconds later), it opens up and shows the rest. They pass it off as a stylish little window into the background, but it's really just there to allow you to see the part of the image that's been loaded without revealing the part where the little blocks are still being filled in. Corrupting the data in certain ways will slow the algorithm down enough that I can watch it populate the tiles while they're being shown.
Kind of interesting though, that they managed to set up sort of a "background task" like this in an SNES program, that will sit there and load tiles while the rest of the title screen is running. I'm betting they tried like hell to make it load real-time before they finally gave up and had to go this route.
Oh, and this code is largely runtime-generated and run off of RAM addresses, which makes it even more fun to follow.
Needless to say, making this thing "editable" should be quite the task.
See? See? I'm doing things.
Edit: I'm also checking out the tree graphic behind the title screen, since it's been somewhat of a mystery for a while now. Looks like they're doing some sort of peculiar matrix math on 8x8 blocks of data derived (somehow) from around D2E63B in the ROM, which end up becoming the tiles that go off to VRAM.
Funny how slow this loading is - they start doing it while the Squaresoft logo is up, and are still working on it while the little black window opens up and shows part of the background, which loads from the bottom up. Once it finishes (~20 seconds later), it opens up and shows the rest. They pass it off as a stylish little window into the background, but it's really just there to allow you to see the part of the image that's been loaded without revealing the part where the little blocks are still being filled in. Corrupting the data in certain ways will slow the algorithm down enough that I can watch it populate the tiles while they're being shown.
Kind of interesting though, that they managed to set up sort of a "background task" like this in an SNES program, that will sit there and load tiles while the rest of the title screen is running. I'm betting they tried like hell to make it load real-time before they finally gave up and had to go this route.
Oh, and this code is largely runtime-generated and run off of RAM addresses, which makes it even more fun to follow.
Needless to say, making this thing "editable" should be quite the task.
Saturday, January 28, 2012
Boss rendering
Finally! I got him to render on his host map correctly. It took like a week's worth of screwing around to get everything straightened out with this.
The other ones are not so healthy looking. But they should be close.
Edit: when I say "not so healthy".. here's Spring Beak as an example.
This is just a matter of reading the wrong value as an offset to the sprite construction data. Once I straighten that out, a bunch of these should look good.
The other ones are not so healthy looking. But they should be close.
Edit: when I say "not so healthy".. here's Spring Beak as an example.
This is just a matter of reading the wrong value as an offset to the sprite construction data. Once I straighten that out, a bunch of these should look good.
Sunday, January 22, 2012
Friday, January 20, 2012
Oops.
As it turns out, Mantis Ant and Tropicallo aren't meant to be in the same place at the same time.
Also, I'm working on bosses and other sprite stuff at the moment. Here are Tropicallo's tiles, shown here with the wrong palette. Thanks to Flow and Enker for bits and pieces of the compression algorithm for these things. Now to figure out how they're all strung together into boss sprites.
Also, I'm working on bosses and other sprite stuff at the moment. Here are Tropicallo's tiles, shown here with the wrong palette. Thanks to Flow and Enker for bits and pieces of the compression algorithm for these things. Now to figure out how they're all strung together into boss sprites.
Friday, January 13, 2012
Subscribe to:
Posts (Atom)