#402 - whodoo - Tue Jan 07, 2003 1:49 pm
Im a GBAnewbie and I got a question.. I just read in a tutorial that the OAM-mem can store up to 128 sprites at one time... but e.g. if I got an array like this:
struct enemie {
//
}enemies[10];
do I have to load each of enemies into a own sprite when I want to draw them like
sprite[0].variables = enemies[0].variables
sprite[1].variables = enemies[1].variables
or can I draw a single sprite two or more times in the same frame and just store it in one sprite.. cause in some games I might need to display more than 128 sprites at the same time
#403 - whodoo - Tue Jan 07, 2003 1:51 pm
... cause I guess there are games displaying more than 128 sprites.. I?ve only worked with PC programming so the console programming is something new for me...
#411 - Touchstone - Tue Jan 07, 2003 4:20 pm
I don't think there are games that display more than 128 sprites but you surely can do. I think I've had 256 or more sprites on-screen at the same time. It's easy, all you have to do is change the content of an OAM entry while it is being rendered. To understand the result it's good to know how the hardware renders sprites and I assume you do so I won't describe that in detail.
Anyways, for example you can set up a vblank interrupt that have OAM entry 0 draw a sprite in the top left corner of the screen and you set up an hblank interrupt on say scanline 100 that will move the sprite in OAM 0 to the bottom left of your screen. That way you have two sprites on screen at the same time using only OAM entry 0. You can modify all data members of the OAM structure like this, not just the screen position.
_________________
You can't beat our meat
#439 - whodoo - Tue Jan 07, 2003 6:40 pm
okey thanks...but how do I do that? For now Im just copying my sprites(a 128 array) to the memory..but is there any way of controlling the screendrawing of the sprites? so I can set OAMentry[0] to a sprite, draw it, and then change it, in the same frame..
#441 - Ped - Tue Jan 07, 2003 7:13 pm
whodoo (woodoo ? :)) *g*):
you can't have more than 128 sprites at the moment.
screen is rendered by lines.
Once HW starts to render some line, all 128 sprites must be set up as desired for that line (you can't change OAM data in the middle of line).
But you CAN change OAM data while in HBLANK, so the next line can be rendered with "other" sprites. I don't think you have enough time to change whole 128 sprites every HBLANK, but you may change at lease few. This technique is called multiplexing??? I'm not sure, but has been used extensively by Atari800 and C64 coders to increase number of sprites at screen (C64 had 8 or 16 sprites? I have grown on ZX Spectrum = no hw sprites :)) so I'm not sure)
If you have seen some game with 128+ sprites, than it must be changing sprites on-the-fly after some lines (every?) and must sort sprite data to make it possible. You may run into some nasty problems with sprites overlapping, etc, and you can't have more than 128 sprites at line. (anyway, the hw is even more limited, when you use large/rotated sprites ... I saw somewhere exact numbers, was like for 64x64 rotated sprites is maximum about 16 or 32 per line?? Buy me better memory somebody .. or just search the web...)
_________________
-- Ped - ped at 7gods dot sk
there used to be times, when sex was safe and flying was dangerous...
#442 - Touchstone - Tue Jan 07, 2003 7:26 pm
You don't ask the hardware to render a sprite, go back to your processing and ask it again to render another sprite. Instead imagine the rendering process the same way as a cathodic-ray tube works. The hardware begin by drawing the leftmost pixel on the top row. It looks at it's display control register to see which tile layers that should be displayed and if the sprites are active. If the sprites are active it looks through the spritelist to see if any of the sprites should be rendered on that particular pixel and if so, which sprite is the one with the highest rendering priority. It then takes this sprite, mix it with the background according to the blend register and plot the result color on screen. It do this again for the next pixel and the next and so on 'til the entire screen have been rendered. So, if you modify your OAM entry after it has been completely rendered, to be rendered again at a later position on the screen you can reuse the same OAM entry multiple times. Uhm, I hope my description made any sense at all. :)
_________________
You can't beat our meat
#463 - ampz - Tue Jan 07, 2003 10:47 pm
The problem that you can't have more than 128(?) sprites on the same line can be circumvented too.
Let's say you have a game with lots of sprites, and sometimes more than 128 sprites might line up horisontallay.
There is one way to handle this that might be acceptable.
Let's say that 256 sprites line up horisontally.
Then just draw the first 128 sprites on every odd screen update, and the second 128 sprites on every even screen update.
That way the sprites will flicker somewhat when they line up, but since they are so tightly packed anyway it wount be very noticeable.
Using more sprites than the hardware supports is tricky stuff.
#465 - Touchstone - Tue Jan 07, 2003 11:00 pm
That's true Ampz, I haven't thought of that. This reminds me of one particular transparency effect you could do with that type of flickering and it's not the standard "render every other frame". It's a really good looking transparency effect that allows for three levels of transparency. 25%, 50% and 75% transparency. With this you still have the hardware transparency at your disposal. This "super transparency" (great name, don't you think) is only feasible on the actual hardware though. Want to take a guess how to implement it? :)
_________________
You can't beat our meat
#489 - theSparko - Wed Jan 08, 2003 2:54 am
Just off the top of my head.. I'd say that in order to achieve "super transparency" you'd toggle the visibility of the sprite per scanline rather than per frame... but that's just a guess. <BG>
Seriously though, I thought that was an interesting article Touchstone, very creative. And I suppose to get 25% you'd draw half the scan-lines each time... but how would you get flicker free 75%? Keep half of the rendering from the previous "render frame" around?
Curious,
theSparko
#492 - Touchstone - Wed Jan 08, 2003 3:44 am
Haha, you had me fooled there for a while. :) I'm glad you enjoyed the article, thank you! I plan on building an archive of articles, by me and hopefully other people to, in a not so distant future. The article you read is just a test for my "article-viewer" I tossed together a couple of hours ago.
Anyways, to answer your question. To achieve 25% transparency you render half of the scanlines during the first half of the render frame and nothing during the other half. To get 75% transparency you render all of the scanlines during the first half of the render frame and half of the scanlines during the other half of the render frame.
The result will probably look a bit odd on detailed sprites but on abstract looking tile layers it looks rather good. The flickering will be a bit more obvious now though.
_________________
You can't beat our meat