spritesort reduces spriteflicker
The result looks a lot nicer!
How much more CPU does this use than the traditional method? That might be an issue.
The "konami attack cascade" sketch takes something like 32 rasterlines.
I noticed that the typical C64 multiplexor game got always MAX 5 sprites
per scanline: 8 sprites hardware, 3 sprites reserved for player, shield, bullet.
And the top enemy row of the 9918 spritesort sketch got 6 colored sprites,
so it goes beyond C64
Also some people believe you should flicker entire characters (when they use multiple overlapping or combined sprites), that also might make things a bit more complicated.
oh, I have not thought about that! it is nicer when the whole character is flickering instead of parts.
it would need another byte in the struct to store chain info.
but the required checks might slow the engine much.
How much more CPU does this use than the traditional method? That might be an issue.
The "konami attack cascade" sketch takes something like 32 rasterlines.
I noticed that the typical C64 multiplexor game got always MAX 5 sprites
per scanline: 8 sprites hardware, 3 sprites reserved for player, shield, bullet.
And the top enemy row of the 9918 spritesort sketch got 6 colored sprites,
so it goes beyond C64
Also some people believe you should flicker entire characters (when they use multiple overlapping or combined sprites), that also might make things a bit more complicated.
oh, I have not thought about that! it is nicer when the whole character is flickering instead of parts.
it would need another byte in the struct to store chain info.
but the required checks might slow the engine much.
Leo, everything you need to know is in the readme.
hit9918, interesting way to make a first post. Looks like a good algorithm. The ability to use with more than 32 sprites makes it especially nice.
Thank you! The demo can be hacked easy by fiddeling the BASIC code,
maybe you want to play a bit with the sketch:
adjust amount of sprites N=foo around line 160.
then for every sprite add DATA Y,X,C,P (it is 9918 layout order).
For example, add 12 more sprites, set N=39 (the demo was N=27).
then duplicate the first 12 data lines and add 100 to the first value in the DATA, the Y values.
now you got 39 sprites, hehe
Then you can see the top sprite row was not degraded by the action going on below.
But when you press cursor key, you can see that the top row has gotten worse
with ringbuffer, because the action below makes the ringbuffer longer and though
the flicker roundtrip longer.
btw if e.g. bluemsx set to "500% speed", then one cannot see it, need 100%
and best is 100% speed and PC Hz same as MSX Hz.
About the ring buffer approach. You can improve its look by choosing an offset 5 or 7. This way you will increase the repeat of the flicker pattern from 8 frames to 32 frames.
Have not tried these, maybe it makes the look more "organic", break up groups.
But I doubt it can do much about the worst case sprite disappearance?
32 sprites, ringbuffer start addresses per frame:
0, 7, 14, 21, 28, 35->35 AND 32 = 3, 10, ...
"3,10,..." means: display 3,4,5,6 in a frame and then 10,11,12,13 in the next frame.
(imagine 32 sprites in a row, worst scenario).
so I found a case where sprite 7,8,9 are missing in TWO roundtrips!
you got the roundtrip down to something like 5 steps, but missing
two roundtrips means a worst case of 2 * 5 = 10 frames:
so for some sprites things got even worse than
the worst case of 7 sprites per frame.
So it looks like a simple ringbuffer aproach can never go beyond the
number "the average worst case with 32 sprites is disappearing for 7 frames".
trying to change the offset from 4 will make things better for some lucky sprites,
and make things worse for some unlucky sprites.
hit9918, interesting way to make a first post. Looks like a good algorithm. The ability to use with more than 32 sprites makes it especially nice.
Thank you! The demo can be hacked easy by fiddeling the BASIC code,
maybe you want to play a bit with the sketch:
adjust amount of sprites N=foo around line 160.
then for every sprite add DATA Y,X,C,P (it is 9918 layout order).
For example, add 12 more sprites, set N=39 (the demo was N=27).
then duplicate the first 12 data lines and add 100 to the first value in the DATA, the Y values.
now you got 39 sprites, hehe
Then you can see the top sprite row was not degraded by the action going on below.
But when you press cursor key, you can see that the top row has gotten worse
with ringbuffer, because the action below makes the ringbuffer longer and though
the flicker roundtrip longer.
btw if e.g. bluemsx set to "500% speed", then one cannot see it, need 100%
and best is 100% speed and PC Hz same as MSX Hz.
About the ring buffer approach. You can improve its look by choosing an offset 5 or 7. This way you will increase the repeat of the flicker pattern from 8 frames to 32 frames.
Have not tried these, maybe it makes the look more "organic", break up groups.
But I doubt it can do much about the worst case sprite disappearance?
32 sprites, ringbuffer start addresses per frame:
0, 7, 14, 21, 28, 35->35 AND 32 = 3, 10, ...
"3,10,..." means: display 3,4,5,6 in a frame and then 10,11,12,13 in the next frame.
(imagine 32 sprites in a row, worst scenario).
so I found a case where sprite 7,8,9 are missing in TWO roundtrips!
you got the roundtrip down to something like 5 steps, but missing
two roundtrips means a worst case of 2 * 5 = 10 frames:
so for some sprites things got even worse than
the worst case of 7 sprites per frame.
So it looks like a simple ringbuffer aproach can never go beyond the
number "the average worst case with 32 sprites is disappearing for 7 frames".
trying to change the offset from 4 will make things better for some lucky sprites,
and make things worse for some unlucky sprites.
By hit9918
Champion (432)
07-03-2010, 01:33