Screen Shearing Specifics

[+Karl G]

So, I understand that when you draw to the screen during the visible portion, some shearing/distortion of objects can happen. I was wondering if there was more information as to when it would or would not happen, and any ways to avoid it (apart from the obvious of avoiding drawing to the screen during the visible portion). It doesn't seem to happen e.g. when doing the updates to the screen for the 48 pixel sprite trick, nor does it seem to happen when changing the playfield registers for an asymmetric playfield.

 

Any information or tips are appreciated!

[azure]

So, I understand that when you draw to the screen during the visible portion, some shearing/distortion of objects can happen. I was wondering if there was more information as to when it would or would not happen, and any ways to avoid it (apart from the obvious of avoiding drawing to the screen during the visible portion).

 

Artifacts happen when your kernel doesn't write to the graphics registers on time. When the beam is running across the visible part of the screen, the kernel has little time to do much else, because its busy shuffling data to the graphics registers.

 

The kernel is like a passenger trying to catch a moving train. If you're late you've missed your chance, so your sprite doesn't get displayed. If you're on time it gets displayed. If you're early, it's okay in the simple case when you only have 2 sprites on the same line (e.g. Combat).

 

However, if you're dynamically repeating sprites with NUSIZ0/NUSIZ1, such as using the 48 pixel trick, writing registers early doesn't work. Each write must occur precisely within a narrow window of time, because the kernel is playing a shell game with the GRP0 and GRP1 registers. That's the cost of using two sprite registers to simulate six sprites. This is why cycle counting matters so much. The timing of each write depends on which cycle count it lands on.

 

 

It doesn't seem to happen e.g. when doing the updates to the screen for the 48 pixel sprite trick

 

That's because the timing has already been worked out. If you insert a nop in the middle of the 48-pixel sprite algorithm, you'll see rendering artifacts, because it will shift the timing of the writes.

 

 

nor does it seem to happen when changing the playfield registers for an asymmetric playfield

 

 

It can happen with the playfield if the kernel is trying to do asymmetric playfields (e.g. Ms Pac-Man) and it gets the timing wrong. But, if your playfield remains static for the duration of a line (e.g. Combat), it's a set and forget situation. You can write the patterns early to PF0, PF1, PF2 at the start of the line while the beam is in the horizontal bank and then sleep for the rest of the line.

 

I really recommend Andrew's tutorials. They get into specific details explaining how things work.

Edited August 25, 2018 by azure

[Just Jeff]

If you are updating sprite graphics, it simply a matter of knowing which cycle you are at when you update the graphic register- and did you do it in time.

 

If your object is moving player you can't know that, so either update it in the blanks, or restrict the movement of the player. You might be able to use VDEL sometimes as well.

 

If the distortion you mention is the vertical distortion that can occur, that is usually because your player is near the right edge of the screen. The typical sprite positioning routine can't finish in time to beat the beam at the end, giving you an unintended extra scan line. You can eliminate this by either repositioning outside the kernel, restricting the movement of the player, or in some cases, you can set a timer that will keep that time consistent, and long enough to cover that extra scan line whether or not your player is on the right edge of the screen.

[+Karl G]

I think that I have a pretty good understanding of timings at this point. So,screen shearing is only an issue if the update to the object happens too late? In this case, I am talking about a static display, so I did work out the timing beforehand.

I'm thinking that the distortion I'm seeing has another cause, since I found a way to get all of my updates in the horizontal blank period, but I'm still seeing the issue.

Anyway, thanks for the information and advice!

[+Karl G]

So, here is my project where I am seeing distortion with my P0 object. I had been blaming doing updates during the visible portion of the scanline, but I rewrote it to avoid that, but I still see the distortion. One obvious difference I am seeing between the 3 copies of P0 is a missing top line on the first copy. I have confirmed via the debugger that the value of GRP0 is set well before it displays the first copy, and VDELP* is not enabled.

 

Does anyone know what I am doing wrong here? Thanks in advance for any advice.

 

Note that this is likely to end up as a bB minikernel, which is the reason for odd stuff like setting up pointers during the visible screen.

 

 

3lives.asm

 

3lives.bin

[DirtyHairy]

It's covered by a HMOVE line

 

[+Karl G]

Oh! Of course it's still there even if I use a black background. I guess I either need to HMOVE one line earlier, or do the early HMOVE trick. Thanks!