QB64 Phoenix Edition 3.4.1 Released

[SMcNeill]

i understand your point of view. that said, you say that this problem has been known for many years. if there is no solution and if it depends on the computer used, how to guess the ideal parameter in the delay command in case the distributed program will run on different slow, fast or very fast computers. the problem should be fixed in the source code, not fixing it exposes to future problems. the link you provided is interesting because it confirms that it happens with other commands than _DESKTOPWIDTH and _DESKTOPHEIGHT...

finally, the fact that it works with qb64 v0.5 and not 3.4.0 and 3.4.1 on the same machine proves that there was a regression somewhere in the code...

Well, I'll deal with it for now. Thanks for your explanations.

It may be frustrating that it doesn't work as you'd like, but here's the basic process and the error at large:

Code: (Select All)

Declare Library
    Function glutGet& (ByVal what&)
End Declare

Sleep

Print glutGet(200)
Print glutGet(201)

Compile and run.  You'll get your desktop width and height back directly from glutget.

Remark out that Sleep statement.  Compile and attempt to run...

This isn't a glitch that's built into QB64 itself; it's a glitch built into one of the core libraries that QB64 is built upon.  glut should wait until after everything is initialized before it tries to call these handles -- it doesn't.  

So, what do we do with such an issue?  Try and patch the version of freeglut that we're using?  Does its license even allow for that??  Does anyone have the expertise to go into freeglut's core and sort out what the issue with their threading is, and apply a fix for it??

For Windows, we chose to skip the glutGet call completely, in the case for _DESKTOPHEIGHT and _DESKTOPWIDTH.  Instead, we use the windows API to get those values, thus we never have the issue to begin with.

Now, on Linux, in its dozens of varieties, what could we call to get that same information, without relying on glut?  Does X11 report it somewhere?  

I dunno!  I'm not a Linux programmer.  I'm not familiar with the Linux system.  I may know what the issue is -- just like you do now as well -- but that doesn't mean I'm any more capable of fixing it than you are. 

It is what it is.  Until someone steps up who's willing to redo the freeglut backend (maybe someone will swap GLEW in for us instead), or who knows enough to work around the issue with freeglut, we're stuck with it -- just the same as we have been for years now.

Not all bugs get fixed the day they're reported, no matter how much both the developers and the user base might wish they did.