Another newbie question: what is your advice for a common/usual GLBasic process to program for different Android screen sizes?
Do you, for example, program for the largest screen size, and then use a command in GLBasic to scale it down? Is there such a command?
Or do you simply have to do everything manually yourself, based on the GETSCREENSIZE command? I've seen erico's useful thread on "mobile screen size database" available and that will be really helpful if one has to do everything manually. :(
Thanks!
My advice is that it depends on the king of project you are doing.
In my case, a single screen action game with big sprites and scenario images, I´m using the most common resolutions out there and scale/accomodate it out myself in code.
It may run on other phones/tablets by using a simple scale routine+getscreensize command (with distorted pixels in this case), but I´m not sure I will take the time to implement this.
Search for SCREEN SIZE on the forum, and you will find a few good solutions and a few universal screen size snipets too.
I work at a standard size that fits on my monitor and use it as the basis for everything. My engine has universal scaling variables that are determined at the beginning of the program and those are used in every function that requires it to compensate for everything. Thought I've found it might be best to use the smallest resolution as scaling gets really weird for tiling when you have to deal with upward and downward scaling.
Also using these values, the code should determine an affix for the end of file names ("_2x", or "_4x", or "_0_5x") in the event that you need differing resolution images for larger screens, or smaller ones. Smaller/slower android devices might have trouble running the largest resolution image, so it's better to have multiple sizes. This is the same practice as used in Corona and pretty much everything else, I find, unless you want to use oldschool pixelated graphics.
I've posted a framework that will allow you to use a fixed resolution for development (screen viewing) base resolution (for graphics to be drawn at) and then automatically scales for each device. You can find it here (http://www.glbasic.com/forum/index.php?topic=9239.0).
It's fairly small and is a good basis for a scaleable game, fixed update rate and variable draw rate logic to ensure game speed is the same on all devices also, and there's a few button routines in there to make menus easier too. Hope you like it and find it helps.
Thanks guys for your helpful advice!
Marcus, your framework looks useful, but there are so many functions that it will take me a while to understand what each does and how to apply them all! :)
You may also check out ampos' z_project:
http://www.glbasic.com/forum/index.php?topic=7145.0
There might be some issues with printing, but other than that it works pretty well. It uses the same principle as spicypixel's framework. I've been using it in my code and it works great.
Thanks for the link, r0ber7 - will check this out too.
I wonder whether GLBasic would consider standardising the process at some stage...
If you've been using Corona's system, you might appreciate trying to reproduce it. Kinda weird to wrap your head around without getting really familiar with Corona, and a lot of groundwork going into it before actually seeing it work (or not work but do something hahaha).
You could start by creating an entity type for the display(s) -- it's good to have multiple layers, which themselves hold an entity type array for objects, which hold information for object type (sprite/image/text), sprite index, size, file path, original scale, new scale, x,y,z, mirror mode etc... and have the main loop automatically cycle through these (resort them in z if there was a modification to that at any point) and draw them every frame. Also it's nice to have a var hold the 1:1 original values.
The scale is taken into consideration in the function that creates the object entity, assigns sprite id, and inserts them into a layer.
Quote from: SFguy on 2013-Jun-09
I wonder whether GLBasic would consider standardising the process at some stage...
What Finnk said comes into play on this subject (I would love a layer system and all that you stated :good:).
I currently made my own, but too hardcoded for this one specific project, it is not a fit all solution, but it sure is helping me to figure out one.
I would be nice to have an easy way of handling all that already inside GLB, but on the other hand, by not having it, you can do one as it pleases you or better suit your project. I´m in favor for a standard in-glb solution and the ability to freely do your own.
There are snipets for this all around, but they are currently quite hard for me to understand.
Thanks for the advice fiink. I haven't used Corona enough to know exactly how it is implemented there. Looks like I should huh? :doubt: The difference is that Corona was specifically designed for mobile programming I guess.
QuoteThere are snipets for this all around, but they are currently quite hard for me to understand.
True! :) Perhaps someone will explain these concepts clearly to the newbie programmers here like me!
If you are thinking of a system for doing as much as possible for you, then you might be interesting in my TSetup system (http://www.glbasic.com/forum/index.php?topic=9207.0). Whilst currently there is only a small(ish) BASIC interface part, if enough people are interested I can certainly make all the rest of the stuff available, along with some example programs.
The system is designed to allow access to sprites, music, standard fonts by a name (#font1 for example) or by index. It is also designed to handle all reloading on screen resolution change.
Yes, I would certainly be interested in a set-up that allows me to just write my game without having to deal with optimizing it for different screen sizes as well. :nw:
Quote from: SFguy on 2013-Jun-09
Thanks for the advice fiink. I haven't used Corona enough to know exactly how it is implemented there. Looks like I should huh? :doubt: The difference is that Corona was specifically designed for mobile programming I guess.
Corona itself only builds for mobile, but the inner workings are pretty solid for anything. I'll maybe put up a video briefly showing the framework later and how it handles objects.
I learned a lot from using Corona and I really can't think of a better way to manage objects in a 2D game (but laying that out took a lot of blind work in GLBasic as I couldn't really test it at all until everything was in place). I also added a lot of things I've learned from the forum, and overhauled nearly everything after some major mistakes I made attempting to use my original first version for Ludum Dare 25.
Thanks, finnk. Perhaps I should indeed take a break from programming in GLBasic, and try out Corona first, to learn how they implement different screen sizes. I'm looking to program for mobile phones/tablets, so am looking for a cross-platform language that allows me to do this with the minimum of fuss. I assume many new purchasers of GLBasic will be looking to do the same. I liked the ease of Basic so was attracted to GLBasic, but if Corona is easier for mobile, I might move to using Corona for 2D, and keep GLBasic for 3D programming. Why didn't you continue using Corona, finnk?
It won't really tell you anything about implementing different screen sizes. It has a line to activate the autoscaling, and some config options that sets up stretching types (letterbox, fill, prefix/affix for different file resolution). The rest is handled by Corona's internals so it just works, but you won't really know how.
But in general seeing how it creates sprites, display layers, transitions and tweens, click, collision, and how nicely they're integrated, you get an idea of how to set up your whole engine so that everything is extremely well integrated and self managing. Scaling is something you just have to build into these functions but once you got it done, it's off your mind forever (once you get it bug free).
I use Unity for 3D, GLBasic for 2D. Unity is free for mobile publishing now and in terms of 3D there are several pros about it that I could not do without (skeletal animation/physics/collision/scriptable components/shaders) for 3D games. I've grown accustomed to both of them. Also was able to download scripts for Morph Targets which I'd never be able to figure out on my own. The math is beyond me.
I stopped using Corona because it didn't support Z-sorting (only x and y, and layers that are really inconvenient to move objects between), it only published for mobiles, and several other customizations that are only possible if you build all the functions yourself. It was good to learn with though and very feasible for people who just want to make mobile games. But I feel a lot more accomplished making my own framework too.
Thanks for the elaboration, finnk. I know nothing about z-sorting! I assume it is available in GLBasic while it is not in Corona, which is why you moved to GLBasic... I will take a closer look at Corona.
Im does my own scaling rutine using either sprite scaling or polyvectors. I'm diddent like offscreen scaling, due it's did slow down by half.
So you might need your own implementation.
In greedy mouse I'm used 3 size of textures to choice from and downscaling. Only some icons did I'm choice to upscale as well.
In Karma Miwa, I'm use 960-640 to around 1388x768 as base resoulution, and up or downscaling it. Backgrounds can use retina and its might scroll up/down as well....
So it's depend on project doing.
SFguy
I had these issues my self dealing with different scale my solution works fine resizing sprites but it uses more memory. Depending on how many sprites you have to import you may have to scale the images outside GLB and have an app for each resolution.
- I start by making all the images/sprites for retina display resolution (1536 x 2048)
- Get the screen size
GETSCREENSIZE screenW, screenH- Calculate the image index coordinates
FUNCTION getimgIDX:
GLOBAL Widx = 1536/screenW
GLOBAL Hidx = 2048/screenH
IF Widx < Hidx THEN Widx = Hidx
ENDFUNCTION- Load the images. (Here is were some devices with less memory have a problem, for instance iPod / iPhone 3rd Generation)
FUNCTION loadImages:
LOADSPRITE "Media/images/paddle.png",0 // paddle
LOADSPRITE "Media/images/ball.png",1 // ball
ENDFUNCTION
[/i]Now Resize the images
FUNCTION resizeIMG:
// Resize the Brick, Paddle and Ball
GETSPRITESIZE 0, PADDLEW, PADDLEH // Paddle
GETSPRITESIZE 1, BALLW, BALLH // Ball
PADDLEW= INTEGER (PADDLEW/Widx) // resize Width
PADDLEH= INTEGER (PADDLEH/Hidx) //resize Height
BALLW= INTEGER (BALLW/Widx) // resize Width
BALLH= BALLW // resize // this is for round shapes to keep the aspect ratio!
ENDFUNCTION
[/i]Now in your draw function use the SPRITE RESIZE[/li][/list]
STRETCHSPRITE 0,paddle_x,paddle_y,PADDLEW, PADDLEHIt would be nice if GLB had a command that allowed resizing the sprites to be resized at load time, this way it would save memoryFor instance something like this:
LOADSPRITE bmp$, num%, width%, height%
Yes, would be nice - plus of course, resizing during plotting does consume a bit of time...
In my case, I guess I´m using one of the offscreen solutions mentioned, it does with a few SETSCREEN / USESCREEN / ZOOMSPRITE commands.
It is quite easy to implement and you will get you app scaled to whatever device.
1- The problem here is that you distort pixels (ye, the aspect ratio) when full screen (using all device´s pixels).
2- It is easy to implement black borders and then keep the pixel ratio square, but....gah black borders?.
Both problems suck. But my game goes fine with the first option. Keep in mind that it is a single screen pixel art action game, no tiles (something on the lines of arkanoid).
You will have these kind of problems on any programming language, real problem is too many different screens with different aspect ratio on android. If the programming language resolves them automatically, then it must be using one of the 2 solutions.
Those 2 are quite easy to do on GLB, check the manual for those 3 command´s definition I stated up there, together with GETSCREENSIZE and you should be done.
...
Couple days ago, I decided to revamp my scaling solution to fit the more important android resolutions out there, no black borders and with square pixels.
Core game so far was in 320x240.
I spent a day studying that table of android screen sizes I posted somewhere and came to some solution:
Core game will have to be 428 x 240, some devices will use 400x240 and the caanoo will use 320x240.
The extra pixels on the androids will also host the game on screen controls.
On the 320x240, the players are allowed a bit off screen just enough to cover the extended 428 res.
PLayers have to collect falling stuff, and whenever it falls off screen on whichever device´s resolution, it does not score so to keep it a bit fair.
Here is a non sense table I did to figure that out:
--------Xp------SCREEN SIZE-------------Xi------VERTICAL SIZE
|
CAANOO--320 x 240------------ x1 320 240
ANDROID----------------------
0--1920 x 1080---6.8% x4 480 270 x4.5 428 240
1--1280 x 720---20.8% x3 428 240 x3 428 240
2---960 x 540----4.1% x2 480 270 x2.25 428 240
3---800 x 480---14.3% x2 400 240 x2 400 240
4--1280 x 768----6.8% x3 428 256 x3.2 400 240
5--1280 x 800----3.2% x4 480 200 x3.2 400 242
6---854 x 480----1.6% x2 428 240 x2 428 240
-----------------------------
TOTAL ANDROID MKT 57.6%
-----------------------------
PANDORA-800 x 600------------ x2.5 320 240
Here is a screen shot of the game considering those 2 new resolutions, I´m currently redesigning to accommodate stuff.
So, like I said, you will have no problem doing your own scaling inside GLB and doing so will help teach you how you can optimize it for your game type.
Thanks, everyone, for showing me some solutions on how you manage the issue of screen size. Looks like there is no one-size-fits-all standard solution.
aroldo, thanks a lot for your detailed explanation - this helps!
erico, your screenshot looks beautiful! :) If you design for a core game size of 320 x 240, and need to scale up for much higher resolution screens (e.g., tablets), won't the game look chunky? Why not design for 1280 x 720 (20.8% of the Android phones, according to your table), and then scale down if necessary?
It is supposed to be a game on the oldschool´s looks, like an amiga AGA game.
I love 320x240, and pure pixel art style. No transparencies, no pixel blending, no smoothshading. No rotation. Just pure blocks.
Yep I´m up scalling stuff with the Xi value and then moving a pixel up or down, left or right to accommodate details.
While I can keep the Xi value close to integer, it will scale better. I might have to check on android #2 (960x540) though...
If I design for 1280x720, on those DPI, it won´t look like old school pixel art, and if I downscale it to 320x240 for the caanoo, art will be destroyed.
So the only reason here for the upscale is to preserve the art style.
I currently looks nice on a galaxy note II at 1280x720.
It may look a bit blocky on a bigger tablet, but then all havoc is set loose in game and players may not bother ::)
Hence why I told you that each game type can benefit from a different solution.
EDIT: Another thing, is that everything is moving internaly on the 320x240 resolution, and the movement scales fine too. If I design for 1280 and objects are capable of moving a single pixel...when I get to 320x240, I will have to deal with the speed and probably subpixels movement. Could bring a lot of trouble since I want the game to flow exactly the same on all different devices. Again, for example, if you are doing a tiled chess board game or a rogue like, you may not have this problem at all.
Extra bla bla... :-[
In my opinion, I take the screen size and DPI not as a problem on the dev tool (be it GLB, corona, etc) but a problem of the game design nature. Specially the UI.
I´m not sure how corona or other tools handle that, but the cheapest way is by free scaling things.
You can get that done in GLB quite easily:
GETSCREENSIZE and then SETSCREEN 0 for your phone resolution.
CREATESCREEN 1 on your core game resolution and set it to draw on sprite 200 and USESCREEN 1 to deal the game.
Before SHOWSCREEN, you USESCREEN -1 and ZOOMSPRITE 200 to the % and position that will fit better on the device resolution.
So this may scale to everything but with distortion. You can work this out a bit to get perfect scaling + black borders too, but I dislike black borders.
Best is to adapt this to your game needs and adapt your game to the nature of it.
I guess this is what friends around here stated as off-screen rendering, since the game is actually happening not on the main screen.
It is said to be slow, but fits my game type, it is going 60fps fine.
Thanks, erico. Makes sense.
Looks like there is no escaping the need to program in customization of the screen display and game format for mobile phones with different sizes. So long as the resizing of sprites can happen outside the game loop, and not slow the game down, I'm fine.
Quote from: aroldo on 2013-Jun-10It would be nice if GLB had a command that allowed resizing the sprites to be resized at load time, this way it would save memory
For instance something like this:
LOADSPRITE bmp$, num%, width%, height%
Its very easy to implement this on your own, at least as long as grabsprite or usescreen are working. Just load your sprite in old size, draw it scaled, create new sprite from this with usescreen/grabscreen, unload original sprite -> use scaled sprite in your game. Once you created a function for this, you can use it for every sprite you want. But wit Mem2sprite it even would be possible to do this without grabsprite or usescreen, but may be slow (and using RAM instead of VRAM).
Quote from: kanonet on 2013-Jun-10
Its very easy to implement this on your own, at least as long as grabsprite or usescreen are working.
But GRABSPRITE only works in iPhone in Portrait mode? I wonder why. Pity there are no universal solutions! :(
But you still can use landscape mode for GRABSPRITE. Or use USESCREEN. Or use MEM2SPRITE. So its still to possible to scale all your sprites at app start. So no resizing at runtime at all.
Btw. can you write to your app's folder? so you could resize your sprites on 1st launch, save them (and maybe delete original ones to save space) and only load the resized ones on later starts.
Interesting - thanks for all the input, guys. :)
Kanonet's idea is something I'll remember myself, it'd save a lot of time.
SPRITE2MEM & MEM2SPRITE are very useful once you understand how to handle the data. Right now I use it to detect the edges in the tileset I use for landscaping a level. In the case of scaling your sprites, you could even add graphics effects like a simple blur during the data handling after SPRITE2MEM... Assuming you have the algorithm. Maybe one day I'll make one. :P