 Previous Messages |
Posted By
Luca
on 2024-11-01
13:12:13
 |  Re: Updating visible characters
Fuzzweed I'm following your progresses via X, keep up the great work!
|
|
Posted By
Murphy
on 2024-11-01
11:39:23
| Re: Updating visible characters
Nice to see someone working on a demo! \o/
As the others have said, you are doing it right, there might be a small error in the implementation.
|
|
Posted By
Fuzzweed
on 2024-11-01
09:20:29
| Re: Updating visible characters
Thank you. I should probably have tried just one direction to begin with 
|
|
Posted By
gerliczer
on 2024-11-01
09:11:06
| Re: Updating visible characters
Your reasoning and logic is good. Your implementation is failing. Most probably you mix up in your background character update the phase of the scroll and from time to time you either miss an update or apply the incorrect shift.
|
|
Posted By
Fuzzweed
on 2024-11-01
09:05:49
| Re: Updating visible characters
Ok thank you. That's a helpful answer
Yes finding the problem is for me, but first I needed to know it is as a problem that could be found, and not trying the impossible.
|
|
Posted By
Csabo
on 2024-11-01
08:54:11
| Re: Updating visible characters
It's difficult to diagnose what could be wrong with your code without seeing it, but from what you're describing, you're doing it correctly. The rule of thumb is: "don't update the part of the screen that is currently being drawn" - which is what leads to flicker.
If you're waiting for $FF1D = $CB, that's good. Common practice is to do a DEC$FF19 at the beginning of the code that updates the screen and an INC$FF19 at the end of it, so you can "see" how much CPU time is taken up. If that highlighted area doesn't wrap around and reach the top part of the screen (and from your video it looks like it doesn't), then you're good. My guess is that you're not updating the background character correctly.
|
|
Posted By
Fuzzweed
on 2024-11-01
08:47:24
| Re: Updating visible characters
Well i know I can update the whole screen by changing 8 bytes, because I did it, but yes now I need to know how it works so I can make it do it better.
Maybe if I show you my idea you can give more specific pointers.
The text is scrolling 'normally' left, up down
So I am trying to update background character in the opposite direction, right, down, up so it looks static.
The idea works, but it's a bit glitchy.
Is it possible at all to improve within the limits of the CPU/ screen refresh
https://youtube.com/shorts/dlalihz1vaY?si=b4rZKR3CIv6fSb8m
In terms of current raster timing I'm just using
CMP ff1d to $cb before any screen movement (pixel scroll, chr update, chr copy)
|
|
Posted By
gerliczer
on 2024-11-01
07:41:03
| Re: Updating visible characters
What?   I think you, unfortunately  , don't have even the foggiest idea about how screen generation works. Would you like to have some basic explanation?
|
|
Posted By
Fuzzweed
on 2024-11-01
05:47:29
| Updating visible characters
I'm just after information on exactly how the ted updates the screen if I change a visible character - IE change the values of the character, not the screen code.
If the screen is blank (chr32) and I change chr32 to $ff, FF, FF... Then now every pixel is 'on'.
For flicker free, is it enough to change these 8 bytes with the raster off screen, or does the TED do 'extra' processing of each chr position that means the process would run into the next screen draw.
|
|
