Questions regarding background updates

[shin]

Thank you all for your valuable information.
I am a beginner.
I had some questions about updating the background, so I posted.

I use vertical mirroring. I am creating a game that scrolls vertically up and down, with the left/right movement range limited to between two nametables.
It is not a platformer, but it is like SMB3 with vertical mirroring.

1. I decided to use 16 x 16 metatiles, considering the capacity and so on.
If I update two name tables at the same time by 16 metatiles (128 tiles), the processing will not finish during vblank, so I wanted to divide the meta tiles into upper and lower parts and update them by 8 pixels in height.
If the level map consists of 16 x 15 metatiles, what steps would be required to update each 8 pixel high column?

2. Is there an efficient way to change the base address of a map as the scroll progresses?
To save space, I am planning to create several patterns of maps and combine them to build the level.

3. In the case of vertical scrolling, is it better to configure the height of one screen map with 15 metatiles? Or would it be better to configure it with 16 metatiles?


It would be greatly appreciated if you could explain the details.
Best regards,

—————
I use a translation website.

[tokumaru]

1- It actually is possible to update all 128 bytes during vblank, if you're willing to unroll the update loop. You could do something like this:

Code: Select all

.repeat 32, index
lda Buffer+index
sta $2007
.endrepeat

At 8 cycles per byte, updating 32 bytes would only take 256 cycles, so 1024 for all 128 bytes, plus a few more cycles to set the target address via $2006 for each of the 4 transfers. The vertical blank is 2273 cycles, so you'd actually only need about half of that for the tile updates, leaving plenty left for attribute updates and OAM DMA. Unrolled loops obviously take up more ROM space, but sometimes it's worth it.

If you still want to go with your original plan of splitting the updates in half, you can simply buffer all 128 bytes but use a flag or something to tell your vblank handler whether to update the top half or the bottom half.

2- That depends on the exact format you're using to store your maps, but generally speaking, if you have a 16-bit address stored in zero page, you can manipulate it as much as you want and also use it as a pointer.

3. Dividing your maps into 15 rows may simplify scrolling a bit, but it will make collision detection much harder. My advice is to stick to the powers of two, since that makes the conversion from object coordinates into map addresses much simpler (only shifts and adds), and spend a little more time fleshing out the scrolling logic, which is something you can complete early on and then forget about.

With vertical scrolling, the attribute tables are going to be your worst enemies. Make sure you understand which bits affect what, and that you're comfortable shifting bits and doing bitwise operations (AND, OR, XOR) before diving into attribute table updates.

[shin]

Thank you tokumaru-san for the useful advice.
I did not know there was such a thing as loop unrolling.
I would like to try loop unrolling, as it seems less confusing to update by metatile columns.
I think to select a specific column from a map of 16 metatiles high, I would use a variable that wraps up at 256, but so far the wrong tiles show up, or the tiles that show up by mirroring when scrolling remain on the screen when scrolling in the opposite direction (I think this is a different problem).
I will try to understand how it works.
I'm so glad to receive your advice.
Thank you.

[tokumaru]

Loop unrolling is a great way to speed up repetitive tasks, but depending on how much space you have it isn't always feasible.

Regarding the wrong tiles showing up, I can't say much without knowing exactly how the map data is arranged in the ROM. The general idea is that all the objects (including the camera) have pixel coordinates, and whenever you need to access a spot on the map that corresponds to these coordinates, you have to convert them into addresses according to the format and dimensions of the level map.

You said your levels are 2 screens wide, so I'll assume 32 metatiles per row (32 * 16 = 512), and a variable amount of rows depending on how tall each level is. If the topmost row is row 0, you'd use the following formula to calculate the address of any metatile:

MapBase + (PointY / 16) * 32 + (PointX / 16)

If you're using a more complicated format (which you probably should, because raw arrays of metatiles would eat up ROM space fast), such as 256x256-pixel chunks that you can reuse, you'd first have to calculate the address from where to read the chunk index, and then calculate the address of the specific metatile you need inside that chunk.

[shin]

Considering the capacity of NROM, I might be better to prioritize writing programs that take up as little space as possible (I am using NROM).
The calculation of the upper and lower bytes of coordinates confuses me, but I will try trial and error until I get used to it.
It is interesting to see the various ways to reduce data volume.
Thank you for your kind advice.