Newbie question - scale for Android phones/tablets

[SFguy]

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!

[erico]

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.

[finnk]

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.

[spicypixel]

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.

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.

[SFguy]

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! 

[r0ber7]

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.

[SFguy]

Thanks for the link, r0ber7 - will check this out too.

I wonder whether GLBasic would consider standardising the process at some stage...

[finnk]

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.

[erico]

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 ).
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.

[SFguy]

Thanks for the advice fiink. I haven't used Corona enough to know exactly how it is implemented there. Looks like I should huh?  The difference is that Corona was specifically designed for mobile programming I guess.

[SFguy]

There 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!

[MrTAToad]

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.

[SFguy]

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. 

[finnk]

Thanks for the advice fiink. I haven't used Corona enough to know exactly how it is implemented there. Looks like I should huh?  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.

[SFguy]

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?