#150819 - brave_orakio - Wed Feb 13, 2008 2:18 am
Hi, I recently played legend of zelda:lttp for the GBA and I was wondering what technique they used in the dark room areas? Is it the hardware windowing feature of the GBA or is it a dynamic black background?
_________________
help me
#150821 - Dwedit - Wed Feb 13, 2008 2:34 am
I think it's just one big black transparent background layer.
The SNES shared the lantern background layer with the status overlay and menu.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
#150920 - brave_orakio - Fri Feb 15, 2008 1:54 am
It does look that way. Isn't it processor intensive though, having to recopy the whole BG map to memory everytime link changes direction to accomodate his "line of sight"? On a related question, what is the size of links sprite, is it 32x32 or 64x64?
_________________
help me
#150924 - tepples - Fri Feb 15, 2008 4:21 am
| brave_orakio wrote: |
| It does look that way. Isn't it processor intensive though, having to recopy the whole BG map to memory everytime link changes direction to accomodate his "line of sight"? |
Not very. It's just a DMA call.
| Quote: |
| On a related question, what is the size of links sprite, is it 32x32 or 64x64? |
As far as I can tell, most of the character sprite cels in ALTTP are 16x32 pixels.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#151066 - brave_orakio - Mon Feb 18, 2008 2:11 am
So for an action game like LOZ:ALTTP, a 16x32 sprite seems big enough. Have any of you seen seiken densetsu 3? How large do you think the sprites are in this game?
I'm trying to decide how big a sprite should be in an action oriented game like LOZ and SD3.
_________________
help me
#151138 - Miked0801 - Tue Feb 19, 2008 5:35 pm
Do you want lots of little enemies or a few biggies? Or do you want to get too tricky and reload OAMs on HBlanks to get more sprites :P
#151159 - brave_orakio - Wed Feb 20, 2008 5:40 am
Maybe about 5 or 6 regular enemies on screen. The bosses should be big of course!
Ah yes the technique to cheat the maximum number of sprites/objects on screen. Wouldn't that load the processor too much though?
_________________
help me
#151169 - tepples - Wed Feb 20, 2008 1:19 pm
| brave_orakio wrote: |
| Ah yes the technique to cheat the maximum number of sprites/objects on screen. Wouldn't that load the processor too much though? |
It worked for Super Puzzle Fighter II (commercial), BulletGBA (homebrew), and Vulkanon (homebrew).
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#151217 - brave_orakio - Thu Feb 21, 2008 3:01 am
Yes I did see Vulkanon, and the number of sprites is indeed incredible to say the least.
Tell me if the process is correct here, basically you load 128 sprites in one vblank and the next 128 is loaded in the next vblank, interchanging every vblank correct? So one set of 128 is shown for a total of 30 frames and the other also around 30 frames per second?
I doubt I have the skills to optimize so much!
_________________
help me
#151222 - tepples - Thu Feb 21, 2008 4:09 am
| brave_orakio wrote: |
| Tell me if the process is correct here, basically you load 128 sprites in one vblank and the next 128 is loaded in the next vblank, interchanging every vblank correct? So one set of 128 is shown for a total of 30 frames and the other also around 30 frames per second? |
You're describing flicker, and "cheating" isn't flicker. Instead, it involves DMAing a block of 16 OAM entries (128 bytes) from IWRAM to OAM during horizontal blank.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#151229 - brave_orakio - Thu Feb 21, 2008 8:54 am
so max sprites is 16*(numberOfHBlanks). Wouldn't it flicker too, or is it fast enough that the eye wont notice?
Edit: scratch that question. Technically the object would still appear onscreen (even though it's previous OAM is already displaying a new object) because the Vertical scan isn't done yet.
_________________
help me
#151230 - Dwedit - Thu Feb 21, 2008 9:39 am
16 is the not the maximum number of sprites, it is the maximum number of sprites that can be changed in a single scanline.
You can change the sprite tables (OAM) as the screen is rendering. As the "Current Scanline" (Vcount) moves down the frame, the gba draws backgrounds and sprites. Anything above the "current scanline" is stuff which has already been drawn. Once a sprite has already been drawn, you can replace its OAM entry with a new sprite (with a higher Y coordinate), then the gba will draw the new sprite as the "current scanline" reaches the new sprite's Y position.
You can have about 28 sprites of width 32 on a single scanline.*
So the "128 sprites limit" can be overcome by loading new sprites in as the old ones are already drawn.
*The limit is 954 pixel clocks worth of unscaled sprites. Scaled sprites take up more time, so you can have less of them on at a time. Also, accessing vram eats up the pixel time.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
#151240 - Miked0801 - Thu Feb 21, 2008 7:13 pm
The same trick can be used to accompish:
* Loading more than 256 colors into a palette to achieve higher colors - used more often on GBC to overcome 32 color BG restrictions.
* Loading the BG scale register to achieve "Mode 7" effects or to get a heat shimmer effect.
* Loading window register to achieve funky shaped window effects - though sprites can do this as well. Thing the large key hole effect in Super Mario World.
* Loading OAMs to increase max sprites in use
* Loading the scroll register to get a "Split screen" effect or to get a heat eave type effect with a sine wave applied - See Spryo Eternal Night for many examples.
* Load in various VRAM locations to increase your available char limits. Not as effective as other because chars are 32/64 bytes in size so you don't get much extra for your trouble. This was more popular in GBC/DMG land.
And many, many more uses. It's a trick that been around since the Atari 2600.
#151241 - gauauu - Thu Feb 21, 2008 8:12 pm
| Miked0801 wrote: |
| It's a trick that been around since the Atari 2600. |
Heh, although on the atari, wasn't it about the ONLY way of doing things? If I remember right, sprites didn't have a Y position, only an X position. To move things up and down, you had to play with the hblank.
#151250 - Miked0801 - Thu Feb 21, 2008 10:33 pm
Probably - I'm only passing familiar with it though. The other thing was they literally had to time when instructions were ran within hblanks in order to do certain palette tricks. That's hardcore :)
#151262 - brave_orakio - Fri Feb 22, 2008 2:46 am
Truly incredible! I didn't know that a lot of graphical effects were accomplished using this method!
Wouldn't DMA mess up the Hblank interrupts though?
_________________
help me
#151304 - Miked0801 - Fri Feb 22, 2008 11:28 pm
Nope, hblank is at a lower level than irq. HBlanks can screw up DMAs, not the other way around. If you try to transfer to VRAM during a restricted period, the info is lost.
#151439 - strat - Tue Feb 26, 2008 12:00 pm
I'm thinking about doing this in my game. Think many rows of SMB2-style mushroom blocks with 30 in each row.
Do you have to account for sprite size when HBlanking? Like if you change a sprite's position after one scanline it'll move to the new spot and only its top will be drawn at the old position?
#151456 - Miked0801 - Wed Feb 27, 2008 1:10 am
Yes - if you move a block that overlaps the scanline on which the swap occurs, you will cut off the sprite. And yes, moving the position is how you actually get away with displaying multiple sprites - just reloading the OAM registers perferably via an HBlank DMA from an ARM RAM table that is set during VBlank (and remembering to reset position each VBlank as well)
There is some CPU overhead for doing this.
#151462 - brave_orakio - Wed Feb 27, 2008 6:33 am
Is the hblank interrupt method to cheat the number of objects only used when you have a large number of similar sprite(i.e. bullets, explosions)?
_________________
help me
#151463 - Dwedit - Wed Feb 27, 2008 7:00 am
The objects can be any time of object. You are overwriting more than just the coordinates, you are also overwriting the other sprite parameters (size, object number) as well. Your only limit is the amount of space in sprite VRAM.
You can also write new data to VRAM as the screen is rendering, but that cuts into the amount of time used by drawing objects.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
#151486 - Miked0801 - Wed Feb 27, 2008 7:18 pm
The HBlank trick for sprites is most ueful for similiar object types - but, like brave_orakio states, you can change any parameter in the sprite list. It just gets more and more complicated, the more you try to change. And, you must restore the original values back to the registers every vblank or the top line sprites won't display correctly.
Needless to say, hblank magic can do some amazing things for fairly cheap.
#151556 - brave_orakio - Fri Feb 29, 2008 2:30 am
Thanks alot for the answers guys! Everyone here has been a real help!
I will probably try the hblank interrupt for some graphical effects.
One more question though, can anyone point me to some indepth pixel art tutorial? There are alot of popular stuff, but maybe you guys can point me to lesser known but excellent tutorials?
The technical stuff I can understand how to do, but making the graphics is something I will need to learn! Again thank you for your time!
_________________
help me