Universal Build (Flexible Aspect Ratio) Stretch Trick -- With Video and Template!

pHghost

Oooh! I'm so excited!

UPDATE: Video and description below!

With the release of new iPhones, and thus new screen sizes, the questions have cropped up again about what is the best way to design universal build apps. The answer for most is starting with an iPad build and then using either stretch (which fudges up your graphics), or overscan (which means you will permanently lose access to parts of the scene due to crop, depending on the secondary aspect ratio). Also, the slight problem is design. If you are using pixel-perfect graphics, both of these will mess you up, since they will down-scale the assets and there is absolutely no guarantee they will stay nice and crisp.

Well, turns out there is a solution. It isn't suitable for all games, but will work for a big majority. Pretty much, if your scene is bigger than your camera, it will work, if they are the same size, it won't (for such games you need to figure out the whole effect on gameplay with changing aspect ratio).

Using this method, you will have no distortion of graphics, and will not be limited by crop factor.

furthergame

there is a new tutorial that can help you. I watched it and it awesome

http://forums.gamesalad.com/discussion/72589/universal-builds-for-ios-and-android-and-anything-else-using-ipad-build-and-stretch-no-distortion#latest

pHghost

Ah, interesting -- I see @BBEnk‌ has discovered the same principle: namely using stretch in such a way to have no distortion. Well done!

That said (though I just flew through his video, so I might be wrong), I think I might have a slightly simpler solution, he is setting up a few attributes to get it done, whereas what I experimented with, you need 0.

colander

@pHghost I have booked marked the thread. Can't wait to see it, I love this stuff .

Thunder_Child

@pHghost‌

Excellent news. Can't wait to see your info. Thanks.

pHghost

Video is here! Written description to follow soon!

pHghost

Hello everyone, hope you enjoyed the video if you've seen it (I recommend watching it, as it demonstrates the possibilities).

Here is a description of what is going on and why it works. Before I do that, I would like to call out @BBEnk‌, who has also discovered the possibility of using stretch while maintaining correct shapes, and has been using the principle in his game Steam Jack, as @furthergame‌ pointed out with his link to BBEnk's thread.

I have not examined BBEnk's method in detail, but from a brief look I noticed he uses a couple attributes you need to set up to make his method work, whereas in what I played with there is no need for that -- thus my decision to present this as another solution.

Onwards:

The discovery revolves around the fact that Stretch works differently than either Overscan and Letterbox. Both of these take their primary setting from the way the project is set up. So you are locked into one specific aspect ratio, no matter how you set up the scene camera, and those display methods just adapt to that AR. Stretch, on the other hand, stretches into the device screen whatever you see in the scene camera. It really is that simple. All you need is an actor with all the device measurements, place it in every scene you have which has a scrollable map, make sure the scene is big enough to support the device resolution and you are ready to go.

There are two things you can do with this:

You can either add a scaler (ideally for the scene camera), which will maintain the same view on all devices. That will scale your graphics, so you need to make sure you have the right resolution images. In this way, no matter what the device, you will see a roughly similar view, with actors taking up the same percentage of the screen. So, if you have a tile-based game and you see 8x12 tiles, the scaler will make sure you see roughly 8x12 tiles on all devices (limited by their actual screen aspect ratio, but you will be able to pan around).

or:

You can also roll without a scaler, which means that the larger the display, the more of the scene you will see. So if you see 8x12 tiles of your map on iPhone Legacy, you will be able to see about 18x24 tiles on an iPad. The bigger the window, the wider the view. The beauty of this is that since you aren't scaling any of the graphics, this is the ideal way to work with pixel-perfect games (8-bit style etc.). Your 64x64 tile will show up perfectly as 64x64 pixels on all iPhones, including 4s, 5, 5s, 6, 6+, all the iPads, Android phones and tablets, Tizen devices, computer screens etc., and so will your full map (you might want to scale to 1/2 size for non-retina devices, if you are targeting any).

Well, that's it, folks. It's quite simple really, but slightly hidden since there is a small logical leap to make.

In any case, I'll be uploading the project you see in the video, after editing it so that everything has clear descriptions of what is going on.

Enjoy!

pHghost

Tada! The template is ready for consumption! Enjoy it!

So far it is just a demonstration template, so it doesn't include all device settings, but feel free to use and edit it to your needs.

A full-featured template (1.0, based on an iPad project) will follow at some point in the future.

BBEnk

