#47175 - ymalik - Wed Jul 06, 2005 4:01 am
Hello,
What is the maximum amount of memory that can be copied during vblank from EWRAM to VRAM using a single 32 bit DMA transfer call without the copying running into the vdraw period? Unless if I have a bug in updating my double buffer, 22 KB seems to be a lot.
Thanks,
Yasir
#47177 - LOst? - Wed Jul 06, 2005 4:30 am
You are trying to double buffering in Mode 3, aren't you?
#47203 - Cearn - Wed Jul 06, 2005 9:25 am
CowBite has a list of DMA timings with which you can calculate this. For EWRAM to VRAM it's 2 cycles/byte. If you have a whole VBlank to write, you can copy 68*308*4/2 = 83776/2 = 42 kB, give or take a few.
#47205 - sgeos - Wed Jul 06, 2005 11:34 am
Assuming you do nothing else.
-Brendan
#47213 - ymalik - Wed Jul 06, 2005 2:30 pm
| LOst? wrote: |
| You are trying to double buffering in Mode 3, aren't you? |
No, I was actually trying to scroll across a massive (10k x 10 k) 16 color image by changing the tiles instead of the tile map (176*256/2=22KB). And I wanted to do it Minish Cap style: instead of taking advantage of the wrapping around effect, the entire screen changes every 16 pixels (of course Minish Cap changes the tile map). According to the DMA timings chart, what I'm doing isn't feasible for 256 color mode.
#47248 - Miked0801 - Wed Jul 06, 2005 7:22 pm
Wow - you're kinda defeating the purpose of the scroll registers and tile map stuff aren't you? Hmmm. If you really are hellbent on doing this, you can do what I did for my first scroll enigne oh so long ago. Create a VCount function that starts about 1/2 way down the screen. Have it do the DMAing starting at the top. This will give you more than enough time to re-fill the entire screen. Beware though that this will eat a huge amount of your CPU time and won't be very interrupt safe for sound or multiplayer stuff as you're locked into an interrupt for a long time.
#47269 - ymalik - Wed Jul 06, 2005 10:58 pm
I didn't want to take advantage of the wrapping around effect of the scroll registers because I thought that wouldn't be suited for games; I would then be loading a new set of tiles at the location where the wrapping around occurs. This is what Mikhail's GBA GPS software does. But then again, changing the entire tile set isn't good of games either.
#47274 - Miked0801 - Wed Jul 06, 2005 11:25 pm
Our engine just reloads/decompresses chars along the edge (mode 0). Works fine.
#47277 - ymalik - Wed Jul 06, 2005 11:50 pm
So you take advantage of the wrapping around effect?
#47279 - tepples - Thu Jul 07, 2005 12:45 am
Pretty much every scrolling game since Super Mario Bros. (NES) takes advantage of tile map wrapping.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#47283 - ymalik - Thu Jul 07, 2005 1:17 am
Why do you think the Minish Cap doesn't take advantage of this? The tile map is changed everytime you move 16 pixels left/right or up/down; the tile set is optimized and is loaded according to the tile need.
#47285 - tepples - Thu Jul 07, 2005 1:49 am
If the map is rewritten whenever the camera moves by 16 pixels, then the used area of the map is restricted to a 32x22 tile area of VRAM. This would in theory allow tiles or other maps to be stored in the part of VRAM that is never shown.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#47329 - ymalik - Thu Jul 07, 2005 4:05 pm
Open up Minish Cap on VBA and go to the forest Minish area. Open up a couple of tile viewers and set them to different char blocks. As you move Link, you'll see tiles being loaded that were never previously there; the new tiles are being loaded according to the position of Link. Tiles are removed accordingly if Link goes out of a certain location and new tiles are brought in. Doing this, they get around the limitation of 1024 tiles in a 256x256 background. If a level had only 1024 unique tiles, scrolling would be not be difficult.
The trick to this is loading the tiles at certain locations in a char block. And the tile set, in 4 BPP mode, is optimized.
#47343 - Miked0801 - Thu Jul 07, 2005 9:13 pm
As I don't have this ROM, I can't see for myself, but question:
Do the tiles change in large groups in VRAM or kinda randomly? Go find (somehow ;) ) Harry Potter: Prizoner of Azkaban GBA, and watch how it loads its chars in. Same idea, more than 1024 chars (in some cases, close to 32K chars!), with the char loads happening as you near the edge of the map.
#47345 - ymalik - Thu Jul 07, 2005 10:05 pm
The tiles come in at large groups. What's amazing is that a tile is not repeated. However, in 8 BPP mode, the tile set does not appear to be optimized. This is fine considering most of the game runs in 4 BPP mode.
When you say chars, you mean tiles, not tile maps, right? This means that the tile set is not optimized.
#47352 - Miked0801 - Thu Jul 07, 2005 10:43 pm
Char - 1 8x8 vram slot.
And if the tiles are coming in in large groups, then yes, they aren't as optimized as they could be vram-wise. If they load them in 2xrow/2xcolumn chunks, they have to have 32x22 = 704 chars of vram available per page. BTW, is the game running in a bmp mode (mode3,4,5)? or a tile mode (0,1,2)?
#47354 - ymalik - Thu Jul 07, 2005 11:13 pm
When I meant the tile set not being optimized, I was refering to the Harry Potter game, not Minish Cap.
The tile set in Minish Cap is almost optimized. They are clever how and where they load the tiles. For example, when you see a large shoe or pot in the forest minish area, you will see a large shoe or pot in tile set in the char block. However, if you go into a tree, you'll that only one quarter of the inside of the tree in stored; the other three quarters are repeated by flipping that quarter. See for yourself.
#47355 - ymalik - Thu Jul 07, 2005 11:24 pm
And the whole game runs in tile mode. I guess that 95 per cent uses 16 16 color palettes.
#47431 - Miked0801 - Fri Jul 08, 2005 7:39 pm
Lol - as opposed to our system (HPPOA). If the tile is in VRAM already, don't load it, else load it into the first available VRAM slot (which includes tiles already freed ).
I'll have to check it out if I can find a ROM :)
#47447 - ymalik - Fri Jul 08, 2005 11:32 pm
What's amazing is that if they have a bunch of trees on screen, only one tree will appear in the char block. Things like grass and rocks only occur once in the char block. They do a great job of utilizing all 16 palettes. For example, a large shoe or mushroom is composed of multiple palettes.
#47566 - Miked0801 - Sun Jul 10, 2005 10:54 pm
Again, when we have time, we quite often will overlay 2 BG layers in the same area in double the palettes on a char to 30. Each char can also have a different palette within an object. We do not dynamically load BG palettes on the fly though as all systems we've thought of and examined limit the on-screen palettes too much.
#47580 - tepples - Mon Jul 11, 2005 1:03 am
| Miked0801 wrote: |
| Again, when we have time, we quite often will overlay 2 BG layers in the same area in double the palettes on a char to 30 |
I thought of this once, but if you're using two different tiles on top of each other, then why not just use a 256-color layer, which would let you dip into the otherwise unused "transparent" colors (16, 32, 48, ..., 240)?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#47664 - Miked0801 - Tue Jul 12, 2005 1:52 am
Because the VRAM tiles for the entire layer would be doubled instead of just in a couple of small key areas. Using the transparant colors for extra colors we do often with sprites (17th palette trick), but haven't done yet with BGs due to teh severe strain on our BG VRAM usage.
#47827 - ymalik - Wed Jul 13, 2005 11:02 pm
| Miked0801 wrote: |
| Again, when we have time, we quite often will overlay 2 BG layers in the same area in double the palettes on a char to 30. Each char can also have a different palette within an object. |
Minish Cap uses two backgrounds to give a "3D" effect. For example, to have the ability to walk behind the green part of a tree. The layer with the green part of the tree has a higher priority.
#47855 - Miked0801 - Thu Jul 14, 2005 2:03 am
Yep - us too :)