DPC+ Graphics Glitch

[KevKelley]

While working on a program I had noticed that in the DPC+ kernel, when I would have sprites (player1-player9) close to each other there may occur a graphical glitch where it seems the top line of the sprite will shift to the right roughly 8 pixels. 

 

I had tried to keep the sprites and copies spaced to avoid flicker as much as possible and I resolved this issue by shifting the y-coordinates by one, or in the instance of the pictured example, I shrunk the toolbox sprite in the street by one line to avoid the glitch on the top of the player counter sprite.

 

I was curious if anyone knew any specifics as to why this occurs?  Why wouldn't the sprites just flicker?

[rsiddall]

I had a similar problem when messing around with my mission impossible demo. Same area close to bottom of screen. One of the robot's heads would scoot off to the right.

 

Was not always apparent and didn't start off doing so but would end up with the shearing after an undetermined amount of time.

 

I think I did the same thing by moving it up or down to avoid the issue.

[JetSetIlly]

(removed because I didn't notice this was posted on the Bb forum. I don't have a Bb answer).

Edited August 14, 2022 by JetSetIlly

[orange808]

Yep. TIA is pissed. Looks like the sprite is being "turned on" too soon after repositioning.

 

https://alienbill.com/2600/101/docs/stella.html#NUSIZ

[KevKelley]

I think I kind of understand. I assumed it was with the copies being too close and when it would switch to draw the copy it would catch the first sprite (in my not so technical speak). 
 

It just interested me as I don’t recall it doing it in any other DPC+ program I made in the past but it was an easy fix. I definitely gotta learn more about some of those things like HMOVE. I had been utilizing the debugger more with this game and had figured out a couple issues but while I figured a fix the technical aspect was not as obvious. 

[orange808]

22 minutes ago, KevKelley said:

I think I kind of understand. I assumed it was with the copies being too close and when it would switch to draw the copy it would catch the first sprite (in my not so technical speak). 
 

It just interested me as I don’t recall it doing it in any other DPC+ program I made in the past but it was an easy fix. I definitely gotta learn more about some of those things like HMOVE. I had been utilizing the debugger more with this game and had figured out a couple issues but while I figured a fix the technical aspect was not as obvious. 

Does it still happen if you set NUSIZ1 to zero?

[KevKelley]

19 minutes ago, orange808 said:

Does it still happen if you set NUSIZ1 to zero?

Yeah. The example pictured is the life tokens but it also happened with the balloon boy. Now I didn’t see it happen with any of the balloons but I also have code that if they get to close they push apart up and down so it might preempt any issue. 

[orange808]

17 minutes ago, KevKelley said:

Yeah. The example pictured is the life tokens but it also happened with the balloon boy. Now I didn’t see it happen with any of the balloons but I also have code that if they get to close they push apart up and down so it might preempt any issue. 

I was just curious. I don't remember how the bB DPC+ kernel handles things.

 

I do remember what might solve the issue over on the ARM side. That's where the flicker handling is. Just need to add one to a variable in the code. The result would increase the required blank scanlines between non-flickering repositioned player1 sprites from six to seven scanlines. Although, that wouldn't be fantastic; more flicker isn't desirable.

 

What specific x coordinates trigger the issue? At first, I figured it would be related to "kernel 6". Kernel six is a tricky spot in the DPC+ kernel at the center of the screen. The kernel needs to strobe player1 (RESP1) and write to the playfield at the exact same time. To sort the problem out, the kernel takes care of the playfield on time and stobes the player1 sprite late. The kernel does two separate repositions using HMP1 afterwards. One to apply the required "fine positioning" and another to "make up" for strobing late. I assumed it would be kernel 6, but it looks like it happens earlier?

 

 

 

[KevKelley]

26 minutes ago, orange808 said:

What specific x coordinates trigger the issue?

It seemed to happen more with a y coordinate issue to me, or at least as my best guess. I cannot remember the exact numbers but it was if they were close to 12 or so pixels apart. I think the balloon boy is at 116 and when I had the balloons spawn at 103 the top line would glitch. So I moved it to 102 and it stopped. 
 

The life counter would only glitch when the toolbox would appear. Not sure if the coordinates but when I shortened the sprite at the bottom it seemed to provide the gap needed. I think I had them at the bare minimum for no flicker. 
 

