@colander said:
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.
Yet I don't do that on purpose. I think some things are better pre-defined. When making a game you are making it either Landscape or Portrait. Simply select the method you want from the ones contained in the the Universal Build Template (they are clearly marked) and after dropping the code into your scene, you are ready to roll, everything else is managed for you.
This template is built on the design principle of starting with an iPad project when making a universal game, that's why the iPad data is pre-defined and not dynamic.
@colander said:
I still think it is not as easy to set up as Overscan for the reasons I stated in the other thread.
I personally find this is much easier, because you copy-paste and run. If you are designing for overscan, you need to figure out how to deal with the 'dead space' on iPad. For some games it can be a problem, for some not. At the end of the day, it really depends what you need, all the different methods have their merit.
For me, the most important and also the most powerful (yet simple) block of logic in what I made is the one that doesn't scaled anything -- and simply adjusts the window through which you 'see into' the game. If you are working on any free-roaming game, Zelda-style, or strategy game, Fire Emblem or Advance Wars style, or RPG, Fallout-style, basically any game with a big map that spans beyond the extent of your screen, and especially if you don't want it rendered huge on iPad or tiny on iPhone, this is the method you want to use, and none other offers the benefits. Basically, that was the primary focus, and the reason is selfish -- I needed it myself. The other methods included are a small added bonus for other use cases.
I haven't seen anything in either of the threads using stretch which makes creating a UB easier only harder.
I don't see how it makes anything harder. If you are unwilling to make one unlocked actor per scene and paste a bit of logic into it to manage scaling for you, this template will be a hard sell.
But I used the method to convert my currently available apps (originally iPhone-only) to Universal Build and it took me about 5 minutes or less per app, with precise control over the result I'm getting. And I find that quite sweet.
pHghost said: Yet I don't do that on purpose. I think some things are better pre-defined. When making a game you are making it either Landscape or Portrait. Simply select the method you want from the ones contained in the the Universal Build Template (they are clearly marked) and after dropping the code into your scene, you are ready to roll, everything else is managed for you.
>
This template is built on the design principle of starting with an iPad project when making a universal game, that's why the iPad data is pre-defined and not dynamic.
Hard coding is not best practise and should be avoided. When you have spare time come back to it and see what you can do to make it more adaptable for yourself and others.
If you are designing for overscan, you need to figure out how to deal with the 'dead space' on iPad.
In non scrolling games both methods have dead space no matter how it is done. It can't be any other way if you want to keep you actors aspect ratio on devices with a different aspect ratio other than the one it was created on.
Creating in iPhone 5 and stretching to iPad there is about 150 pixels of dead space on the right side in Overscan it is 88 pixels on each side. Creating in iPad and stretching to iPhone 5 you wont be able to see the space you will need to fill. You can get around this by making the scene larger but it would still look and feel odd having that much space on the right which is not part of the game. It also adds yet another layer of complexity to the method. In Overscan the dead space is on the top and the bottom in the viewable area. For scrolling games in both methods you can eliminate this issue by shifting the camera's starting position/origin if necessary so dead space is not an issue.
I don't see how it makes anything harder. If you are unwilling to make one unlocked actor per scene and paste a bit of logic into it to manage scaling for you, this template will be a hard sell.
Sure you can copy and paste then each time and you will also need to add the camera width and height attributes which becomes a tedious process if it needs to be done many times. With Overscan you don't need to do any of it.
@colander said:
Hard coding is not best practise and should be avoided.
I disagree. It really depends on the situation. Sometimes hard-coding is the clearest way to avoid wonky problems.
@colander said:
In non scrolling games both methods have dead space no matter how it is done. It can't be any other way if you want to keep you actors aspect ratio on devices with a different aspect ratio other than the one it was created on.
Agreed. But for non-scrolling games of that sort it is basically a question of design rather than finding a magical UB fix. Generally, try to see if you can fill the empty space with UI. From the very beginning I was clear about the fact that this method won't work if you have a scene that is the same size as the camera (i.e. non-scrolling).
@colander said:
Sure you can copy and paste then each time and you will also need to add the camera width and height attributes which becomes a tedious process if it needs to be done many times. With Overscan you don't need to do any of it.
What do you mean? You don't need to adjust any camera attributes. It's copy-paste and you're ready to go.
@pHghost said: I disagree. It really depends on the situation. Sometimes hard-coding is the clearest way to avoid wonky problems.
Don't take my word for it ask any qualified programmer, hard coding should be avoided at all costs. The problem with hard code is when something needs to be changed you have to go and manually change it everywhere it exists.
You can avoid this by using attributes in your formulas and always use the engine attributes in place of the ones you create wherever possible. For example the centre of your screen should always be game.Screen.Size.Width/2 not a hard value like 512 or an attribute set to 512. Attributes can be set in one place generally when the game loads if a value needs changing you only have to go to one place to do it. If your code is solid and tested there wont be any wonky problems.
I urge you and anyone reading this to always use best practise in you code. You may know exactly what is happening in your code now. Come back in twelve months time after doing two more games and try and figure it out. Always use attributes and plenty of notes using the Note container and the title bar of your rules, groups, behaviours, etc.
By using best practise you will get better at this much quicker, have far fewer problems and your development life will be 5,000 times easier.
Agreed. But for non-scrolling games of that sort it is basically a question of design rather than finding a magical UB fix. Generally, try to see if you can fill the empty space with UI. From the very beginning I was clear about the fact that this method won't work if you have a scene that is the same size as the camera (i.e. non-scrolling).
My point is Overscan can do everything Stretch can do and do it easier and also do everything Stretch can't. Why use Stretch for one style of game and something else for another when you can just use Overscan for everything. This doesn't mean Stretch can't be better than Overscan I just haven't seen it yet. I been around here long enough to know you or someone else could come back with something truly amazing and blow all the other methods out of the water.
What do you mean? You don't need to adjust any camera attributes. It's copy-paste and you're ready to go.
Ahh! sorry my mistake I was thinking of accessing it through the layers but of course you don't.
@colander said:
Don't take my word for it ask any qualified programmer, hard coding should be avoided at all costs. [...] For example the centre of your screen should always be game.Screen.Size.Width/2 not a hard value like 512 or an attribute set to 512. [...] I urge you and anyone reading this to always use best practise in you code.
I feel you just don't (want to) understand why I am doing it this way and don't want to believe it is a design decision.
Your example is a bit misleading. Yes, the centre of your screen should always be game.Screen.Size.Width/2, without any doubt, but that's an entirely different situation.
The reason things are sometimes wonky is because GameSalad is still very actively in development and now and then a feature breaks. I had that happen to me several times in the past. It wasn't a problem of the game logic. I just had to wait for a version with a fix and it started working again.
The very specific reason certain parts of the code are hard-coded (BUT this does not apply to the main unscaled method, which is actually entirely dynamic) is because best practice for making UB is starting with an iPad (Landscape or Portrait) project. That way, if you make graphics to size, they will scale well on every device. And for that reason, I decided to focus strictly on that.
As with Apple and their sand-boxing or App-store curation, some people don't like it because it is too 'controlled' and not 'free' enough. You don't have to use it if you don't like it. I believe some limitations are very good and important in design, and it is the same in this case.
It is a conscious decision.
@colander said:
My point is Overscan can do everything Stretch can do and do it easier and also do everything Stretch can't. [...] I been around here long enough to know you or someone else could come back with something truly amazing and blow all the other methods out of the water.
That is not true. Overscan, with it's cutting off of edges can be problematic in huge ways. Panning around a map and seeing into all the corners on every device is a very good example of what Stretch can do and Overscan cannot. As well as making a UB where things retain their dimensions in pixels. Feel free to prove me wrong in any of those (with a demo), but I have yet to see overscan be able to do that.
I am starting to have the feeling that you generalize things a bit too much here. Each case has different needs. And for that reason, there will never be something truly amazing to blow all the other methods out of the water. I am absolutely certain about that.
@pHghost said: That is not true. Overscan, with it's cutting off of edges can be problematic in huge ways. Panning around a map and seeing into all the corners on every device is a very good example of what Stretch can do and Overscan cannot. As well as making a UB where things retain their dimensions in pixels. Feel free to prove me wrong in any of those (with a demo), but I have yet to see overscan be able to do that.
This is just a design issue handled in the actor that controls the camera. In the attached example the scene is created larger to allow the camera to pan to far left and far right sides of the playing area. There is no need to fill this area it is never seen. At the moment it can only go from 720p HD to iPad. I decided to go from widescreen to iPad for the hell of it but the same principals apply in reverse.
It doesn't work on the other devices because of this section of code (1-( game.Screen.Size.Width /( game.Screen.Size.Height * game.rOrigRatioX ))) in self.meCamOffsetX in the Cam actor. Excluding "1-" in 720p HD it resolves to 1 and in iPad it resolves to 0.75. I need the inverse of this hence the "-1" and I haven't figured out the math for that yet. I did high school maths so it will take me awhile to nut it out and I may have to ask for help from the math guys on the forums to get it done. If you select iPhone 5 it returns 0.33 when it needs to be 99.67 and it gets similar results with the other resolutions.
Only the HUD items are moved and resized. All of these can be turned on and off in any combo as needed. They always retain their aspect ratio unless you turn off one dimension and not the other and that would be a design decision.
I am starting to have the feeling that you generalize things a bit too much here. Each case has different needs. And for that reason, there will never be something truly amazing to blow all the other methods out of the water. I am absolutely certain about that.
Fare enough I exaggerated a bit here. My point is quite often there is a better way to do things and just because you and I can't think of it doesn't mean it can't be done. Also there could be a new feature come out in the future and change how it is done making UB's a lot easier.
I will get this finished and add it to my UB, I am creating a template for future apps. I want something I can just grab and start creating any style of app with. I will include ten blank tables at the top of the Attribute panel (I hate that I can't sort the tables and attributes or images for that matter). UB and other standard game attributes with a lot of blank ones in between I can use as I code and have some sort of order at the end of the project. A custom score and high score system and some other stuff.
Anyway I said enough on this subject we will just have to agree to disagree.
***Edit removed project see next post for the latest one.
Ok it is now working for all devices in landscape. I will add portrait later although I can't see anyone wanting to create a game like this in portrait, maybe a business app.
I was tackling the problem from the wrong angle anyway just swipe to scroll around the screen. There is an issue with swipe scroll in Creator it freezes sometimes, it doesn't do this on a device. This is to do with When mouse button is down, just refresh creator and keep you mouse inside the screen and don't scroll too fast and it will work fine.
I will remove the project from my last post to save confusion.
I see what you do there and for me that seems very problematic, especially from a design perspective. It just confirms my position on not targeting HUD in Universal Build templates and urging people to design a specific HUD per-device or at least per-device-category. Why? 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, BUT!
iPad -- 160x160 pixels* -- 1.54cm per side at 264 dpi
>
iPhone 4(s) -- 75x75 pixels* -- 0.58cm per side at 326 dpi
>
iPhone 5 -- 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 absolutely no consistency, the buttons are more than 2.5x larger on an iPad than on a iPhone 4(s). This comes back to what I wrote in the notes of my template:
Not adjusting your HUD manually for every platform you are publishing to is a really bad idea. On some platforms it is possible to scale the HUD along with the rest of the graphics, but if you scale from iPad down to iPhone, you will end up with either tiny buttons on iPhone or huge ones on iPad.
And if you don't scale them, they will start overlapping.
I will reiterate what I said several times. These things are on a case-by-case basis and resizing the HUD might work in some instances, but as a general approach, from a design standpoint it is usually tragic and you end up with wonky controls that aren't accurate and frustrate the user. Personally, I try to avoid that.
This is exactly the reason why I made my template, to avoid this problem. And for that reason you will also find my commentary on the subject included in the notes of the template.
Does that mean my template is perfect? No. Every benefit has it's downside. And with my method, it means you will have to manually adjust your HUD. But I take that as a good thing.
Cool. I wrote something slightly different in each thread, in this one I talk more about my general take on HUD 'policies' and about my method of doing things, which I didn't want to do in the other one, hijacking the discussion there.
An updated version of the template! Primarily I added more description notes and made sure it is clear in the documentation what the template does and what it doesn't as there was some confusion around that. If anybody has questions about a certain feature, feel free to ask here, or send a PM.
Disclaimer:
This template is constructed specifically to work with games containing scrollable scenes. It is perfect for vertical and horizontal scrollers or games with extensive maps.
>
Although it is possible to use this template also for games with static one-screen scenes, there are other templates that are more suitable for games of that type.
@pHghost I would love to use this template but what's in the zip file won't open in my gamesalad (is it something to do with the difference between a .gsproj and .gameproj )
Either can you help me open the current project... or is there any chance of getting screenshots of the 'rules' of the actor that changes the settings?
Thanks
@blendnzjnr said:
pHghost I would love to use this template but what's in the zip file won't open in my gamesalad (is it something to do with the difference between a .gsproj and .gameproj )
Either can you help me open the current project... or is there any chance of getting screenshots of the 'rules' of the actor that changes the settings?
Thanks
I've been trying my best to thoroughly understand universal builds and study this thread. I've downloaded the "Stretch_UB_iPad_1.0.1.zip" and placed the code into my project properly.
The code appears to be doing something!
However, whichever "Scaled" option I choose, a large black border appears along the top and right side of my game display. Making it seem as if my entire game has shrunk down to the bottom left corner...
Could there be something wrong with the way I've coded my game before placing the UB code in?
@pHghost
I tried using your method to build my portrait project. (Non Scrolling, just one single scene with fixed camera sizes based on devices screen sizes).
I got in to a small problem though. When I preview my game in 50%, on any IOS devices, the scene looks correct and everything works fine. (I did refreshed after I select the devices I wanted to preview and clicked stretch) However, when I tried to preview on 100%, the camera zoomed into the bottom left corner. (There is no behaviour to camera except changing camera size to fit the screen size once enter scene.
I just couldn't get the preview working correctly whenever I chose 100% on any iOS devices.
Comments
Yet I don't do that on purpose. I think some things are better pre-defined. When making a game you are making it either Landscape or Portrait. Simply select the method you want from the ones contained in the the Universal Build Template (they are clearly marked) and after dropping the code into your scene, you are ready to roll, everything else is managed for you.
This template is built on the design principle of starting with an iPad project when making a universal game, that's why the iPad data is pre-defined and not dynamic.
I personally find this is much easier, because you copy-paste and run. If you are designing for overscan, you need to figure out how to deal with the 'dead space' on iPad. For some games it can be a problem, for some not. At the end of the day, it really depends what you need, all the different methods have their merit.
For me, the most important and also the most powerful (yet simple) block of logic in what I made is the one that doesn't scaled anything -- and simply adjusts the window through which you 'see into' the game. If you are working on any free-roaming game, Zelda-style, or strategy game, Fire Emblem or Advance Wars style, or RPG, Fallout-style, basically any game with a big map that spans beyond the extent of your screen, and especially if you don't want it rendered huge on iPad or tiny on iPhone, this is the method you want to use, and none other offers the benefits. Basically, that was the primary focus, and the reason is selfish -- I needed it myself. The other methods included are a small added bonus for other use cases.
I don't see how it makes anything harder. If you are unwilling to make one unlocked actor per scene and paste a bit of logic into it to manage scaling for you, this template will be a hard sell.
But I used the method to convert my currently available apps (originally iPhone-only) to Universal Build and it took me about 5 minutes or less per app, with precise control over the result I'm getting. And I find that quite sweet.
>
Hard coding is not best practise and should be avoided. When you have spare time come back to it and see what you can do to make it more adaptable for yourself and others.
In non scrolling games both methods have dead space no matter how it is done. It can't be any other way if you want to keep you actors aspect ratio on devices with a different aspect ratio other than the one it was created on.
Creating in iPhone 5 and stretching to iPad there is about 150 pixels of dead space on the right side in Overscan it is 88 pixels on each side. Creating in iPad and stretching to iPhone 5 you wont be able to see the space you will need to fill. You can get around this by making the scene larger but it would still look and feel odd having that much space on the right which is not part of the game. It also adds yet another layer of complexity to the method. In Overscan the dead space is on the top and the bottom in the viewable area. For scrolling games in both methods you can eliminate this issue by shifting the camera's starting position/origin if necessary so dead space is not an issue.
Sure you can copy and paste then each time and you will also need to add the camera width and height attributes which becomes a tedious process if it needs to be done many times. With Overscan you don't need to do any of it.
Universal Binary Template - Universal Binary Template Instructions Rev 4 (Short) - Custom Score Display Template
I disagree. It really depends on the situation. Sometimes hard-coding is the clearest way to avoid wonky problems.
Agreed. But for non-scrolling games of that sort it is basically a question of design rather than finding a magical UB fix. Generally, try to see if you can fill the empty space with UI. From the very beginning I was clear about the fact that this method won't work if you have a scene that is the same size as the camera (i.e. non-scrolling).
What do you mean? You don't need to adjust any camera attributes. It's copy-paste and you're ready to go.
Don't take my word for it ask any qualified programmer, hard coding should be avoided at all costs. The problem with hard code is when something needs to be changed you have to go and manually change it everywhere it exists.
You can avoid this by using attributes in your formulas and always use the engine attributes in place of the ones you create wherever possible. For example the centre of your screen should always be game.Screen.Size.Width/2 not a hard value like 512 or an attribute set to 512. Attributes can be set in one place generally when the game loads if a value needs changing you only have to go to one place to do it. If your code is solid and tested there wont be any wonky problems.
I urge you and anyone reading this to always use best practise in you code. You may know exactly what is happening in your code now. Come back in twelve months time after doing two more games and try and figure it out. Always use attributes and plenty of notes using the Note container and the title bar of your rules, groups, behaviours, etc.
By using best practise you will get better at this much quicker, have far fewer problems and your development life will be 5,000 times easier.
My point is Overscan can do everything Stretch can do and do it easier and also do everything Stretch can't. Why use Stretch for one style of game and something else for another when you can just use Overscan for everything. This doesn't mean Stretch can't be better than Overscan I just haven't seen it yet. I been around here long enough to know you or someone else could come back with something truly amazing and blow all the other methods out of the water.
Ahh! sorry my mistake I was thinking of accessing it through the layers but of course you don't.
Universal Binary Template - Universal Binary Template Instructions Rev 4 (Short) - Custom Score Display Template
I feel you just don't (want to) understand why I am doing it this way and don't want to believe it is a design decision.
Your example is a bit misleading. Yes, the centre of your screen should always be game.Screen.Size.Width/2, without any doubt, but that's an entirely different situation.
This is not about me not knowing about constructing dynamic code. In my pathfinding project that I'm working on (http://forums.gamesalad.com/discussion/71909/demo-combat-terrain-generation-and-ai-on-a-grid-based-map#latest) you won't find a single hard-coded line. It would make it a mess when trying to adapt it to different projects and screen sizes.
The reason things are sometimes wonky is because GameSalad is still very actively in development and now and then a feature breaks. I had that happen to me several times in the past. It wasn't a problem of the game logic. I just had to wait for a version with a fix and it started working again.
The very specific reason certain parts of the code are hard-coded (BUT this does not apply to the main unscaled method, which is actually entirely dynamic) is because best practice for making UB is starting with an iPad (Landscape or Portrait) project. That way, if you make graphics to size, they will scale well on every device. And for that reason, I decided to focus strictly on that.
As with Apple and their sand-boxing or App-store curation, some people don't like it because it is too 'controlled' and not 'free' enough. You don't have to use it if you don't like it. I believe some limitations are very good and important in design, and it is the same in this case.
It is a conscious decision.
That is not true. Overscan, with it's cutting off of edges can be problematic in huge ways. Panning around a map and seeing into all the corners on every device is a very good example of what Stretch can do and Overscan cannot. As well as making a UB where things retain their dimensions in pixels. Feel free to prove me wrong in any of those (with a demo), but I have yet to see overscan be able to do that.
I am starting to have the feeling that you generalize things a bit too much here. Each case has different needs. And for that reason, there will never be something truly amazing to blow all the other methods out of the water. I am absolutely certain about that.
This is just a design issue handled in the actor that controls the camera. In the attached example the scene is created larger to allow the camera to pan to far left and far right sides of the playing area. There is no need to fill this area it is never seen. At the moment it can only go from 720p HD to iPad. I decided to go from widescreen to iPad for the hell of it but the same principals apply in reverse.
It doesn't work on the other devices because of this section of code (1-( game.Screen.Size.Width /( game.Screen.Size.Height * game.rOrigRatioX ))) in self.meCamOffsetX in the Cam actor. Excluding "1-" in 720p HD it resolves to 1 and in iPad it resolves to 0.75. I need the inverse of this hence the "-1" and I haven't figured out the math for that yet. I did high school maths so it will take me awhile to nut it out and I may have to ask for help from the math guys on the forums to get it done. If you select iPhone 5 it returns 0.33 when it needs to be 99.67 and it gets similar results with the other resolutions.
Only the HUD items are moved and resized. All of these can be turned on and off in any combo as needed. They always retain their aspect ratio unless you turn off one dimension and not the other and that would be a design decision.
Fare enough I exaggerated a bit here. My point is quite often there is a better way to do things and just because you and I can't think of it doesn't mean it can't be done. Also there could be a new feature come out in the future and change how it is done making UB's a lot easier.
I will get this finished and add it to my UB, I am creating a template for future apps. I want something I can just grab and start creating any style of app with. I will include ten blank tables at the top of the Attribute panel (I hate that I can't sort the tables and attributes or images for that matter). UB and other standard game attributes with a lot of blank ones in between I can use as I code and have some sort of order at the end of the project. A custom score and high score system and some other stuff.
Anyway I said enough on this subject we will just have to agree to disagree.
***Edit removed project see next post for the latest one.
Universal Binary Template - Universal Binary Template Instructions Rev 4 (Short) - Custom Score Display Template
Ok it is now working for all devices in landscape. I will add portrait later although I can't see anyone wanting to create a game like this in portrait, maybe a business app.
I was tackling the problem from the wrong angle anyway just swipe to scroll around the screen. There is an issue with swipe scroll in Creator it freezes sometimes, it doesn't do this on a device. This is to do with When mouse button is down, just refresh creator and keep you mouse inside the screen and don't scroll too fast and it will work fine.
I will remove the project from my last post to save confusion.
Universal Binary Template - Universal Binary Template Instructions Rev 4 (Short) - Custom Score Display Template
@colander
I see what you do there and for me that seems very problematic, especially from a design perspective. It just confirms my position on not targeting HUD in Universal Build templates and urging people to design a specific HUD per-device or at least per-device-category. Why? 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, BUT!
>
>
>
>
>
There is absolutely no consistency, the buttons are more than 2.5x larger on an iPad than on a iPhone 4(s). This comes back to what I wrote in the notes of my template:
And if you don't scale them, they will start overlapping.
I will reiterate what I said several times. These things are on a case-by-case basis and resizing the HUD might work in some instances, but as a general approach, from a design standpoint it is usually tragic and you end up with wonky controls that aren't accurate and frustrate the user. Personally, I try to avoid that.
This is exactly the reason why I made my template, to avoid this problem. And for that reason you will also find my commentary on the subject included in the notes of the template.
Does that mean my template is perfect? No. Every benefit has it's downside. And with my method, it means you will have to manually adjust your HUD. But I take that as a good thing.
No I didn't miss this I answered it in the other thread. Note to self "Just let it go"
http://forums.gamesalad.com/discussion/70748/universal-binary-rule-works-in-landscape-and-portrait-for-all-resolutions#latest
Universal Binary Template - Universal Binary Template Instructions Rev 4 (Short) - Custom Score Display Template
Cool.
I wrote something slightly different in each thread, in this one I talk more about my general take on HUD 'policies' and about my method of doing things, which I didn't want to do in the other one, hijacking the discussion there.
An updated version of the template! Primarily I added more description notes and made sure it is clear in the documentation what the template does and what it doesn't as there was some confusion around that. If anybody has questions about a certain feature, feel free to ask here, or send a PM.
>
@pHghost I would love to use this template but what's in the zip file won't open in my gamesalad (is it something to do with the difference between a .gsproj and .gameproj )
Either can you help me open the current project... or is there any chance of getting screenshots of the 'rules' of the actor that changes the settings?
Thanks
Hey @blendnzjnr,
What you need to do is add the extension .gameproj to the folder name.
Hey guys,
I've been trying my best to thoroughly understand universal builds and study this thread. I've downloaded the "Stretch_UB_iPad_1.0.1.zip" and placed the code into my project properly.
The code appears to be doing something!
However, whichever "Scaled" option I choose, a large black border appears along the top and right side of my game display. Making it seem as if my entire game has shrunk down to the bottom left corner...
Could there be something wrong with the way I've coded my game before placing the UB code in?
Thanks for your help in advance
@pHghost
I tried using your method to build my portrait project. (Non Scrolling, just one single scene with fixed camera sizes based on devices screen sizes).
I got in to a small problem though. When I preview my game in 50%, on any IOS devices, the scene looks correct and everything works fine. (I did refreshed after I select the devices I wanted to preview and clicked stretch) However, when I tried to preview on 100%, the camera zoomed into the bottom left corner. (There is no behaviour to camera except changing camera size to fit the screen size once enter scene.
I just couldn't get the preview working correctly whenever I chose 100% on any iOS devices.
Let me know if you have any thoughts.