+  RHDN Forum Archive
|-+  Romhacking
| |-+  ROM Hacking Discussion
| | |-+  Stupid, STUPID Mode-7 gfx...Help. :)
Pages: [1]
Author Topic: Stupid, STUPID Mode-7 gfx...Help. :)  (Read 2 times)
Bongo`
Guest
« on: December 26, 2009, 12:48:45 pm »
  OK, I'm in a new world now. Mode-7 storage, format and display. I have studied the documents currently on the web but I'm still having a few issues with the format, Tilemap ( or the lack there of ) and tile data storage. I have played with realtime data in a game. I have dumped the data from Vram and split the WORDs into two different BYTE files and see that each pixel has a a NameTable byte.

OK. This is where it gets weird to me.
EX:
  I change NameTable value at pixel $00 from $00 to $04.

  This now points at the # $04 tile instead of the # $00 tile.
Why does ALL of the tile change on screen instead of just the one pixel???
The whole 8x8 tile changes instead of just the top/left pixel on screen???

Any help would be appreciated!
creaothceann
Guest
« Reply #1 on: December 26, 2009, 04:15:15 pm »
Quote from: Bongo` on December 26, 2009, 12:48:45 pm
I change NameTable value at pixel $00 from $00 to $04.

This now points at the # $04 tile instead of the # $00 tile.
Why does ALL of the tile change on screen instead of just the one pixel???
The whole 8x8 tile changes instead of just the top/left pixel on screen???
That's not completely possible.


Mode7 summary:

- one background of 128x128 tiles
- tilemap can select from 256 tiles --> tilemap is 128x128 bytes stored at even VRAM addresses (0, 2, 4, ...)
- a tile is 8x8 pixels in 256 colors, i.e. 64 bytes
- 256 tiles --> 16384 bytes stored at odd VRAM addresses (1, 3, 5, ...)


Changing the tilemap changes the tile displayed at the corresponding area.
Changing the tile will produce changes in all tilemap entries using that tile.
Bongo`
Guest
« Reply #2 on: December 26, 2009, 07:16:37 pm »
Quote from: creaothceann on December 26, 2009, 04:15:15 pm
Quote from: Bongo` on December 26, 2009, 12:48:45 pm
I change NameTable value at pixel $00 from $00 to $04.

This now points at the # $04 tile instead of the # $00 tile.
Why does ALL of the tile change on screen instead of just the one pixel???
The whole 8x8 tile changes instead of just the top/left pixel on screen???
That's not completely possible.


Mode7 summary:

- one background of 128x128 tiles
- tilemap can select from 256 tiles --> tilemap is 128x128 bytes stored at even VRAM addresses (0, 2, 4, ...)
- a tile is 8x8 pixels in 256 colors, i.e. 64 bytes
- 256 tiles --> 16384 bytes stored at odd VRAM addresses (1, 3, 5, ...)


Changing the tilemap changes the tile displayed at the corresponding area.
Changing the tile will produce changes in all tilemap entries using that tile.

I've read and undeerstand up to that part of the same document you  got that info from. I guess I'm still a bit lost how the storage works. Thanks for the help BTW...

Ok..

0 2 4 6 8 A C E = Map data
1 3 5 7 9 B D F = Tile data.   

This is where I believe I am getting lost. Smiley

128x128 Name table entries... ok,
the other 128x128 ( Odd ) BYTE entries are what??
Char data or pixels??? It should be pixels, correct?

From what I understand...

// Vram[$00] = Pixel's location
// Vram[$01] = Pixel's Color index into Pal register

I changed an EVEN value ( Nametable entry ) and a Tile changed... Like it would a normal tile map / gfx formula...

My question is what is the ODD value pointing at if it's NOT a pixel
because when one EVEN value is changed, the 8x8 tile ONSCREEN changes.

I have like 2 starnds of hair left. Sad Thanks for the help...

