Whats your solution to running your app on these situation ?
Will you scale your gfx ?
Is it possible to eunumerate the supportet screen resolutions on a mobile devices for the use of setscreen ?
If you write an app with maybe 800x600 setting in project /option but the device will have only 640x480 or maybe 1024x768 or something bigger (ipad3) , so how to detect this ?
Setup the res in project options to 9998x9999 (or 9999x9998 depending on orientation) and then handle all the resizing code yourself. If you look in the code snippets forum I wrote some code a while back to resize a load of images (inc. alpha channel) and then use them at any resolution. Ampos has also posted code to resize the whole screen (a fair bit slower and uses more memory but much easier to code for especially if you have a project already finished or almost finished and want a quick fix especially if it's not a fast updating type of game), and is now (I believe) working on new routines for resizing on the fly with things like rotation, zoom, and print support.
Cheers
Quote from: Marmor on 2012-Jan-10
If you write an app with maybe 800x600 setting in project /option but the device will have only 640x480 or maybe 1024x768 or something bigger (ipad3) , so how to detect this ?
Setting the project resolution to max (e.g. 9999x9998) like Crivens suggested then detecting the actual resolution the app starts in with GETDESKTOPSIZE should work well enough.
If you compile for Android you'll need to set
android:anyDensity="true" in the <supports-screens> element. Setting this to false causes some devices to try to resize your screen to fit while others won't. That creates problems so to make sure you start in the native resolution of the device make sure anyDensity is always true.
Since scaling is GPU intensive there will inevitably be some devices that can't keep up 100%. Because of this adding frame-skipping to your main loop is kind of vital.
Thx a lot !
Getdesktopsize and some scaling ,include the 9998,9999 thingy will work if you will play with the standardscreensize ok .
Also understand the anydensity :true on Android .
But whats the solution to change resolution ?
If i remember right ,so the using of Setscreen isnt safe on some Devices .
Quote from: Ocean on 2012-Jan-10
do EVERYTHING in 3D and gone are your scaling issues :nana:
That's a good point. Rather than drawing to the screen, 2D could be drawn to a "camera" view, where the origin is in the center.
QuoteBut whats the solution to change resolution ?
You can't on a mobile device. You either use the project settings resolution or use the 9998x9999 trick to get it to use it's max resolution and then use scaling code accordingly.
Quotedo EVERYTHING in 3D and gone are your scaling issues
Yep. My current WIP is Pseudo2D (ie. looks 2D but is actually 3D). Only thing is that the menu system isn't and uses my scaling code. I would like it all in 3D as all scaling issues go away but I can't get Gernot's 3DES static object code (for the menus) to work in my project (haven't tried latest version mind), and I'm too near completion (ie. beyond caring any more) to change it at this point.
Cheers
I do direct scaling using poly vector and I have 3 texture sizes to draw tiles from. I don't use offscreen buffer since its was too slow (I use intens use of tiles, so it's was not possible). I just use desktop size to detect resolution, like other posts due.
But for font and icons I only use one size, so they might up scaling in some resolutions, but still look nice. But only use few of them.
This was a compromise for size and still look very clear, so we diddent need to use 3 sizes for anything.
But don't do low resolutions (like 480x320) and upscaling to tables. it's look too blocky (except by design). Yes I did little up scaling too (but limited that), but only none in game graphics.
Ps. For speed I use 25fps on android (with 3 graphics details), and 30fps on iOS (4s and iPad2 got 50fps). So make sure to support various framerate (mine is a tile puzzler, so 25fps still fell nice).
With the main use of 3D for pseudo 2D I'm now getting 60FPS on a iPod4 (not S) at full retina. Good stuff is 3D...
QuoteBut for font and icons I only use one size, so they might up scaling in some resolutions, but still look nice. But only use few of them
Most of my text I have drawn the words then used them as rescaled sprites (including scores). However where I need dynamic text (my shop function for example) then I used a routine where it uses createscreen for only the width and height of the text I want to use and I work out all text on the first loop so I'm not doing this every showscreen loop. Then I resize the createscreen sprites for scaling purposes. Works pretty well.
Cheers
Crivens, it surprises me that pseudo 2D could be faster than POLYVECTOR 2D. Interesting. Might have to look into that.
spacefractal, limiting the FPS by a set amount works OK but wouldn't frame-skipping be better? That way you know your games will scale up the FPS for faster devices while maintaining an overall game speed that is the same on all devices.
I limit by limitfps, and off course I have frameSkipping too, i just wanted to do stable constant framerate, so frameskipping is rare. Elsewise I would get too much varied fps on many levels, depend on content (tiles count from from 150 to around 900 onscreen).
Gameplay speed is same, fell same and just multiplied in update() for each regular paint(), except frameskipping.
Would it be cool to have a global offset/scale setting?
That way one could scale all 2D operations (OpenGL/ES only) with no performance impact.
Quote from: Kitty Hello on 2012-Jan-12
Would it be cool to have a global offset/scale setting?
That way one could scale all 2D operations (OpenGL/ES only) with no performance impact.
YES PLEASE! =D :good: :booze: :enc:
I "think" it's possible with glTranslatef and glScalef right after a showscreen.
Can someone test this?
resizable GLB-Screen :)
setscale
getscale
setblend
getblend
:D :D :D
That's pretty much what I do anyway. All my graphics are rescaled at app startup (only the once though unless you update the graphics version) and then I base all calculations on the target resolution (eg. Retina). When I want to put something on the screen I just multiply by the scale calcs, and for the mouse I divide. Seems to work.
Personally though even though I used 3D to simulate a 2D environment for the game I'm going to do the lot in 3D (even menu) next time (assuming Gernots new 3DES 2D code works now) so no mucking around and the only downside is memory (graphics won't be scaled).
Cheers
Well my game is 3D so it doesn't look any different just more of the play area is shown on an iPad. My menus which are scaled do look fatter but not to a level that I'm that bothered right now (just want to finish the damn thing). Wouldn't be too hard to take the aspect ratio into account though.
Cheers
I second the 'SETSCALE' command!
Imagine, no matter the physical resolution of the device, if you did a 'SETSCALE 1.0, 1.0' (or 'SETSCALE 480.0, 320.0'), then all other references would then be relative to this scale.
The top/left corner would be (0,0), the center of the screen would be (0.5, 0.5), and bottom/right would be (1.0,1.0)
(Or whatever scale you specified).
But, to make it perfect, you would need a 'scale' command for each sprite (it would mimic something like 'STRETCHSPRITE').
Why? A 48x48 sprite would look different on different sized screens.
So in the above scale (1.0, 1.0), you would set the scale for that sprite using something like:
SCALESPRITE sprite_id, 0.1, 0.1
That would mean whenever you draw that sprite, scale it to 1/10th of the screen for both the x and y.
This could be handled in the 'LOADSPRITE' command too with additional optional parameters.
Then, to draw that sprite at the bottom right of the screen, you would use:
LOCAL screen_width# = 1.0, screen_height# = 1.0
LOCAL sprite_width# = 0.1, sprite_height# = 0.1
SETSCALE screen_width, screen_height
SCALESPRITE sprite_id, sprite_width, sprite_height
DRAWSPRITE sprite_id, screen_width - sprite_width, screen_height - sprite_height
I guess you could do the above fairly easily on your own, using your own ratios etc. (And STRETCHSPRITE or POLYVECTORS for the sprite displaying)
But it may make it easier for beginners to implement a resolution independent game.
Now, regarding aspect ratios . . . this would stretch or compress your graphics if the device has a different aspect ratio than what you expected. The easiest way, do nothing and accept it.
Or have a new command 'GETASPECTRATIO' that returns a float (3/2, 16/9) etc, then multiply your screen scale 'y' value above to this ratio. So your new screen ratio may be (1.0, 1.2). But then relative positioning is more difficult as before you could just use '1.0' for the bottom edge, so you can't hard code that value in your positioning code. Or, also allow a percentage value when positioning such as: DRAWSPRITE id, 90%, 90%.
No clear obvious method I guess.
should that setscale also affect the viewport calls?
Gernot, since we are on the subject, have you given any more thought to the idea of allowing project settings to have an exclude list? If you remember we talked about using the 9998x9999 trick to get the max resolution to allow universal apps, but the iPhone/iPod4 might not be quite upto the task for Retina gameplay while the 4S is fine (and non-retina is great for everything).
Essentially it would just be an option in the iOS project settings really. Essentially if using 9998x9999 (or 9999x99998 - although a max portrait/landscape option might be nicer) then have an exclude list you could add to that have different resolutions. So in my example I would set iPhone4 and iPod4 to have a set resolution of 320x480 and everything else would be maxed. So then the 4S would be 640x960 and the iPad would get it's max resolution (although can include them too if for example iPad1 hasn't got enough power so use lower resolution) but anything else would get 320x480. Can't see it being too hard to implement no?
I take it that the idea of changing resolution any time you want (so menus can be high res on iPhone4 but then the game itself switches to low res and we can work out ourselves if device can handle it (4S stays high res all the time)) is a complete no-no still? I know you completely rejected it before but now you are looking at all these scaling changes perhaps it would easier to implement.
Cheers