Problem with _Resize

[dano]

Code: (Select All)

$Resize:On



'_Resize Off

MenuScreen& = _NewImage(1000, 500, 32)

MainScreen& = _NewImage(1400, 965, 32)



start:

Screen MenuScreen&

_ScreenMove 200, 50

_ScreenMove 175, 10

Cls

Print "smaller screen"

wfk



'_Resize On , _Stretch '    causes screen to be shrunken down in size

'_Resize On , _Smooth '    causes screen to be shrunken down in size

'_Resize On '              works correctly

Screen MainScreen&

w# = _Width

h# = _Height

Cls

Print "larger screen as "; w#; " x "; h#

wfk

GoTo start









Sub wfk '  wfk=wait for key

    i$ = ""

    While i$ = ""

        i$ = InKey$

    Wend

    If i$ = Chr$(27) Then System

End Sub

When you run this program as is, everything works fine.  The screen sizes are correct and they go back and forth as expected.
BUT...

un-REM      '_Resize On
>everything still works correctly.

un-REM      '_Resize On , _Stretch      -or-      '_Resize On , _Smooth
>the second screen size has shrunk - the resolution is still correct, just the default size has been shrunk down.  Why?  How can I avoid this?

It does not matter if the $Resize is On or Smooth or Stretch, you get the same behavior. 



>>>>>     ALSO     <<<<<
In this program if you try to Ctrl-Break to break out of this program (in the wfk Sub), it seems to lock up and you can never exit and you have to kill it with Task Manager.  BUT if you take the wfk subroutine and use it with a program that does not do anything with the screens (basically only printing...try it!), it will exit with Ctrl-Break every time.  Why?  Is this a bug?

[dano]

No takers for this issue ?

[SMcNeill]

If you notice, the issue here is that the width never changes.   Swap back and forth a few times and watch -- the screen grows taller, but it doesn't grow wider.  

I'd say this is a glitch somewhere, but I'm not certain where it's at.  Give the dev team some time to dig into this.  It might not be all that complicated to sort out, if it's just a glitch where one value isn't passing properly or some such. 

[SMcNeill]

The problem here, is you're giving it an impossible task to try and sort out and it's exploding on you.

_RESIZE ON, _SMOOTH and _RESIZE ON, _STRETCH tries to do one important thing for you -- it tries to maintain your aspect ratio.

Start with a 600x400 screen, drag it to where it's twice as wide, and it becomes a 1200x 800 screen.  It maintains that 3:2 aspect ratio for you.

So in this case, you're starting with a screen which is 1000 x 500, so it has a 2:1 aspect ratio.

Then you tell it to _RESIZE ON, _SMOOTH, which means it's going to try and maintain that 2:1 ratio.

Then you tell it to create a 1400x965 screen...   Which is anything BUT a 2:1 aspect ratio screen.

How exactly is it supposed to stretch your 1000x500 screen, and maintain a 2:1 aspect ratio, and put it on a 1400x965 screen?  It can't do it, and it just more-or-less explodes trying.   

---

I think the only thing you can do in a case like this is to turn _RESIZE OFF, make the screen the size you want it to be, and then turn _RESIZE ON, _SMOOTH afterwards.

Code: (Select All)

$Resize:On



'_Resize Off

MenuScreen& = _NewImage(1000, 500, 32)

MainScreen& = _NewImage(1400, 965, 32)



start:

_Resize Off: _Delay .25 'turn off resizing when manually setting a display,  give time for setting to change

Screen MenuScreen&

_Delay .25: _Resize On , _Smooth 'turn back on, after time has passed and screen has changed size

_ScreenMove 200, 50

_ScreenMove 175, 10

Cls

Print "smaller screen"

wfk



_Resize Off: _Delay .25 'turn off resizing when manually setting a display,  give time for setting to change

Screen MainScreen&

_Delay .25: _Resize On , _Smooth 'turn back on, after time has passed and screen has changed size

w# = _Width

