Discussion about software development for the old-school Gameboys, ranging from the "Gray brick" to Gameboy Color
(Launched in 2008)
You are not logged in.
Nearly all of the programming I have done has been on hardware with few limitations (mainly PCs) so I have little experience with low end hardware such as the Gameboy.
Now, to get to the point: I'm a bit stumped on how to go about managing sprites because there is a limited amount of them to work with. Normally on a PC I would just blit everything to the screen without worrying about sprite indexes and what-not, but with the Gameboy I get a mere 40 sprites to manipulate.
My initial thought was to just assign each object their own static sprite index as I've seen in many examples but that doesn't seem well suited for something with a dynamic amount of stuff on-screen. My other idea was to create a linked list of the game objects and assign each object the first available sprite index. While I may be able to come up with ways to do it myself, I would still like some input from fellow programmers who are more experienced with these sort of situations.
What is/are the best way(s) of doing this?
Offline
Sprite rendering problem is much more complex.
Game objects are usually bigger than sprite size (8x8 or 8x16), so you need to combine few hardware sprites to display one object.
Also remember about sprite priorities (based on offset in OAM) . Assigning static sprite indexes may cause problems with overlapping
object , if the object-object priority is important.
40 sprites is OAM size limit, not hardware limitation. You can extend the num of sprites on screen by changing OAM on the fly.
It's possible to use different OAM data for each screen scanline (and get more sprites , different shape/position , different gfx etc).
There's also another problem - video hardware can process only 10 sprites in each scanline.
Process - not draw. So even transparent pixels and off-screen ones (but assigned to current scanline) counts.
To get more sprites on scanline you can change order/priority each frame (offset of sprite data in OAM determine the priority of
rendering, as well as the sprite "disapearing" when limit (10/line) is reached). As a side effect It will cause bad gfx flickering,
but some smart code can minimize it.
Another solution is render directly to tile ram, and not use hardware sprites at all.
Offline
dox wrote:
40 sprites is OAM size limit, not hardware limitation. You can extend the num of sprites on screen by changing OAM on the fly.
It's possible to use different OAM data for each screen scanline (and get more sprites , different shape/position , different gfx etc).
I'll definately keep that in mind. Is there any example code that uses this technique that I can look at?
dox wrote:
Another solution is render directly to tile ram, and not use hardware sprites at all.
That's an interesting idea, but wouldn't it take up a large chunk of the Gameboy's processing power? It certainly would make things allot more like what I'm used to (:
EDIT: What exactly does OAM stand for? My best guess is Object Attribute Memory.
Last edited by Shiny (2008-03-20 14:17:11)
Offline
Shiny wrote:
I'll definately keep that in mind. Is there any example code that uses this technique that I can look at?
Hmm. I don't think so.
Shiny wrote:
That's an interesting idea, but wouldn't it take up a large chunk of the Gameboy's processing power? It certainly would make things allot more like what I'm used to (:
A couple of games use that technique. For example check one of my fav dmg games - Monster Max.
Shiny wrote:
What exactly does OAM stand for? My best guess is Object Attribute Memory.
You're right.
Offline
dox wrote:
Shiny wrote:
That's an interesting idea, but wouldn't it take up a large chunk of the Gameboy's processing power? It certainly would make things allot more like what I'm used to (:
A couple of games use that technique. For example check one of my fav dmg games - Monster Max.
I checked out Monster Max and it looks really impressive for a Gameboy game, but it's not really my type of game ;P. I think i'll try this type of rendering some time, but still try to use hardware sprites as much as possible to save on CPU cycles.
Offline