#20342 - DiscoStew - Sat May 08, 2004 12:11 am
I'm having a tough time with sprite drawing on actual hardware. If anyone remembers a previos post of mine, I had a problem with "sprite stripping" which was defined as the hardware unable to draw a certain number of sprite pixels per scanline, thus skipping any pixels beyond its limit. Things that affected it were such things like the sprite's size, use of rotation, use of double, etc. Emulators don't have this problem. Now I need to make a decision based the following question...
Should I stick with normal sizes, or should I shrink the sprites to a certain size, and just apply an x-y scaling on them, including doubling? I currently have about 26 sprites on-screen, with most being 64x64 16 color, and some of them, depending on animation data, will rotate. No use of DOUBLE just yet. Of course with the sprites being somewhat close together, the "stripping occurs", and as more start rotating, the stripping gets worse. I've been thinking about shrinking my sprites so that they'd be smaller in size (which would be good for VRAM), and just apply scaling and doubling to each sprite. Granted that there is only a limited number of affine transformation slots, though with what I'm doing that shouldn't necessarily be a problem. I'd have to take some time to implement this in my code, which I why I'd like to ask before wasting any time I have.
_________________
DS - It's all about DiscoStew
#20349 - sajiimori - Sat May 08, 2004 6:07 pm
If the sprites are the same size after being scaled, doesn't it use the same number of sprite rendering cycles no matter what the original sprite's size was?
#20356 - DiscoStew - Sat May 08, 2004 8:55 pm
Dang it, I guess I'm at a loss then. I just wish that there was a way to get more sprite rendering cycles per scanline without having to sacrifice any precious sprites. I've been thinking about trying a super-transparency effect to mix with my sprites, so I would need the use of H-Blanks. Does anyone know of a way to get more sprite rendering cycles per scanline?
_________________
DS - It's all about DiscoStew
#20364 - tepples - Sun May 09, 2004 12:04 am
This was a problem on the NES, which allowed only 64 sprite pixels per scanline. Developers worked around it by mixing up the order of sprites from frame to frame, turning dropout into flicker.
Or if you have one really big sprite object, you could make it a background. Godzilla for NES used the system's only background to draw bosses.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#20370 - DiscoStew - Sun May 09, 2004 2:37 am
Thanks for reminding me. I've been thinking about using a background as an alternate sprite some time ago, but I just haven't had time to really implement it into my object handler. I'll probably get to it after the end of the college semester.
Also a quick question, are there any specific registers I need to enable when trying out super transparency other than interrupt registers? I know there is a bit in the Display register (OAM_H_BLANK I think), but when I enabled it, the number of sprite rendering cycles dropped.
_________________
DS - It's all about DiscoStew
#20373 - tepples - Sun May 09, 2004 3:22 am
Yes, if changing OAM during hblank, you need to set the OAM unlock bit in REG_DISPCNT, which does reduce your sprite rendering cycles by about 20% or so.
If you're using scaled sprites, try switching to several pre-scaled sizes of sprites like Super NES games used to use.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#20381 - DiscoStew - Sun May 09, 2004 9:11 pm
Ugh! More bad news. Oh well...
With what I'm doing for my first demo (which I'll release sooner or later), scaled sprites is a must. When working with 64x64 16 color sprites, having pre-scaled sprites would take up an immense amount of ROM. Pre-scaled sprites is a better option, but not with what I'm working on.
I wonder if the GBA Accelerator that Ahead Games is making would increase the sprite rendering cycle count per scanline? I'd have to ask them. A thread on the SNESAdvance wesite about the GBA Accelerator can be found here.
_________________
DS - It's all about DiscoStew
#20393 - tepples - Mon May 10, 2004 6:11 am
In that case, you may have to drop down to software rendering.
It looks like the GBA Accelerator just overclocks the GBA CPU. This has been done before. It increases the display frame rate rather than increasing the number of sprite drawing cycles per scanline, so software sprite engines might have a better chance at a decent frame rate.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#20400 - poslundc - Mon May 10, 2004 1:59 pm
What size sprites are you dealing with? I have been working on a highly optimized software-scaler that scales 32x32 sprites (or less, I suppose) up to 64x64. 16-colour only. Those are pretty specific requirements, but if that's your need then I might be willing to share it when it's completed; let me know.
(It still takes a good chunk of the CPU to work, but it's way faster than any alternative I've seen.)
Dan.