Oh yeah, of course everything in Vram is clear! Nothing exist other than
the Map/GFX data...
creaothceann
Guest
« Reply #3 on: December 26, 2009, 08:47:30 pm »
Quote from: Bongo` on December 26, 2009, 07:16:37 pm
0 2 4 6 8 A C E = Map data
1 3 5 7 9 B D F = Tile data.   

128x128 Name table entries... ok,
the other 128x128 ( Odd ) BYTE entries are what??
Char data or pixels??? It should be pixels, correct?
It's the pixels of the 256 tiles - not 128x128, but 8x8x256.


In the SNES there are two RAM chips for VRAM connected to the PPUs, each 32 KB in size. All emulators (except Super Sleuth) handle this by interleaving them into one 64 KB mix, since all BG modes except Mode7 use VRAM as one continuous block.

For Mode7, the tilemap (128x128) is in the first chip and the tiles (8x8 x 256) are in the second chip. The rest of VRAM is as usual.


Quote from: Bongo` on December 26, 2009, 07:16:37 pm
// Vram[$00] = Pixel's location
// Vram[$01] = Pixel's Color index into Pal register
It's more like this:

VRAM[1] = byte 0 of the first 8x8 tile
VRAM[3] = byte 1 of the first 8x8 tile
VRAM[5] = byte 2 of the first 8x8 tile
...
VRAM[125] = byte 62 of the first 8x8 tile
VRAM[127] = byte 63 of the first 8x8 tile
VRAM[129] = byte 0 of the second 8x8 tile
... and so on.

The tile pixels are arranged like this:
byte 00 = tile's top left pixel
byte 07 = tile's top right pixel
byte 56 = tile's bottom left pixel
byte 63 = tile's bottom right pixel


Quote from: Bongo` on December 26, 2009, 07:16:37 pm
I've read and undeerstand up to that part of the same document you  got that info from.
Just for the record, I most often use anomie's register document.
Bongo`
Guest
« Reply #4 on: December 26, 2009, 09:40:38 pm »
Quote from: creaothceann on December 26, 2009, 08:47:30 pm
Quote from: Bongo` on December 26, 2009, 07:16:37 pm
0 2 4 6 8 A C E = Map data
1 3 5 7 9 B D F = Tile data.   

128x128 Name table entries... ok,
the other 128x128 ( Odd ) BYTE entries are what??
Char data or pixels??? It should be pixels, correct?
It's the pixels of the 256 tiles - not 128x128, but 8x8x256.


In the SNES there are two RAM chips for VRAM connected to the PPUs, each 32 KB in size. All emulators (except Super Sleuth) handle this by interleaving them into one 64 KB mix, since all BG modes except Mode7 use VRAM as one continuous block.

For Mode7, the tilemap (128x128) is in the first chip and the tiles (8x8 x 256) are in the second chip. The rest of VRAM is as usual.


Quote from: Bongo` on December 26, 2009, 07:16:37 pm
// Vram[$00] = Pixel's location
// Vram[$01] = Pixel's Color index into Pal register
It's more like this:

VRAM[1] = byte 0 of the first 8x8 tile
VRAM[3] = byte 1 of the first 8x8 tile
VRAM[5] = byte 2 of the first 8x8 tile
...
VRAM[125] = byte 62 of the first 8x8 tile
VRAM[127] = byte 63 of the first 8x8 tile
VRAM[129] = byte 0 of the second 8x8 tile
... and so on.

The tile pixels are arranged like this:
byte 00 = tile's top left pixel
byte 07 = tile's top right pixel
byte 56 = tile's bottom left pixel
byte 63 = tile's bottom right pixel


Quote from: Bongo` on December 26, 2009, 07:16:37 pm
I've read and undeerstand up to that part of the same document you  got that info from.
Just for the record, I most often use anomie's register document.

Ok, that is just what I thought. Like I mentioned earlier, I de-interleaved the Vram data from a Zsnes ZST file and I got the tile and map data. I guess I wasunderstanding it to some point, just got side tracked after changing the one map value and seeing a complete tile change. Oh well, time to code a demo and see what it really works like. Thanks for the doc. That is a new one for me.
Pages: [1]  


Powered by SMF 1.1.4 | SMF © 2006-2007, Simple Machines LLC