Lillapojkenpåön Posted January 5, 2019 Share Posted January 5, 2019 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? Quote Link to comment Share on other sites More sharing options...
Lillapojkenpåön Posted January 8, 2019 Author Share Posted January 8, 2019 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 Quote Link to comment Share on other sites More sharing options...
Lillapojkenpåön Posted January 8, 2019 Author Share Posted January 8, 2019 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. Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted January 8, 2019 Share Posted January 8, 2019 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? Quote Link to comment Share on other sites More sharing options...
Lillapojkenpåön Posted January 9, 2019 Author Share Posted January 9, 2019 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? Quote Link to comment Share on other sites More sharing options...
RevEng Posted March 19, 2019 Share Posted March 19, 2019 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. Quote Link to comment Share on other sites More sharing options...
Lillapojkenpåön Posted March 19, 2019 Author Share Posted March 19, 2019 Thanks! then I can stop worrying about that Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.