Getting the SCREEN mode

[TerryRitchie]

I need to find the current mode that was used with SCREEN. I found this code snippet in the Wiki:

https://qb64phoenix.com/qb64wiki/index.php/ScreenMode

This does work but its use of registers I don't like.

Has there been a command introduced that reports the current screen mode? I didn't know about the _HYPOT, _D2R, and _R2D statements until recently so perhaps something I need has been added and I'm just having trouble finding it?

[Pete]

Rho might know. I'm not aware of a keyword that does this, oh except...

IF Pete THEN SCREEN 0

Probably not what you are looking for. I also wonder about Ted's routine. Solid on colors, but since we can set font sizes and screen sizes in all screens, I wouldn't want to depend on those for detection.

Pete

[TerryRitchie]

Rho might know. I'm not aware of a keyword that does this, oh except...

IF Pete THEN SCREEN 0

Probably not what you are looking for. I also wonder about Ted's routine. Solid on colors, but since we can set font sizes and screen sizes in all screens, I wouldn't want to depend on those for detection.

Pete

Well for Pete's sake everyone knows that's how you detect SCREEN 0

[Pete]

[RhoSigma]

No such command yet and don't see the "why would you need one"
As every other screen mode than SCREEN 0 has to be explicitly programmed, you should know what mode you gave to the SCREEN call.

And for what exactly you would need the returned mode, other than making another image surface with the same mode, which would be _COPYIMAGE(0).

Or do you need the _PIXELSIZE, _WIDTH or _HIGHT.

Don't get me wrong, it would be pretty easy to implement such a command, as the mode is available in every image surface and just need to be picked and returned. I just don't see any use for it. Maybe you can explain what you try to achive by such a command.

[mnrvovrfc]

I was going to post earlier saying "SCREEN" isn't recommended for new programs over "_NEWIMAGE". It's simply because a wrapper function could be created that sets the screen mode and saves the width, height, color depth and other information. "SCREEN" statement is around largely to support old BASIC programs and up to and including VGA 256-color mode.

I wanted to point out also that I don't like the "screenmode" example neither, in addition because it makes assumptions beyond "SCREEN 13", especially for 32-bit color. Toward "SCREEN 0" there's also the fallacy of how many rows and columns, and the "$CONSOLE" isn't going to be an option for some programmers.

[Pete]

Yeah, I would be in favor of scrapping that example from the Wiki, and adding a return for the screen value, as Rho suggested.

I would also like to know what Terry envisions doing with it.

Pete

[TerryRitchie]

Yeah, I would be in favor of scrapping that example from the Wiki, and adding a return for the screen value, as Rho suggested.

I would also like to know what Terry envisions doing with it.

Pete

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.

[Pete]

I love it. I think that is probably the best reason to have this feature implemented. Without it, a user would have to pass the screen in the form of a variable to the library.

So the library would have a variety of popup message box sizes and colors, based on the chosen screen and font size. Nice!

Pete

[bplus]

Using _NewImage these days for setting up graphics screens makes screen modes a bit out dated.