Discussion in 'Engineering & Reverse Engineering' started by TeaTime_Beta, Jan 19, 2013.
Quote from my forum.
Frankly, I'm amazed that you've even gotten that far into Satourne without it crashing ten times in a row.
Anyway, to explain why you can't properly get the graphics out, here's how the ground works in Sonic Jam.
The graphics themselves are stored in 8x8 pixel tiles (the manual calls them cells....). This mess of tiles is the character pattern, stored at the start of the VRAM in Sonic Jam, from 0h to 20000h. These are the lego blocks that compose the picture. Note that I'm using all memory values relative to the VDP2 VRAM start position, or absolute to the SCRDATA.MUS file because it is the one loaded to VDP2 practically as-is anyway from what I can tell.
So you have the 8x8 cells which are actually more like 16x16 because they are grouped two by two into a tile.
Then you have the Pattern Name Table, which tells which tile to use where. They are "maps" that specify 64 x 64 tiles: they specify their address, their palette, and whether to flip them vertically or horizontally. Since Sonic Jam is using 16x16 tiles, a Pattern Name Table technically stores 32 x 32 tiles, each 16x16 in size. Since it uses 16x16 cells (the manual calls it "Character size of 2 H cells x 2 V cells"), and the pattern name data is 1 word, one table ends up 800h long.
Then you have Planes which can each read one, two, or two by two Pattern Name Tables. There's a part here I don't get and it may just be an inaccuracy in the yabause debugger, because it says the planes are stored in 1 x 1 patterns, but they are in fact stored in 2 x 2. Perhaps the registers are shifted mid-scanline and yabause only grabs the value between frames, possibly for displaying the clouds. I'm not sure.
Anyway, the list of planes is between 20000h and 40000h, each of them 2000h each in size, so they store four Pattern Name Tables in a 2 by 2 grid.
And finally you have a Map, which consists, for VDP2 rotated backgrounds, a 4x4 pattern of planes. In memory, the top right plane is the one with the clouds: when the camera moves out to view the clouds only, the map is switched to only use that one cloud plane repeatedly. When the camera shows the ground, everything is shown in the normal order, but the top right plane has a copy of plane H instead, the one directly south to it, likely because it has the most grass. Incidentally this is the location of the waterfall, and this is why you can see a quarter of a field when you look behind it, because that copied plane is not entirely filled with only grass but a corner of it has the floor cells of the gallery building. As a matter of fact you can see some ground outside the normal Sonic World area at other locations too, because the entire map is set up to repeat indefinitely.
I'm guessing that the switch from cloud to ground happens mid-scanline, and that's how you make two rotating background appear simultaneously. Many later games also moved a ground and a ceiling like that, like Last Bronx.
So we have:
- four 8x8 pixel tall/wide Cells, that make up a 16x16 pixel Tile, (these are the ONLY graphics, the rest are just pointers and palette entry indexes!)
- a Pattern Name Table which holds 32x32 Tiles, (so 32x16 by 32x16 = 512 x 512 pixels tall/wide)
- a Plane set up to hold four Pattern Name Tables in a two by two grid (so, 1024 x 1024 pixels tall/wide)
- and a Map set up to hold sixteen Planes in a 4x4 grid. (so, 4096 x 4096 pixels)
Therefore, your final map should be 4096 x 4096 in size with the clouds being 512x512.
And just to put this into perspective: the Saturn could move around a 4096x4096 pixel background in 1994, when most standard PCs used 640x480! That kind of kicks ass if you think about it.
In other words, and if I understood correctly, once you replace each group of two adjacent grey pixels (in reality just a two-byte hex value) with the 16x16 tile which has that value assigned to it:
(12x9 two-byte hex values)
(12x9 tiles of 16x16 pixels each)
Yes, except that you also have to pair it with the correct palette entry from CRAM (the entry is also stored in the pattern name table).
And for bonus fun, 1 word is not enough to hold the entire character pattern name and palette entry, so the remaining bits are stored in the Pattern Name Control register of the VDP2. The fun part in this is that:
- there's one for every background, each of them 2 bytes (RBG0 is at 058f0038h)
- whether it is global, or changed as stuff is rendered, I do not know
- there are multiple different pattern name data configurations per settings - auxillary modes, rotations, etc, and all of them hold the palette and pattern name bits in different orders.
- the Pattern Name Control register is write only!
Ain't the Saturn just wonderful?
Quote from AXSX Forums:
Since Moop does not have a retro account. Fun stuff being the middle man lol
By the way, from the looks of it (and please forgive my ignorance if this is just plain wrong), I suspect that the whole map might be actually assembled using the following groups of increasingly bigger tiles, before being loaded into RAM:
8x8 pixel tiles (Well duh. =P)
2x2 groups of the tiles above (making tiles of 16x16 pixels) -> Which we also know about already (also done in the Mega Drive games)
32x32 groups of the tiles above (making tiles of 512x512 pixels)
2x2 groups of the tiles above (making tiles of 1024x1024 pixels) -> This includes the "clouds" tile seen at the top-right corner of the full map
And last, the final map consists of a 4x4 set of the tiles above -> With the "clouds" tile being thrown in fourth place for some reason (could be a leftover from a time when that value had a grass-filled tile)
But this is just speculation based on the posted images, I hope I'm not misguiding anybody or anything. =|
Here are the new Sonic Xtreme textures Moop has got a hold of. I'm just posting theme here for you guys to check out since many people cant seem to download from my Forums directly without a full membership.
here are 2 of em as a sample
I bet there are some nice tiles found here !
not sure what this could be....
Sorry for the double post.
Using one of Moops textures as a guide I visually recreated the Sonic Xtreme Boss stage cloud layout.
( had to match cloud patterns from the floor texture to the greyscale patterns to figure out the layout(for finding center area) using photoshop layers, Got lucky with the strategy since the clouds were easily made out by the pixel patterns. I don't think this will work in other situations though)
The only 2 that may be off are the 2 circled textures. The patterns did not match anywhere when overlapping the boss stage floor clouds to Moop's greyscale texture.
You are correct actually.
The clouds are thrown in there because... that's how they are loaded in memory. It works like this:
They are mapped to the playfield, displayed, then at the middle of the screen the pattern map switches out the grass, and the field rotation perspective gets "inverted" (don't have a better word for it cause I suck at 3d math, haha). The upper right plane, which is the one using the clouds, gets replaced with a copy of the plane directly south to it, since it's just a replacement of a map coordinate anyway. That's why you get that quarter of a ground when you look behind the waterfall.
So there are two maps: one of the clouds, one of the grass, but in VRAM both are loaded at the same place due to various reasons (memory partitioning, etcetera).
You can actually see the plane addresses in that satourne debug window screenshot... plane a to h: 0x20000, 0x22000, 0x24000, 0x2E000, 0x28000, 0x2A000, 0x2C000, 0x2E000. 0x2E000 is displayed twice.
The VDP2 can actually specify TWO rotation parameters, which get changed out mid-screen, hence it displays 2 "grounds", you can see that in the debugger window too: plane parameter A is the grass, while plane size parameter B has the graphics at 0x26000 repeating... those are the clouds.
No, they are 2H x 2V, they only appear squashed because you are not ripping out graphics, just loading a pattern table as a greyscale image.
Also, I'm not sure what you are trying to do with the Sonic Xtreme graphics. I've ripped them basically the same night the iso was out. They only use part of the clouds on the top, and the entire gfx at the bottom, you can read what size they really are with yabause, I'm late for work.
edit:fixed a million typos
Yeah I did the same using Saturone the same day they were out myself.
It seems Moop has found that the Sky clouds are not barrowed from the floor texture as was originally thought. The sky had its own VDP2 layout.
Moop also found a few other layouts excluding what we have.
(We as a community already have the sky and floor you posted, as well as Hud, Title and game over screens, But three are a few VDP2 layouts that are a mystery which is what Moop recently uncovered. One of them was made out to be the sky texture's cloud layout. which I used as a guide to re-creat that layout using what we have.
This is the floor texture we already have. you can see that the floor itself is covering up some clouds in the center, some are even cut in half.
And here is the new Cloud VDP2 layout that was found. The cloud pattern around the parameter is the same, but it also has the central cloud patern layout.
Hope that helps you to understand what I was on about in the previous post.
here are the other VDP2s that were found, I can make out the game over for sure in the first one. Another one has just got to be the title screen, (not sure which at this point) but there are 3 left over that don't seem to fit anything that we can visually see in game.
Perhaps they are different versions of title screens? the only way to know for sure is to get them rebuilt somehow.
Oh, I see. Where did you found those?
Come on over and check it out, the info is kind of scattered around page 1 of the post. http://www.sonic-xtreme.com/forums//viewtopic.php?id=515
It seems we have 4 games being hacked at the same time, Xtreme's 718, Sonic adventure 1 and 2 Beta, and also Jam,, wow. Busy community this summer!
So, what's stopping you from switching out the pattern data in the game files, so they are loaded in some position that you CAN dump with satourne?
Genius ,,, Pure Genius man ! Looks like we have all we need to finish modeling the stage for a release!
( I don't have the tree models so I'll be doing them from scratch.) Can't thank you and Moop enough.
Also a quote from Moop:
Wonderful! I look forward to bringing the map into the source engine.
@ Meat Miracle
All I did was cut half a pattern table from the end and paste it to the beginning, so the order of everything moved up by one.
For the clouds I moved around an extra table the same way. In theory, I could've edited the plane order too (it's at the start of SPRDATA.MUS), but this was way faster.
If the textures are loaded in memory, exchanging the pattern tables should get your graphics loaded. If not, they'll load but display garbage of various flavours.
Wow, this really flared up! I'm so glad that I was at least able to spark some interest for hacking Sonic Jam. I suppose that since everything I've ever wanted to do with Jam has already been done by someone else (though I helped at times!), I'll move on to a different game in my "collection".
NiGHTS into Dreams...
Sonic 3D Blast
and Sonic Jam
any suggestions on what I should attempt next?
You could try 3D blast here. I finished all acts for the first 3 Zones, although I have not uploaded some of them yet. ( I started waiting for a no collision detection hack to make things easy to rip levels without dieing every few minutes on later levels, I guess that I forgot about the whole thing all together after awhile)
Edit: Panzer dragoon 2 would be a lovely game to look into, I wonder what kinds of goodies can be found there.
I'm kinda surprised no one has done any hacking (that I've found) of any of the Panzer Dragoon games. Actually, if there was one thing that could get me off my ass to learn hacking, it would be that franchise. Oh, and NiGHTS. And Rayman. . .
Separate names with a comma.