GLBasic forum

Hello Fellas,
I´m finishing up support to android resolutions the hard way (hardcoded), here are the supported resolutions for phones (no tablets yet):
1920 x 1080
1280 x 800
1280 x 768
1280 x 720
960 x 540
854 x 480
800 x 480
It seems to me to be a good set that currently covers about 87% of the android market.
I don´t see a reason to support any other resolution for android.

Does anyone have a device or know someone that has, that does not fit in there?

SORRY FOR THE MANY EDITS AGAIN.

(http://dl.dropboxusercontent.com/u/3236515/chicken/Screenshot_2014-05-27-13-04-38.png)

If you hardcode contain reolutions, you will face this issue seen on that screenshot. You have not covered toolbars by those resolutions, which is NOT reported by GETSCREENSIZE as well GETDESKTOPSIZE. In this case the reported resolution is 1024x552, not 1024x600 (48px is covered by the toolbar), a resolution which is not on your list.

Im thinks to fix the annoying issue is simply fall back to the nearst hard coded resolution, reported by the GETSCREENSIZE and then uses VIEWPORT/virutal screen to center it. Here im thinks its would been covered much more and better covered by eventuelly toolbars, even your game might not been fully fullscreen (in my case, 960x540), the game would still not been cropped.

Due that im recommered to add those three hard coded resolution to your list, based on nearst resolution method:
- 1024x600 (which property would uses on tables devices with 1024x768 with toolbars).
- 800x432 (if a tool bar used on a 800x480 screen).
- 480x320 (supports lowres screen, small screens in your manifest, here im have not seen toolbars used on those screens.

Then im thinks you would cover most devices out here.

Should you actually cover the bottom icons though - would make it harder to people to exit, look at the time etc.

Nice graphics by the way.

you cant hide the toolbars as shown here, only temp for movie players (when hided, a touch will shown them again). Its by Android design to replace physical buttons. Im whish they used iOS design with smart uses of home button, but its property patented.

So this is why fixed hardcode resolution is really a bad idea if you ask me, and did not do that for my games at all. Howover its can been possible to uses clostest hardcoded resolution, even you might seen black borders in this case (like Snake Slider excellents did). So make sure you might can lost up to 128px, depend of resolution.

The game happens on landscape (90 degrees counter clock), but the system stays at portrait, the ´top pull down´ bar comes from the left side of my phone when game is running. So here I can assume the toolbar will show on the left side, and will interfere the numbers of the highest resolution portion on , ex 1280x720 will report 1152x720 on getscreensize if considering a 128px bar, is that correct?

I have enough side parts to deal with the bar loss, it will just suck if you touch those buttons by mistake as the app will exit with the middle and right ones.
I also think I can get by without having to re-center the app.

Problem now is to find out if that menu bar is standard in pixel size, like either 48px or 128px so I can account for that.
If it can be ANY size between those numbers there will be trouble :P

Do you have any info on this Space? Maybe the bar manifests in 2 or 3 fixed sizes?

If too troublesome and deal break,  I will have to do a scale-to-anything routine, but I really don´t have the time to do it now, possibly on an update maybe. :(

Here a picture of it at the 854x480 size, the cyan lines are touch limits, I´m having them a lot bigger then the actual buttons so it gets comfortable for the player.
The game happens on a virtual screen of 428x240 and gets scaled, 28 of the native pixels (about 14 each side) are not accounted in game at all and is to support some device sizes where I would like to keep pixels square. On a 1280x720 android phone, those 28 pixels get to be 84 pixels, 42 each side. This, the no-centralized nature of things and the extended button areas might help I hope.

I guess I probably need to test on that kind of device to be sure.   

Just for the records, I tried the apk on a galaxy s2, it has a 2.something android, and here the pull down status/settings bar does not show up. On my note II at android 4.3 it gets called if I pull the border. (this is that time/settings bar)

Toolbars is mostly on the bottom, and its can been vareried from system to system. Sometimes they can been removed, sometimes not. Sometimes its 48px, but its can been 128px and sometimes in the middle. Its again vareried from system to system. They can been checked, but is really not  recommered. This is not a issue on iOS at all.

The screenshot was taking on a Samsung Tab2 and im could eventuelly test what it happens on that device if you wish.

But for you, im thinks, all you need is, just add a option to let the controller to been user moveablee without rescaling the great controller graphics it self. This could help very much for the user, if click area is too big or too small for the device. This would fix the controller issue.

Scaling to anything is best way, as you see my screen did reported to 1024x552 (1024x640 physical). But really you could uses the closest hardcoded resolution (here 960x540) and top/center it (using VIEWPORT), and could even crop some of the floor graphics, if reported resolution is a very close match.

in both Greedy Mouse and Karma Miwa, im used rescaling to anything without used virtual screen (its was too slow).

PS. if toolbar is rotated wrong, this is a glbasic bug, fixed by AE (which Search button is disabled and you can control the Back button).

Quote from: spacefractal on 2014-May-27
Toolbars is mostly on the bottom, and its can been vareried from system to system. Sometimes they can been removed, sometimes not. Sometimes its 48px, but its can been 128px and sometimes in the middle. Its again vareried from system to system. They can been checked, but is really not  recommered. This is not a issue on iOS at all.

There I meant the usual top bar you call up by dragging a finger over the top corner of the screen, it is where you have a few settings, wifi, gps, etc on 4.3 or the likes.
What I meant from the last post, and I recall talking about it somewhere else, is that when I had 4.2 android (and olders), this one bar would not show up, then I updated to 4.3 and now it shows. Maybe it is something related to the manifest, I might check that later.

The bottom bar I have no clue, I don´t have a device with such around neither my friends. The galaxy S and iphone seem to rule in brazil.

In my game´s case, I bet the tool bar you are talking about is going to be on the right side (the lower part of the phone when you hold him normally).
Visually, that is not going to cause much trouble, but I have to attend to those resolutions and possible bar sides.

For that, what I really need is to know the possible sizes of that bar that gets reported on GETSCREENSIZE.
Say, in my unrotated case, a 1280x720 resolution phone might report from GETSCREENSIZE a 1152x720 and thus fail to fit on what I have(here considerind a 128px bar).

I´m also failing to find a site that states this info, what are the bottom bar standard sizes? (standards in android hehe :D)

I currently can´t afford time to re-write the scaling code neither the touch controls, so I have to work with what I can.
I will get better next project. ;)

By what I checked, any device bellow 1ghz, won´t be able to hold the 60fps with the virtual screen, and I haven´t accounted for speed changes in game either, so they are probably out.

It would be a shame to skip great phones for a resolution check fail, so I need to attend for this bottom bar.

As Space recommended, I may as well check into VIEWPORT command for my screen scale.

I have no experience with it, my game happens in a 428x240 virtual screen, when upscaled, I work with a 320x240 or a 400x240 centered part of it and get it to the final output screen size. Maybe VIEWPORT can give me an edge here.

The other thing is that the touch coordinates are checked on the output screen size, which is attached to my resolution check to boot.
Hopefully it is not much trouble to change. I have to at least check it.

I want my pixels moving on the 428x240 resolution grid.
In a 1920x1080 output, 1 original pixel mean 4.5 pixels. I didn´t want to deal with this and the pixel break on the many other resolutions, that is where a virtual screen is good for me.

It works already, I will give a quick try on it later to see what happens.
Damn, I should be doing the music... :(

Here a good resource on the navigation bar size (ye the bottom bar).
http://www.emirweb.com/ScreenDeviceStatistics.php

I hope to be able to go around it by checking that.

Sorry the 300 posts...

Quote from: MrTAToad on 2014-May-27
Should you actually cover the bottom icons though - would make it harder to people to exit, look at the time etc.
Nice graphics by the way.

I don´t wanna cover them. but actually detect it.
The top bar is a pull down stuff, so it is fine and design wise escapable when setting (project options) compile to android with a resolution like 9999x9998 (instant landscape here working with a portrait phone). GETSCREENSIZE reports me a standard X/Y screen size. At least to this kind of game style and the devices I tested.

The navigation bar at bottom is not skipable and, according to Space, GLB reports a resolution considering less pixels of its screen state to compensate the bar.
I must check this out.

Those gfx are from Karma Miwa, available at the playstore. I did a few sprites there, check it out, it is a great game!

Samsung Galaxy S is a quite old phone. Older phones does not have navigation toolbars. This due they have physical buttons, which is today is moved to the screen its self as those navigation toolbar and removed the physical buttons. So Android is quite very fragmented by returned supported resolution to the app by the device. So newer do hard code fixed supported resolution on Android (But fine to choices the closest one). Gernot or im with AE cant do anything about this at all. Its by Android design.

Im did used quite long time for Karma Miwa on this issue, which is why up/down scrolling is required for some devices, depend on detected resolution (the game dont do scaling if detected resolution is between 960x640 and 1280x720).

This is a issue not to been seen on iOS, here we have just 5 resolutions need to been supported, all fullscreen (or 4, if you not want support 3gs):
480x320, 960x640, 1136x640, 1024x768 and 2048x1536.

If the game cant hold 60fps, the game should not slowdown (lag), but instead uses some sort of frameskip measure to keep the same speed. Greedy mouse used a frameskip measure, while Karma Miwa used a timer to keep the speed.

Got one question Space...

When using GETSCREENSIZE on a phone/tablet with navigation bar, the final resolution stated by the command is the actual resolution minus the bar size right?
Like, suppose a phone is 768x1024 in portrait mode and the bar is 48px , will GETSCREENSIZE report 768x976?

Its will return 768x976. Its the surface size created in SDLActivity.Java glbasic uses.

Im just checked now, im really uses GETDESKTOPSIZE(), not GETSCREENSIZE() to detect the current surface resolution (due its recommered in the help file), but its should not been any different at all (see log file below).

just for fun, here is the logcat start of the Karma Miwa game:


Android Debug Bridge version 1.0.31
List of devices attached
c1607391b81267f device

--------- beginning of /dev/log/system
--------- beginning of /dev/log/main
I/SDL     ( 2969): ---------------------------------------------
I/SDL     ( 2969): ---               restart                 ---
I/SDL     ( 2969): ---------------------------------------------
I/SDL     ( 2969): onCreate
I/glbasic ( 2969): external files dir is /data/data/com.spacefractal.karmamiwa/files
I/glbasic ( 2969): external storage /storage/sdcard0/Download
I/glbasic ( 2969): DPI 169
I/glbasic ( 2969): SDL Surface: GT-P3110
I/glbasic ( 2969): Exception starting GPS: Provider gps requires ACCESS_FINE_LOCATION permission
I/glbasic ( 2969): Creating SoundPool instances...
I/glbasic ( 2969): SoundPool instances created
I/glbasic ( 2969): try to load a Interstitial
I/glbasic ( 2969): device: espressowifixx
I/glbasic ( 2969):    onCreate done
I/SDL     ( 2969): startApp, thread
I/glbasic ( 2969): surfaceCreated()
I/glbasic ( 2969): surfaceChanged()
I/SDL     ( 2969): pixel format RGB_565
I/glbasic ( 2969): startApp, thread
I/SDL     ( 2969): hint screensize to glb
I/glbasic ( 2969): glb_notify_screen_size 1024x552
I/SDL     ( 2969): SDL_Android_Init()
I/SDL     ( 2969): SDL_Android_Init() finished!
I/glbasic ( 2969): Can't init SDL.
I/glbasic ( 2969): Passed a NULL mutex
I/glbasic ( 2969): timer
I/glbasic ( 2969): rbow
I/glbasic ( 2969): rbow init
I/glbasic ( 2969): SDL_init video
I/glbasic ( 2969): SDL_GetVideoInfo = 1024x552 @ 0 bpp. Screen 1024x552
I/glbasic ( 2969): C++ calling SDL_CreateWindow (fs:1)
I/SDL     ( 2969): ceateGLContext
I/SDL     ( 2969): ceateEGLContext
I/SDL     ( 2969): [STUB] GL_SetSwapInterval
I/glbasic ( 2969): C++ SDL_CreateWindow stuff finished
I/glbasic ( 2969): get accurate timer - 1st call
I/glbasic ( 2969): flip - 1st call
I/glbasic ( 2969): BGRA ext supported
I/glbasic ( 2969): Texture size limit: 2048
I/glbasic ( 2969): init fbo
I/glbasic ( 2969): 2D VP
I/glbasic ( 2969): OGRB init [OK]
I/glbasic ( 2969): Cptn
I/glbasic ( 2969): Network
I/glbasic ( 2969): Input
I/glbasic ( 2969): Window mode
I/glbasic ( 2969): Create DXin
I/glbasic ( 2969): getexe
I/glbasic ( 2969): cd
I/glbasic ( 2969): exepath=curdir= /data/data/com.spacefractal.karmamiwa
I/glbasic ( 2969): shoeboxing...
I/glbasic ( 2969): init gettimer
I/glbasic ( 2969): clear screen
I/glbasic ( 2969): flip
I/glbasic ( 2969): mk2D
I/glbasic ( 2969): finding font...
I/glbasic ( 2969): SDL audio: wanted stereo 16-bit 44.1kHz, 1024 frames buffer
I/glbasic ( 2969): SDL audio: got stereo 16-bit 44.1kHz, 4096 frames buffer
I/glbasic ( 2969): open sound: 44100 Hz 2 chan, buffers 1024, format -32752
I/glbasic ( 2969): Init Finalized
I/glbasic ( 2969): [GLB]->******* STARTUP *******
I/SDL     ( 2969): [STUB] GL_SetSwapInterval
I/glbasic ( 2969): [GLB]->Platform: Platform=Android VersionAPI=16 Manufacturer=samsung device=espressowifi model=gt-p3110
I/glbasic ( 2969): [GLB]->GameWidth: 1187 640
I/glbasic ( 2969): [GLB]->Graphics Resoulutuon: 1024x552
I/glbasic ( 2969): [GLB]->Scaling Used: .8626790047
I/glbasic ( 2969): [GLB]->Frames Per Second: 60


Yes some spelling, but that me. There is a SDL error, but its do work correctly. IM not sure why its happens, but its does work.

glb_notify_screen_size 1024x552 is that line of code that tell glbasic, which surface Android have created for the app.

Nice, so a 1024x600 gets to be 1024x552 which is minus the navigation bar at 48 pixels.
Good thing is that if getscreensize is returning the real resolution minus the navigation bar, it will be easier for me to accommodate the phones/tablets that have it.

Based on the link I posted a few posts ago, I compiled a list of resolutions and bar to work with.
Hopefully, I may also create a quick test.apk just to test results with the phones we have here on forum. :good:

Here is a function, that should help you quite very much for auto scaling, which also can precalculate image borders:

GLOBAL PX, PY, PW, PH   // The calculate rectangle
GLOBAL sx, sy           // The screen resolution

FUNCTION PaintImage: id, x#, y#, xspot, yspot, zoom#, mirror=0, draw=1
// get size of the incoming sprite
LOCAL h#, w#
GETSPRITESIZE id, w, h
IF w<1 OR h<1
RETURN 0
ENDIF

// calculate rectangle of the sprite position.
IF xspot=-1 THEN PX=x#+0.5
IF xspot=0 THEN PX=sx/2.0-(w#*zoom#/2.0)+x#+0.5
IF xspot=1 THEN PX=sx-w#*zoom#-x#+0.5
IF yspot=-1 THEN PY=y#
IF yspot=0 THEN PY=sy/2.0-(h*zoom#/2.0)+y#
IF yspot=1 THEN PY=sy-h#*zoom#-y#

// checks if the rectangle is on the screen
IF PY-PH>sy OR PX-PW>sx OR PY<-h*zoom*1.2 OR PX<-w*zoom*1.2 THEN RETURN 0

// perform scaling to the image.
PW=INTEGER(w*zoom#)
PH=INTEGER(h*zoom#)

// should the image draw or not? usable for rectangle calculate for ingame controls.
IF draw=0 THEN RETURN

// draw the image (using STRETCHSPRITE)
IF mirror=1
STRETCHSPRITE img, PX, PY, -ABS(PW), ABS(PH)
ELSE
STRETCHSPRITE img, PX, PY, ABS(PW), ABS(PH)
ENDIF
RETURN 1
ENDFUNCTION


dont forget to global PX, PY, PW and PH. This tell the borders of a drawed or precalculated image.

scaling (in boot) can been perfomed like this:

scaling=sx/428
IF scaling*240>sy THEN scaling=sy/240


when invoking PaintImage(200, 0, 0, 0, 0, scaling, 0, 0) (example), you know the image borders of the virtual image, so you can uses its values to your controller code (its sent to global PX, PY, PW and PH). so for mouse controller, you can do something like x=(mousex-PX)/scaling. mousex is the value got from MOUSESTATE. X will now hold the correct value correspons to the virtual image, not the whole surface.

If you want pixel perfect scaling for contain known resolutions, you can still do that in the boot after setting the scaling value. You can eventuelly align the image if you want.

Super thanks Space :good:

I read the code and don´t understand much :(
Problem is that I´m not that best of coders, haven´t messed with types neither functions (but the fps check by Hemlos I use without knowing what it is actually doing).

The best I´m looking into now is to be able to have a MAC/PC/LINUX release and obviously, to have the game done.
Android will have to follow, It works fine on the current models I tried, I know it works in a blunt way, but it seems to be working fine.

I´m giving a shot here to hardcode current solutions in an attempt that it does not take much time for me.
I did some code today to hold up to that problem. I will need testing.

It does work so far on the devices I tested, but I have to try on one with navigation bar.
I will put up an apk here to give a go tomorrow.

Again, thanks for the help, I will sure study into that code. :good:

So here is what variables do:
id=id if your image (which was 200 in your test project).
x=x position of the image.
y=y position of the image.
xpos=is the x hotspot you want to alignment the image.
ypos=is the y hotspot you want to alignement the image.
zoom=is the scaled value (etc zoom=2 is scaled the image by twice).
mirror=mirror the drawed image.
draw=draw the image (0 can been used for precalucate the image, or 1 to draw it).

xpos/ypos can set to -1 (hotspot to left), 0 (hotspot to center) or 1 (hotspot to right).

Global values:
- sx and sy was the returned GETSCREENSIZE from the boot section.
- PX, PY, PW, PH is the calculated rectangle values its have been for the image.

This is very useable for cacluate scaling for the mousetate, so you can get mouse positions from the virtual area (428x240 regardless scaling and position of the view), not the whole surface (as im seen you trying, which is not recommered at all). This is the main purpose of the function (and VIEWPORT is not required at all). So even the image got scaled, you dont need to change the mouse controller code at all again.

Etc you want to center the virtual image (id=200, x=0, y=0, xspot=0, yspot=0, zoom=scaling, mirror=0, draw=0):
- PaintImage(200, 0, 0, 0, 0, scaling, 0, 0) for calculate the rectangle of the image before MOUSESTATE.
- PaintImage(200, 0, 0, 0, 0, scaling, 0, 1) for calculate the rectangle of the image, and also draw the image.

Etc you want to draw the image to the bottom of screen (id=200, x=0, y=0, xspot=0, yspot=1, zoom=scaling, mirror=0, draw=0):
- PaintImage(200, 0, 0, 0, 1, scaling, 0, 0) for calculate the rectangle of the image before MOUSESTATE.
- PaintImage(200, 0, 0, 0, 1, scaling, 0, 1) for calculate the rectangle of the image, and also draw the image.

PS. edited both post, due there was some cleanup in the PaintImage function with comments and removed some unusabled local variables.

Noted, I will try to give a try with this and viewport for mac and android.
I should also gain some speed against the virtual screen I guess, might be important for old android devices.
But I still think I might release the game on working platforms with what I have in current code IF it works.

For this reason, I stripped a test from my game to scale the virtual screen, consider GETSCREENSIZE and the navigation bar and do a very little centralization.
Again, the base screen is 428x240.

I compiled a list of android devices based on the list I posted and another android resolution thread, I believe this covers it all.
There is also a few android going about that have landscape hardware LCD screens, there the game won´t work, but it is just so very few and unknow brands.

Here is the list, also, the game strugles on processors below 1ghz because I guess the virtual screen takes too much, but I don´t care those devices, they are not quite suitable for gaming anyways. I have an LG 320x240 800ghz here where I got this info from.

So to start with, here is the compiled list of android resolutions that matters to me:

QuoteSLT.....RESOLUTION......REPORTED........NAVBAR..PIX.....ON_SCREEN
_______________________________________________________________
ORI   428.240      428.240      0   1   428
---------------------------------------------------------------
0   2560.1600   2560.1600   0   6.6   388
1   2560.1600   2464.1600   96   6.6   
---------------------------------------------------------------
2   1920.1200   1920.1200   0   5   384   
3   1920.1200   1824.1200   96   5
4   1920.1200   1834.1200   86   5
5   1920.1200    1848.1200   72   5
---------------------------------------------------------------
6   1920.1080   1920.1080   0   4.5   428
7   1920.1080   1776.1080   144   4.5
8   1920.1080   1794.1080   126   4.5
9   1920.1080   1803.1080   117   4.5
10   1920.1080   1824.1080   96   4.5
11   1920.1080   1834.1080   86   4.5
12   1920.1080   1848.1080   72   4.5
13   1920.1080   1872.1080   48   4.5
14   1920.1080   1884.1080   36   4.5
---------------------------------------------------------------
15   1280.800   1280.800   0   3.33   384
16   1280.800   1205.800   75   3.33
17   1280.800   1212.800   64   3.33
18   1280.800   1224.800   56   3.33
19   1280.800    1232.800   48   3.33
---------------------------------------------------------------
20   1280.768   1280.768   0   3.2   400
21   1280.768    1184.768   96   3.2
22   1280.768   1248.768    32   3.2
---------------------------------------------------------------
23   1024.768    1024.768   0    3.2   320
24   1024.768   976 .768   48   3.2
---------------------------------------------------------------
25   1280.720   1280.720   0   3   426.6
26   1280.720    1184.720   96   3
27   1280.720    1212.720   64   3
28   1280.720    1232.720   48   3
---------------------------------------------------------------
29   1024.600    1024.600   0    2.5   409
30   1024.600    952 .600   72   2.5
31   1024.600   976 .600   48   2.5
---------------------------------------------------------------
32   960.540      960 .540   0   2.25   426.6
33   960.540      888 .540   72   2.25
---------------------------------------------------------------
34   854.480      854 .480   0   2   427
35   854.480      782 .480   72   2
36   854.480      788 .480   66   2
---------------------------------------------------------------
37   800.480      800 .480   0   2   400
38   800.480      728 .480   72   2
39   800.480      752 .480   48   2
40   800.480      764 .480   36   2
---------------------------------------------------------------
41   320.240      320 .240   0   1   320

SLT is the android type number
RESOLUTIUON is the hardware resolution
REPORTED is what I expect from GETSCREENSIZE
NAVBAR is the available nav bar sizes for those devices
the other info don´t bother, it is my game related.

Ok, here I´m posting the code for the test, I´m also adding a .zip with the project.

// --------------------------------- //
// Project: ANDROID_RES_TEST
// Start: Friday, May 30, 2014
// IDE Version: 12.096

// ------------------------------------------------------------------------------------------------------------------- DECLARE VARIABLES
GLOBAL tcxa, tcxb, tcy ;// Touch Control coordenates (x-block left, x-block right , y-middle jump)
GLOBAL FramesPerSecond ;// Helmos fps Routine
GLOBAL sx,sy ;// Android Get Screen Size (pixels)
GLOBAL andro ;// Android Screen Model (0-NOTE.II 1-GALA.S2...)
GLOBAL bar ;// Expected navigation bar size
// ------------------------------------------------------------------------------------------------------------------- DECLARE VARIABLES [END]


// ------------------------------------------------------------------------------------------------------------------- LOAD VISUAL ASSETS
LOADSPRITE "Media/TEST.bmp" ,1 ;// Background image test
// ------------------------------------------------------------------------------------------------------------------- LOAD VISUAL ASSETS [END]


// ------------------------------------------------------------------------------------------------------------------- DIP SWITH
SYSTEMPOINTER TRUE ;// Show mouse
LIMITFPS 60 ;// Vertical sync limit fps
AUTOPAUSE TRUE ;// Set pause when lost focus
// ------------------------------------------------------------------------------------------------------------------- DIP SWITH [END]


// ------------------------------------------------------------------------------------------------------------------- SET OUTPUT SCREEN / TOUCH
CREATESCREEN 1,200,428,240 ;// Virtual Screen
// --- ANDROID SETS
GETSCREENSIZE sx,sy ;// Get Android Screen Size
// sx=976 ; sy=768 ;// Simulate a resolution/android set
// ---
IF sy=1600
SETSCREEN 2560,1600,0 ;// sy 1600
IF sx=2560
andro=0
tcxa=590 ; tcxb=1970 ; bar=0
ENDIF
IF sx=2464
andro=1
tcxa=542 ; tcxb=1922 ; bar=96
ENDIF
tcy=983
ENDIF
IF sy=1200
SETSCREEN 1920,1200,0 ;// sy 1200
IF sx=1920
andro=2
tcxa=442 ; tcxb=1478 ; bar=0
ENDIF
IF sx=1824
andro=3
tcxa=394 ; tcxb=1430 ; bar=96
ENDIF
IF sx=1834
andro=4
tcxa=391 ; tcxb=1427 ; bar=86
ENDIF
IF sx=1848
andro=5
tcxa=406 ; tcxb=1442 ; bar=72
ENDIF
tcy=742
ENDIF
IF sy=1080 ;// sy 1080
SETSCREEN 1920,1080,0
IF sx=1920
andro=6
tcxa=497 ; tcxb=1423 ; bar=0
ENDIF
IF sx=1776
andro=7
tcxa=425 ; tcxb=1351 ; bar=144
ENDIF
IF sx=1794
andro=8
tcxa=434 ; tcxb=1360 ; bar=126
ENDIF
IF sx=1803
andro=9
tcxa=439 ; tcxb=1365 ; bar=117
ENDIF
IF sx=1824
andro=10
tcxa=449 ; tcxb=1375 ; bar=96
ENDIF
IF sx=1834
andro=11
tcxa=454 ; tcxb=1380 ; bar=86
ENDIF
IF sx=1848
andro=12
tcxa=461 ; tcxb=1387 ; bar=72
ENDIF
IF sx=1872
andro=13
tcxa=473 ; tcxb=1399 ; bar=48
ENDIF
IF sx=1884
andro=14
tcxa=479 ; tcxb=1405 ; bar=36
ENDIF
tcy=665
ENDIF
IF sy=800 ;// sy 800
SETSCREEN 1280,800,0
IF sx=1280
andro=15
tcxa=309 ; tcxb=971 ; bar=0
ENDIF
IF sx=1205
andro=16
tcxa=272 ; tcxb=934 ; bar=75
ENDIF
IF sx=1212
andro=17
tcxa=277 ; tcxb=939 ; bar=64
ENDIF
IF sx=1224
andro=18
tcxa=281 ; tcxb=943 ; bar=56
ENDIF
IF sx=1232
andro=19
tcxa=285 ; tcxb=947 ; bar=48
ENDIF
tcy=493
ENDIF
IF sy=768 ;// sy 768
IF sx>=1184 AND sx<=1280 THEN SETSCREEN 1280,768,0
IF sx>=976 AND sx<=1024 THEN SETSCREEN 1024,768,0
IF sx=1280
andro=20
tcxa=309 ; tcxb=971 ; bar=0
ENDIF
IF sx=1184
andro=21
tcxa=261 ; tcxb=923 ; bar=96
ENDIF
IF sx=1248
andro=22
tcxa=296 ; tcxb=955 ; bar=32
ENDIF
IF sx=1024
andro=23
tcxa=180 ; tcxb=844 ; bar=0
ENDIF
IF sx=976 ; // Too Small
andro=24
tcxa=156 ; tcxb=820 ; bar=48
ENDIF
tcy=473
ENDIF
IF sy=720 ;// sy 720
SETSCREEN 1280,720,0
IF sx=1280
andro=25
tcxa=330 ; tcxb=950 ; bar=0
ENDIF
IF sx=1184
andro=26
tcxa=282 ; tcxb=902 ; bar=96
ENDIF
IF sx=1212
andro=27
tcxa=298 ; tcxb=918 ; bar=64
ENDIF
IF sx=1232
andro=28
tcxa=306 ; tcxb=926 ; bar=48
ENDIF
tcy=443
ENDIF
IF sy=600 ;// sy 600
SETSCREEN 1024,600,0
IF sx=1024
andro=29
tcxa=254 ; tcxb=770 ; bar=0
ENDIF
IF sx=952
andro=30
tcxa=218 ; tcxb=734 ; bar=72
ENDIF
IF sx=976
andro=31
tcxa=230 ; tcxb=746 ; bar=48
ENDIF
tcy=370
ENDIF
IF sy=540 ;// sy 540
SETSCREEN 960,540,0
IF sx=960
andro=32
tcxa=247 ; tcxb=713 ; bar=0
ENDIF
IF sx=888
andro=33
tcxa=211 ; tcxb=677 ; bar=72
ENDIF
tcy=333
ENDIF
IF sy=480 ;// sy 480
IF sx>=782 AND sx<>800 THEN SETSCREEN 854,480,0
IF sx=854
andro=34
tcxa=219 ; tcxb=635 ; bar=0
ENDIF
IF sx=782
andro=35
tcxa=183 ; tcxb=599 ; bar=72
ENDIF
IF sx=788
andro=36
tcxa=186 ; tcxb=602 ; bar=66
ENDIF
IF sx>=782 AND sx<>800 THEN tcy=296
ENDIF
IF sy=480 ;// sy 480
IF sx<=764 OR sx=800 THEN SETSCREEN 800,480,0
IF sx=800
andro=37
tcxa=193 ; tcxb=607 ; bar=0
ENDIF
IF sx=728
andro=38
tcxa=157 ; tcxb=571 ; bar=72
ENDIF
IF sx=752
andro=39
tcxa=169 ; tcxb=583 ; bar=48
ENDIF
IF sx=764
andro=40
tcxa=175 ; tcxb=589 ; bar=36
ENDIF
IF sx<=764 OR sx=800 THEN tcy=295
ENDIF
IF sy=240 ;// sy 240
SETSCREEN 320,240,0
IF sx=320 THEN andro=41
tcxa=57 ; tcxb=263 ; tcy=149 ; bar=0
ENDIF
// ------------------------------------------------------------------------------------------------------------------- SET OUTPUT SCREEN / TOUCH [END]


// ------------------------------------------------------------------------------------------------------------------- MAIN GAME LOOP
WHILE TRUE
// --------------------------------------------------------- DISPLAY
// --- SET VIRTUAL SCREEN
ALPHATESTING 0.0 ;// GLBv12 alpha on
SMOOTHSHADING FALSE ;// Hard pixels
USESCREEN 1 ;// Set Virtual screen buffer

// --- DRAW TEST IMAGE
DRAWSPRITE 1,0,0

// --- PRINT DEBUG INFO
FramesPerSecond=FPS()
PRINT "ANDROID TYPE: "+andro,117,24
PRINT "GETSCREEN X : "+sx,117,34
PRINT "GETSCREEN Y : "+sy,117,44
PRINT "NAV BAR SIZE: "+bar,117,56
PRINT "FPS         : "+FramesPerSecond,117,66


// --------------------------------------------------------- DISPLAY [END]

// --------------------------------------------------------- OUTPUT AND SCALE
USESCREEN -1 ;// Set Backbuffer
SMOOTHSHADING FALSE ;// Hard pixels

// --- ANDROID SETS
IF andro=0 THEN ZOOMSPRITE 200,1067,681,6.6,6.6 ;// 2560.1600 0
IF andro=1 THEN ZOOMSPRITE 200,1019,681,6.6,6.6 ;// 2464.1600 96
// ---
IF andro=2 THEN ZOOMSPRITE 200,747,481,5,5 ;// 1920.1200 0
IF andro=3 THEN ZOOMSPRITE 200,699,481,5,5 ;// 1824.1200 96
IF andro=4 THEN ZOOMSPRITE 200,704,481,5,5 ;// 1834.1200 86
IF andro=5 THEN ZOOMSPRITE 200,711,481,5,5 ;// 1848.1200 72
// ---
IF andro=6 THEN ZOOMSPRITE 200,747,421,4.5,4.5 ;// 1920.1080 0
IF andro=7 THEN ZOOMSPRITE 200,675,421,4.5,4.5 ;// 1776.1080 144
IF andro=8 THEN ZOOMSPRITE 200,684,421,4.5,4.5 ;// 1794.1080 126
IF andro=9 THEN ZOOMSPRITE 200,689,421,4.5,4.5 ;// 1803.1080 117(58)
IF andro=10 THEN ZOOMSPRITE 200,699,421,4.5,4.5 ;// 1824.1080 96
IF andro=11 THEN ZOOMSPRITE 200,704,421,4.5,4.5 ;// 1834.1080 86
IF andro=12 THEN ZOOMSPRITE 200,711,421,4.5,4.5 ;// 1848.1080 72
IF andro=13 THEN ZOOMSPRITE 200,723,421,4.5,4.5 ;// 1872.1080 48
IF andro=14 THEN ZOOMSPRITE 200,729,421,4.5,4.5 ;// 1884.1080 36
// ---
IF andro=15 THEN ZOOMSPRITE 200,428,280,3.33,3.33 ;// 1280.800 0
IF andro=16 THEN ZOOMSPRITE 200,391,280,3.33,3.33 ;// 1205.800 75(37)
IF andro=17 THEN ZOOMSPRITE 200,396,280,3.33,3.33 ;// 1212.800 64
IF andro=18 THEN ZOOMSPRITE 200,400,280,3.33,3.33 ;// 1224.800 56
IF andro=19 THEN ZOOMSPRITE 200,404,280,3.33,3.33 ;// 1212.800 64
// ---
IF andro=20 THEN ZOOMSPRITE 200,428,265,3.2,3.2 ;// 1280.768 0
IF andro=21 THEN ZOOMSPRITE 200,380,265,3.2,3.2 ;// 1184,768 96
IF andro=22 THEN ZOOMSPRITE 200,412,265,3.2,3.2 ;// 1248,768 32
// ---
IF andro=23 THEN ZOOMSPRITE 200,300,265,3.2,3.2 ;// 1024.768 0
IF andro=24 THEN ZOOMSPRITE 200,276,265,3.2,3.2 ;// 976,768 48 !too small
// ---
IF andro=25 THEN ZOOMSPRITE 200,428,240,3,3 ;// 1280.720 0
IF andro=26 THEN ZOOMSPRITE 200,380,240,3,3 ;// 1184.720 96
IF andro=27 THEN ZOOMSPRITE 200,396,240,3,3 ;// 1212.720 64
IF andro=28 THEN ZOOMSPRITE 200,404,240,3,3 ;// 1232.720 48
// ---
IF andro=29 THEN ZOOMSPRITE 200,300,180,2.5,2.5 ;// 1024.600 0
IF andro=30 THEN ZOOMSPRITE 200,264,180,2.5,2.5 ;// 952.600 72
IF andro=31 THEN ZOOMSPRITE 200,276,180,2.5,2.5 ;// 976.600 48
// ---
IF andro=32 THEN ZOOMSPRITE 200,264,150,2.25,2.25 ;// 960.540 0
IF andro=33 THEN ZOOMSPRITE 200,228,150,2.25,2.25 ;// 888.540 72
// ---
IF andro=34 THEN ZOOMSPRITE 200,214,120,2,2 ;// 854.480 0
IF andro=35 THEN ZOOMSPRITE 200,178,120,2,2 ;// 782.480 72
IF andro=36 THEN ZOOMSPRITE 200,181,120,2,2 ;// 788.480 66
// ---
IF andro=37 THEN ZOOMSPRITE 200,184,120,2,2 ;// 800.480 0
IF andro=38 THEN ZOOMSPRITE 200,148,120,2,2 ;// 728.480 72
IF andro=39 THEN ZOOMSPRITE 200,160,120,2,2 ;// 752.480 48
IF andro=40 THEN ZOOMSPRITE 200,166,120,2,2 ;// 764.480 36
// ---
IF andro=41 THEN DRAWSPRITE 200,-54,0 ;// 320x240 0

// --- DRAW POSSIBLE NAV BAR

ALPHATESTING .1
ALPHAMODE 1.5
DRAWRECT sx,0,2560,1600,RGB(255,0,0) ;// NAV BAR
ALPHATESTING 0.0
ALPHAMODE 0

// --------------------------------------------------------- OUTPUT AND SCALE [END]
SHOWSCREEN
WEND
// ------------------------------------------------------------------------------------------------------------------- MAIN GAME LOOP [END]

FUNCTION FPS:
// created by Hemlos
STATIC OldTimeReport$,FPSDat,TimeReport$,FPSd
OldTimeReport$=TimeReport$; FPSDat=FPSDat+1;
TimeReport$=PLATFORMINFO$("TIME")
IF OldTimeReport$<>TimeReport$; FPSd=FPSDat ; FPSDat=0; ENDIF
RETURN FPSd
ENDFUNCTION



EDIT: I know this is guerrilha coding...do your best not to laugh too hard here :D

FINALLY, here is a zipped APK.

Please, I would like you to run this apk on your android phone/tablet and report the results.
Possibly if you could take a screen shot and post the name and brand of the the device.

If it is impossible to take a picture/screenshot, then I just need to know if you see the annexed screen,
and if you can tell me the following printed info:

ANDROID TYPE
GETSCREEN X
GETSCREEN Y
NAV BAR SIZE
FPS

FPS will be good for me if it is stable on 59-60. It is limited to 60.
I´m really interested if it will work properly on androids with navigation bars.

EDIT: so far it works fine on my galaxy note II, galaxy s2 and an LG-e400f with the later holding around 42-45 fps.

im pm  a cleaner example with auto scaling anything method (which im wont post here, except if Erico do). But rather pm the test result, here im will just post as it are:

Samsung Tab 2.
- Reports 976x600 (type: 31).
- Crops around 10pixels on each side (im have to say im perfer letterbox, so im can see the whole graphics, just like a movie, small thing).
- Navigationbar to the right (which should have been on the bottom, the famous orientation issue fixed by Android Extras).
- Would been fully playable, despite the Navigation/orientaion issue (as well remember set manifest to Landscape?).

Can I get a screen shot? Did the FPS stay around 58-60?

The image is supposed to be cropped on many resolutions up to the 320 mark (caanoo resolution) the game contents accommodate that.
I´m fine with the nav bar on the side, players will just have to be carefull not to touch the central or back button on the frenzy of action  :)
But the touch detection area is quite big to help that out.
If the things displays correctly, as it seems to on your system and mine, the game is fully playable, don´t worry.

Thanks for testing Space, at least this system works for standard GLB android compilation.
I would like to see it tested on the 2560.1600 devices and more bar devices, but I don´t know anyone with one.
I will try to push it this way into stores and later transit to a more elegant style.
But it is best for me to try Android Extras on a new project, that way I will learn better.

More test people! pleeease ::)

58fps. not sure its due framerate counter or its cant been full 60fps trought. Im have seen Virtual Images on some devices can been little bit slow, which im avoided to uses them in my games and scaled graphics directly on the Backbuffer.

This is also why Mr Plow choice to set his games to 30fps, which is the right choice if you ask me.

Karma Miwa is designed with 60fps in mind, but still fully playable with around 25fps (if its below, its remove some graphics).

58fps is fine and actually means 60, game will run greatly there.

Change the game to 30fps would work fine too.
But I find that only old devices with less then 1ghz will strugle on the simple things I´m drawing on screen.(the virtual screen being the real hog here)

I will post my results on tests I do around here too.

First img is LG-e400f at:
type     41
x          320
y          240
navbar 0
fps       49

Second img is galaxy note 2 at:
type     25
x          1280
y          720
navbar 0
fps       58

The last snapshot have the wrong orientation issue as well. I'm asume my game did corrected it (except a screen dimmer issue). But it's ok for testing, but should fix that after the release with AE (can help that too).

Don´t worry about the orientation here.
It is supposed to be that way.

The game is to happen on landscape mode and this picture is to show on landscape mode as it does on devices I tested, I rotated the note 2 picture before posting. :good:
In other words, if you hold your phone normally, the test picture must show it sideways with the bottm part of the image to the left, as in the LG.

But is still wrong. Taskbar should have been in bottom, not in the right (just like tab2), you see Karma Miwa fixed it (please check). Can been fixed later, absolutty not important now at all. It's was worse in greedy mouse really in its day (which supports both orientations).

Yep. But it is better for me the nav bar is on the side. That is because of the nature of the game and the design decisions i took. Like i have spare space to the sides. I dont have spare space to the bottom as ia a correct orientation. So it is better for me that the nav bar is at where it is. :D

Karma miwa has an elegant system. If i flip the landscape mode it is working. Game flips accordly. That is really nice.

Here i want to hardcode the game to have the bottom on the left side and bars at bottom as is on the test apk  :P

That why im want letterbox in the game (often top/bottom), like in a movie if should happens.

The code im gave you in PM would not have a issue in correct orientation. Its would been letterboxed top/bottom or left/right (depend on resolution). Im dont mind them at all.  In the pm code im gave you, you can still uses perfect scaling for contain known resolutions and might crop few pixels (only scaling value is required to been set).

If you dont like letterbox, then create a Super Gameboy style border.

Karma Miwa does not check when you turn around your device. This is handled by the Android system automatic (and required in iOS), but did need a orientation fix throught in the boot. Im love "sensorLandscape" (require SDK 2.3+). Its took time to deal with Android many resolutions too with the camera/scrolling system.

Quote from: spacefractal on 2014-May-31
That why im want letterbox in the game (often top/bottom), like in a movie if should happens.
...

Should not be a problem, I designed the game to happen on a 320x240 screen, later I added up to 428x240 so I could have spare to crop and also to fill android resolutions, and also full hd and the likes. What I didn´t want for sure was a black border on the sides.

On my list, there are a few resolutions that go way too close on under 320 (type 24 for example), those would probably be better at letterbox (type 0-5 too), specially since touch devices may take extra sides for control as I don´t want fingers getting on the way of action. But I would like it to look like the game, no gameboy borders or the likes.

Tested the APK on another old device,
an LG-e305:

type     41
x          320
y          240
navbar 0
fps       50

pretty much as the other LG, should get to different phones in a couple days...

Black border on the side would not been a problem either. This is just make sure for better control area instead. So fingers dosent cover over the actions.... It's happens automatic with the code givin.

On the side border some colors could been used, but not if it's a normal letterbox. But that up to you.

Ps. I'm do have seen some iOS game with those borders by design.

Here the galaxy s2:
type     37
x          800
y          480
navbar 0
fps       60

Here a failed one I had the chance to test today.
It is a GT-S5830B fone, at a resolution of 480x320...a resolution not supported by the current hardcoded code.

I don´t get to see this kind of phones going around and people who use it, got it free from operator and only worry for the actual phone ability.
I don´t think I should support it for the current game I´m finishing up (specially as I don´t want to break the pixels too much).

Here a picture of it failing.

So far the rest and tablets are all going ok :)

Mental? Hark0? any news? ::)

Space Fractal sent me an update code with it supporting all resolutions, and a very well done feat.
Maybe this could be a good code to help people starting up android dev? It may be worth a newer thread. :good:

You could do something like this in your androidmanifest.xml:


<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
      package="com.%YOURCOMPANY_LOWERCASE%.%APPNAME%"
      android:installLocation="preferExternal"
      android:versionCode="%GLB_PROJ_VERSION_INT%"
      android:versionName="%GLB_PROJ_VERSION%">
    <uses-sdk android:minSdkVersion="9" android:targetSdkVersion="14" />
<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.VIBRATE" />
<uses-permission android:name="android.permission.BATTERY_STATS" />
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
<uses-permission android:name="android.permission.WAKE_LOCK" />
<supports-screens android:resizeable="false"
  android:smallScreens="false"
  android:normalScreens="true"
  android:largeScreens="true"
  android:anyDensity="true" />
    <application android:label="@string/app_name" android:icon="@drawable/icon" android:debuggable="false">
        <activity android:name="org.libsdl.app.SDLActivity"
android:label="@string/app_name"
android:screenOrientation="portrait"
>
<!-- android:screenOrientation="sensor"  android:configChanges="orientation|keyboardHidden" -->
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>
    </application>
</manifest>


If you upgrade to AE, then you can add android:xlargeScreens=false to the list too. You can then minSdkVersion to "9", even you uses "8" in glbasic. This is so older devices got delisted in the Google Play as well small screen support. Then im pretty sure you would have a greater support, because most problem devices now got delisted (im did the same for Karma Miwa too).

Yep, most likely I have to take the 480x320 and probably the 320x240 resolutions off the game on the Play Store.
I haven´t checked yet what is supposed to be on the manifest neither how to sign up the app.
So this will come handy, thanks Space!

I made a few more tests, all ok so far, here I post an S4 result, but I don´t see much reason to post more, it seems to work fine.
One think though, that got me thinking, Some navigation bar seems to be transparent, or the next round will be, so in some of my repositioning, I don´t have extra image to show on this transparency and there will be a little black part under it. No much a trouble, but something to think about design wise from now on.

Here the galaxy s4:
type     6
x          1920
y          1080
navbar 0
fps       56

The fps there don´t mean much, it does hold the speed in game as tested, it was probably something by the snapshot/screenshot.

As Space already told me, it will be nice to release a code on the snippets that attends to scaling for multiple android outputs (and maybe ios too) so others can enjoy it.
I also thought to release some other parts on my code, like the touch control that reads the last in-press touch for action games.

Give me a little while for that as I have to move again... :rant:

Hi Erico, my And device are 800x400 px resolution...

The first APK (game) works correctly (screen have correct resolution/adapt)...

Today I install this APK... sorry (very very busy)  :-[

im have posted the scaling code im gave Erico, which also readed the mousepos etc. Its posted here:
http://www.glbasic.com/forum/index.php?topic=9848.msg85853#msg85853

Thanks HArk0, all seems just fine!

Good thing Space, I may add a few things there to try and get the virtual screen away from it.
But it is good it is available because as soon as someone gets an android compilation going, the next step is to deal the screen size.

I hope it helps users around.

Quote from: erico on 2014-Jun-04
Thanks HArk0, all seems just fine!

Good thing Space, I may add a few things there to try and get the virtual screen away from it.
But it is good it is available because as soon as someone gets an android compilation going, the next step is to deal the screen size.

I hope it helps users around.

I send to you a photos of my android device:

Alcatel Onetouch 992D:

- Type: 37
- GetScreen X: 800
- GetScreen Y: 480
- Nav Bar Size: 0
- FPS: 60

yep thanks, here the pic, looks fine

I occurred  to me I never set this thread to an end.
So forth, all the many more tested device I got hand into did ok, so I guess I´m good for now till the highest resolution support, which should be a couple years....till they push 4k into mobiles :D :D

Thank you all for taking the time to help on this front. :good:

Hi, I have new mobile phone Android... are a Orange Gova (huawei ascend g6 maybe)...

Have a 540x960 px... quad core... os 4.3... rooted  =D

If you have a new apk for test... I can install on phone!

Kitkat can play in fullscreen, but only in the next update of AE.

im got a new device recently with a resoulution of 1024x600.

Hi Erico

I have nexus 7 II
1920 x 1200
if you would like me to test on it.

G

Thanks for the offers guys, but it is not needed anymore.

I was worried about the 2560x1600 resolution tablets as I can´t simulate that on my windows and never came about one.
But I tested on a huge monitor and it works fine too.

If anyone wants to use the routine, best use the updated version by Spacefractal at this thread:
http://www.glbasic.com/forum/index.php?topic=9848.0

It works with any resolution and also auto position touch regions.