11-18-2022, 03:41 PM
Ahhh.. One set of commands that have a known workaround is glitched. There's a race condition which occurs with screen handles when QB64 first starts and runs. It's been in the language forever and ever, and writing a fix into the language isn't something that's as trivial as a walk in the park. This same style issue has been reported ever since version QB64 version 0.954 -- the last SDL version before Galleon swapped over to OpenGL for QB64 -- and the solution is always the exact same as you posted in a few places yourself: https://qb64phoenix.com/forum/showthread...57#pid9057
Just add a _DELAY at the start of the program and give the OS time to finish registering the handles properly, before trying to do anything with them.
The issue is a race condition which, like almost all race conditions, has unpredictable outcomes when ran. IF the system OS is running slow due to background processes, the qb64 program wins the race and runs properly. If the qb64 program is running fast as the OS might give it priority as a new process, then the program glitches.
v0.5, which you mention, is still plagued by this race problem. Nothing has changed between then and the latest version to introduce the issue into the language. So *why* does 0.5 work for you and 3.4.1 not?? It's impossible to say. Code we cleaned up might compile and run one nanosecond faster under the newest version. Or maybe it was swapping in the newer audio and image libraries. Whatever the cause, the end result is that 3.4.1 is running a weeeeeee bit faster at the initial startup phase, and thus it's hitting that race condition and glitching out more often than the 0.5 version is.
Now note -- that's not to say that the 0.5 version *won't* glitch out, at all! It's just that it's slower, so it's going to glitch out less often. That's just the nature of how race conditions work.
So what can one do about it??
Well, they could always code in COBOL or some such and avoid the issue completely. OR, they could wait for the devs to finally correct the issue, and not code anything at all until then. (I wouldn't hold my breath on this point, as this style race condition has been around for at least the last 10 years in the language. Here's a link to the exact same issue, and exact same solution, being discussed 5 years ago at the old forums: Occassional Graphical Glitch (alephc.xyz).) OR, you can just add a _DELAY to the start of any program that requires a window handle early in its creation.
Sticking with v0.5 won't solve the issue for you. At best, it'll be a bandaid that lets the program run on your specific computer. Share the code elsewhere, and others will have unpredictable results due to how fast/slow their PC performs against the compiled exe. OS wins the race, all is good. QB64 program run fast, it glitches trying to access a handle that the OS hasn't registered yet.
That's the issue, and the options, in a nutshell, for what's going on with the code you linked to.
Just add a _DELAY at the start of the program and give the OS time to finish registering the handles properly, before trying to do anything with them.
The issue is a race condition which, like almost all race conditions, has unpredictable outcomes when ran. IF the system OS is running slow due to background processes, the qb64 program wins the race and runs properly. If the qb64 program is running fast as the OS might give it priority as a new process, then the program glitches.
v0.5, which you mention, is still plagued by this race problem. Nothing has changed between then and the latest version to introduce the issue into the language. So *why* does 0.5 work for you and 3.4.1 not?? It's impossible to say. Code we cleaned up might compile and run one nanosecond faster under the newest version. Or maybe it was swapping in the newer audio and image libraries. Whatever the cause, the end result is that 3.4.1 is running a weeeeeee bit faster at the initial startup phase, and thus it's hitting that race condition and glitching out more often than the 0.5 version is.
Now note -- that's not to say that the 0.5 version *won't* glitch out, at all! It's just that it's slower, so it's going to glitch out less often. That's just the nature of how race conditions work.
So what can one do about it??
Well, they could always code in COBOL or some such and avoid the issue completely. OR, they could wait for the devs to finally correct the issue, and not code anything at all until then. (I wouldn't hold my breath on this point, as this style race condition has been around for at least the last 10 years in the language. Here's a link to the exact same issue, and exact same solution, being discussed 5 years ago at the old forums: Occassional Graphical Glitch (alephc.xyz).) OR, you can just add a _DELAY to the start of any program that requires a window handle early in its creation.
Sticking with v0.5 won't solve the issue for you. At best, it'll be a bandaid that lets the program run on your specific computer. Share the code elsewhere, and others will have unpredictable results due to how fast/slow their PC performs against the compiled exe. OS wins the race, all is good. QB64 program run fast, it glitches trying to access a handle that the OS hasn't registered yet.
That's the issue, and the options, in a nutshell, for what's going on with the code you linked to.