Universal Binary Rule Works In Landscape And Portrait For All Resolutions

colander

I started playing around with a UB for Overscan some time ago and have gone back to it again and have come up with a fairly simple rule which can go in each actor. There are also six attributes, four are preset in the Attribute panel and the other two are set when the app loads. Currently those two are in the on screen actor but can be moved to an off screen actor for loading at start up.

The code will work in any resolution in landscape and portrait. For example if you choose iPhone landscape for your project it will place and resize actors in all the other resolutions in both landscape and portrait. I have attached three projects "UB 5 iPad Landscape", "UB 5 iPad Portrait" and "UB 5 Mac Book Landscape" to demonstrate this and they all have the same code. You only need to set four game level attributes in the Attribute panel in your project. The two less obvious ones of them are;

rOrigRatioX = your projects width/height
rOrigRatioY = your projects height/width

This is not a magic bullet no UB is or can be you will still need to design your game with a universal binary in mind. You can see this when you run the projects. Overscan works by magnification from the centre point in all directions and stops when it fills the screen. This means that two edges on one of the axes (X or Y) are off the screen. The rule works by plotting the X and Y positions from the centre. For example if the edges on the X axis are off the screen it will reposition the actors on the X axis and adjust their height and width and not effect the position of the actor on the Y axis. The greater the difference in the original aspect ratio and the aspect ratio of the target device the greater the effect on the actors size. You can really see this when you preview a landscape project in portrait and vice versa.

You can strip out different parts of the rule to suite your game. For example if you only need to move your HUD elements on the X axis you can remove the attributes for self.Position.Y and if they are spaced far enough apart you can also remove the self.Width and self.Height attributes.

This would have already been done by others but I wanted to do it myself so I could understand it better which helps a lot when designing an app for multiple aspect ratios. I left some test display stuff in there in case people wanted to play with it.

---