The way your doing it, is the way I used to do it which works but you have to put in the screen you wish to detect. mine auto detect size and adjust camera with a little math for any size device which is why I use attributes. So once you build your game it works with any size screen.

pHghost

This method also detects screen sizes and automatically adjusts. What exactly do you need the attributes for?

BBEnk

@pHghost said:
This method also detects screen sizes and automatically adjusts. What exactly do you need the attributes for?

Right, but yours is only detecting size you enter iP4 and iP5 right. So if I select iP6 it no longer works. but you can add those sizes. In mine you don't need too thats why I use attributes everything is automated.

pHghost

@BBEnk‌ -- that's only because a couple things need to still be implemented. Version 0.8 was a little brute-force, only to show what is possible. Here's version 0.9, where you can switch to absolutely any device you wish, and it works, calculated by GS, without the need to set up any attributes to do it.

The only problem with version 0.9, and with your implementation as well, is that they both scale the graphics to achieve this. That is a huge problem if you work with pixel perfect graphics which cannot be scaled if you want them to stay sharp. Which is why I am working on building 1.0 with two possibilities -- scaled and unscaled. So, as I wrote in my explanation, a 64x64 actor will show up as 64x64 on every device, without scaling.

pHghost

For everyone else, I recommend sticking with 0.8 for now, 0.9 is just to make a point that it can scale automatically without any attributes.

It's actually an interesting question whether to brute-force the resolutions, or have GS figure them out. The downside of brute-force is that it only supports resolutions you code in, but at the same time, it gives you a lot more manual control over things. Letting GS do the work means you don't have to add devices to the list if a new gadget comes out.

I think it might depend a lot on the type of game you are making, as every project will have slightly different needs.

pHghost

Here is a mid-version, 0.95, which combines GS calculating the screen sizes, but at the same time it does not scale your graphics. Make sure you create the scene big enough if you are building for iPad.

BBEnk

@pHghost said:
For everyone else, I recommend sticking with 0.8 for now, 0.9 is just to make a point that it can scale automatically without any attributes.

It's actually an interesting question whether to brute-force the resolutions, or have GS figure them out. The downside of brute-force is that it only supports resolutions you code in, but at the same time, it gives you a lot more manual control over things. Letting GS do the work means you don't have to add devices to the list if a new gadget comes out.

I think it might depend a lot on the type of game you are making, as every project will have slightly different needs.

Thats better but it's still just minus 1 attribute,lol. either way this make making games a whole lot easier I been doing it for awhile, sort of figured others did too.

pHghost

@BBEnk‌

So you use only one custom attribute? I though it was more.

In any case, the benefit of not using any attributes is that is it drag-and-drop.

If you take the rule from the unlocked camera control actor in 0.95 and paste it into any actor in a scene you have, it works on the spot, no setting up, nothing.

I just tried it in @DeepBlueApps‌' DragAround (http://www.deepblueapps.com/drag-around) and the only thing I needed to edit was their template (because of how they have their buffer zones set), the camera control didn't need any changes and it just worked.

I challenge you to do the same with yours. I mean that as a friendly challenge, test it out to see. The point is, if you are building a game from the ground up, then both methods work well. But if you need to adapt an existing app, since you cannot drag-and-drop attributes, you method will mean a lot of setting up, so you will end up spending more time on annoying manual adjustments.

BBEnk

Yea I only use one attribute for changing camera Size, I don't have too, I just do. The other attributes are used for getting actors into positions and or unique scenes.

and mine is nothing more then drag and drop the same as yours I only set things up on 1st scene after that one rule for camera.

I made a template check it out.

pHghost

Cool, checked it out, I understand now -- before I was slightly confused because your video was not narrated.

I think you method might unnecessarily be a bit complicated, but hey, it works, and that is all that matters in the end. Good work figuring this out, I think you were definitely the first one to start using this in practice:

@BBEnk said:
either way this make making games a whole lot easier I been doing it for awhile, sort of figured others did too.

Yeah, they probably weren't.

BBEnk

@pHghost said:

Cool, checked it out, I understand now -- before I was slightly confused because your video was not narrated.

I think you method might unnecessarily be a bit complicated, but hey, it works, and that is all that matters in the end. Good work figuring this out, I think you were definitely the first one to start using this in practice:

It might seem complicated but my game has a lot of rules and actors by having attributes it makes tracking down which actors have those attributes a lot easier, just by simply clicking on them and hitting the minus sign. thats why I use attributes and theres no performance hit.

