#58756 - mice - Tue Oct 25, 2005 8:43 pm
Sorry to bother you all, but exactly what happens when you line up all of the sprites on a single row? Glitches of some kind, I'd guess. But what type of glitches?
Is the background affected by this or?
I'm not in the position to test this, seeing that I don't have a GBA.
Thanks!
((mice
#58759 - poslundc - Tue Oct 25, 2005 9:18 pm
The GBA can process up to 1,210 pixels per scanline (954 if you have the bit enabled that lets you modify OAM during HBlank). Transparent pixels still count towards this, and the pixels of rotation/scaling-enabled sprites consume more than three times the pixels that normal ones do.
Objects are processed in the order they appear in OAM, so entry 0 gets processed before entry 1, etc.
If you run out of pixels on a scanline, the remaining pixels for the remaining OAMs are dropped.
http://www.work.de/nocash/gbatek.htm#lcdobjoverview
Dan.
#58761 - mice - Tue Oct 25, 2005 9:33 pm
Thanks!
So only the remaining sprites are dropped, nothing of the background, right?
The reason I'm asking is that I'm creating a small console of my own. And I write the sprites first and the bkg afterwards. Which means if I line up enough sprites on a line, the bkg will be affected as well.
And that's pretty stupid. I've got to rethink this a bit.
Thanks again!
((mice
#58786 - poslundc - Wed Oct 26, 2005 12:39 am
| mice wrote: |
Thanks!
So only the remaining sprites are dropped, nothing of the background, right? |
Right.
| Quote: |
The reason I'm asking is that I'm creating a small console of my own. And I write the sprites first and the bkg afterwards. Which means if I line up enough sprites on a line, the bkg will be affected as well.
And that's pretty stupid. I've got to rethink this a bit. |
You might want to download the source code for Visual Boy Advance (or SNES9X, since the SNES is a comparable machine anyway) and see if it does anything to inspire your design.
Dan.
#58792 - tepples - Wed Oct 26, 2005 1:49 am
During the "draw" portion of each scanline, the NES scans the 64-entry OAM (sprite display list) to see which sprites of the next scanline are "in range". If more than 8 sprites are in range, it stops the search. Then it fetches the appropriate sprite video patterns (tile data) during horizontal blanking. The Game Boy works roughly the same way.
The Super NES and GBA, on the other hand, seem to scan OAM and read patterns during draw time. (The GBA can be set to do so in hblank as well, giving even more ridiculously many sprite pixels per line.)
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#58833 - mice - Wed Oct 26, 2005 4:43 pm
Really appreciate all of your answers!
I'll DL the source and have a peek.
Thanks!
((mice
#58895 - Joat - Thu Oct 27, 2005 12:30 am
Most 2D consoles have seperate memory and circuits for the sprites, or seperate times to read them in. On the NES, it only had to read a maximum of 8 patterns (since that's how many sprite record structs it had), and so it had a deterministic time during each scanline to do so, where it wouldn't interfere with the background search.
The GBA has seperate VRAM for sprites than backgrounds, and although I'm not exactly sure how it's sprite rendering works (I can't seem to design it in my head without a pair of scanline buffers, one that gets priority composited and cleared as a scanline is being drawn, and another that is getting filled for use on the next scanline), it's certainly doing both the background and sprites at the same time, so running out of time on sprites will not affect the background.
Anyhoo, for anyone who cares, I haven't figured out why the rot/scale sprites take 10 cycles of setup instead of just 4 (for the matrix reads), but the reason they take 2x to write is simple, sprite tile vram is on a 16 bit bus, so you get two pixels every cycle for normal sprites (or four for 4-bit mode, but that doesn't seem to be taken advantage of), but the random accesses of rot/scale sprites drop you down to one useful pixel per read.
Hmm, actually, it probably takes 10 because it has to compute the current sprite texture position, two multiplies, but why that couldn't be pipelined away, I dunno. Anyhow, the scanline buffers would explain the quirky alpha blending behavior (since the sprites get rendered on top of each other first, with no blending, and then only get blended as they're actually displayed against the background).
_________________
Joat
http://www.bottledlight.com
#58896 - Joat - Thu Oct 27, 2005 12:35 am
Also, if you're desiging console hardware (on a FPGA or whatever, I presume), please feel free to drop by the IRC channel #hwdev on EFNet. Several of us have done some FPGA graphics / console stuff, or at least think about it.
_________________
Joat
http://www.bottledlight.com
#58987 - keldon - Thu Oct 27, 2005 9:31 pm
http://nessie.emubase.de/
the NES emulator nessie also features full assembler source code for its nes emulator - so you can have a real nice look at how its hardware is implemented using low level instructions
the rosasm assembler IDE is required to view NESSIE's asm source
#59036 - mice - Fri Oct 28, 2005 9:14 am
| Quote: |
The GBA has seperate VRAM for sprites than backgrounds,...
|
That would mean you have the complete scanline to do the sprites and equal amount of time to do the background. Would be optimal.
Unfortunately I don't have that luxury.
| Quote: |
...and although I'm not exactly sure how it's sprite rendering works (I can't seem to design it in my head without a pair of scanline buffers, one that gets priority composited and cleared as a scanline is being drawn, and another that is getting filled for use on the next scanline), it's certainly doing both the background and sprites at the same time, so running out of time on sprites will not affect the background.
|
I've got two buffers for the actual pixel-info as well, for even and uneven lines. And a third buffer (one 256bit-register) holding the 'alpha' info. (The screen is 256x224).
Before reading pixel-data from memory this alpha-buffer is read to see if there is already a pixel written to that particular position, if so it moves on to the next pixel. Saves memory accesses.
| Quote: |
Also, if you're desiging console hardware (on a FPGA or whatever, I presume), please feel free to drop by the IRC channel #hwdev on EFNet. Several of us have done some FPGA graphics / console stuff, or at least think about it.
|
Yep, it's on a fpga. Will most certainly check out the channel. Thanks!