#149375 - load*,8,1 - Sat Jan 19, 2008 11:40 am
In my OpenTTD project I'm currently trying to optimize memory usage. But I'm still a bit confused concerning the video modes. I want to pack everything as tight as possible. Here's what I need:
- a 48 KB memory block mapped as a bitmap to Main Screen
- a 48 KB memory block mapped as a bitmap to Sub Screen
- an approximately 112 KB continuous memory block
- not mandatory, but would be nice: 10KB for the debug console
- the remaining memory (~448KB) in a continuous chunk
Is this asking too much? I had a like at the possible combinations and it seems like I'm always wasting way too memory.
#149379 - PypeBros - Sat Jan 19, 2008 12:01 pm
It seems not to be directly compatible with the usual setup of the VRAM, at least. and it will mostly depend on what you plan to do with your "remaining one chunk".
You can (afaik) mix bitmaps, tiles and maps in a single 128K BG bank. You might setup bank E for main BG (64K) and save 128K banks for any purpose you'd like in LCD mode ...
Though, when one use a dynamic bitmap, we typically like to have double buffering to avoid flickering, so you might like to have 128KB at hand anyway.
_________________
SEDS: Sprite Edition on DS :: modplayer
#149389 - tepples - Sat Jan 19, 2008 1:31 pm
Why does this sub screen have to be 8 bits per pixel? Would you like to learn how to treat a 4-bit tiled background as a pseudo-bitmap background, so you can do a frame buffer in 26 KiB of VRAM?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#149390 - load*,8,1 - Sat Jan 19, 2008 1:37 pm
If my dream setup is not possible, I would also be satisfied to simply put the main screen bitmap and sub screen bitmap as high in memory as possible. But do I read the specifications correctly that the highest I could put the sub screen is bank C?
Edit (just noticed your post):
| tepples wrote: |
| Why does this sub screen have to be 8 bits per pixel? Would you like to learn how to treat a 4-bit tiled background as a pseudo-bitmap background, so you can do a frame buffer in 26 KiB of VRAM? |
OpenTTD uses a 256 color palette. So I'm not sure if I understand your suggestion. If only using 26 KiB would be possible that would be great. Maybe a little explanation about how the graphics in OpenTTD work can help:
The blitter writes sprites to a surface whenever something changes. It then marks that area as "dirty" and the video driver copies those dirty areas over to the frame buffer at regular intervals. Note that with this setup it is not possible to use double buffering.
What I want to use the remaining VRAM for is mainly the sprite data. My tests are indicating that I'll need ca. 500KB for it to run smoothly. More would be preferred of course. If it can't be a continuous chunk at all I might have to write an allocator for it.
#149419 - Cydrak - Sat Jan 19, 2008 10:31 pm
How about this?
- Banks F, G, A = 2*16K + 128K = 48K main bitmap with 112K spare
- Banks B, C, D, E = 3*128K + 64K = 448K spare in LCD mode
- Banks H, I = 32K + 16K = 48K sub bitmap
Something I noticed, but haven't seen done, is that F and G can map anywhere in the first 128K. The catch is, they mirror in two places:
| Code: |
A, VRAM_OFFSET(0): [AAAAAAAA--------]
A, VRAM_OFFSET(1): [--------AAAAAAAA]
E (any offset): [EEEE------------]
F/G, VRAM_OFFSET(0): [X-X-------------]
F/G, VRAM_OFFSET(1): [-X-X------------]
F/G, VRAM_OFFSET(2): [----X-X---------]
F/G, VRAM_OFFSET(3): [-----X-X--------]
|
So, it should be possible to make F and G contiguous with A (there seem not to be any special constants for this):
| Code: |
// [----FGFGAAAAAAAA] (160K, starting at 96K)
VRAM_F_CR = VRAM_ENABLE | VRAM_F_MAIN_BG | VRAM_OFFSET(2);
VRAM_G_CR = VRAM_ENABLE | VRAM_G_MAIN_BG | VRAM_OFFSET(3);
vramSetBankA(VRAM_A_MAIN_BG_0x06020000);
// If you need to use a console, this should offset all map and tile base past the hole, making them start at 2*64K = 128K (bank A).
DISPLAY_CR |= DISPLAY_SCREEN_BASE(2) | DISPLAY_CHAR_BASE(2);
|
Due to the hole, the first usable bitmap base is 6(*16K). (According to GBAtek, there's no global offset, like above, for bitmaps. You wouldn't need one since the bitmap base value is wide enough to cover all 512K.)
#149511 - load*,8,1 - Mon Jan 21, 2008 11:38 am
Thanks for the tips! I didn't know that the VRAM setup is so flexible. I was thinking that nothing beyond the libnds was possible. I do understand it much better now and can experiment with some possible solutions. :)