Jump to content
Sign in to follow this  
Lillapojkenpåön

How does the DPC+ flicker management works?

Recommended Posts

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?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...