Getting the SCREEN mode

[bplus]

Here is a sub for saving and restoring the Screen State I use for Message Box, Input Box and similar. The idea suggested to me long ago by SMcNeill: https://qb64forum.alephc.xyz/index.php?topic=1511.0

Code: (Select All)

' for saving and restoring screen settings
Sub ScnState (restoreTF As Long) 'Thanks Steve McNeill
    Static defaultColor~&, backGroundColor~&
    Static font&, dest&, source&, row&, col&, autodisplay&, mb&
    If restoreTF Then
        _Font font&
        Color defaultColor~&, backGroundColor~&
        _Dest dest&
        _Source source&
        Locate row&, col&
        If autodisplay& Then _AutoDisplay Else _Display
        _KeyClear
        While _MouseInput: Wend 'clear mouse clicks
        mb& = _MouseButton(1)
        If mb& Then
            Do
                While _MouseInput: Wend
                mb& = _MouseButton(1)
                _Limit 100
            Loop Until mb& = 0
        End If
    Else
        font& = _Font: defaultColor~& = _DefaultColor: backGroundColor~& = _BackgroundColor
        dest& = _Dest: source& = _Source
        row& = CsrLin: col& = Pos(0): autodisplay& = _AutoDisplay
        _KeyClear
    End If
End Sub

[Pete]

I used to do similar stuff in QuickBasic, by passing this type of info in the form of a parseable string.

Pete

[bplus]

Thanks to Static variables in the sub you can save the state by making the Restore input to sub 0 False and then to Restore = True which instructs sub to restore all the settings that it had stored into Static variables: colors, font, autodisplay or Display, Dest, Source... even print line and column! Like getting 2 subs for the price of one.

[mnrvovrfc]

I working on Lesson 20: Libraries and was thinking about having the user go through the process of making one. My idea was to make custom text inputs, popups, message boxes, etc... However, the library would need to know which SCREEN mode it was in first for dimensions, available colors, current colors, etc.

For a site called "QB64 Game Programming" it might be better to make a recommendation to use "_NEWIMAGE" instead of "SCREEN" for new programs. "SCREEN" prevails, though for a generic tutorial which must accept importing programs from M$QB or QBasic. You could tell the students of the tutorial about "SCREEN", probably about the "historic" parameters it has which are confusing ("don't touch that second parameter or you'll be sorry LOL"), and then tell them why it's more limited than the means available in the programming system of choice. Also emphasize how "SCREEN()" is different and is quite good for "SCREEN 0", and for a graphics screen not going much further than "PRINT" to generate output. Finally consider telling the students about "$CONSOLE" mode which is a whole different world which has nothing to do with graphics, and the functions vary widely between "cmd.exe" on Windows and the Linux and MacOS terminals.

Somebody who doesn't care what M$ did to BASIC, but does know something about BASIC programming and is willing to dive into QB64PE, should be taught to use "_NEWIMAGE". Talking about "SCREEN" statement anyhow would only introduce confusion and would bring about questions like, "But Freebasic could use it" while that other programming system has an alternate way to set graphics screens and a structure to get and set the properties of the screen. As I've already said, using "_NEWIMAGE" comes down to saving width, height, color depth etc. into variables to be recalled when need be, run from a function to set those properties, and another function to acquire those properties.

EDIT: B+ wrote a good function above but it doesn't have to be interactive, just save into variables what could make one windowed screen different from another in QB64PE before using "_NEWIMAGE".

[RhoSigma]

I working on Lesson 20: Libraries and was thinking about having the user go through the process of making one. My idea was to make custom text inputs, popups, message boxes, etc... However, the library would need to know which SCREEN mode it was in first for dimensions, available colors, current colors, etc.

All that information can be easily acquired with existing keywords _WIDTH(0), _HIGHT(0), _PIXELSIZE(0), _DEFAULTCOLOR(0) and _BACKGROUNDCOLOR(0).

On the other hand it's eg. bad to assume the screen's dimension just from the mode number, since it's possible to create ANY size legacy screens with SCREEN _NEWIMAGE(w, h, mode).

[TerryRitchie]

I working on Lesson 20: Libraries and was thinking about having the user go through the process of making one. My idea was to make custom text inputs, popups, message boxes, etc... However, the library would need to know which SCREEN mode it was in first for dimensions, available colors, current colors, etc.

All that information can be easily acquired with existing keywords _WIDTH(0), _HIGHT(0), _PIXELSIZE(0), _DEFAULTCOLOR(0) and _BACKGROUNDCOLOR(0).

