7800 screen drawing/tearing issue

[R_Leo_1]

I've create a screen fade-out function for use in my LadyLady Demo, but I'm having an issue where part of the screen will be a frame ahead of the other. In other words, part of the screen is fading at a faster rate than the rest of the screen, and the section of the screen that is lighter than the other will "catch up" on the next frame. My assumption is that this is a screen tearing issue but I'm not 100% sure, and even if it is I've tried everything I could possibly think of to correct it, to no avail. I have included screenshots of the problem in action and my code as an attachment, just look for the fadeout function, it should be labeled as such. Any help would be appreciated, thank you.

 

 

LadyLadyDemo.zip

[+SmittyB]

Nothing looks obviously wrong to me. I think what you're seeing is where the values of the brighter colours take more frames to decrement to the lowest value, and because your text has large areas of colour with brightness changes, as it gets darker the colour divisions are a bit more obvious where the brighter areas take on the same colour of the darker areas a frame or so after.

[RevEng]

7800basic code runs during the visible screen, until a display changing command happens (ie. plot* commands) at which point 7800basic then waits for the visible screen to end before proceeding.

 

Color register updates don't cause this same screen wait to happen, since nobody will ever perceive a single color register update. But regular updates of the color registers happening around the same time may be perceived as tearing.

 

Try adding the drawwait command just prior to the color register updates. This causes you to waste a bunch of computational time, so I wouldn't choose to use this technique during regular game code (not without positioning the color register updates closer to my plot* commands, anyway) but you're not doing anything other than the fading here so you should be fine.

 

Side note 1 - you don't need to "clc" or otherwise worry about the carry for "dex". It's not affected by, nor affects, the carry.

Side note 2 - if you just want to decrease a memory location without actually using the value anytime soon, you don't need to load, decrement, and store. You can just use the "dec" opcode directly on the memory instead. e.g. "dec p0COL3"

[R_Leo_1]

10 hours ago, SmittyB said:

Nothing looks obviously wrong to me. I think what you're seeing is where the values of the brighter colours take more frames to decrement to the lowest value, and because your text has large areas of colour with brightness changes, as it gets darker the colour divisions are a bit more obvious where the brighter areas take on the same colour of the darker areas a frame or so after.

I had thought this was it at first, but there would be a section of the art that was all one color, say white, it would be split up and you can see this on the headphone-looking device on LadyLady's ear, that device was all using pure white and during the fade it gets split. 

7 hours ago, RevEng said:

7800basic code runs during the visible screen, until a display changing command happens (ie. plot* commands) at which point 7800basic then waits for the visible screen to end before proceeding.

 

Color register updates don't cause this same screen wait to happen, since nobody will ever perceive a single color register update. But regular updates of the color registers happening around the same time may be perceived as tearing.

 

Try adding the drawwait command just prior to the color register updates. This causes you to waste a bunch of computational time, so I wouldn't choose to use this technique during regular game code (not without positioning the color register updates closer to my plot* commands, anyway) but you're not doing anything other than the fading here so you should be fine.

 

Side note 1 - you don't need to "clc" or otherwise worry about the carry for "dex". It's not affected by, nor affects, the carry.

Side note 2 - if you just want to decrease a memory location without actually using the value anytime soon, you don't need to load, decrement, and store. You can just use the "dec" opcode directly on the memory instead. e.g. "dec p0COL3"

Thank you for the advice, I placed in the drawwait command, and it's working fine now  

Also I appreciate the 6502 advice. I'm only now starting to use asm more often, so tips like this are very much appreciated!

[SlidellMan]

Just downloaded and I have to say that it looks promising.

[R_Leo_1]

10 hours ago, SlidellMan said:

Just downloaded and I have to say that it looks promising.

Thanks, man! I apologize for not having more to show thus far, I decided to restructure most of the code to be more efficient and less un-organized. That has eaten up most of my development since the last large reveal, and the Coronavirus situation is certainly not helping either.

[Mord]

Not sure if it would help, but perhaps for any color starting with an intensity higher than 7 to drop in intensity by 2 instead of 1 per frame?  You won't achieve a perfect fadeout that way either (hard to do that with the limitations) but it might look a bit nicer?  You'd need to keep track of which palette color -started- greater than 7 of course. eventually they'll all be under 7.

 

Then again doing it such that so long as the current color is > 7, decrement it by 2, it might still work out well.  The bright white would certainly fade a little faster and reach 0 a little sooner.

 

To get as good as possible for a nice fade, you'd probably have to do up a table of predetermined values that you could step through. It'd probably be a big waste of rom to do it that way though.