Author Topic: QB64 _Display/_ScreenMove Glitch  (Read 3895 times)

0 Members and 1 Guest are viewing this topic.

Offline SMcNeill

  • QB64 Developer
  • Forum Resident
  • Posts: 3972
    • View Profile
    • Steve’s QB64 Archive Forum
QB64 _Display/_ScreenMove Glitch
« on: November 25, 2021, 02:58:32 pm »
Now here's a little oddity which you guys might want to make note of, if you're ever going to write a program which removes the window's title:

Code: QB64: [Select]
  1. Screen _NewImage(1280, 720, 32)
  2.  
  3.  
  4.     Function GetWindowLongA& (ByVal hWnd As _Offset, Byval nIndex As Long)
  5.     Function SetWindowLongA& (ByVal hWnd As _Offset, Byval nIndex As Long, Byval dwNewLong As Long)
  6. a = SetWindowLongA&(_WindowHandle, -16, GetWindowLongA(_WindowHandle, -16) And Not &H00C80000)
  7.  
  8.     k = _KeyHit
  9.     If k = 32 Then TRY = Not TRY
  10.     If k = 27 Then System
  11.     If TRY Then
  12.         _Display
  13.     Else
  14.         _ScreenMove _Middle
  15.     End If
  16.  

Honestly, I don't have a clue what the heck is going on here!   To start with, we make a screen.... Then we remove the title and border...   So far, so good...

Then we enter the do loop with an initial value of 0 for TRY, so we attempt to _SCREENMOVE _MIDDLE endlessly...

And, at this point, the window then centers itself for a nanosecond or two, only to then pop down to my bottom right corner of my screen where it stays until the next call to _SCREENMOVE _MIDDLE.  Inside the loop, this produces a sickening flicker as the screen jumps back and forth endlessly.

BUT....

Then you hit the SPACE BAR and the value of TRY toggles.  We execute a simple _DISPLAY command...  And NOW our window stays in the center, regardless of if we ever hit the spacebar again, or not.

Without the _DISPLAY, the window loses itself and doesn't know where the heck to pop, going to the bottom corner rather than the center of the screen.

My initial impression is (and this might be completely wrong):

I have a feeling that QB64 (or GLUT) has internal variables which track our various pieces of screen information (x and y position, size, ect..), and this information doesn't update until a call to _DISPLAY is made.  By removing the title bar, we've changed some of the Windows-side value of these things, but not the QB64-side of stuff.  GLUT, or Windows, or whatever has one value for the middle of the screen (as seen by how it first positions itself in the correct position), but our internal variables have a different position (as seen by how it moves to the second position).

All this time, I've been telling folks that there's a race condition in handles going on when a screen is first created, so they need to place a small delay before making a screenmove call; when instead, it might be this issue with variables not updating until _DISPLAY is called.

Note that the following works perfectly and places the screen in the middle of our display as it should:
Code: QB64: [Select]
  1. Screen _NewImage(1280, 720, 32)
  2.  
  3.  
  4.     Function GetWindowLongA& (ByVal hWnd As _Offset, Byval nIndex As Long)
  5.     Function SetWindowLongA& (ByVal hWnd As _Offset, Byval nIndex As Long, Byval dwNewLong As Long)
  6. a = SetWindowLongA&(_WindowHandle, -16, GetWindowLongA(_WindowHandle, -16) And Not &H00C80000)
  7.  
  8.  

Whereas this doesnt:
Code: QB64: [Select]
  1. Screen _NewImage(1280, 720, 32)
  2.  
  3.     Function GetWindowLongA& (ByVal hWnd As _Offset, Byval nIndex As Long)
  4.     Function SetWindowLongA& (ByVal hWnd As _Offset, Byval nIndex As Long, Byval dwNewLong As Long)
  5. a = SetWindowLongA&(_WindowHandle, -16, GetWindowLongA(_WindowHandle, -16) And Not &H00C80000)
  6.  
  7.  

The  only difference in the two?  The use of _DISPLAY before _SCREENMOVE.  :P
https://github.com/SteveMcNeill/Steve64 — A github collection of all things Steve!

Offline Dav

  • Forum Resident
  • Posts: 792
    • View Profile
Re: QB64 _Display/_ScreenMove Glitch
« Reply #1 on: November 26, 2021, 09:24:19 am »
Interesting.  None of those even compile for me on 32-bit.  I'll play around with it some today.