**Mod Edit: Ignore zip files UB 5 (unfortunately this can't be removed) and use UB 8. I have updated the zip file which fixes the bug where the Setup actor was not placed at the bottom of the tree in the scene layer tab. And added a map scroller example.

The code handles the HUD actors you will need to setup everything else it’s your game. As always you will need to consider the game play when choosing a starting resolution to design your game in. I have included a map scroller to show you how scrolling can be handled, the code is in the Hero. The “Orig Screen Edge” actors mark the the edges of the game. Use the arrow keys to scroll around the map. The scene is wider to allow the camera to offset in overscan, this area is never seen and doesn’t need anything in it.

This will work in any resolution you choose however these are my recommendations. For non-scrolling and side scrollers start in widescreen (The widest aspect in Creator 11.1.11 is 720p HD at 1:1.778) and over scan to iPad. For vertical scrollers start in iPad and overscan to widescreen. For map scrollers I prefer widescreen and overscan to iPad you can go the other way of you want but you will need to set it up.

I can’t think of one but if you have a game style this doesn’t suit let me know and I will try to help you.

3DMA

Thank you very much @colander‌
this comes just in the right time as i am working on the very same problem right now. So i can have a look at your way of handling it
This help is much appreciated

colander

@3DMA your welcome. If you have any questions or find any issues let me know.

mdt3ch@gmail.com

So, we need to plug your attributes into our games? How would I go about applying your values into my game? I added the 4 attributes, where should I put the UB rules?

Braydon_SFX

Great stuff -- thanks for sharing!

colander

@mdt3ch@gmail.com the rule goes in each actor you want to reposition and resize. You need to create six attributes, four of them are preset in the attribute panel to your projects specifications as shown in the examples. The other two go in an off scene actor which is usually the actor you use to load other attributes for your game. Those two attributes are the two at the top in the UB actor in the examples game.rScreenRatioX and game.ScreenRatioY.

@Braydon_SFX thanks, it's a drop in the ocean compared to the stuff you provide which has helped me so much.

gyroscope

Post amends done for you as requested, @colander ... and please ignore my DM to you - I thought I'd accidentally deleted your thread here.... but phew, obviously not! :

colander

lol no worries mate I have already pm'ed you with one last thing to do.

colander

The example have been updated to UB 7. I tidied it up by removing the the setup attributes in the UB actor to an of screen actor and added a description to the Note in the UB actor.

PhilipCC

Thanks, this is great.

Do you plan to modify it for iOS8 and the iPhone 6+ debacle, once GS 0.12.6 is sorted out?

colander

@PhilipCC you don't have to change anything it will work in any resolution on any OS GameSalad publishes to.

PhilipCC

@colander That's fantastic. That is the best news this week.

stahboy

Awesome!

pHghost

Just a small notice, I did some math while discussing UB methods with @colander‌, and this are the results.

So, let's look at the math:

If you have an actor that is 100x100 size in the 720p project, it will render at 100x100 pixels on a MacBook Pro (or double if it is retina), at a real-world size of 2.25cm per side. This is what happens on other devices:

iPad -- 160x160 pixels* -- 1.54cm per side at 264 dpi

>

iPhone 4(s) -- 75x75 pixels* -- 0.58cm per side at 326 dpi

>

iPhone 5(s) -- 89x89 pixels* -- 0.69cm per side at 326 dpi

>

iPhone 6 -- 104x104 pixels* -- 0.81cm per side at 326 dpi

>

iPhone 6+ -- 172x172 pixels* -- 1.08cm per side at 401 dpi

>

*these are actual on-device render sizes, not actor sizes

There is a big gap in consistency, on an iPad the buttons are more than 2.5x larger than on a iPhone 4(s), and roughly 2x larger than on iPhone 5(s) and 6. This means you can end up with huge buttons in iPad or tiny unresponsive buttons on older iPhones.

You might not realize this just looking at GS Preview, where it all looks OK and you have the precision of a mouse to interact with buttons (your fingers don't scale with the buttons!)

What does it all mean? Should you not use this? Nonsense! This template does very well what is sets out to do -- scaling the HUD.

But whether to scale the HUD or not is a design decision you must make for yourselves. And most importantly, test your app on as many different devices as possible! Always! Don't simply assume: "It works well on my iPhone, and this is a UB template, so it will work well everywhere else." That will only lead to quirks and unsatisfied customers.

There are several different approaches (and templates) to create UB apps. First and foremost, think about the design of your app, what it does and needs to do, then research the different adjustment methods and how they fit your design. Try to find a method that suits the design you have in mind, instead of changing your design to fit a certain template.

colander

@pHghost like I said in my OP

You can strip out different parts of the rule to suite your game. For example if you only need to move your HUD elements on the X axis you can remove the attributes for self.Position.Y and if they are spaced far enough apart you can also remove the self.Width and self.Height attributes.

I know this is not what you are talking about. You are not scaling at all in your map scrolling scene and I'll come back to that. First I want to talk about the affect on actors in both methods and my code.

It is a design issue, in Overscan or Stretch your HUD will shrink (The same amount) simply because you are going from a large device to a smaller one and as developers we have to account for that.

I never use the code in my UB to adjust the width and height of my HUD actors. The code is there for anyone who needs it for something like going from landscape to portrait. The actors on my HUD's are the same size in Overscan or Stretch as long as I account for the stretching. In Overscan they look fine in all my games because they are designed for it. If you want to increase the size of the buttons relative to the background in smaller devices or keep the same size buttons the code can be changed to do.

For example grab the attached project (It is the same one I put in your thread) and Preview it in Overscan on iPhone 5 note the size of the buttons. Now in the UB actor turn off the actors self.Size attributes in the rule and don't forget the OTHERWISE section. Open the setup actor and switch off both Change Attributes. Preview it again in Stretch on iPhone 5, they are the same size.

Now regarding your project. You only have a HUD in your the map scrolling scene of your project with five buttons all on one layer. You have not scaled them only shifted them but this gives you a viewing area problem. I don't know how it could be used in a game played on tablet and a phone. The viewable playing area on a tablet is far greater than on a phone it would completely change the feel and playability of the game. In any case this can be done in Overscan and no I am not going to make you a demo it's you turn to make some demos more on that later.

A lot of games have a busy HUD with other actors like scores, power up bars, etc. If you don't scale they might not fit or will be so big they interfere the playing area. I am sitting here thinking of my three games and the HUD's wouldn't fit if they were not scaled.

Everything you raised in your post is a design issue as long as nothing in either method prevents it from being handled. In mine it doesn't in yours I don't know you don't have a HUD in the other scenes and the one you do has a the playability issue already mentioned.

You have asked me to put up and I have at every turn now its your turn to put up. Show me demo projects for non-scrolling, map scrolling, vertical and side scrollers. With HUD's that have more than five buttons and use the same code. Also the entire design area in Creator needs to be viewable, nothing out of sight otherwise it will not be practical for app creation.

Before you say "I never said Stretch was suitable for all games, etc" I agree and that's my point it isn't and Overscan is. In non scrolling games Overscan cuts of two sides while Stretch adds it all to one side in either case this unplayable space needs to be filled. You haven't been able to give me one legitimate reason or show me one example where Stretch is better.

Life is much simpler in Overscan land, time to come over to the dark side young pHghost. Plus I am getting tired of writing these epic posts, you'll could end up winning the argument by simply wearing me out, ha! not likely .

pHghost

@colander said:
Before you say "I never said Stretch was suitable for all games, etc"

I will not say that, or definitely not use it as an argument. All methods have their limitations, and that's just how it is, but that's not the point. What riddles me is your insistence on the idea that Overscan is suitable for all games. I gave you two examples of what it couldn't do and what is very important for me, and you actually haven't shown me that it could manage anything in those situations.

What I will say, though, again, is that I think managing HUD through any automated method is a bad idea. If, as you suggest, I:

@colander said:
turn off the actors self.Size attributes in the rule and don't forget the OTHERWISE section. [...] Preview it again on iPhone 5, they are the same size.

then yes, they are the same size, but in all of the platforms except iPad the buttons now overlap each other. That means you cannot turn that off, as it makes matter only worse.

@colander said:
You only have a HUD in your the map scrolling scene of your project with five buttons all on one layer. You have not scaled them only shifted them but this gives you a viewing area problem. I don't know how it could be used in a game played on tablet and a phone.

Very easily. Either, optimally, you manually create one HUD for phones and one HUD for tablets. That isn't much more work. You have the assets, just design in your head two optimal arrangements. Or, design the buttons to be the right size on iPhone first, so they don't obstruct, and then use them, at the same size, on the iPad. Why do you need to have a bigger HUD on iPad? I always found that annoying. With a bigger screen, personally I want to see more of the game, not a bigger HUD! As I said earlier, your fingers aren't bigger when using a bigger screen, the HUD can stay the same size, just find the right place for it.

@colander said:
Show me demo projects for non-scrolling, map scrolling, vertical and side scrollers. With HUD's that have more than five buttons and use the same code.

I'm really not sure you read my other post and my overall opinion on HUD management. If you know I think that adjusting HUD by an automated method is a really bad idea, why would you ask me to make a demo of such a method? That's like if you had a guitarist friend who you know doesn't like Country music, and then you asked him to explain to you how to write a good Country song. It'a a bit absurd.

If you take that requirement away, I already have that demo. It's my template. You will actually find four different scenes inside it, one for non-scrolling, one for map scrolling, one for vertical and one for side scrollers. It's all there. Just without the HUD.

colander

pHghost said: I gave you two examples of what it couldn't do and what is very important for me, and you actually haven't shown me that it could manage anything in those situations.

Refresh my memory which two are they?

then yes, they are the same size, but in all of the platforms except iPad the buttons now overlap each other. That means you cannot turn that off, as it makes matter only worse.

You are misreading my point and diverting the argument. This example was to specifically point out to you that Overscan and Stretch produce the same size buttons when you account for the stretch. Come on you can't be throwing this up as an argument no one is proposing to use it as a UB. The resizing was switched off to compare the relative BUTTON SIZE not position so you understood both methods produce the same size buttons in that situation. I then addressed your preference for buttons to remain the same size on all devices and it can easily be done in Overscan, surely you understand that by now? It is only a matter of constructing the formulas to do it. Am I going to prove it to you by adding it to a project? No not yet, first show me yours then I'll show you mine .

Very easily. Either, optimally, you manually create one HUD for phones and one HUD for tablets. That isn't much more work. You have the assets, just design in your head two optimal arrangements. Or, design the buttons to be the right size on iPhone first, so they don't obstruct, and then use them, at the same size, on the iPad. Why do you need to have a bigger HUD on iPad? I always found that annoying. With a bigger screen, personally I want to see more of the game, not a bigger HUD! As I said earlier, your fingers aren't bigger when using a bigger screen, the HUD can stay the same size, just find the right place for it.

As I said above and my previous post you can do that very easily in Overscan. As before show me it in all your scenes not just the map scroller.

I'm really not sure you read my other post and my overall opinion on HUD management. If you know I think that adjusting HUD by an automated method is a really bad idea, why would you ask me to make a demo of such a method? That's like if you had a guitarist friend who you know doesn't like Country music, and then you asked him to explain to you how to write a good Country song. It'a a bit absurd.

Man it is hard to know what to say to that, guitarist and country music, really? Ok don't use the same code but that sure doesn't make it very universal. You put your method up as a UB solution correct? Nearly every game has a HUD show me your universal method with a HUD for each device on each of your scenes.

For example put a score on it along with playing buttons, level label, menu button, etc, you know a typical HUD. The actors don't have to work mine don't they are just there to show people what happens when you change device. You can keep them all the same size just show me how you make it work on all devices.

You will actually find four different scenes inside it, one for non-scrolling, one for map scrolling, one for vertical and one for side scrollers. It's all there. Just without the HUD.

That's what I want a HUD on all of them then we can see how it all works together. Come on I put up now it is your turn .

bluetractorjt

Ok, I have tried Colander's method and it worked great after I applied offset. Everything sizes down perfectly.

However, the offset affected my rotating aiming arrow the user uses to launch a ball with. The arrow is pointing to the left where the offset origin has moved. I'm using vectorToAngle code for my aiming arrow and the code is this....

vectorToAngle( game.ballX - game.Mouse.Position.X , game.ballY - game.Mouse.Position.Y )

The aiming arrow spawns when the user taps on a ball to launch btw.

colander

@bluetractorjt can you upload a test project or send me a version of yours showing the problem so I can take a look. I can't solve it with the information provided.

BBEnk

vectorToAngle( game.ballX+offset/2 - game.Mouse.Position.X+offset/2 , game.ballY - game.Mouse.Position.Y )

just a guess.

bluetractorjt

Sure, here you go...

bluetractorjt

Thanks for helping in advance. :-)

colander

@bluetractorjt in the ball actor in rule launch ball there is an attribute missing in the third condition. Fix this and retest it if that doesn't fix it let me know what is it called.

bluetractorjt

@colander, you mean if self.touched is true?

bluetractorjt

@colander, or game.HowManyshots > 0

colander

@bluetractorjt I had a quick look correct me if I am wrong your are altering the camera in actor resizer which is not this method it is a Stretch method. This is causing the problem.

To use my method you will need to create the game in a widescreen device like 720p HD and Overscan back to iPad. The way your game plays it is important to keep a full view of the y axis. If you overscan form iPad to widescreen you loose the top and bottom of the screen. To see this turn off the rule in resizer and run it in overscan on 720p HD.

Your other option is to use either @pHghosts or @BBEnk Stretch method which resizes the camera which is what you are trying to do. There will still be dead space you will need to account for on the right side of the screen on widescreen devices.

bluetractorjt

So there is not a way to offset the camera and have my launch method work the way it needs to? this is independent of the UB stuff BTW. I tested it without UB and it still does it.

colander

@bluetractorjt when I turned off the UB rule in resizer it worked fine for me. Anyway I saw your post in the other thread saying it is all working now, that's great .

EDIT: I like the game it is fun to play, let me know when you publish it.

PhilipCC

@pHghost‌ VS @colander‌ The battle of Titans! I love it .

Wait until we get multiplayer. You can take each other on in the virtual space of an app each building your own weapons.

colander

@PhilipCC lol I gotta admit I am enjoying it even though it is very time consuming. The real good thing about it is I now have an even greater understanding of UB's and the challenge it presents. The importance of starting resolutions iPad or widescreen, game design, etc. I can feel another epic post coming on, I better stop .

colander

@pHghost said: I gave you two examples of what it couldn't do and what is very important for me, and you actually haven't shown me that it could manage anything in those situations.

Refresh my memory which two are they?

then yes, they are the same size, but in all of the platforms except iPad the buttons now overlap each other. That means you cannot turn that off, as it makes matter only worse.

You are misreading my point and diverting the argument. This example was to specifically point out to you that Overscan and Stretch produce the same size buttons when you account for the stretch. Come on you can't be throwing this up as an argument no one is proposing to use it as a UB. The resizing was switched off to compare the relative BUTTON SIZE not position so you understood both methods produce the same size buttons in that situation. I then addressed your preference for buttons to remain the same size on all devices and it can easily be done in Overscan, surely you understand that by now? It is only a matter of constructing the formulas to do it. Am I going to prove it to you by adding it to a project? No not yet, first show me yours then I'll show you mine .

Very easily. Either, optimally, you manually create one HUD for phones and one HUD for tablets. That isn't much more work. You have the assets, just design in your head two optimal arrangements. Or, design the buttons to be the right size on iPhone first, so they don't obstruct, and then use them, at the same size, on the iPad. Why do you need to have a bigger HUD on iPad? I always found that annoying. With a bigger screen, personally I want to see more of the game, not a bigger HUD! As I said earlier, your fingers aren't bigger when using a bigger screen, the HUD can stay the same size, just find the right place for it.

As I said above and my previous post you can do that very easily in Overscan. As before show me it in all your scenes not just the map scroller.

I'm really not sure you read my other post and my overall opinion on HUD management. If you know I think that adjusting HUD by an automated method is a really bad idea, why would you ask me to make a demo of such a method? That's like if you had a guitarist friend who you know doesn't like Country music, and then you asked him to explain to you how to write a good Country song. It'a a bit absurd.

Man it is hard to know what to say to that, guitarist and country music, really? Ok don't use the same code but that sure doesn't make it very universal. You put your method up as a UB solution correct? Nearly every game has a HUD show me your universal method with a HUD for each device on each of your scenes.

For example put a score on it along with playing buttons, level label, menu button, etc, you know a typical HUD. The actors don't have to work mine don't they are just there to show people what happens when you change device. You can keep them all the same size just show me how you make it work on all devices.

You will actually find four different scenes inside it, one for non-scrolling, one for map scrolling, one for vertical and one for side scrollers. It's all there. Just without the HUD.

That's what I want a HUD on all of them then we can see how it all works together. Come on I put up now it is your turn .

EDIT: I originally posted this yesterday and only just realised I hadn't put the @ preceding your name.