#26641 - pyros - Tue Sep 21, 2004 9:20 pm
As you know, the GBA can only display a maximum number of sprites on each line. My program is using 32x32 sprites with the double size flag set (for rotation and scaling), so a maximum of only eight sprites can be correctly displayed on each scan-line.
Unfortunately, I only realised how much of a problem this was when i bought a GBA and a flash linker last week.
I know this is a long shot, but is there any way of displaying more sprites per scanline? Perhaps by freeing more resources for the displaying of sprites, as i'm not using tiles or bitmap images.
Thanks,
Paul.
#26642 - Miked0801 - Tue Sep 21, 2004 9:41 pm
Nope. No way around it. You can always use BGs for additional graphics, but there is no reloading of hblank resources mid-line to get around sprite issues (ala 2600)
#26644 - ScottLininger - Tue Sep 21, 2004 9:52 pm
Hmmm. I wasn't aware of this limitation. So what exactly determines the limit? I thought the hardware could display 128 sprites simultaneously?
But this post suggests that there is another limit per scanline.
Info? Docs I should look at?
Thanks,
Scott
#26645 - poslundc - Tue Sep 21, 2004 9:55 pm
| Miked0801 wrote: |
| Nope. No way around it. |
Haha, are you so sure? ;)
I wasted an inordinate amount of time writing a ridiculously-optimized software scaler for the GBA that functions exclusively for 32x32 sprites being doubled up to 64x64... it consumes a fair bit of resources, but it's about as fast you can get scaling in software and it means instead of using a 64-pixel wide rot sprite you can use a 64-pixel wide regular sprite (when scaling upwards from 32x32).
Plus, you can decide how best to implement it based on the app... it can write directly to VRAM if you've either got the VBlank cycles to spare or sufficient sprite VRAM to double-buffer, in which case it's actually quite fast. Or you can write to IWRAM if you've got enough of it and then DMA it to VRAM during VBlank. Or the slowest version, which I'm doing, is rendering to EWRAM and then copying to VRAM during VBlank.
I'm using it on four of my sprites and it makes all the difference. I have plans to eventually make it available to the public once I clean it up a bit.
Dan.
#26646 - poslundc - Tue Sep 21, 2004 9:59 pm
| ScottLininger wrote: |
Hmmm. I wasn't aware of this limitation. So what exactly determines the limit? I thought the hardware could display 128 sprites simultaneously?
But this post suggests that there is another limit per scanline.
Info? Docs I should look at?
Thanks,
Scott |
http://www.work.de/nocash/gbatek.htm#lcdobjoverview
Basically it's 1210 pixels per scanline if you don't fuss around with OAM during HBlank, but scale/rot pixels consume a little more than 3 times that. Plus if you're double-sizing, it's double the pixels.
Dan.
#26656 - tepples - Wed Sep 22, 2004 3:21 am
There has been "another limit per scanline" on Nintendo sprite display systems since the NES. The NES can show 64 sprite pixels per scanline, the Game Boy and GBC 80 pixels, and the Super NES 256 pixels.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#26693 - Miked0801 - Thu Sep 23, 2004 10:08 pm
| Quote: |
Haha, are you so sure? ;)
|
Hehe. I'm never so sure. I don't think the guys at Nintendo or ever so sure :)
Yes, doing the work yourself in software takes the load off the hardware. I thought the original post was asking about mid-hblank sprite multi-plexing. Seems like you had a different interpretation. Good idea!
#26716 - getch - Fri Sep 24, 2004 11:29 am
SO what exactly happens when your program gets to a point where there's too many sprites on the same scanline?
Does is crash, or just not display some, or not display all?
It this limitation on sprites with coordinates on the same scanline, or with graphic data on the same scanline?
#26723 - poslundc - Fri Sep 24, 2004 1:57 pm
| getch wrote: |
SO what exactly happens when your program gets to a point where there's too many sprites on the same scanline?
Does is crash, or just not display some, or not display all? |
Any pixels remaining to be processed once the rendering cycles have run out, won't be. Sprites are processed in the order they appear in OAM.
| Quote: |
| It this limitation on sprites with coordinates on the same scanline, or with graphic data on the same scanline? |
Not quite sure what you are asking here. The limitation is on pixels plotted (including both opaque and transparent pixels) on a scanline. If two sprites overlap on a particular scanline, then both their pixels must be plotted (even the one that is obscured).
Dan.
#26728 - ampz - Fri Sep 24, 2004 2:51 pm
One easy solution to the problem is to let the sprites swap places every other frame. Works very well in games where it can be assumed that the problem will not occur too often.
What will happen is that when too many sprites line up on the same scanline, some of them will start to flicker.
Alot of games use this approach.
#26729 - getch - Fri Sep 24, 2004 4:51 pm
Seems to me that checking the sprite, aswell as swapping them, would use lots of cpu cycles.
And swapping every frame would not also cause flicker?
#26731 - poslundc - Fri Sep 24, 2004 5:07 pm
| getch wrote: |
| Seems to me that checking the sprite, aswell as swapping them, would use lots of cpu cycles. |
If they are rotated/scaled then yes, there is some math involved. But most likely you are doing a lot of that math anyway if you are using rot/scale sprites.
| Quote: |
| And swapping every frame would not also cause flicker? |
The alternative is to have the sprite not display at all, or possilby have gaping chunks of it missing. Most people prefer flicker.
Dan.
#26741 - tepples - Fri Sep 24, 2004 9:36 pm
| getch wrote: |
| Seems to me that checking the sprite, aswell as swapping them, would use lots of cpu cycles. |
Depends on whether you're making a sideview game or an overhead game. In sideview games, you can just start drawing your sprite list at a random point in each frame, as Konami's NES games did. In an overhead game, add a random element to Y when Y-sorting the sprites each frame.
| Quote: |
| And swapping every frame would not also cause flicker? |
People accepted the flicker on the NES.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#26848 - Touchstone - Mon Sep 27, 2004 1:10 pm
| tepples wrote: |
| People accepted the flicker on the NES. |
Well, that was quite some time ago. The times they are a-changin'
_________________
You can't beat our meat
#26968 - R0d Longfella - Thu Sep 30, 2004 2:27 pm
I remember someone making a multiplexer to display 6 times 128 sprites during one frame. I suppose he should have faced this problem too. Does anyone know him, and if so, what solution he used to overcome this?
#26969 - poslundc - Thu Sep 30, 2004 2:48 pm
I don't imagine he did. The hardware limitation is very real, but so long as you're responsible with your resource usage you won't necessarily have a problem with it. You have 1210 rendering cycles per scanline for a 240-pixel width, after all (for regular sprites one pixel == one rendering cycle).
In particular, the problem is most often encountered with scale/rot sprites, which consume a little more than 3 times the rendering cycles that regular sprites do, and often need to be double-sized, which effectively make them consume 6 times as many.
Sprite MUXers are most often used with variable-width font systems or things like particle effect systems, where the sprites aren't being scaled/rotated and are usually quite small. So more sprites does not necessarily imply running into the hardware limitation.
Dan.
#26970 - tepples - Thu Sep 30, 2004 2:49 pm
The hack to draw >128 sprites on one screen involved overwriting OAM during hblank. However, that solves the sprites per screen problem (letting people port Neo-Geo games) not the sprites per scanline problem.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#26975 - ampz - Thu Sep 30, 2004 5:13 pm
Swapping: If you have 128 sprites, the idea is to every other frame let the lower 64 sprites switch places with the upper 64 sprites in the list. This change of order will make sure that each sprite is displayed at least every other frame in case too many sprites line up on the same scanline.
Since the GBA framerate is twice that of SNES/NES, I'd expect the flickering to be even less annoying.
#26976 - poslundc - Thu Sep 30, 2004 5:57 pm
I think most games would require a more complicated routine than that, since you will generally have different classifications of sprites depending on their purpose in the game, and they can be grouped into clumps within the OAM structure. There is also the need to maintain proper z-ordering, which can be a problem when you start moving chunks around.
Dan.
#26977 - sajiimori - Thu Sep 30, 2004 6:46 pm
Since when do NES/SNES run at 30Hz??
#26980 - ampz - Thu Sep 30, 2004 7:05 pm
| poslundc wrote: |
I think most games would require a more complicated routine than that, since you will generally have different classifications of sprites depending on their purpose in the game, and they can be grouped into clumps within the OAM structure. There is also the need to maintain proper z-ordering, which can be a problem when you start moving chunks around.
Dan. |
Yes, you need to maintain proper z-order, but often the bulk of your sprites are at the same z-level. You just leave the "special class & z-level" sprites alone and swap the rest.
sajiimori: Sorry, forgot they only use half the TV resolution.
#27002 - tepples - Fri Oct 01, 2004 1:57 pm
| sajiimori wrote: |
| Since when do NES/SNES run at 30Hz?? |
Since more than five sprites wandered onto the screen. One example is halfway through the level of SMB3 where enemies throw spike balls at you. A few Super NES games had slowdown issues as well.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#27010 - sajiimori - Fri Oct 01, 2004 3:56 pm
Yeah, I just thought ampz was implying that full speed on NES/SNES is 30Hz.
#27027 - ampz - Fri Oct 01, 2004 8:44 pm
Full resolution consoles have to operate at 25/30Hz, but since the NES and SNES were half resolution, they operated at twice that.
#27032 - sgeos - Fri Oct 01, 2004 9:22 pm
| tepples wrote: |
| letting people port Neo-Geo games |
Neo-Geo games have been ported!?
-Brendan
#27041 - tepples - Sat Oct 02, 2004 12:55 am
Puzzle Bobble/Bust-A-Move was originally a Neo-Geo game. So were the Metal Slug, Magical Drop, and KoF games.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#27047 - Miked0801 - Sat Oct 02, 2004 1:21 am
On the 30 Hz issue. If you flicker sprites every other tic, they become semi-transparent to the BG. In addition, it looks absolutely awful on Emulator and on a TV set through the GC player due to interlacing.
#27063 - ampz - Sat Oct 02, 2004 9:33 am
| Miked0801 wrote: |
| On the 30 Hz issue. If you flicker sprites every other tic, they become semi-transparent to the BG. |
I would imagine so since the LCD screen is a bit slower than CRT TVs.
| Miked0801 wrote: |
| In addition, it looks absolutely awful on Emulator and on a TV set through the GC player due to interlacing. |
It should not look any different than NES/SNES games... Perhaps sprites were swapped at 30Hz on the NES/SNES after all?
#27078 - tepples - Sat Oct 02, 2004 6:25 pm
Yes. Many NES games did swap the order of sprites at 30 Hz. Konami's sprite engine actually used 15 Hz in four banks, which is why you sometimes see what appears to be 75% opacity.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#27142 - FluBBa - Mon Oct 04, 2004 3:35 pm
| ampz wrote: |
| Miked0801 wrote: | | In addition, it looks absolutely awful on Emulator and on a TV set through the GC player due to interlacing. |
It should not look any different than NES/SNES games... Perhaps sprites were swapped at 30Hz on the NES/SNES after all? |
Maybe because the NES (and allmost all SNES games) doesn't use interlace, which the GC does (all the time?).
_________________
I probably suck, my not is a programmer.
#27145 - ampz - Mon Oct 04, 2004 5:06 pm
| FluBBa wrote: |
| ampz wrote: | | Miked0801 wrote: | | In addition, it looks absolutely awful on Emulator and on a TV set through the GC player due to interlacing. |
It should not look any different than NES/SNES games... Perhaps sprites were swapped at 30Hz on the NES/SNES after all? |
Maybe because the NES (and allmost all SNES games) doesn't use interlace, which the GC does (all the time?). |
I don't think you can choose to use or not use interlacing on a TV. It's always there (it's defined in the PAL/NTSC standard). What you can do it treat the odd and even subframes as identical frames. This is equivalent of applying a 2x scale factor to a half resolution frame (which probably is exactly what the GC NES/SNES emulators are doing).
#27161 - tepples - Tue Oct 05, 2004 2:55 am
Actually, if you send only 262 and not 262.5 lines in a field, NTSC and PAL/M TVs will interpret it as a progressive signal. It worked for the Atari 2600, NES, Sega Genesis, Super NES, CD-i, Atari Jaguar, PlayStation, and N64.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#27164 - ampz - Tue Oct 05, 2004 6:15 am
Okay. Think it violates the standard?
It is 312 lines for all other PAL versions.
#27170 - FluBBa - Tue Oct 05, 2004 9:55 am
We've been discussing this before, the fact is (wheter or not it's a violation of the PAL/NTSC specification) that all the consoles Tepples mentioned (plus the Amiga and Sega Dreamcast at least) can output 262p/312p, and it's different from outputing the same image twice with interlace on.
Edit: Searched high and low, but only found this that even remotly speaks about videogames outputing a non-interlaced signal.
_________________
I probably suck, my not is a programmer.