h# = _Height

Cls

Print "larger screen as "; w#; " x "; h#

wfk

GoTo start





Sub wfk '  wfk=wait for key

    i$ = ""

    While i$ = ""

        i$ = InKey$

    Wend

    If i$ = Chr$(27) Then System

End Sub

Exactly what do you envision happening here?  You can't stretch a 2:1 screen and keep the same aspect ratio on a 7:5 (estimated) screen.  Not without skewing and scaling and making something go funky somewhere along the way.

[dano]

Thank you Steve!  I took your example and played around with it a LOT and discovered that the _Delay .25 fixes a lot of things...but why ???  

I'm not wanting to stretch a screen and keep the aspect ratios the same - I'm wanting to create a new screen where the user could stretch the screen as needed (and keep the same aspect ratio). The menu screen is not changeable, but after making their selection the main screen would be stretchable. When you go to the main screen and add Stretch to it, as you mentioned in your first post, the width stayed the same (physical onscreen size). When you do not add stretch it changes on screen correctly. There is something happening when Stretch is added.

Sometimes when entering a new screen mode without the delay, the text becomes a blurred larger version, but introducing the delay also fixed that.  So far all of these issues seem to only manifest themselves when either smooth or stretch are used.  This is a very interesting issue that makes me wonder if this is a bug?  It also makes me wonder if someone is running on a old and very slow PC that the delay will have to be longer to avoid this issue?

I am thoroughly confused at this point, but the delay seems to be a work around...but inquiring minds still want to know - why ?

[SMcNeill]

The reason for the delay is because a lot of our screen stuff is set up via its own independent processing thread.  

_RESIZE is basically just setting a variable for us, which is then handled with the screen stuff.

The SCREEN stuff is basically stuck on an ON TIMER type event where it takes place every 1/60th of a second.  (For 60 FPS display usually.)

Here's the basic program flow without a delay:

_RESIZE OFF     <-- this sets the variable to turn resize off

SCREEN _newsize   <--- this sets a flag so that on the next update of the screen thread, we swap to a new screen.   This can be anywhere from 0.00000 seconds to 1/60 seconds, as that timer event runs through its process

_RESIZE ON, _STRETCH   <--- this sets the variable to turn resizing back on, with it attempting to maintain the same aspect ratio you currently have.

---

See the issue with just the explaination above??

That SCREEN statement *MAY* not trigger automatically.  It's really just setting a flag so that the NEXT time the screen updates, it resizes to the screen you called.

That _RESIZE ON statement *HOWEVER* instantly sets the flag to turn resizing back on.  In most cases, this is going to be 0.0000000001 seconds (or some insane nano-count of time such as that) after that SCREEN statement sets its flag.

You're basically:
Turn OFF resizing
Set Flag for new screen
Turn On resizing
Let flag process 1/60 second later and ....   BLOW UP as you really don't want it to resize yet!

---

Add that delay in there and you solve that issue.

Turn OFF resizing
Set Flag for new screen.
whistle for a short moment and do nothing so that the screen actually resizes to the size we want
Turn on resizing

^^  That's the process you want to happen.   The actual code to accomplish this is even simpler than what I had before:

_RESIZE OFF   'no delay is needed here, as that variable changes instantly
SCREEN _newsize  'set the flag to change to the screen that you want  here
_DELAY 0.25 '0.25 is probably longer than actually required, but when dealing with any sort of race condition, I'd rather err on the side of caution
_RESIZE ON, _STRETCH

---

Does that all make sense over what we're seeing here and why it was acting the way it was for you previously?

[dano]

Thank you 1000%.  It now makes sense why it does not work properly without the delay.  I will add that and hopefully everything will work.

Is this something that should be added to the help for _Resize ?  Would it be beneficial to add an option to the _Resize statement that allows a [milliseconds] delay to be added into the statement?

Thank you for this explanation and work around.

[dano]

UPDATE:
Just made changes...works like a charm.