Handling full screen resolutions

Previous topic - Next topic

AndyH

Could we see some enhancements to the way GLB handles full screen modes please?  A bit of background to why I'm asking first :)

I'd like to run my pocket PC / GP2X games on my PC too (without having to make separate versions of the code).  Some graphics cards, one in my laptop included, doesn't support full screen at 320x240.  When I try to set a full screen mode that is not supported by my graphics card, I get a beep then it opens in a window instead which isn't nice for certain types of games.  Full screen, and blocky, is nice!

So my laptop (which has a hideously large desktop of 1920x1200) has a tiny window with my game in it, where as my desktop which supports full screen at this res will look excellent with it filling the screen.

My laptop supports standard resolutions with 640x480 as the smallest.  I've figured out some work a-rounds to the problem.  For example I can use the PLATFORMINFO$ command to detect if I'm on a DESKTOP or hand held device and change the way the program works.  If a desktop I could go for one of the options below:


1) A nice option, but would take a lot of work, could be to create both 320x240 and 640x480 graphic sets which I could SHOEBOX up and load the appropriate shoebox, making adjustments to my code for how I display and move things about on screen.  Would be a lot of work though!

2) A slightly less nice, but quicker and simpler option, would be to set the screenmode to the next best screen mode that is available for full screen.  EG: 640x480, and use VIEWPORT 160,120, 320,240, then my game area would appear central in the 640x480 screen.  There's some workarounds to do for LOADBMP, USESCREEN etc but all manageable.

3) A third option would be to use CREATESCREEN and USESCREEN to draw everything to a virtual screen then use one of the sprite scaling routines to draw that virtual screen at the full 640x480 window size.   EG:     STRETCHSPRITE 1,0,0,640,480 or ZOOMSPRITE 1,160,120,2,2.


Both options #2 and #3 are relatively easy to implement if I know the next best resolution available should the native resolution of the game not be available.

Option #3 should see the OpenGL acceleration handling the graphics fast enough, a danger though could be if there are any graphics cards that don't support the CREATESCREEN commands too well (eg: if ^2 sized textures or max size textures are an issue).


So here comes the requests bit again ;)  Could you provide any of the following in GLB that would work on any platform...

1) A command to return if a screen mode is available or not (ideally a command to return a list of modes available).

2) The ZOOMSPRITE and STRETCHSPRITE (option 3) will not work correctly for my scenario at present when there are transparent areas ( RGB(255,0,128) ), as GLB / OPENGL scales the graphic data and smooths the image, so where there is a transparent coloured pixel next to a real pixel, you'll get a purple edge.  Effectively you end up with a purple halo around every graphic (I can post an example if required).  I have a work a-round to this work a-round by not having any transparent areas in the virtual screen (can draw with transparent on to it though) but then I can't use LOADBMP and have to put everything into the one virtual screen.  Is it possible to add a command to tell GLB to not use smoothing when scaling and rotating sprites - we could then choose the method to use.

I think both of these requests would be useful for other scenarios, so they'd be a benefit to have.


Maybe there is a better work a-round, if so please let me know.  BTW, have seen the code that can detect screen modes in Windows, but this doesn't work for other platforms so it's limited.

Ian Price

I know exactly what you mean Andy - my lappy doesn't support 320x240 either and I just get a gerbled screen iff I go full screen at that res.

Scaling the whole screen x2 would be great, allowing the game to be displayed properly (albeit chunky) :)
I came. I saw. I played.

AndyH

It's very easy to do with GLB fortunately.

Code (glbasic) Select
CREATESCREEN 0, 1, 320,240
USESCREEN 0
BLACKSCREEN

USESCREEN -1  // back to back buffer

// ...

USESCREEN 0
BLACKSCREEN  // this works OK
//DRAWRECT 0,0,320,240,RGB(255,0,128) // this does not work very well

// ... do all your drawing operations in here to the created screen

USESCREEN -1
STRETCHSPRITE 1,0,0,640,480  // draws the created screen to the real screen
// ZOOMSPRITE 1,160,120,2,2  // this works also
If you could do transparencies on the scale, you could also layer more than one created screen for some nice parallaxing effects.

Here's a screenshot of both, the first is using black and no transparent areas.  The second uses transparent areas.


Ian Price

I came up with a similarly simple function that does pretty much the same thing, simply run your game in 640x480 (for a 320x240 based game) resolution and call the DBLE() function instead of using ShowScreen in your functions. It's fast too.

Code (glbasic) Select
// Double size screen
FUNCTION dble:

GRABSPRITE 0,0,0,320,240

ZOOMSPRITE 0,160,120,2,2

SHOWSCREEN

ENDFUNCTION
I came. I saw. I played.

AndyH

Thanks Ian, I like your solution better!  I was thinking about using the CREATE'd SCREEN as a collision map originally, one reason I went down that route, but I have found a simpler and more obvious method  to do that, so this grab and zoom will be perfect.