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 > How to fully utilize all Video capabilities on DS?

#148724 - JanoSicek - Wed Jan 09, 2008 11:30 am

I want to write a nice 'engine' that could potentially be used for coding some nice 2D scroller gamer on DS. I disregard 3D completelly.

The VRAM banks assigment I want to use is:
VRAM A - MAIN BG 0x600 0000
VRAM B - MAIN SPRITE 0x642 0000
VRAM C - SUB BG 0x620 0000
VRAM D - MAIN BG 0x602 0000

VRAM E - MAIN SPRITE 0x640 0000
VRAM F - MAIN EXTENDED PALETTES 0..1
VRAM G - MAIN SPRITE EXTENDED PALETTES 0..1
VRAM H - SUB EXTENDED PALETTES 0..3
VRAM I - SUB SPRITE 0x660 0000

This would map me this memory:
MAIN BG: 256kB in one block from 0x600 0000
SUB BG: 128kB in one block from 0x620 0000
MAIN SPRITE: 192kB in two blocks
SUB SPRITE: 16kB in one block
And some palettes.

Now my questions:
As I mapped only 16kB for extended palettes, does this mean that I have only 2 palettes that will be used for backgrounds 0&1 ?
What will display on background 2&3?
I believe that there is some shift register with which I can map the other backgrounds to use the same palettes...

How the sprite ext. palettes work? As there is no background layer for sprites, and I have 2 sprite palettes on main screen... what do they do? Or is the second palette (second 8kB) ignored and the first one is always used?

If I want to use sprite palettes on BOTH screen, do I need to assign separate banks for ext palettes for each screen, even though they only need 8kB each?

And more -- to use ext. palettes for sprites on sub screen, I need to use bank I, and then only bank I can use for sprites themselves is bank D, which is 128kB (a waste for me)

If anyone can answer me, or give me any tips, that would be welcome. Thanks!

#148740 - josath - Wed Jan 09, 2008 6:16 pm

Just a suggestion, but you may be thinking about this the wrong way. Personally, I'd write the engine first, and then later worry about squeezing every last KB out of VRAM.

#148743 - JanoSicek - Wed Jan 09, 2008 6:44 pm

Funny thing, that everyone is telling me the same.

However as there is terrible lack of documentation of how DS internally works (at least to me!) I first want to know exact capabilities and space in VRAM is one of this.

Currently I am writting (yet another boring) scrolling engine with dynamic loading of tiles, where the size of map is unlimited, and the number of tiles per layer is limited only by 65536.

If you want 4 layers, you need to store at least 3300 tiles in your cache, so you need at least 206kB of VRAM for tiles, that means you need 2 main banks.

My own solution scrolls 3 layers, uses 4th background for 256x192 bitmap and has double maps for double buffering. First I had to compute whether I can squeeze enough bits in VRAM to handle all this.

In the end I managed, and this is the way I currently allocated the tilebases:
0: 4 maps 64x32
1: 2 maps 64x32 and first 128 tiles for layer 0
2-4: 768 tiles for layer 1
5-8: 1024 tiles for layer 2
9-12: 1024 tiles for layer 3
13-15: 256x192 framebuffer for layer 4

I scroll the map in 6 miliseconds, and I can move the viewpoint to an arbitrary position in about 16 miliseconds (1 frame), that's for one layer.

Scrolling of 3 layers is about 18ms, which is more than 1 frame, and this worries me. A lot of time is spent managing the LUT for cache to find out which tiles to release and where I can load new ones. I implement this as sorted array, but it looks like I will have to move to hashes.

Does anyone have dynamic tile loading implemented and can show me his code? I could not find any examples, the PERN project is missing the last chapters.

#148754 - Dwedit - Wed Jan 09, 2008 9:57 pm

Since you can very quickly write new graphics into VRAM, you only really need enough VRAM for what is immediately on the screen. You only need large VRAM when you have a wide variety of graphics on the screen.

I'd make VRAM into one big graphics cache. Load in graphics as needed, dump out graphics that haven't been used in a while, and no need to recopy what has been displayed recently.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

#148755 - tepples - Wed Jan 09, 2008 10:04 pm

All games for Sega Master System, Game Gear, TurboGrafx-16, and Sega Genesis, as well as almost all Super NES games and many GBA games, use 16-color graphics for backgrounds and sprites. If you use 16-color graphics in your DS game engine, you will have 64 palettes (16 main bg, 16 main sprite, 16 sub bg, 16 sub sprite) without using the extended palettes.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.