For x coordinates, balloon boy walks back and forth and balloons enter from the left or right. I think it only occurred when they came from the right. I hadn’t taken notice where on the screen it would occur but I thought it had happened elsewhere on the screen then in the middle. 
 

And I have to check videos but in earlier versions of the toolbox, it came right up to the top of the street and I don’t recall the toolbox glitching. 

[+Gemintronic]

One experiment might be to pad the top of sprites with a top layer of nothing "%00000000".  If the kernel is gonna shift the top line it may as well be blank.

 

Is there a universally agreed upon spacing between virtual sprites before flickering is triggered on DPC+?  In the multi sprite kernel it seems to be 3 pixels/lines.

[orange808]

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;
    }
  }
}

Six scanlines.

 

2 hours ago, Gemintronic said:

Is there a universally agreed upon spacing between virtual sprites before flickering is triggered on DPC+? 

 

Edited August 14, 2022 by orange808
My apologies, the number of scanlines minus one is hardcoded, not a variable.

[KevKelley]

I checked and it does occur with the balloons but not as frequent. And I only noticed when I was playing around with virtual sprites. It occurred at various parts of the screen. 

[orange808]

4 minutes ago, KevKelley said:

I checked and it does occur with the balloons but not as frequent. And I only noticed when I was playing around with virtual sprites. It occurred at various parts of the screen. 

Next thing to do is have other people try it out on other consoles. Your TIA may (or may not) be an outlier.

 

[KevKelley]

This was all done in emulation but it occurred when played on hardware. It may be something I had never noticed before today. I usually try to avoid flicker.  

[+Karl G]

Can anyone share an example with source that displays this glitch?

[KevKelley]

31 minutes ago, Karl G said:

Can anyone share an example with source that displays this glitch?

I only had the screenshot above and in my videos, or do you mean the actual binary?

[KevKelley]

I believe the .bin I have uploaded for Lineman displays the glitch when played. 

[rsiddall]

1 hour ago, Karl G said:

Can anyone share an example with source that displays this glitch?

Here's a early version of mine that I think is showing the same glitch.

I found a remedy of sort at some point (moving the sprite up or down a line or two). 

 

I attributed this effect to poor coding on my part and moved on.

Imp-Mis-CURRENT.bas

[orange808]

Double and triple check it on real hardware. If it's there for sure, make a bug report in the batari Basic thread. If you don't see it on your Atari machine, maybe Stella has a bug.

 

I admit I only spent a few weeks actually using batari Basic, but I am almost certain this bug was not present back then in the DPC+ kernel. I have seen this before while coding a kernel, though. It's the "undefined behavior" the Stella guide warns us about when we don't leave the registers alone.

 

Back then, the only really big bug I encountered was related to the top of the playfield. That was easy enough to work around.

Edited August 14, 2022 by orange808

[JetSetIlly]

1 minute ago, orange808 said:

Double and triple check it on real hardware. If it's there for sure, make a bug report in the batari Basic thread. If you you see it on your Atari machine, maybe Stella has a bug.

 

I admit I only spent a few weeks actually using batari Basic, but I am almost certain this bug was not present back then in the DPC+ kernel. I have seen this before while coding a kernel, though. It's the "undefined behavior" the Stella guide warns us about when we don't leave the registers alone.

 

Back then, the only really big bug I encountered was related to the top of the playfield. That was easy enough to work around.

 

It's definitely not a bug in Stella. It's because the player1 position is being reset (to clock 66) and then being drawn before a HMOVE is triggered (moving the counter to clock 60). You can see it if you single-step scanline 203 to 204 on a frame with the glitch.

 

 

[orange808]

1 minute ago, JetSetIlly said:

 

It's definitely not a bug in Stella. It's because the player1 position is being reset (to clock 66) and then being drawn before a HMOVE is triggered (moving the counter to clock 60). You can see it if you single-step scanline 203 to 204 on a frame with the glitch.

 

 

Thanks. I'll peek at github to see when changes were made to the kernel.

 

If all else fails, it can be patched on the ARM side in that checkswap() function.

[KevKelley]

Was this always present or did I just never notice in any DPc+ program I made? I gotta check what version I have of bB.