06-15-2024, 03:02 AM
First, run the following:
Now, as you can see, with that _DELAY in there, _RESIZE prints a resize at each and every step along the way.
When the screen is created, that's a RESIZE.
When we swap to (640, 480, 32), that's a RESIZE.
When we swap to (800, 00, 32), that's a RESIZE.
Remove *ANY* of those _DELAY statements and then run the program and watch 0 become the next result.
Isn't that odd as heck?!!
The reason for this oddish behavior is just from the way _RESIZE works. We type in a command to change the screen.... Our compiled EXE starts to change the screen... The RESIZE flag isn't set until AFTER the change takes place, so it's still 0...
Now, since most of our SCREEN/WINDOW type commands are all on their own thread/core, the rest of the program is doing it's thing, all La-De-Da, blissfully unaware that the screen is changing.
That PRINT statement is processed, and at this point, _RESIZE is still 0, so it prints 0...
A cycle or two later, the SCREEN stuff is all finished and reset and the RESIZE flag is finally changed...
And you wait until AFTER the next screen change to (640, 480, 32) before asking for it once again, so it's still holding that -1 from the initial screen 0 screen of (80, 25, 0).
RESIZE occurs on a couple of cycles delay from any actual changes. It's not instant, and that's where you're seeing this type of reporting coming from.
Here's the play-by-play run down of what you're seeing:
$RESIZE:ON <-- okies, no questions here.
PRINT _RESIZE ' no resize event triggered for SCREEN 0 <-- at this point, the RESIZE even hasn't had time to run through the whole process. We have no _DELAY for it to take time to trigger and respond to us.
SLEEP <-- no questions here.
SCREEN _NEWIMAGE(640, 480, 32) <-- we have now triggered a SECOND resize event.
PRINT _RESIZE <-- This prints -1 from the FIRST event, which we haven't polled or reported yet. The second event hasn't processed yet.
SLEEP <-- all's good here
SCREEN _NEWIMAGE(800, 600, 32) <-- We now trigger a THIRD resize event.
PRINT _RESIZE <-- But this one is now printing the -1 from the SECOND resize event. That 3rd event hasn't processed yet.
I think this little code snippet should clear up things 100% for you:
As you can see, without giving it time to process and report back to us, you're always reporting on PAST events and not the most recent one.
Code: (Select All)
$RESIZE:ON
_DELAY .5
PRINT _RESIZE ' no resize event triggered for SCREEN 0
SLEEP ' REM in front of this line has no effect on SCREEN _NEWIMAGE triggering a resize event
SCREEN _NEWIMAGE(640, 480, 32)
_DELAY .5
PRINT _RESIZE ' resize event triggered
SLEEP ' REM this line and the SCREEN statement below will not trigger a _RESIZE event
SCREEN _NEWIMAGE(800, 600, 32)
_DELAY .5
PRINT _RESIZE ' resize only triggered if sleep statement above not REM'ed
Now, as you can see, with that _DELAY in there, _RESIZE prints a resize at each and every step along the way.
When the screen is created, that's a RESIZE.
When we swap to (640, 480, 32), that's a RESIZE.
When we swap to (800, 00, 32), that's a RESIZE.
Remove *ANY* of those _DELAY statements and then run the program and watch 0 become the next result.
Isn't that odd as heck?!!
The reason for this oddish behavior is just from the way _RESIZE works. We type in a command to change the screen.... Our compiled EXE starts to change the screen... The RESIZE flag isn't set until AFTER the change takes place, so it's still 0...
Now, since most of our SCREEN/WINDOW type commands are all on their own thread/core, the rest of the program is doing it's thing, all La-De-Da, blissfully unaware that the screen is changing.
That PRINT statement is processed, and at this point, _RESIZE is still 0, so it prints 0...
A cycle or two later, the SCREEN stuff is all finished and reset and the RESIZE flag is finally changed...
And you wait until AFTER the next screen change to (640, 480, 32) before asking for it once again, so it's still holding that -1 from the initial screen 0 screen of (80, 25, 0).
RESIZE occurs on a couple of cycles delay from any actual changes. It's not instant, and that's where you're seeing this type of reporting coming from.
Here's the play-by-play run down of what you're seeing:
$RESIZE:ON <-- okies, no questions here.
PRINT _RESIZE ' no resize event triggered for SCREEN 0 <-- at this point, the RESIZE even hasn't had time to run through the whole process. We have no _DELAY for it to take time to trigger and respond to us.
SLEEP <-- no questions here.
SCREEN _NEWIMAGE(640, 480, 32) <-- we have now triggered a SECOND resize event.
PRINT _RESIZE <-- This prints -1 from the FIRST event, which we haven't polled or reported yet. The second event hasn't processed yet.
SLEEP <-- all's good here
SCREEN _NEWIMAGE(800, 600, 32) <-- We now trigger a THIRD resize event.
PRINT _RESIZE <-- But this one is now printing the -1 from the SECOND resize event. That 3rd event hasn't processed yet.
I think this little code snippet should clear up things 100% for you:
Code: (Select All)
$RESIZE:ON
PRINT _RESIZE ' no resize event triggered for SCREEN 0
SLEEP ' REM in front of this line has no effect on SCREEN _NEWIMAGE triggering a resize event
SCREEN _NEWIMAGE(640, 480, 32)
PRINT _RESIZE ' resize event triggered
SLEEP ' REM this line and the SCREEN statement below will not trigger a _RESIZE event
SCREEN _NEWIMAGE(800, 600, 32)
PRINT _RESIZE ' resize only triggered if sleep statement above not REM'ed
SLEEP
PRINT "Final Resize:"; _RESIZE
PRINT "And all clear:"; _RESIZE
As you can see, without giving it time to process and report back to us, you're always reporting on PAST events and not the most recent one.