| |
Dano
Registered: Jul 2004
Posts: 234 |
Sprite sorting for DYSP or alike?
Arising from the other threads about sorting, i asked myself if one needs a proper sprite sorter for "controlled" effects like a DYSP or a for moving sprites in a circle-manner?
As i have not coded a multiplexer of this kind before up to now, i was puzzled if there was a smarter way round to achieve a proper movement like so?
A hammer-until-things approach from the top of my head could be something like stepping through Y values and then setting up the needed IRQs for that. Or analysing the movement on compiletime and setting up 1..x Tables for the IRQ-D012-Values..
What would you recommend me as a multiplexer n00b to do? |
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
find symmetries. eg a simple sinus can simply be splitted horizontally in a few zones. (circle is the same thing). no need for sorting in such cases :) |
| |
Dano
Registered: Jul 2004
Posts: 234 |
you mean like for 24 sprites define 3 zones and then put the needed sprites into those zones?
what you mean by "finding symmetries"? doesn't quite ring a bell on how or what was this helps for the ordering?
am i thinking too complicated (again)? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
if you put N objects evenly on a circle, and then cut the circle in half horizontally, each half contains exactly N/2 objects. that makes having 16 sprites on a circle trivial and obvious :) and you can repeat the process on the halves (not really symmetric now, ok). the same can be done on sinus-movements (and a lot of other things). |
| |
lft
Registered: Jul 2007
Posts: 369 |
Consider a simple sinus Y-movement. At any given time, half of the sprites will be moving upwards, and half of them will be moving downwards. Place the first half in sprites 0-3 and the second half in sprites 4-7. Now you can just apply a round-robin schedule to each half.
Did you mean something like that, groepaz? |
| |
lft
Registered: Jul 2007
Posts: 369 |
You beat me to it. =) |
| |
Dano
Registered: Jul 2004
Posts: 234 |
@LFT: as far as i understand it, that implies to have the full sinus on screen all the time?
meaning if one doesn't have the full data on screen, one can't take full effect on similarities and such.
so if i understand it correctly you would all analyze the movement in beforehand/on compile time? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
you just look at the full period, it doesnt really matter if all of it is visible all the time - the logic behind it stays the same. |
| |
Perplex
Registered: Feb 2009
Posts: 255 |
If the length of your y movement table is a multiple of the number of objects, say 32 objects and 128 values in the movement table, then the y values used by those objects will repeat every 4 frames. Just create 4 separate multiplexing code blocks, then alternate between them. No sorting needed, and you will always know in each code block how many cycles will be used by sprites on each line throughout the screen. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
yeah, dividing whatever your effect does into "animation frames" is another thing that helps a lot |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
That's what I usually did. Split the movement into 'frames', so for example after 8 updates you reset the Y-positions to their 'frame 0' state and move sprite pointers.
For sideborder stuff involving graphics on screen with badlines, I'd usually write separate routines for each frame.
Absolutely no need to sort anything, but the y-movement is fixed. |
