#141797 - Div03 - Sun Sep 30, 2007 4:26 am
I did some searching around and didn't find anything too specific, so here I go.
Alright, so I know the sprite "limit" is 128, but really, could you have 128 sprites at 256 colors and have the game move smoothly? I really don't think so.
Reason I ask, our game will involve many sprites on the screen at a time, say, around 15-20 enemies at once. I was wondering if I could achieve this without losing any performance while playing a Mp3 @ 56 or 40kbps 22khz. We have been told that playing a small Mp3 like that could be handled by the ARM7 alone, so I'm hoping that means we'd be in the clear. I was thinking one possible solution would be to make alot of the enemy sprites have only 16 colors.
My concern comes from commercial games (such as SRPGs, most notably Luminous Arc) that loses framerate when there are too many sprites on the screen. It is crucial we don't lose any performance, and was wondering if that's possible with our current game structure (small Mp3s and many sprites).
#141799 - DiscoStew - Sun Sep 30, 2007 5:51 am
128 is really just the limit of the sprite portion of the 2D hardware per scanline. There are other ways to get around this, such as changing sprite information on a scanline basis, or using the 3D hardware to draw quads, but back on subject...
"Could you have 128 sprites at 256 colors and have the game move smoothly?" In my opinion, yes most definitely, but it also depends on what else is being done and how you get those sprites into memory.
You've got an MP3 playing, so there goes a good chunk of your CPU, and I'm sure you've got other things going than just that and sprites. Not really sure what I can help you with, as I don't know how you are coding your stuff. Perhaps there are some bottlenecks and/or unneeded lines of code that could be cleared a bit. Changing your sprites to 16 colors "could" help, that is, if you are continually updating the VRAM with new tilecels for this sprites, as it would split the copying by half.
_________________
DS - It's all about DiscoStew
#141800 - Div03 - Sun Sep 30, 2007 6:53 am
Well we're still in a conceptual stage of development. We're trying to get all of our information right before we hit pre-production and production.
We'd have 1-3 characters, who would be 256 colors no matter what, an interface, and skills being used. Every character/enemy/skill happening would be animated, most likely in some way shape or form.
So we haven't started hard code yet, we're just wondering what we can do with the DS hardware and what it can support while having a Mp3 playing. If need be, we could use tracked music, but I'd need to learn how to use a tracker.
#141801 - HyperHacker - Sun Sep 30, 2007 7:26 am
Larger sprites can be moving transparent layers (see Super Mario World's bosses for examples), if necessary.
_________________
I'm a PSP hacker now, but I still <3 DS.
#141982 - josath - Tue Oct 02, 2007 8:18 pm
Having too many sprites, by itself will NEVER make your game slow down. The sprites are rendered in hardware. In theory, if you went over some kind of limit (128 sprites of 64x64 each, all on the same line or something), the worst that would happen is some sprites not display, or would flicker.
If a game slows down, it's because some other code is slowing it down...for example the AI which controls the movement of all the enemies may not be fast enough to calculate their movements each frame in time. Or perhaps it's trying to update the graphics of all the sprites, and can't load the data fast enough.
#142043 - silent_code - Wed Oct 03, 2007 7:33 pm
most certainly that is the cause of a slowdown. josath is totally right.
think of code that runs on a per entity base: ai (that's a very wide term), collision detection, animation (that can be made really fast with a bit of vram "wastage") etc.
you could split entity updates that don't need to be made every frame across several frames (update every x th entity in a frame, then every y th etc.) e.g. ai updates ("think frames").
usually there are some nice hacks to get things going smoothly with the user noticing you're in fact tricking him/her. ;^D
#142135 - Div03 - Thu Oct 04, 2007 11:08 pm
So I take it alot of games out on the commercial market are coded poorly? Or could be coded better? I mean, I just look at some games I've played that slowed down when they really shouldn't have. For example, in Luminous Arc, a strategy RPG, the framerate would slow down whenever I'd say 12 or so players/enemies were on the screen. All they were doing is an idle animation.
I worked on a mod that had lag issues with a certain feature and the culprit was the engine not being able to handle all the code necessary. The coders said it was impossible to get rid of in the current engine.
#142146 - M3d10n - Fri Oct 05, 2007 5:35 am
On Luminous Arc slowdown, it is possible that the game is streaming character animation frames straight from ROM to VRAM, or something similar, thus the reason behind the slowdown. Since it's a strategy game (framerate doesn't impair the gameplay), the developers probably didn't feel optimizing it was worth the extra time.