On the other hand it's eg. bad to assume the screen's dimension just from the mode number, since it's possible to create ANY size legacy screens with SCREEN _NEWIMAGE(w, h, mode).

Thanks for all the input everyone. Last night I decided to make the library SCREEN 0 only. If _PIXELSIZE reports anything other than 0 the library will report the mis-match.

I understand the reasoning for others pointing out that legacy screen modes should be avoided but they do exist and can be used. Over the years I've known of at least a few QuickBasic projects that were updated using QB64 because I was asked to help with some of the conversion. One was a program that controlled a small milling machine and it drew the routing outline in screen 12. Creating a library that may potentially be used with legacy screen modes still needs to be considered.

Over the years I've also had people contact me while using the tutorial to ask questions about programs they were typing in from old QuickBasic books. Those old books and programs are still a wealth of knowledge for people learning QB64 even though they use the legacy screen modes.

This gives me an idea for another lesson that deals with converting QuickBasic, PDS, and VBDOS code to use new QB64 commands. Hmm...

[TerryRitchie]

I working on Lesson 20: Libraries and was thinking about having the user go through the process of making one. My idea was to make custom text inputs, popups, message boxes, etc... However, the library would need to know which SCREEN mode it was in first for dimensions, available colors, current colors, etc.

For a site called "QB64 Game Programming" it might be better to make a recommendation to use "_NEWIMAGE" instead of "SCREEN" for new programs. "SCREEN" prevails, though for a generic tutorial which must accept importing programs from M$QB or QBasic. You could tell the students of the tutorial about "SCREEN", probably about the "historic" parameters it has which are confusing ("don't touch that second parameter or you'll be sorry LOL"), and then tell them why it's more limited than the means available in the programming system of choice. Also emphasize how "SCREEN()" is different and is quite good for "SCREEN 0", and for a graphics screen not going much further than "PRINT" to generate output. Finally consider telling the students about "$CONSOLE" mode which is a whole different world which has nothing to do with graphics, and the functions vary widely between "cmd.exe" on Windows and the Linux and MacOS terminals.

Somebody who doesn't care what M$ did to BASIC, but does know something about BASIC programming and is willing to dive into QB64PE, should be taught to use "_NEWIMAGE". Talking about "SCREEN" statement anyhow would only introduce confusion and would bring about questions like, "But Freebasic could use it" while that other programming system has an alternate way to set graphics screens and a structure to get and set the properties of the screen. As I've already said, using "_NEWIMAGE" comes down to saving width, height, color depth etc. into variables to be recalled when need be, run from a function to set those properties, and another function to acquire those properties.

EDIT: B+ wrote a good function above but it doesn't have to be interactive, just save into variables what could make one windowed screen different from another in QB64PE before using "_NEWIMAGE".

That's exactly what I do in Lesson 5

https://www.qb64tutorial.com/lesson5

$CONSOLE is being reserved for a metacommand lesson I plan to add. Metacommands are an advanced topic and I purposely kept them out of the first 13 lessons that deal with pure beginner topics.

[Pete]

Wait... ONLY SCREEN 0??? OKAY! Now I love it even more!

Pete

[mnrvovrfc]

For a site called "QB64 Game Programming" it might be better to make a recommendation to use "_NEWIMAGE" instead of "SCREEN" for new programs. "SCREEN" prevails, though for a generic tutorial which must accept importing programs from M$QB or QBasic. ...

While I wrote this I failed to notice "SCREEN" statement was needed anyway combined with "_NEWIMAGE". I was unable to remember "_NEWIMAGE()" is a function, can't do stuff itself that "SCREEN" does! I'm sorry about that.

If there are people typing in programs from old books, meant for QuickBASIC then they must be running DOSBOX, or actually be on a computer old enough to support 16-bit, pre-Windows8. Less likely they would be doing it on QB64. It's because otherwise they would be whining, "Damn it SCREEN 13 is wee too small! How do I make it larger?" LOL why make it larger, so you could appreciate the rough resolution? This is before the hogs, of the many-inches television screens used as computer viewports, come into mind. In the music-creation world there is a lot of pathetic complaining about too-small GUI's out of programs created in decade-2000. They want to get out of 32-bit so much.

Somebody is going to ask to convert a GUI program done in VBDOS to QB64PE. Then expect it to run on Linux without Wine. Do it yourself bruv!

This "rant" wasn't aimed at anybody in particular.

[Pete]

So it's an aimless rant? Okay!

Pete