gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

DS development > To meta tile, or not to meta tile

#178012 - fluffypants - Wed Jul 17, 2013 6:05 am

So I'm putting the finishing touches on my NDS Tile Editor, Grout, and need to make a decision about saving map data. My tiles blocks are 16x16, split to 8x8, and then stuffed into BG_TILE_RAM. No big surprises there. Bonus ASCII illustration:

Code: Select all

 -------           -------
|        |        | 0 | 1 | 
| Tile 0 |  --->   ---+---
|        |        | 2 | 3 |
 -------           -------
Currently in the editor I'm storing the map data as the original 16x16 tile indices, which saves me a little on ram, and I'm just transposing to the correct 8x8 indices when I copy from the map to the BG_MAP_RAM. This works, but is definitely slow (not enough that I need to refactor, but enough that I wouldn't want to do it this way in my game). It's mostly slow because I have to account for the meta tile h/v flips.
Given the previous tile illustration, if I wanted to flip that tile horizontally, I would need to re-position the meta tile like the following and set the hflip bit on each piece:

Code: Select all

 -------                   -------  
| 0 | 1 |                 | 1 | 0 | 
 ---+---    --H Flip-->    ---+---  
| 2 | 3 |                 | 3 | 2 |
 -------                   -------
Which means that every time I set a map value on the hardware it has to check all the h/v flip edge cases and sort the meta tiles accordingly. Quite slow.

So with those details out of the way, my questions are:

1. Am I going about this incorrectly, because it seems like this is a bad way to shuffle map data to the hardware?
2a. Should I take the 4x hit on ram and just store my maps as 8x8 meta tile indices so that copying to hardware doesn't require any additional logic?
2b. Am I overly concerned about having the CPU process map data during copies?

Feel free to question my entire approach to this, I want to do it correctly. Thanks in advance.

#178013 - Dwedit - Wed Jul 17, 2013 1:34 pm

Since you probably won't be changing more than 32 metatiles per frame, speed really doesn't matter so much here.

#178014 - fluffypants - Wed Jul 17, 2013 5:09 pm

Thanks Dwedit for the quick reply!

I should also mention, that I have 4 BGs in use, 3 for standard stuff and 1 for weather effects in my game. I'm also going to be scrolling the BGs around my character using a BG_64x32 setup with preloading around the offscreen edges. I was under the impression that meant I would need to update all tiles on screen in some cases. Which is 192 tiles (16*12), on 4 BGs, giving me 768 tiles ( 3072 meta tiles! ). I may just be thinking about how to scroll BGs incorrectly, and I hope I'm wrong.

You mentioned 32 meta tiles, which makes me think you are considering the edge loading too. Am I approaching this problem wrong?

#178015 - Dwedit - Wed Jul 17, 2013 5:23 pm

At 66MHz, you have over 1 million clock ticks per frame. Let's say it takes your code 100 clock cycles to update a single metatile. If you constantly update 3072 metatiles, that's about 30% CPU usage for some hypothetical slow tile update routine, for that single frame.
But you only really need to update up to 96 metatiles per frame (newly exposed tiles scrolling onto the screen diagonally), and your code for updating metatiles probably won't be so slow that it takes 100 clock cycles, maybe 30 cycles would be more reasonable. At those numbers, it's 0.2% CPU usage instead.
The only time you need to update 3072 metatiles is when you initially display the entire area.

#178017 - fluffypants - Wed Jul 17, 2013 6:52 pm

At those numbers, it's 0.2% CPU usage ...
Well that certainly puts things in perspective. Thanks for the help Dwedit. I think I'll go ahead and deal with meta tiles on the fly then.