Universal Screen Size support.

[ampos]

This is a "system" I am using to support any screen size.

First we got iPhone 3G, that just had 320x480. When 4G comes, it was easy, 640x960, with auto upscale 2x by iOS himself for old 3G games; for us was easy too: retina display was just x2. Then it comes iPad, 768x1024. Damm. It even has not the same screen aspect ratio.

Later was the Pre2. Ok, it is also 320x480, same as 3G; nothing to do here. But we noticed other WebOS devices had different screen sizes. But hey!, they were not a huge market to worry!; also, the TouchPad had 768x1024, same as iOS (intelligents this guys at HP, eh?).

And then, Android did come. And it was a nightmare. Any resolution can be out there. And to make things even worse, Google Android do not talk in any place about the screen sizes in pixels! They call it small, large, extra large,... even pixel density (what the hell was this on a mobile?).

And not to talk about aspect ratios... 320x480, 800x480, 854x480, 1280x800. Are they doing this just to disturb us?

With so many different screen sizes and aspect ratios, relative screen coordinates (to screen sizes and aspect ratio) has to be used, with an overcomplicated programming (any X coordinate has to be done as (x*xzoomsize)+aspect ratio... or if you want to print on top right corner, you have to substract coordinates... a shame.

So I got a solution. Perhaps it is not the best, and don't know if the fastest, but it works, and great!

First, create a virtual screen 1024x640 pixels. It has 16:10 aspect ratio (as many PC monitors out there) and it has also the highest texture size for many devices.

Type this at the start of your programs.

Code (glbasic) Select Expand

createscreen 1,100,1024,640
usescreen 1

Write all your graphics to this screen, and instead calling showscreen, just call my function sc()

Code (glbasic) Select Expand


FUNCTION sc:
LOCAL x,y,xz,yz,zoom,xres,yres


VIEWPORT 0,0,0,0
USESCREEN -1
        GETSCREENSIZE xres,yres

xz=xres/1024;yz=yres/640
zoom=MIN(xz,yz)

INC alfa,dalfa   //alfa is the current alphamode for your screen
IF alfa>-0.01   //dalfa is the speed of fade in/out
alfa=-0.01;dalfa=0
ENDIF

IF alfa<-1
alfa=-1;dalfa=0
ENDIF

ALPHAMODE alfa

deltax=(xres-(1024*zoom))/2     //perhaps you want to make global deltax, deltay and zoom at the ini of your program...
deltay=(yres-(640*zoom))/2       //and/or xres, yres
// STRETCHSPRITE 100,deltax,deltay,1024*zoom,640*zoom   //this is the same without polysprites

STARTPOLY 100,0
POLYVECTOR deltax,deltay,0,0,RGB(255,255,255)
POLYVECTOR deltax,deltay+(640*zoom),0,640,RGB(255,255,255)
POLYVECTOR deltax+(1024*zoom),deltay+(640*zoom),1024,640,RGB(255,255,255)
POLYVECTOR deltax+(1024*zoom),deltay,1024,0,RGB(255,255,255)
ENDPOLY

IF MOUSEAXIS(4)=1 THEN ShowZones()    // press right to see zones, if you are using zones()

IF KEY(31)      //press S to save a screenshot
SAVEBMP RND(9999)+".png"
MOUSEWAIT  //to avoid saving multiple savings with just 1 keypress
ENDIF

SHOWSCREEN
VIEWPORT 0,0,0,0
ALPHAMODE -1
USESCREEN 1
SETTRANSPARENCY RGB(0,0,0)
DRAWRECT 0,0,1024,640,RGB(0,0,0) // will draw black colour _AND_ transparent alpha
SETTRANSPARENCY RGB(255,128,0)
VIEWPORT 0,0,0,0

ENDFUNCTION

The sc() functions read the device real screen size and scales and center your virtual screen.

It doesnt matter anymore the screen size, ratio or density (!) of target device. It fits like a suit.

(although it is created for landscape portraits, it can be easily adapted to portrait ones)

To see it in action, just download the demo here:

http://www.glbasic.com/forum/index.php?topic=6905.0

(the example code is the same as for the imput$() function)

[spicypixel]

I was doing this a while back by blitting everything to one screen and then re-blitting it as a polyvector stretched to the real screen resolution. Indeed it does work well. You still need to re-calculate mouse touch areas though

[ampos]

No, I don't. All my touch areas are defined using ZONES lib, and they are also scaled by the createzone() function himself.

[doimus]

I do this all the time for my unfinished code rejects, erm, demos...
Draw everything to a virtual screen and then that screen stretched to main screen. Even on PC.

For example on PC, this gives you a nice option to scale/rotate game screen as you see fit. Or even to have multiple game screens at once!

[msx]

¡Fantástico!, estás que te sales. Ya me explicarás eso de librerias de zona (traducción literal) para la pantalla táctil. 

[msx]

A question, is it possible to define a virtual screen with CREATESCREEN larger than resolution of the device?

Thank you

[MrTAToad]

Technically yes, although the device itself may not allow it (due to memory restrictions for example).

[ampos]

A question, is it possible to define a virtual screen with CREATESCREEN larger than resolution of the device?

Thank you

Yes; in fact it is what I am doing, a 1024x640 screen for a 480x320 device.

Perhaps, as MrTAToad says, some devices could not like it. WebOS likes it, not yet tested on 3G. My cutre-tablet chinorro 800x480 like it also.

[msx]

Thanks, I have a problem resizing the screen but I can only test it on Windows because I have only an iPhone 3GS and a Palm Pre 2 and both have the same screen resolution. The problem occurs for lower screen resolutions of 320x480 but not for higher resolutions.

Could anyone test it on a Palm Pixi?

[Ian Price]

I've got a Pixi, what exactly would you like testing? If it's the scaling code above (not tested, but experience tells), you're probably better off forgetting it. The Pixi is really quite/very slow and scaling takes a large hit on the CPU. If you want to target the Pixi, then you need to code for it specifically. You really shouldn't try to force high end stuff down to its level. It's a nice device, but it's not really geared up to anything with lots of drawing or real-time effects.

[msx]

Hi Ian, the application that I want to try not consume many resources because it has no real-time effects and great graphics. what I want is not well functioning in Pixi, but it works in any screen resolution correctly. The code is mine and I can not prove in a different resolution of 320x480.


If I send you the apk file, could you install it on your Palm Pixi?.

Thank you.

[bigtunacan]

This is a nice idea when you are scaling to screens with the same ratios 4:3 for example, but otherwise you end up with images that are distorted; this does not look good and is noticed by end users.  I code for everything relativistically rather than with absolute coordinates as much as possible, but I use separate image sets for each separate device resolution

[Ian Price]

Hi Ian, the application that I want to try not consume many resources because it has no real-time effects and great graphics. what I want is not well functioning in Pixi, but it works in any screen resolution correctly. The code is mine and I can not prove in a different resolution of 320x480.


If I send you the apk file, could you install it on your Palm Pixi?.

Thank you.

Yep, no problems. Email it to mrijprice gmail com (with AT and DOT)

[ampos]

This is a nice idea when you are scaling to screens with the same ratios 4:3 for example, but otherwise you end up with images that are distorted; this does not look good and is noticed by end users.  I code for everything relativistically rather than with absolute coordinates as much as possible, but I use separate image sets for each separate device resolution

My routine scales with aspect ratio, so they are not distorted. It will scale up/down to fit in the screen and centers it.

Of course, some proyects will fit this system and others will not.

My App "The Last Angel" was programmed with relative coordinates and screen orientation.

In fact, I did a function to convert any coordinate relative to any corner relative position (print "test",-10,0 will print with text finishing at screen xres-10) and taking into account the screen orientation (that was before screenrotate by Gernot), and so, just look in the code snippets section, and when GLB was only iOS, and it just worked for Android and WebOS resolutions without changes.

Also my very first app (non-finished) was programmed with aspect ratio and screen sizes in mind and worked fine in my android device resolution easily.

But if your app can use the "universal screen size" function, it is a hell easier to code.

[spacefractal]

screen size on Android can been very hell, but its really not more speciel programmering for the pc really.

Also offbuffer is not very effective as well and you would lost very much of bandwidth/fillrate, so its is not or might been useable for some devices, where you can notice the framerate can fall by two, which was happens on the Sony Experia Play. I did optimize the update() (the function I use for game logic), so its do run smooth on that device.

So for best performents, you should do the awfull way doing scaling directly, or you can call it to a more advanced DRAW function, that so can do all scaling before its draw.

This was that I was need to do in my game.... For some games offbuffer do can work of course. Its depend on the game.