Author
|
Topic: Unirally/Uniracers level viewer (Read 2 times)
|
Spinal
Guest
|
 |
« Reply #15 on: November 23, 2009, 07:48:19 am » |
|
*HUUUUUUGE bump*
A year ago, after I got stuck, I decided to try something radical: I contacted Mike Dailly, one of the programmers of Unirally. I got a reply after a few years which was really useful (in a way).
He explained that the levels are compressed using "Rob Northern Compression", which conveniently start with the magic bytes "RNC". I extracted the files and was able to find a program that could decompress it, but it wasn't working for me (16-bit program on a 64-bit system). So I gave up again.
However, because I still want this project to work, I started working on it again. I don't know why I didn't think of it sooner, but using DOSbox I managed to decompress the RNC files, then wrote a viewer for it, based on a comment from Mike that levels are 256 tiles wide.
And yes: it sort of works!
Before I tried to write a level viewer I made some level maps by hand, and when I overlay the map I made on the "map" the viewer produces, they overlay perfectly!
I mentioned earlier that the level is build up out of 16x16 tiles, this is not true. As it appears now, the level is build up out of 64x64 blocks. The tile map though consists of 8x8 tiles. I currently do not know yet how these relate.
I'll play around with a debugger some more, see if I can figure this stuff out.
|
|
|
|
« Last Edit: November 23, 2009, 11:26:22 am by Spinal »
|
|
|
|
GenoBlast
Guest
|
|
« Reply #16 on: November 23, 2009, 08:37:56 pm » |
|
Wow, that's pretty awesome that he actually responded. Nice to know that you're making progress.
Good luck with this project! I've always loved Uniracers.
|
|
|
|
|
Spinal
Guest
|
|
« Reply #17 on: November 25, 2009, 04:16:54 am » |
|
Thanks  I'll do my best to finish it! I could use some more help though, since I don't know much about how this stuff works. Okay, so I know for sure that one byte in a level file (aka in the decompressed ROM) corresponds to a 64x64 tile. I also have the full set of 8x8 tiles, with a total of 1280 tiles. One of the 64x64 tiles looks like this:  On the left is what it looks like "real size", on the right is what the tile is made up of. Some of the tiles are flipped, some are not (checked by corrupting them non-symmetrically) I'm hoping someone here knows if and if so, how this would be stored in the ROM. If the game knows how to create this bigger tile, it must be stored somewhere, right? |
|
|
|
|
KaioShin
Guest
|
|
« Reply #18 on: November 25, 2009, 04:19:59 am » |
|
You should read up on Tilemaps. They map various small tiles to the screen to form a complete picture. It's very possible though that the tilemaps are generated by code from a completely different data structure. You might to have to get your feet wet at debugging.
|
|
|
|
|
Spinal
Guest
|
|
« Reply #19 on: November 25, 2009, 05:12:48 am » |
|
I've read a bit on them, from this document, but that doesn't seem to apply here. For example, it says "The map is 2 dimensional array (32x32, 64x32, 32x64 or 64x64) of tile indexes." but the size doesn't match. It also gives 10 bits for the tile index, but that means the tile map can only contain 1024 tiles, whereas Unirally has 1280 and thus needs 11 bits. I'll search for some other documents though, one source is never enough |
|
|
|
|
Nightcrawler
Guest
|
|
« Reply #20 on: November 25, 2009, 08:38:10 am » |
|
For goodness sake man, please use VSNES and examine a savestate so you can learn factually exactly how the screen is put together and constructed. It will certainly be within the tilemap restrictions the hardware has in place. In VSNES, you can see VRAM where the tilemap is stored, see all the registers, see where the graphics are stored, what tile mode the system is in etc. Quit guessing when you can find out for sure once and for all. You may also find the screen is constructed one way, but the game actually does store objects which can be any grouping of tiles together that essentially function as a unit. This is mostly done for sprites and not background tiles, but there's no reason why the game couldn't function that way. In the end however, it will still be broken down to the hardware screen construction limitations though. |
|
|
|
|
Spinal
Guest
|
|
« Reply #21 on: November 25, 2009, 09:40:49 am » |
|
I've looked at vSNES many times, but it doesn't tell me much, because I don't know what half of it means or where to look...
I can see the tilemap in the MemViewer, organised in 16x16 tiles, so already different than in the ROM.
I can see the scene in the SceneViewer (BG1) which says the tiles are 16x16 and the index corresponds (naturally) to the MemViewer. Under Info it says the tile base is at 4000h (tile size 16x16) and the tilemap base is at 1800h (32x32). But what does this mean? It's at 4000h in the VRAM or somewhere else?
And then what? Like I said: I'm new to this so I don't know where to go next...
|
|
|
|
|
creaothceann
Guest
|
|
« Reply #22 on: November 25, 2009, 10:03:21 am » |
|
I've looked at vSNES many times, but it doesn't tell me much, because I don't know what half of it means or where to look...
You can get one (very good) version of the facts from anomie's register doc. There are other docs that can explain things in a different way, but pretty much all of them contain some factual errors. (which doesn't make them useless though) I can see the tilemap in the MemViewer, organised in 16x16 tiles, so already different than in the ROM.
vSNES is never game-specific. It uses the savestates (i.e. the state of the SNES console), and the ROM data is used only in some cases. Therefore, all it can tell you is how things are laid out in VRAM, OAM etc. to form the currently visible scene. This might or might not be the same as the layout in the ROM. [...] Under Info it says the tile base is at 4000h (tile size 16x16) and the tilemap base is at 1800h (32x32). But what does this mean? It's at 4000h in the VRAM or somewhere else?
Yep, VRAM. VRAM contains the graphics (tiles) and the layout (tilemaps). There's one tilemap for every BG (located at "tilemap base {address}"). Every tilemap has 10 bit reserved for the index of each tile. Tile 0 would be located at "tile base {address}", and the location of the following ones depend on the BG's bit depth. To quote anomie for the "large tiles" mode: "If the appropriate bit of {register} $2105 is set, each "tile" of the tilemap actually
corresponds to a 16x16 pixel block consisting of Tile, Tile+1, Tile+16, and
Tile+17. In this case, the 32x32 tile tilemap codes for a 512x512 pixel screen
rather than a 256x256 pixel screen as normal. Thus, using both 16x16 tiles and
the 64x64 tilemap each BG can be up to 1024x1024 pixels. There is no wrapping
like there is for 16x16 sprites: if you specify Tile=$02FF, you'll get $02FF,
$0300, $030F, and $0310 (as opposed to $02FF, $02F0, $020F, and $0200 you might
otherwise expect). $03FF goes to $0000, of course. Flipping in this mode flips the
whole 16x16 tile, not just the individual 8x8 tiles." |
|
|
|
« Last Edit: November 25, 2009, 10:08:27 am by creaothceann »
|
|
|
|
Spinal
Guest
|
|
« Reply #23 on: November 25, 2009, 10:55:22 am » |
|
Okay, I'll have a look at the register doc. I guess the things related to VRAM are the most important sections? vSNES is never game-specific. It uses the savestates (i.e. the state of the SNES console), and the ROM data is used only in some cases.
Therefore, all it can tell you is how things are laid out in VRAM, OAM etc. to form the currently visible scene. This might or might not be the same as the layout in the ROM. I knew that much  all I meant to say was that in the VRAM it was already different from how it is stored in the ROM. VRAM contains the graphics (tiles) and the layout (tilemaps). There's one tilemap for every BG (located at "tilemap base {address}"). Every tilemap has 10 bit reserved for the index of each tile. Tile 0 would be located at "tile base {address}", and the location of the following ones depend on the BG's bit depth. Okay, sounds good. Is there any way to set a breakpoint on VRAM writes to a specific address in Geiger's Snes9x (or any other tool)? "If the appropriate bit of {register} $2105 is set, each "tile" of the tilemap actually
corresponds to a 16x16 pixel block consisting of Tile, Tile+1, Tile+16, and
Tile+17. In this case, the 32x32 tile tilemap codes for a 512x512 pixel screen
rather than a 256x256 pixel screen as normal. Thus, using both 16x16 tiles and
the 64x64 tilemap each BG can be up to 1024x1024 pixels. There is no wrapping
like there is for 16x16 sprites: if you specify Tile=$02FF, you'll get $02FF,
$0300, $030F, and $0310 (as opposed to $02FF, $02F0, $020F, and $0200 you might
otherwise expect). $03FF goes to $0000, of course. Flipping in this mode flips the
whole 16x16 tile, not just the individual 8x8 tiles."
I'll look into that Thanks for your help |
|
|
|
|
creaothceann
Guest
|
|
« Reply #24 on: November 25, 2009, 11:55:24 am » |
|
Okay, I'll have a look at the register doc. I guess the things related to VRAM are the most important sections?
Yeah, though some things like VRAM access registers ($2118 etc) might also be useful. Note that vSNES displays VRAM addresses in byte units, but one (or more?) SNES registers need the address in word units. Is there any way to set a breakpoint on VRAM writes to a specific address in Geiger's Snes9x (or any other tool)?
I haven't worked with Geiger's before, but probably. You could try bsnes (the debugger version) too. |
|
|
|
|
Nightcrawler
Guest
|
|
« Reply #25 on: November 25, 2009, 02:32:29 pm » |
|
Remember the VRAM address written to register $2116 is always half of the effective address you see in VSNES. For example, if VSNES says tiles start at $e000, in game code, they will write $7000 to $2116. VSNES gives the effective byte address. The SNES addresses VRAM by word due it's multi-chip hardware layout, but I digress. Just keep that in mind. It fouls most people up. |
|
|
|
|
|
RHDN Forum Archive