Yeah, they probably weren't.

No there are others who do this I've seen it mentioned on the forums before.

P.S.
What do you mean by scaling your graphics because don't both version just change camera size and not the graphics?

BBEnk

Ok I see what .95 is doing it's increasing camera size to the right and up to scale but without testing on device seems this would make things look way zoomed out, but weird thing is doesn't work when you select iPhone5, it uses IPhone4 size I think theres a bug in GS.

pHghost

@BBEnk said:
Ok I see what .95 is doing it's increasing camera size to the right and up to scale but without testing on device seems this would make things look way zoomed out

Not so. Because you are showing the graphics at their actual pixel dimensions, you know exactly what size they are going to be -- you just need to know the pixel density of the target device. This actually gives you very precise control over how to show your graphics. But it isn't ideal for every type of game.

@BBEnk said:
but weird thing is doesn't work when you select iPhone5, it uses iPhone4 size I think theres a bug in GS.

Strange, what version of GS are you using? It works perfectly for me.

colander

@pHghost I thought I had better post here and not in @BBEnk thread. I have had a look at 0.95 and will wait for 1.0 before making any comments. If you feel like going a bit further put a HUD layer in to see how it handles it.

pHghost

Attached, find version 1.0 of the template!

Enjoy and comment!

pHghost

@colander have you had a chance to test it out?

colander

@pHghost had a quick look but it could be some time before I get spare time to have a really good look at it just too busy right now.

pHghost

No problem.

pHghost

Here is a script specifically tailored for converting iPhone 5 projects to work as Universal apps. Simply copy the rules and select whether you are using Landscape or Portrait.

If you are starting a new project, check out the Universal Build Trick!

colander

@pHghost found a few minutes to play with "iPhone_5_to_universal" and made a few small changes to the code to make it a one size fits all resolutions in landscape or portrait. I made it in iPad portrait but it can be made in any of the other project resolutions. I haven't fully tested it so it may not be 100% right check it out and see what you think.

To evaluate your UB method I would need to see background and HUD in the same project so I can see what happens to the actors like @BBEnk did in his. I would think it is the same thing done differently with the same pros and cons.

pHghost

@colander‌ -- The Universal method starts with iPad. The reason I made a version specifically for iPhone 5 was because I found it practical in converting my own iPhone 5 projects.

The Universal App method is much better documented and also offers several options of processing to choose from. When not converting specifically iPhone 5 to Universal, I would suggest everyone use 1.0 of the method, instead of adapting the iPhone 5 sub-version.

There is an example that includes a HUD. Additionally, I wrote an extensive explanation about HUD in the documentation, on what can work and what cannot (in general, not only using this method) and why. Have a look when you have some time.

colander

So much for me not having time to look at it . This could be made more universal by using Game/Display Size/ Width or Height instead of hard coding these values. When creating a UB method my goal is using the same code in every UB wether it starts in iPad or widescreen, portrait or landscape, etc.

I still think it is not as easy to set up as Overscan for the reasons I stated in the other thread. Also in this method rules are needed in a unlocked scene actor which will need to be set up every time (Although you can get around this by setting up one scene and copying it for new ones) as well as rules for the HUD actors. In Overscan it only needs rules in the HUD actors and using my method you can use the same code wether it is in a widescreen or iPad resolution, landscape or portrait and overscanning in any direction from iPad to widescreen or widescreen to iPad.

In any UB method the developer has to design their game accordingly. In my Overscan method you only have to deal with the HUD actors anything on the background is a design issue and will require a method to handle it. For example in a vertical scroller (Scrolling from top to bottom) starting in iPad landscape using either overscan or stretch methods there will be actors at the top of the scene which wont be scene on a widescreen device. They will require code to bring them on scene or the camera starting position will need to be shifted up depending on the screen height of the device. In either case this can be coded quite easily.

I haven't seen anything in either of the threads using stretch which makes creating a UB easier only harder. The beauty of Overscan is you only need to think about the design resolution you are creating the game in (Which you need to do in either method) everything after that remains the same (Same rules and code).

While comparing the two I have noticed some things with my Overscan method which needed to be updated (Now UB 7).

pHghost

@beefy_clyro‌ -- cannot post you these by PM, so putting them here. Two methods to make iPhone 5 to Universal. First is similar to overscan, adding space top and bottom.

Second is -- tada! -- a script you throw into actors to reverse the squish factor when using stretch!

Enjoy!