#91333 - Dark Knight ez - Thu Jul 06, 2006 2:29 pm
Hey everyone.
Having gotten tiled backgrounds to work, I was kind of dissapointed that even though I assigned a 128kb VRAM to them, I could only use the first 64kb (as is the case on GBA). That is, my quick tests indicated this. If someone can tell (and show) me otherwise, please do so.
It wouldn't be so much of a concern, if it weren't for the fact that I need to output more graphics, and doing this only via the sprites would not be enough. I will most likely need to display more than 128 tiles of graphics.
My question to you all is this:
How can I boost the throughput of 2D graphics?
- Am I wrong, and can more graphics be stored in the VRAM bank and utilized by the tiled backgrounds? If I could utilize the entire 128kb for backgrounds, my problem would be solved.
- Is it possible to use an affine background as framebuffer (to complement sprites) in the 64kb not utilized currently by the regular tiled backgrounds? I have seen an affine background used as a framebuffer, but can it be relocated to the last 64kb of the 128kb VRAM?
I know I could probably use the screen-capture functionality, but I'd rather not have to worry about displaying one frame, while the DS is already busy doing logic and such of the next frame.
#91340 - parrot_ - Thu Jul 06, 2006 4:02 pm
With tiles you've got a limit of 1024. For sprites, reuse them :). Keep a map of all their positions and when their positions are in the visible area of your map move the sprites X & Y, or you could write a dynamic sprite allocator.
_________________
Squak! etc.
My Blog
#91341 - Dark Knight ez - Thu Jul 06, 2006 4:19 pm
It is only logical that I only show the sprites or tiles in the visible area of my map.
I am just saying that having available "only" 64kb of graphics for the backgrounds I can not display units and other objects as well on the backgrounds as tiles. They do not fit in the 64 kb along with background and structures graphics.
And displaying all the units and other objects could still be not enough if shown as sprites, because of the limitation of 128 sprites at a time on a screen.
So... for backgrounds I would've prefered more storage for graphics,
and for sprites I would've prefered more possible to display at a given time.
Thus my question.
#91349 - tepples - Thu Jul 06, 2006 4:53 pm
| Dark Knight ez wrote: |
| limitation of 128 sprites at a time on a screen. |
What limitation? You can rewrite OAM during horizontal blanking (as seen in BulletGBA and Super Puzzle Fighter II), or you can use the 3D engine for 1,500 additional quads on one screen.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#91352 - Dark Knight ez - Thu Jul 06, 2006 5:00 pm
| Quote: |
| You can rewrite OAM during horizontal blanking |
Perfect. That should give me more than enough room to work with.
Thank you for your input, tepples.
#91375 - dovoto - Thu Jul 06, 2006 8:16 pm
| Dark Knight ez wrote: |
It is only logical that I only show the sprites or tiles in the visible area of my map.
I am just saying that having available "only" 64kb of graphics for the backgrounds I can not display units and other objects as well on the backgrounds as tiles. They do not fit in the 64 kb along with background and structures graphics.
|
You have an extra two bits to control the graphics offset for tiled backgrounds on the DS. Instead of only 16 possibilities for the start offset available on the GBA (often referred to as char base block or tile base block) you now have 64. Each represents 16KB of memory enabling you to offset into 256KB of video ram from a single background.
You are still limited to 1024 tiles per layer (due to the tile index size of 10 bits) and so, can only access 64KB of tile graphics per layer (without some trickery.
At most you will have 825 unique tiles visible on any given layer (33 x 25 tiles) so this is not much of a limitation. A dynamic map renderer which loads tile graphics into memory keeping track of which tiles are in use and dynamically loading needed ones while unloading ones not on screen will allow you to render any possible tile combination. This is very common and although not trivial to do efficiently it is also not terribly difficult.
As far as 128 sprites you are pretty much out of luck there, you must either sort them by Y each frame and inject them at the appropriate place in the hblank..not all that practical if you need much more than 128 sprites --especially if you use many rotated, scaled sprites-- since you will likely exceed scan line limits as the DS can only display so many sprites per scan line. Or, you can use the 3D system to display the objects which is more flexable but does not work as well for rotated and scaled sprites (texture coordinates get shifted slightly and make a one to one mapping of texture to sprite cumbersome when the sprite is rotated).
At least sprite graphics memory no longer is mapped to same location as background graphics memory. Also the DS supports extended graphics memory for sprites which eliminates the 32KB graphics limitation of the GBA (up to 256KB in 1D mapping mode).
_________________
www.drunkencoders.com
#91404 - Dark Knight ez - Fri Jul 07, 2006 12:30 am
| Quote: |
| You have an extra two bits to control the graphics offset for tiled backgrounds on the DS. Instead of only 16 possibilities for the start offset available on the GBA (often referred to as char base block or tile base block) you now have 64. Each represents 16KB of memory enabling you to offset into 256KB of video ram from a single background. |
Ah. I was trying to use graphics located at the last 64kb of VRAM bank A for a background while still having its charblock located at offset 0. You're saying I could relocate it to the last 64 kb of VRAM bank A, which would give me 128 kb (minus the size of the maps) to work with. If that's possible, I probably won't have to deal with HBlank interrupts, which would be nice. Thank you for the reply.
| Quote: |
| You are still limited to 1024 tiles per layer |
I don't see any reason to go beyond 256x256 (32x32) backgrounds. Thus that should be fine.
#91432 - tepples - Fri Jul 07, 2006 5:37 am
| Dark Knight ez wrote: |
| Quote: | | You are still limited to 1024 tiles per layer |
I don't see any reason to go beyond 256x256 (32x32) backgrounds. |
Other than that if you horizontally scroll, a single tile will be split on the side? Ever played Super Mario Bros. 3 on an NES (or emulator) and looked at the far right side of the screen?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#91462 - Dark Knight ez - Fri Jul 07, 2006 9:23 am
Horizontally scrolling will be done in steps of 16 pixels (the "tiles" of which the RTS gameplay will exist out of). This rules out such a problem, although scrolling will be considered less smooth.
#91474 - silent_code - Fri Jul 07, 2006 12:00 pm
| tepples wrote: |
| Ever played Super Mario Bros. 3 on an NES (or emulator) and looked at the far right side of the screen? |
ever played the first nes zelda? ;) it often had the problem, that you would see when new tiles are being written to the map... even vertically :(
i hope your 16 px scrolling will be ok for you, otherwise you will have to use a bigger map (512 x 256 is the next step, right?). i imagine it (16 px steps) to be a bit choppy for a rts :(
#91482 - Dark Knight ez - Fri Jul 07, 2006 1:14 pm
It's not at all that choppy, plus it has its benefits. In fact, I believe most (oldschool) RTS games implemented a similiar scrolling.