How does the DPC+ flicker management works?

[Lillapojkenpåön]

I have tried to find how it keeps track of how many sprites are overlapping and what order to flicker but can't see it? It has to be stored in a byte right?

It would be useful to experiment with lumaboost in bB, I would personally like to use it to get a third player to wait if there's allready two players flickering.

 

player1 waits if player2 is flickering

player2 waits if player1 is flickering

 

player3 waits if player4 is flickering

player4 waits if player3 is flickering

 

I could do that with alot of vertical checking, but that must allready be done somewhere for the flicker management?

[Lillapojkenpåön]

I have made a nice and easy to understand LumaBoost example that I look forward to sharing, but I need help figuring out what bits of what byte to check if the players are overlapping and flickering

 

 

includes/custom/main.c contains this..

 

int checkswap(int a, int b)

{

signed int temp1;

char s1,s2;

s1=checkwrap(RIOT[player1y+a],RIOT[player1height+a]);

s2=checkwrap(RIOT[player1y+b],RIOT[player1height+b]);

temp1=s1-s2;

if (temp1>0)

{ // larger is higher

if ((temp1-=5)>0)

{// not overlapping

if (temp1>RIOT[player1height+b])

return SKIP;

else return OVERLAP;

}

else

return OVERLAP;

}

else // largerXislower

{

if ((temp1=(temp1^0xFF)-5)>0)

return OVERLAP;

else

{//notoverlapping

if (temp1>RIOT[player1height+b])

return NOOVERLAP;

else return OVERLAP;

}

}

}

Then it continues in includes/DPCplus_kernel.asm i guess?

spritedisplay, SpriteGfxIndex and SpriteGfxIndex+1 gives promising results when the virtual sprites are overlapping.

asm

lda spritedisplay

sta temp4

end

_sc1 = 0 : _sc2 = _sc2 & 15

if temp4 >= 100 then _sc1 = _sc1 + 16 : temp4 = temp4 - 100

if temp4 >= 100 then _sc1 = _sc1 + 16 : temp4 = temp4 - 100

if temp4 >= 50 then _sc1 = _sc1 + 5 : temp4 = temp4 - 50

if temp4 >= 30 then _sc1 = _sc1 + 3 : temp4 = temp4 - 30

if temp4 >= 20 then _sc1 = _sc1 + 2 : temp4 = temp4 - 20

if temp4 >= 10 then _sc1 = _sc1 + 1 : temp4 = temp4 - 10

_sc2 = (temp4 * 4 * 4) | _sc2

asm

ldy #0

lda SpriteGfxIndex,y

sta temp4

end

_sc2 = _sc2 & 240 : _sc3 = 0

if temp4 >= 100 then _sc2 = _sc2 + 1 : temp4 = temp4 - 100

if temp4 >= 100 then _sc2 = _sc2 + 1 : temp4 = temp4 - 100

if temp4 >= 50 then _sc3 = _sc3 + 80 : temp4 = temp4 - 50

if temp4 >= 30 then _sc3 = _sc3 + 48 : temp4 = temp4 - 30

if temp4 >= 20 then _sc3 = _sc3 + 32 : temp4 = temp4 - 20

if temp4 >= 10 then _sc3 = _sc3 + 16 : temp4 = temp4 - 10

_sc3 = _sc3 | temp4

 

I put that code into RT's 13 objects with cordinates example in hope that someone can help me figure it out.

"Hold down the fire button and press the joystick up or down to select an object"

 

player0y

player1y

player2y

player3y

player4y

player5y

player6y

player7y

player8y

player9y

ex_dpc_13_objects_MODIFIED.bas

[Lillapojkenpåön]

I think I'm onto something

 

if SpriteGfxIndex+0 <> 0 then P1 is flickering

if SpriteGfxIndex+1 <> 1 then P2 is flickering

if SpriteGfxIndex+2 <> 2 then P3 is flickering

if SpriteGfxIndex+3 <> 3 then P4 is flickering

etc.

When player1 is not flickering SpriteGfxIndex+0 will be 0, when it's flickering and visible it will be +1, so 1

when not visible SpriteGfxIndex+0 will be the number/numbers of the player/players it's overlapping with -1, so if it's overlapping with player7 it will be 6.

Needs more testing, seems to work a little differently sometimes?

I have never noticed it before but if you place one sprite so two other ones start flickering, it shows those two for two frames then the other for one, instead of every other frame.

[+Gemintronic]

One experiment I did with the non DPC+ multi sprite kernel was rotating which player got the first sprite. It didn't do any better than bataris built in flicker management. But, who knows if DPC+ will be different?

[Lillapojkenpåön]

The last thing I said wasn't correct at all, I'm getting nowhere because I don't understand c code and I don't even get when the c code is accessed?

[+RevEng]

I don't believe any of the ARM memory used in the sort algorithm is exposed to the 6507.

 

Looking over the main.c code, the initial flicker/sort order is set when the spritesort array is created. After that, detected overlaps will cause shiftnumbers() to alter that order. Calling again the next frame, will cause the order to be altered again.

[Lillapojkenpåön]

Thanks! then I can stop worrying about that