nesdev.org

tepples wrote:Are those effects emulated properly in a debugging emulator like NO$SNS? If so, open them and see how they're arranging BG3.

Nope.png, but you can still watch the map in the vram viewer.

tomaitheous wrote:

AWJ wrote: Tomathious is a bit confused. The "third tilemap" used in offset-per-tile modes isn't a full 32x32 tilemap; it's only 32x2. The first row contains the horizontal offsets for each full column of the other tilemap(s); the second row contains the vertical offsets for each full column.

For one... http://wiki.superfamicom.org can eat a d*ick. Ughh. And secondly, why can't documents and sites contain a bit of redundancy in their information? It helps to understand stuff. Looking at what you said, and re-looking over the official dev manual, I can see that now. But even the official documents are crappy in this respect. The example format given for the 'map' (which isn't even a map anymore, it's just a small offset scroll table that just happens to share the same base pointer as BG3 for other modes), doesn't indicate that it's limited to just two rows data.

It is a tilemap in most respects; the PPU just ignores the electron beam position when deciding what row of it to read. Other than that, it is affected by all the registers that affect BG3. If you set BG3 to use 16x16 tiles then the scroll columns will have 16-pixel granularity instead of 8-pixel (for all the use that is...). Changing the BG3 scroll registers changes exactly where in VRAM the table gets fetched from (this is how you do raster splits; you can't overwrite the offset table in mid-frame because it's in VRAM and the CPU can't access VRAM outside of VBlank, but you can upload several tables during VBlank and then switch between them by HDMAing to the BG3 scroll registers)

AWJ wrote: It is a tilemap in most respects; the PPU just ignores the electron beam position when deciding what row of it to read. Other than that, it is affected by all the registers that affect BG3. If you set BG3 to use 16x16 tiles then the scroll columns will have 16-pixel granularity instead of 8-pixel (for all the use that is...). Changing the BG3 scroll registers changes exactly where in VRAM the table gets fetched from (this is how you do raster splits; you can't overwrite the offset table in mid-frame because it's in VRAM and the CPU can't access VRAM outside of VBlank, but you can upload several tables during VBlank and then switch between them by HDMAing to the BG3 scroll registers)

Hmm.. I'm trying to visualize this. So the v_offset of BG3 is essentially where the two rows are going to be read from? If you have a v_offset of 0x000, the first two rows of BG are used? If the v_offset was 0x010 (16 pixels), then the next two set of rows would be used instead? So, assuming I understand that correctly, when the BG3 v_offset is changed mid screen to point to next/new/different set of rows - then those values are used instead of the tile offsets as it's drawing the next map line? That's really cool. So you get both; full map tile offset, and just regular column scrolling. Either one, depending on how much resource you want to put into it.

tomaitheous wrote: Now that that's clear, why the hell is Aladdin slowing down for on the snake boss??? That makes even less sense now.

Capcom can't do anything without slowdown.