11-18-2023, 03:59 PM
_DISPLAY basically says to only update the buffer when the video card is ready for it. This stops screen tearing or printing of partial screens.
_LIMIT says to pause the program so it runs a maximum of X number of times in a second.
Now nothing in Display says that it's going to limit or affect the speed of your program. It just affects how often the screen refreshes.
And nothing in Limit has any control over how often the screen refreshes. It just limits the program speed.
The problem here is that the two won't always be in perfect sync with each other.
Even with a limit of 60, you're dealing with floating point math and rounding. At some point, there's going to be a value of x seconds when the LIMIT does it thing and moves the character once in that loop, and then the next time it runs that loop is going to be 0.999999999999999 seconds later. It's effectively running the loop TWICE before the _DISPLAY ever gets called, which results in that character "skip" that you're noticing.
There's not much really that you can do with such minor glitches. Floating point math is always going to be fuzzy and off by a minute fraction, and its effects will showcase themselves in various little ways like this one.
The one real thing that you can do, however, is to minimize the appearance of the glitch as much as possible. Instead of using LOCATE and PRINT, which moves one character (8 pixels) at a time across the screen, change that to a _PRINTSTRING statement and move pixel by pixel. Will you still see those skips? Surely -- by they'll be 1/8th as large as before, and you're not really likely to even notice that they're going on with the program! A guy who jumps 8 feet is noticable; a guy who jumps one is... Ehh... Who??
Take the above program and run it, for consideration.
My display is 60FPS. With a limit of 600, the program should run 10 times before the _DISPLAY updates. In this case, the last digit should always be a ZERO in the number printed. Unfortunately, they're not synced that perfectly in line with each other. As you can see, that last digit changes constantly as the program is ran. There's got to be times where it processes 9 loops before a refresh, or times where it processes 11 loops before a refresh, because it's certainly not keeping a perfect 10 loop per refresh going on!
_LIMIT says to pause the program so it runs a maximum of X number of times in a second.
Now nothing in Display says that it's going to limit or affect the speed of your program. It just affects how often the screen refreshes.
And nothing in Limit has any control over how often the screen refreshes. It just limits the program speed.
The problem here is that the two won't always be in perfect sync with each other.
Even with a limit of 60, you're dealing with floating point math and rounding. At some point, there's going to be a value of x seconds when the LIMIT does it thing and moves the character once in that loop, and then the next time it runs that loop is going to be 0.999999999999999 seconds later. It's effectively running the loop TWICE before the _DISPLAY ever gets called, which results in that character "skip" that you're noticing.
There's not much really that you can do with such minor glitches. Floating point math is always going to be fuzzy and off by a minute fraction, and its effects will showcase themselves in various little ways like this one.
The one real thing that you can do, however, is to minimize the appearance of the glitch as much as possible. Instead of using LOCATE and PRINT, which moves one character (8 pixels) at a time across the screen, change that to a _PRINTSTRING statement and move pixel by pixel. Will you still see those skips? Surely -- by they'll be 1/8th as large as before, and you're not really likely to even notice that they're going on with the program! A guy who jumps 8 feet is noticable; a guy who jumps one is... Ehh... Who??
Code: (Select All)
DO
LOCATE 1, 1: PRINT x
_LIMIT 600
_DISPLAY
x = x + 1
LOOPTake the above program and run it, for consideration.
My display is 60FPS. With a limit of 600, the program should run 10 times before the _DISPLAY updates. In this case, the last digit should always be a ZERO in the number printed. Unfortunately, they're not synced that perfectly in line with each other. As you can see, that last digit changes constantly as the program is ran. There's got to be times where it processes 9 loops before a refresh, or times where it processes 11 loops before a refresh, because it's certainly not keeping a perfect 10 loop per refresh going on!