Issue with sprite jumping in Bb

[kikipdph]

When, for example, a sprite jumps from y 140 to y 30, all the sprites located between y 30 and 140 flicker, including the one that jumped. This is happening in the DPC+ kernel.

So, let's say:

player3y = 140 player2y = 50 if joy0fire then player2y = 30

When someone presses the button on the joystick, player2 will jump to position 30, but all the sprites on the lines in between, as well as player2, will flicker.

Is there a simple solution for this?

[KevKelley]

1 hour ago, kikipdph said:

When, for example, a sprite jumps from y 140 to y 30, all the sprites located between y 30 and 140 flicker, including the one that jumped. This is happening in the DPC+ kernel.

So, let's say:

player3y = 140 player2y = 50 if joy0fire then player2y = 30

When someone presses the button on the joystick, player2 will jump to position 30, but all the sprites on the lines in between, as well as player2, will flicker.

Is there a simple solution for this?

Without seeing specifics the only thing I can think of is that either the top or bottom of player2 sprite is too close to the other sprites resulting in a flicker. I cannot recall but I thought the safe space in between sprites in DPC+ is somewhere around 15 pixels. 

[kikipdph]

1 hour ago, KevKelley said:

Without seeing specifics the only thing I can think of is that either the top or bottom of player2 sprite is too close to the other sprites resulting in a flicker. I cannot recall but I thought the safe space in between sprites in DPC+ is somewhere around 15 pixels. 

That's not the problem you're mentioning, and it doesn't flicker continuously, just once. Take a look at the example in the video.

I've noticed some other things as well. Could it possibly be related to my PC? For example, if the "gosub" isn't close to "drawscreen," the game doesn't work on the Atari, even though the emulator doesn't show any errors.

But that's a different topic. Watch the video, and when a new item appears, all the sprites skip and flicker.
In the video, due to the aspect ratio, it may not be visible every time, but in reality, every time a new item appears

 

[+Gemintronic]

Recently I tried to make a scrolling pinball table and got similar flickering using the multi sprite kernel.  It's a reach but maybe related?  Use UP or DOWN on joystick to scroll the playfield and sprites.

 

My hunch is that something I am doing is triggering flicker mitigation in the kernel when virtual sprites reach a boundary.  But, my understanding of graphical kernels is very poor.

 

mysteryflicker.binmysteryflicker.zip  

 

[kikipdph]

6 hours ago, Gemintronic said:

Recently I tried to make a scrolling pinball table and got similar flickering using the multi sprite kernel.  It's a reach but maybe related?  Use UP or DOWN on joystick to scroll the playfield and sprites.

 

My hunch is that something I am doing is triggering flicker mitigation in the kernel when virtual sprites reach a boundary.  But, my understanding of graphical kernels is very poor.

 

mysteryflicker.bin 4 kB · 0 downloads mysteryflicker.zip 3.88 kB · 0 downloads   

 

 It's less noticeable on a dark background.

Edited June 21 by kikipdph

[KevKelley]

Hmm. The only thing I am wondering that I would look at in my code is if is either where the placement of the repositioning of the sprite is in relationship to the drawscreen and messing with what @Gemintronicmentioned about the flicker mitigation. 
 

The only other thing I could think of is maybe skipping a frame and then reposition it to avoid any conflicts. 

[kikipdph]

5 hours ago, KevKelley said:

Hmm. The only thing I am wondering that I would look at in my code is if is either where the placement of the repositioning of the sprite is in relationship to the drawscreen and messing with what @Gemintronicmentioned about the flicker mitigation. 
 

The only other thing I could think of is maybe skipping a frame and then reposition it to avoid any conflicts. 

 

Positioning the sprites in relation to the drawscreen doesn't help.

I haven't tried anything else.

[+Random Terrain]

You mentioned that you were using GOSUB. Are you using return thisbank or return otherbank?

 

Speaking of GOSUB, unless I absolutely need to use the same code from multiple places because I'm running out of space, I try to avoid GOSUB.

[+splendidnut]

The sprite sorting routine in the bBasic multisprite kernel is designed to both (A) put the sprites in drawing order while also (B) trying to rotate the order of the sprites that currently overlap.  Those two disparate things are handling by a single sorting algorithm, so compromises have been made to support both.  I believe the DPC+ bBasic kernel uses the same or a similar algorithm.

 

I'm betting that, because you're moving a sprite from the very end of the sort list to the very beginning, you're trigger a case where the sorting algorithm needs a frame or two to recover.

 

The easiest way for you to workaround that would be to keep the sprites in order.  i.e.  If you remove sprite 5, put the data from 4 into 5, 3 into 4, 2 into 3, and the put your new sprite in 2.

[kikipdph]

11 hours ago, Random Terrain said:

You mentioned that you were using GOSUB. Are you using return thisbank or return otherbank?

 

Speaking of GOSUB, unless I absolutely need to use the same code from multiple places because I'm running out of space, I try to avoid GOSUB.

I use both, depending on which bank the subroutine is in.

[+Gemintronic]

6 hours ago, splendidnut said:

The sprite sorting routine in the bBasic multisprite kernel is designed to both (A) put the sprites in drawing order while also (B) trying to rotate the order of the sprites that currently overlap.  Those two disparate things are handling by a single sorting algorithm, so compromises have been made to support both.  I believe the DPC+ bBasic kernel uses the same or a similar algorithm.

 

I'm betting that, because you're moving a sprite from the very end of the sort list to the very beginning, you're trigger a case where the sorting algorithm needs a frame or two to recover.

 

The easiest way for you to workaround that would be to keep the sprites in order.  i.e.  If you remove sprite 5, put the data from 4 into 5, 3 into 4, 2 into 3, and the put your new sprite in 2.

 

That sounds like it might be a workaround.  Don't know if it feels good since in my mind you'd need to spend at least 5 extra vars on virtual Y coordinates and non-assembly sorting routines running every main game loop.

 

I haven't brought this up with RevEng since I'm always not %100 percent on if it's just my ugly coding.

[+splendidnut]

You shouldn't need any temporary variables using the order I provided in the example.  It's a linear data shift, not a sorting routine, so it really shouldn't use too much time.

[kikipdph]

7 hours ago, splendidnut said:

The sprite sorting routine in the bBasic multisprite kernel is designed to both (A) put the sprites in drawing order while also (B) trying to rotate the order of the sprites that currently overlap.  Those two disparate things are handling by a single sorting algorithm, so compromises have been made to support both.  I believe the DPC+ bBasic kernel uses the same or a similar algorithm.

 

I'm betting that, because you're moving a sprite from the very end of the sort list to the very beginning, you're trigger a case where the sorting algorithm needs a frame or two to recover.

 

The easiest way for you to workaround that would be to keep the sprites in order.  i.e.  If you remove sprite 5, put the data from 4 into 5, 3 into 4, 2 into 3, and the put your new sprite in 2.

The easiest way is to stop programming Atari games

[+splendidnut]

Ah, sorry... I missed the fact there's no flexible way to load sprite graphics.  Such as:   player2sprGfx = BirdGFX   or player2sprGfx = player1sprGfx.

 

Also, realized that it will still take a bit of time to shift all that data since it's ALL the sprite variables that need to be shifted.

 

So, it's probably best if someone takes a closer look at the kernel sorting routine to see if this could easily be remedied.