DPC+ Sprite Troubles Came Back

[+Random Terrain]

I was working on this just before my Windows 7 computer died and now I've finished it on my Windows 8 computer.

 

Look at the second to last sprite:

 

youtube.com/watch?v=xWM2sDDgLGE

https://www.youtube.com/watch?v=xWM2sDDgLGE

 

At one time all of that weird stuff was fixed and it seems like most of it is still fixed, but it looks like a bit of it came back during one of the bB updates.

 

You can try it yourself here:

 

randomterrain.com/atari-2600-memories-batari-basic-commands.html#ex_dpc_13_objects

 

 

[The example program above was updated so moving any of the sprites in their original y positions left and right no longer makes a piece of another sprite disappear.]

[Papa]

I found that by changing the object placement...

 

;***************************************************************
;
; Object placement.
;
player0x = 77 : player0y = 0
player1x = 77 : player1y = 20
player2x = 77 : player2y = player1y + 20
player3x = 77 : player3y = player2y + 20
player4x = 77 : player4y = player3y + 20
player5x = 77 : player5y = player4y + 20
player6x = 77 : player6y = player5y + 20
player7x = 77 : player7y = player6y + 20
player8x = 77 : player8y = player7y + 20
player9x = 77 : player9y = player8y + 20
missile0x = 98 : missile0y = 14
missile1x = 98 : missile1y = 31
ballx = 98 : bally = 48

 

..to this, eliminates the problem. I believe that sprite 1 is encroaching on the space for the extra sprites by being placed in an odd original distance from the reflected spaces. By making the distances the same they all have an equal space to reflect in. This may be a quick fix, but it works! I just realized it works AFTER the first sprite is moved at least once..

Edited March 30, 2015 by Papa

[Papa]

..and this seemed to fix it completely..

 

;***************************************************************
;
; Sets color of missiles.
;
COLUM0 = $FE : COLUM1 = $AC


;***************************************************************
;
; Object placement.
;
player0x = 77 : player0y = 155
player1x = 77 : player1y = 15
player2x = 77 : player2y = player1y + 15
player3x = 77 : player3y = player2y + 15
player4x = 77 : player4y = player3y + 15
player5x = 77 : player5y = player4y + 15
player6x = 77 : player6y = player5y + 15
player7x = 77 : player7y = player6y + 15
player8x = 77 : player8y = player7y + 15
player9x = 77 : player9y = player8y + 15
missile0x = 98 : missile0y = 14
missile1x = 98 : missile1y = 31
ballx = 98 : bally = 48

 

This makes them all visible and places the 0 sprite at the bottom of the screen..

[RevEng]

[...]

At one time all of that weird stuff was fixed and it seems like most of it is still fixed, but it looks like a bit of it came back during one of the bB updates.

Actually, this one was never fixed. From the BUGS.txt file...

 

overview: DPC+ vsprite vertical stack glitch.

details: If the virtual sprites are stacked with very little spacing, cumulative round-off [error] can occur, and eventually coarse positioning will happen during a virtual sprite display, resulting in a visual glitch.

workaround: avoid stacking vsprites vertically without much spacing. Or put them all on even or all odd rows, depending if the height of the vsprites are even or odd.

There's nothing to be done about it in all cases, short of a rewrite of the DPC+ kernel and trading off some capabilities to squash it.

[+Random Terrain]

..and this seemed to fix it completely..

 

Thanks, but the sprites are too close together using 15 (causing flicker). I'm trying to avoid flicker when the program starts up. Users can then move the sprites around and see all of the different ways that the sprites can flicker.

 

test_flicker_ex_dpc_13_objects.bin

 

After playing around with the code, I found out that staggering 17 and 18 gets rid of the problem shown in the first part of the video when moving the last two sprites left and right messed things up.

 

 

 

Actually, this one was never fixed. From the BUGS.txt file...

 

 

There's nothing to be done about it in all cases, short of a rewrite of the DPC+ kernel and trading off some capabilities to squash it.

Thanks. Oh, I see:

 

atariage.com/forums/topic/214909-bb-with-native-64k-cart-support-11dreveng/?p=2821726

 

I thought you eventually found a way to fix it.

 

At least staggering them using 17 and 18 lets the user move the objects left and right without pieces of sprites disappearing:

_

   ;***************************************************************
   ;
   ;  Object placement.
   ;
   player0x = 77 : player0y = 0
   player1x = 77 : player1y = 17
   player2x = 77 : player2y = player1y + 18
   player3x = 77 : player3y = player2y + 17
   player4x = 77 : player4y = player3y + 18
   player5x = 77 : player5y = player4y + 17
   player6x = 77 : player6y = player5y + 18
   player7x = 77 : player7y = player6y + 17
   player8x = 77 : player8y = player7y + 18
   player9x = 77 : player9y = player8y + 17
   missile0x = 98 : missile0y = 14
   missile1x = 98 : missile1y = 31
   ballx = 98 : bally = 48

_

ex_dpc_13_objects_2015y_03m_31d_0200t.bin

[Papa]

It's all about spacing, I think. I'm currently making a pretty rad racing game with DPC+ (a few others, too). I've been working with it since it came out and it is really fun! You can run out of space fast with all the higher resolution playfields. The ability to avoid the 'icing' effect and bring the pixel count up is worth it. Many of my games started on the old Bb and have been ported to DPC+. I would have lost a LOT of animation with Titan Axe, though. My second Titan Axe game is DPC+ and uses less badguys but has more color changes and *gasp.. TWO PLAYER COOP!! When using multiple drawcreens to have similar effects on the old system I encountered greater levels of flicker, but, of course, the system is slowed considerably. When I ported one of my games from old to new I had to go in and lengthen all the notes on my musical score because the multiple drawcreens slowed it down so much. With all this control over resolution, this really is a fun way to program.