#14369 - StealthElement - Mon Jan 05, 2004 10:15 pm
what if a game had significantly more than 128 sprites throughout the whole game? How can it be done, if at all?
#14372 - poslundc - Mon Jan 05, 2004 10:29 pm
You are limited to 128 sprites onscreen per frame, not throughout the whole game. Frames occur at a rate of 60 times per second. If you want, you can display 128 completely different sprites in frame 2 than you do in frame 1.
Even that limit is not fast-and-hard; there are ways around it with some creative programming. But the vast majority of games have no need to display more than 128 sprites at a time.
Dan.
#14373 - yaustar - Mon Jan 05, 2004 10:30 pm
Not 100% sure what you mean by that. The 128 limit only comes into effect when you try to display then on screen at once (without tricks) if that helps.
_________________
[Blog] [Portfolio]
#14375 - DekuTree64 - Mon Jan 05, 2004 10:33 pm
128 is only the limit to how many can be on the screen at once. Generally you keep track of all the sprites in your game world with your own structs in EWRAM or IWRAM, and then each frame build up a set of OAM entries for the ones onscreen to copy over on VBlank. Unless you're doing something with particle effects, a text engine that uses a sprite for each letter, or like a puzzle game where each block is a sprite, 128 is probably more sprites than you'll ever come close to needing. And even if you are doing one of those, there are some clever tricks to get more than 128 to 'appear' on the screen. Search around the forum if you want to know the specifics, but basically you wait until the sprite has been drawn, and on HBlank, change its picture and move it down below where the screen has currently drawn to, so when the drawing of the screen gets down to the new position, it shows up again, even though it's the same OAM entry as was drawn (and is still visible) at the top of the screen.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#14378 - poslundc - Mon Jan 05, 2004 10:37 pm
Haha, I won!
(Just doing my part to make everyone's day a bit more geeky/surreal)
Dan.
#14380 - StealthElement - Mon Jan 05, 2004 10:44 pm
thanks y'all, i used to think 128 was the hardware limit. that cleared many things in my mind. about character memory(i'm sure that's what it's called), is there no limit to this either?
#14383 - poslundc - Mon Jan 05, 2004 10:54 pm
You've got 32K of VRAM dedicated to sprites which can hold 1024 8x8 tiles using up to 16 different 16-colour palettes (you can hold 512 8x8 tiles if you use a 256-colour palette).
It is feasible (practical, even) to swap sprites from the cartridge into and out of VRAM in-between frames, but you've only got time enough to swap some of them in the short time between frames.
I highly suggest you go and work through some tutorials, either The Pern Project or http://www.gbajunkie.co.uk. These will answer all of your questions and more.
Dan.
#14384 - DekuTree64 - Mon Jan 05, 2004 10:58 pm
Of course there's a limit, but as with sprites, it's only what can be seen on the screen at once. You can copy in new data anytime you want, so again it's more than you need for most things. In my map system, anytime a sprite walks onto the screen, if it doesn't have a chunk of VRAM allocated to it already, it calls the allocator, which just searches through a list of claimed tiles until it finds a block big enough to hold the sprite, declares all those tiles used, and returns the first tile of the block. If the same sprite is still onscreen next frame, it will still have its same chunk of VRAM, and won't have to do anything except possibly copy in a new frame of animation.
Then for any sprites offscreen, if they have a VRAM chunk already, it frees it, so it's available for any new sprites that come onto the screen.
EDIT: Dangit, Dan wins again :P
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#14387 - StealthElement - Mon Jan 05, 2004 11:02 pm
thanks again
#14393 - sajiimori - Mon Jan 05, 2004 11:46 pm
| Quote: |
thanks again
_________________
'Reality' is only what people perceive it to be.
|
Your statement is self-contradictory because you just gave an absolute description of reality. You can't use the word 'is' while referring to the actual unless you presume an objective reality.
#14396 - tepples - Mon Jan 05, 2004 11:52 pm
Removing 'to be' from one's writing can make it much more precise I think StealthElement meant the following: People use the word "reality" to refer to nothing more than the models of the world that they construct based on their perceptions.
But to keep it on topic for a board about programming a Nintendo system: 'Reality' was the codename for the N64 console.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#14452 - StealthElement - Tue Jan 06, 2004 11:20 pm
It means just what it says, sajiimori san. Hint: it's based on a theory that logic only exists because people believe it exists. Don't bother to reply because I won't be around to read it anymore
#14453 - dagamer34 - Tue Jan 06, 2004 11:40 pm
Yeah, that's one of those tricks for the gba. There are a bunch of others like mode 7 and hmm... that's it.
True, there are limits but you can ALWAYS get around those limits.
Here's something to think about: Rules are made to be broken.
_________________
Little kids and Playstation 2's don't mix. :(
#14460 - Miked0801 - Wed Jan 07, 2004 12:54 am
Except that mikeEngine is a 32-bit number and yours is 8 :P
;)
#14684 - NEiM0D - Sun Jan 11, 2004 4:41 am
You can display a maximum of 128 sprites per line.
You can change it during an hblank interrupt, but be careful: you need to enable the OBJ sprite bit in the DISPCNT counter in order to fully use 128 sprites per line rapidly.
nb: It's easy to have a variable width text printer without using nasty bitmap routines.
#14862 - bahnhof - Tue Jan 13, 2004 8:18 pm
What DekuTree64 and NEiM0D said is also known as sprite multiplexing, it is a very clever trick but it requires you to keep track of the y-coordinates of each sprite and you will have to check/sort them. If you think you really need more than 128 sprites and you don't mind a little slowdown then sprite multiplexing really is the way to go :)