Occassional Graphical Glitch

[SMcNeill]

With all this discussion about map making and map editors, I thought I'd sit down and take a little time to write up a little map engine/maker, but from testing it as I get it started, I'm coming across a rather odd graphical glitch.

Graphics are set for 1024x800, 32-bit resolution, and $RESIZE is set to allow the user to STRETCH the screen if they so desire...

Normally, everything compiles and runs exactly as one would expect...

However, about once every 10th compile, the screen starts at a 640x480 resolution, much like we'd expect a SCREEN 0 screen to appear -- though it's still in 32-bit color mode and everything still runs as expected.

It seems as if there's a race condition occurring somewhere, which is affecting the $RESIZE, which "stretches" the screen to an undesirable size at startup...

My question:  Has anyone else experienced this in any other programs?  Can anyone else reproduce this issue?   This is a behavior I've never seen before, and it's an issue that's intermittent -- though annoying -- and I'm wondering if anyone has any ideas where to start to debug it (or just work around the issue temporarily, so it doesn't keep popping up as I run/test this work-in-progress).

[SMcNeill]

And an image of the odd graphical startup issue:

 [ You are not allowed to view this attachment ]  

As you can see, it squeezes everything onto a screen much too small as to be actually comfortable to read and use.

Any idea what the issue might be?

[FellippeHeitor]

I haven't seen it happen before, at least not that regularly. Can you confirm it comes every 10 runs? And is there a _SCREENEXISTS check in there somewhere?

PS: It hasn't happened not even once on my XP Virtual Machine.

[SMcNeill]

It's a random occurrence, one in ten is an estimation of how often I see it.  Sometimes it'll pop up two or three times in a row, sometimes it won't pop up at all, for multiple attempts.

Currently, I've disabled the $RESIZE option, and it's disappeared, but the _SCREENMOVE is still failing to operate properly, as it's moving the screen BEFORE it changes graphic modes.  IF my screen was SCREEN 0, the position would be perfectly centered on my monitor; however, as it is, the screen is popping up off-center, requiring me to move it to see the bottom segment of the program.

(Top Left is positioned for centering SCREEN 0 placement; the issue with screen positioning is when it changes from SCREEN 0 to SCREEN _NEWIMAGE(1024,800,32), which places the Bottom Right off the visible display.)

Both the $RESIZE glitch, and the _SCREENMOVE glitch, are something new, which I haven't experienced before. 

[FellippeHeitor]

Does waiting for _SCREENEXISTS give any positive results?

[SMcNeill]

Does waiting for _SCREENEXISTS give any positive results?

Code: QB64: [Select]

1. SCREEN _NEWIMAGE(1024, 800, 32)
2. DO
3.     _LIMIT 30
4. LOOP UNTIL _SCREENEXISTS AND _WINDOWHANDLE
5.  
6. _SCREENMOVE _MIDDLE
7. _TITLE "Game Maker 64 (GM64)" + STR$(Version)
8. '$RESIZE:STRETCH

By itself, the above seems to have no issues working as intended.  As an $INCLUDE, as part of the overall program I'm writing, it doesn't seem to do a thing -- almost EVERY start up ends with the program screen popping up off-center.

[FellippeHeitor]

Beats me then.

[RhoSigma]

Hi Steve,

nice to see you guys finally running into this problem too now. Since working on my GuiTools project (late 2015) I've complaint about this several times over at [abandoned, outdated and now likely malicious qb64 dot net website - don’t go there]. It worked fine with the old SDL version but not (always) with the GL version, unfortunatly most of the times when I was complaining I only got mobbed, why still comparing everything to SDL and I should forget about it as GL is the future (afaik the name of the main SDL opponent was Steve).

However, best advices I got was try to play with delays, which I did, but it finally turns out the _MIDDLE keyword is the troublemaker, if the screen is not fully setup and ready, then it simply can't calculate the middle.

so here is what I do as workaround in GuiTools, and so far I had no problems with it:

Code: QB64: [Select]

1. wid% = 1024: hei% = 768
2. appScreen& = _NEWIMAGE(wid%, hei%, 256)
3. SCREEN appScreen&
4. DO: _LIMIT 20: LOOP UNTIL _SCREENEXISTS
5. _DELAY 0.05
6. _SCREENMOVE (_DESKTOPWIDTH - wid%) / 2, (_DESKTOPHEIGHT - hei%) / 2
7. _DELAY 0.05
8. _SCREENSHOW
9.  

[Dav]

I came across this too when making a video player.  Don't know what was causing it, but I also ended up removing _MIDDLE and increasing delay to allow the screen to setup and the glitch seemed to go away. (The video image was also messed up when playing back).

- Dav

[FellippeHeitor]

so here is what I do as workaround in GuiTools, and so far I had no problems with it:

Code: QB64: [Select]

1. wid% = 1024: hei% = 768
2. appScreen& = _NEWIMAGE(wid%, hei%, 256)
3. SCREEN appScreen&
4. DO: _LIMIT 20: LOOP UNTIL _SCREENEXISTS
5. _DELAY 0.05
6. _SCREENMOVE (_DESKTOPWIDTH - wid%) / 2, (_DESKTOPHEIGHT - hei%) / 2
7. _DELAY 0.05
8. _SCREENSHOW
9.  

Indeed a clever workaround. Thanks for sharing, RhoSigma.

[RhoSigma]

Yes, the simple and logic idea behind it was: Ok, if QB64 doesn't know the windowsize before the window is actually established, no problem I (the programmer) know the size prior the window is there.
This way I can also do a border correction, eg. to get the very same positioning as with the old SDL version _SCREENMOVE _MIDDLE (which did automatic border correction), I've to use the following in GL on my Win7 system. Of course correction values may differ from system to system and the used theme to theme, that's why a automatic internal correction would be a good thing for the GL version too.

Code: QB64: [Select]

1. _SCREENMOVE (_DESKTOPWIDTH - wid%) / 2 - 3, (_DESKTOPHEIGHT - hei%) / 2 - 25
2.  

[bplus]

I've had problems with _MIDDLE even on new much faster laptop and have resorted to solution similar to RhoSigma. His is a little more refined than mine with the -3 and -25. :)

RhoSigma's reasoning in explaining the cause makes sense to me.

[Cobalt]

I wonder if its not just a GL bug, cause every so often(at random) the IDE will resize smaller on me, go from the 80x33 I normally have it set at back to 80x25 default. And its completely random when it happens. I also have a couple old GL powered games that will very occasionally do the same thing and these are 'professionally' released games, not QB64 programs. they will just go from starting up at a larger size back to some default resolution.

[Bert22306]

I wonder if its not just a GL bug, cause every so often(at random) the IDE will resize smaller on me, go from the 80x33 I normally have it set at back to 80x25 default. And its completely random when it happens. I also have a couple old GL powered games that will very occasionally do the same thing and these are 'professionally' released games, not QB64 programs. they will just go from starting up at a larger size back to some default resolution.

Yes, I have reported this glitch too, but the suggestion was that maybe it had to do with my virus check software. When this happens to me, the IDE comes up in the small 80 X 25 default size, black background, with the words "press any key" in the window. Pressing any key will close the IDE, and then when re-opening it, with the proper blue background coming up, the IDE will have reset itself to the default 80 X 25 window size. My usual IDE setting is 150 X 43 or 150 X 50. The glitch appears to be totally random.

Now, to me, this has only happened on the PC in which I use McAfee. Both PCs are Windows 10. In the one with Defender, it has never happened, although I wouldn't put too much emphasis on that. I use QB64 quite a bit less often in that Defender PC.

I cannot say for certain that this never happened with the SDL version. It's possible that it never did, come to think of it.

[RhoSigma]

Defintly no AntiVirus or Windows 10 specific glitch, it happens to me too. I've Windows 7 and don't even have installed any AntiVirus at all and Defender is deactivated too.