23 replies to this topic

[Chronic]

Because of the varying sizes of mobile devices (i'm mainly interested in iOS as of now), what is the recommended way to making a game run at a devices native size?

Are there currently any functions to lock the screen orientation, and get gyroscope data?

[Sindarin]

Instead of browser_width and browser_height, wouldn't display_get _width() and display_get_height() functions sound more semantic?

About orientation, I suppose it would be useful to have a "Device Orientation" (Landscape,Portrait) setting and a "Enable Auto Orientation" in the Global Game Settings, under Android and iPhone.
It'd be also nice to have a YoYo_GetOrientation() GML function ( returns 0 on landscape, 1 on portrait )

Edited by Sindarin, 21 January 2012 - 05:44 AM.

[Chronic]

Will there be also a display_set_orientation(portrait/landscape/free)? (but with better sounding arguments)

[Sindarin]

I know browser_width/browser_height aren't great names, but it does make it code compatible with the HTML5 version.

I personally would give priority to the desktop platforms for consistency and also since you named the orientation function display_get_orientation().
I believe desktop & mobile should come first then HTML5 as it needs a "browser" to work.

I would expect to do something like this:

if (os_browser == browser_not_a_browser)
{
    //for desktop and mobile
    return display_get_width();
}
else
{
    //for browsers
    return browser_width;
}

Anyway, as long as display_get_width() / display_get_height() work on mobile the same way as well, I will be happy actually. :D

And finally, do you have any plans to categorize all the internal YoYo functions at some point?
For example YoYo_GetTiltX() could be device_get_tilt_x(), YoYo_GetURL() could be web_open_url() or something.
I am just saying camelCase syntax looks a little out of place to people who use GML, and personally I always loved how the GML functions were neatly organized in categories d3d_ sprite_ sound_ etc..

Edited by Sindarin, 22 January 2012 - 12:30 AM.

[Sindarin]

Okay, I know I am probably nitpicking again, but shouldn't the browser_width / browser_height be
browser_get_width() and browser_get_height() like window_get_width(), display_get_width() etc. and since they are not constants?

EDIT: Also just had this idea that the YoYo_GetURL(); could be renamed to browser_get_url() or browser_open_url() and this way you can build a relevant index of browser_* functions and categorize some YoYo ones under it

Edited by Sindarin, 23 January 2012 - 08:48 PM.

[Sindarin]

Ah I can see what you mean, also noticed there are readonly variables like room_width & view_width, so it's not completely out of place.

[Rossay]

There's 2 or 3 ways of doing this.

• Pick a size (1024x768) and then allow it to "scale to fit", which is the default. This is fine for most things, but on lower res devices, can look a bit pooh.
• Have a couple of room sizes and "pick" the best one for your device screen size.
• We're adding cross platform support for browser_width and browser_height (not the best of names...) so that on non-desktop, you'll be able to see the sizes of the screens and resize your view to fit.

This is probably a really stupid question, but what about if you were making games which primarily use pixel art? Wouldn't scaling etc. tend to make them blurry & defeat the point of using pixel art (which kind of needs a 1:1 or 1:2 ratio)?

[Crystal Noir]

Hey guys

I asked myself this question about the screen size of an Android device. But I'm a little confused about this. I don't know with GM Studio how to design my test game and in witch room size and project resolution I have to choose.

The fact is that android devices have their resolution and that's not the same each time. So I try to understand how can I deal with GM Studio to make the game playable on several android devices.

Have you got an example or something ? I've seen the posts at the top of this topic but I'm just a little lost with this things

Thank you in advance

[Chronic]

You can get the devices resolution using os_browser_width and os_browser_height

[rwkay]

The tactic we use internally is to have a dummy initial room that modifies the width and height of the other rooms based on os_browser_width and os_browser_height (NOTE : These names will be changed in the future to be more intuitive). This allows you to adapt the rooms to fit what you are doing.

The other way that we have done is to just allow the room to stretch to fit and use iPhone resolution 960x480 (for landscape) and 480x960 (for portrait) and live with any issues on different devices, most folk are actually fine with that.

Russell

[Crystal Noir]

The tactic we use internally is to have a dummy initial room that modifies the width and height of the other rooms based on os_browser_width and os_browser_height (NOTE : These names will be changed in the future to be more intuitive). This allows you to adapt the rooms to fit what you are doing.

The other way that we have done is to just allow the room to stretch to fit and use iPhone resolution 960x480 (for landscape) and 480x960 (for portrait) and live with any issues on different devices, most folk are actually fine with that.

Russell

The problem is , if you change the size room dynamically with a dummy , you have to modify sprites position and so on to make the game matches with the new resolution no ? The problem with resizing is that sprite are stretched or something...depend of the device (I work with Android and not iphone so, each phone has his resolution...).


PS : sorry for my english, I try to give my better to make you understand me ^^

[rwkay]

Agreed on the changing sprite positions - you need to design your game around the strategy that you want.

i.e. if you are scrolling level based game then just increase the view width and height so larger screens can see more (rather than moving them around).

If you are a static game then scale the sprites or use relative positions..

You need to design within the limitations of the devices...

Our advice on Android - pick a resolution or 2 and scale on the other devices.

BTW - all input positions are scaled relative to the room so you do not need to keep changing the scale based on the device size, that is all done for you.

Russell

[Crystal Noir]

Agreed on the changing sprite positions - you need to design your game around the strategy that you want.

i.e. if you are scrolling level based game then just increase the view width and height so larger screens can see more (rather than moving them around).

If you are a static game then scale the sprites or use relative positions..

You need to design within the limitations of the devices...

Our advice on Android - pick a resolution or 2 and scale on the other devices.

BTW - all input positions are scaled relative to the room so you do not need to keep changing the scale based on the device size, that is all done for you.

Russell

It's a little tricky for me (because of my english), do you have a small sample of your idea (with the dummy initial room) ? We should search the most resolution we find on android to know how to deal with that. For the input positions, if I understand, when we scale the room the sprite position will be correct automatically.

EDIT : I've found this : http://developer.and...ns_support.html

On the table at the bottom of this page, we can see the resolution screen android has. Phones are in the small and normal screen range.

Edited by Crystal Noir, 29 February 2012 - 03:57 PM.

[daz]

The good news is browser_width and height change based on the orientation, so that can be used to detect orientation changes.

[King Tetiro]

The good news is browser_width and height change based on the orientation, so that can be used to detect orientation changes.

Question as I don't have GMS yet. Does the runner automatically switch the orientation based on the tilting? As I noticed on iPhones the interface can rotate.

[Crystal Noir]

orientation doesn't work yet in GM Studio....there's a few bug with it for now. In fact, when the game launches it detects the orientation but does not rotate the screen.

Just a question : I have some difficulties to understand this sentence :

"BTW - all input positions are scaled relative to the room so you do not need to keep changing the scale based on the device size, that is all done for you."

That's because of my english....may be could you help me to understand this easier ?

Thank's in advance

Edited by Crystal Noir, 29 February 2012 - 08:36 PM.