- Dav

Offline SMcNeill

  • QB64 Developer
  • Forum Resident
  • Posts: 3972
    • View Profile
    • Steve’s QB64 Archive Forum
Re: QB64 _Display/_ScreenMove Glitch
« Reply #2 on: November 26, 2021, 09:29:56 am »
Interesting.  None of those even compile for me on 32-bit.  I'll play around with it some today.

- Dav

Windows?  Or your new Linux set up?  Those are Windows-only library calls.  ;)
https://github.com/SteveMcNeill/Steve64 — A github collection of all things Steve!

Offline Dav

  • Forum Resident
  • Posts: 792
    • View Profile
Re: QB64 _Display/_ScreenMove Glitch
« Reply #3 on: November 26, 2021, 09:32:08 am »
Win7 32-bit.

- Dav

Offline SMcNeill

  • QB64 Developer
  • Forum Resident
  • Posts: 3972
    • View Profile
    • Steve’s QB64 Archive Forum
Re: QB64 _Display/_ScreenMove Glitch
« Reply #4 on: November 26, 2021, 12:54:22 pm »
Try tossing a small _DELAY in there right after the SCREEN _NEWIMAGE call.  See if that fixes the instant crash issue for you.  I'd guess that invalid handle is still at work and causing a seg fault on a slower PC.  Just add that as another glitch for our screens.
https://github.com/SteveMcNeill/Steve64 — A github collection of all things Steve!

Offline Dav

  • Forum Resident
  • Posts: 792
    • View Profile
Re: QB64 _Display/_ScreenMove Glitch
« Reply #5 on: November 26, 2021, 02:16:48 pm »
_DELAY didn't work, but I did get it working -- had to do DECLARE CUSTOMTYPE LIBRARY instead and it compiled.

Hmm, on my Windows 7 32-bit I didn't get the glitch, all stayed centered for good. Maybe it's a video driver issue?

- Dav

Offline SMcNeill

  • QB64 Developer
  • Forum Resident
  • Posts: 3972
    • View Profile
    • Steve’s QB64 Archive Forum
Re: QB64 _Display/_ScreenMove Glitch
« Reply #6 on: November 26, 2021, 02:25:52 pm »
_DELAY didn't work, but I did get it working -- had to do DECLARE CUSTOMTYPE LIBRARY instead and it compiled.

Hmm, on my Windows 7 32-bit I didn't get the glitch, all stayed centered for good. Maybe it's a video driver issue?

- Dav

Now stuff like this leaves me baffled.  When we DECLARE LIBRARY, we don't need to use CUSTOMTYPE or add a library name, if the functions we want to access are already declared somewhere inside QB64.  DECLARE LIBRARY by itself should be more than sufficient for things to work for us...

Yet, it doesn't work for you...

Which leaves the question, "Why the heck not??"

Is 64-bit QB64 referencing the User32 library, while the 32-bit version isn't??  And why the heck does it work for you and yet perform so jaggedly for me??   

The more I learn about this screenmove/no title business, the more questions I have about what the heck it -- and QB64 -- are doing behind the scenes.   
https://github.com/SteveMcNeill/Steve64 — A github collection of all things Steve!

Offline Dav

  • Forum Resident
  • Posts: 792
    • View Profile
Re: QB64 _Display/_ScreenMove Glitch
« Reply #7 on: November 26, 2021, 03:07:18 pm »
Here's the compile log error I get when it fails (without adding CUSTOMTYPE).

- Dav

Quote
In file included from qbx.cpp:2208:
..\\temp\\main.txt: In function 'void QBMAIN(void*)':
..\\temp\\main.txt:6:99: error: invalid conversion from 'int' to 'HWND' {aka 'HWND__*'} [-fpermissive]
 *__SINGLE_A=(  int32  )SetWindowLongA(func__handle(), -16 ,((  int32  )GetWindowLongA(func__handle(), -16 ))&(~( 13107200 )));
                                                                                       ~~~~~~~~~~~~^~
compilation terminated due to -Wfatal-errors.

EDIT: Oh BTW, I'm not using the latest QB64 version on this laptop.  I'll try to compile on my other laptop with the latest QB64 release.

EDIT #2:  Yeah, compile fails on latest QB64 in 32-bit too, unless CUSTOMTYPE added.
« Last Edit: November 26, 2021, 03:15:46 pm by Dav »