musings on graphics support

[Z!re]

How about this, for the SCREEN command.

SCREEN sets fullscreen modes, just like QB (not the same modes, but work the same way)

And then theres some... RESOLUTION command, or simillar, that leaves the program in windowed mode, but changes the window size to some pre-set sizes.

For example:
SCREEN 12 = 640x480x16bits (or 15, whatever works best, and is most compatible...)

RESO[...] 12 = Window resolution of 640x480, bitdepth same as desktop.


If possible, it would be nice to have things such as:
SCREEN 460, 300, 32 (xres, yres, bps)


But a few preset values wouldnt hurt at all...

[marzecTM]

yeah that's an idea

screen mode for fullscreen
window width, heigth, bpp for windowed mode

thing is that screen width, heigth, bpp would have to return a value wheter it succeeded or not. something somebody could complain about. in windowed mode nearly everything is possible resolution and bpp wise. providing constants here at least for bpp should solve the "unknown screen mode" problem

uh sterling didn't notice you already put together some stuff. DON'T STOP THAT!

[adosorken]

It makes less sense to specify BPP in a window than it does to specify it fullscreen. Plus, most Windows graphical libraries know how to remap colors in realtime, so for windowed, it's not even really a problem, is it?

[marzecTM]

It makes less sense to specify BPP in a window than it does to specify it fullscreen. Plus, most Windows graphical libraries know how to remap colors in realtime, so for windowed, it's not even really a problem, is it?

i don't think i get your point a hundred percent. but, hm..., yeah well since you already said it yourself color remapping is the key to having any bitdepth in windowed mode that is not the actuall desktop bpp. so... i don't get your point... providing only certain fullscreen modes that will be 100% supported, that's why i wouldn't let people chose the width, height and bpp, especially if they are new to that topic. they'd have to check wheter initialization succeeded or not, that is screen would have to return a value. do you want this? i mean it would not be a problem to implement.

[Z!re]

How about

Code:

SCREEN 12
If Err = 3472 Then
'Unable to init videomode
End If

Or, do it with regular error, trapped by ON ERROR... but prolly better with just setting ERR to a value (ERR is a function in QB that returns the last error number that has occured)

[marzecTM]

would be an idea, didn't know that Err thing, it's been a while for me hehe... thx for the hint, will ask v3c to implement it

[adosorken]

Err is one of the most useful things in BASIC. If it's not implemented, you're gonna have tremendous problems in Windows-based coding...

[marzecTM]

can you explain that to me? what does that have to do with windows (don't get me wrong, not offensive or something..)

[Z!re]

So you can return error codes, smoothly...

Like:

(call some functio in some random DLL)
(It goes wrong, and everything crashes)

or:

(call some function in some random DLL)
(It goes wrong, and ERR get's set to some number)

You get the number, look it up, and see:
ERR 34875394 = Error calling function in DLL

And tada, fix problem...


It's easier then having everything being functions that return a fail or ok value

[Marcade]

How about

Code:

SCREEN 12
If Err = 3472 Then
'Unable to init videomode
End If

Or, do it with regular error, trapped by ON ERROR... but prolly better with just setting ERR to a value (ERR is a function in QB that returns the last error number that has occured)

Hrmm ..

Personally ... I'd rather have a way to detect if a screen resolution is supported or not, instead of trial&error things, using ON ERROR GOTO .. or the err variable.

maybe something like

Code:

IF SCREENRES(320,200,24)=TRUE THEN PRINT "Supported"

or sumting silly