22 replies to this topic

[Hgameguy]

I have built a couple of test apk's with GM: Studio, and have successfully installed them on an AVD by following these instructions.

However, when I run them in the emulator, I see the game's loading screen as expected, then the game starts and the screen (of the AVD) turns white.
I do hear the game's music playing, although it stutters quite a lot (about five interruptions per sec.). The white screen never goes away.

(Perhaps I'm not allowing the emulator enough RAM?)

Anyway... Basically I'm here to ask if anyone else has tried to run their apks in the AVD emulator, and if so, whether or not it was successful.

[alpha_centauri]

I have built a couple of test apk's with GM: Studio, and have successfully installed them on an AVD by following these instructions.

However, when I run them in the emulator, I see the game's loading screen as expected, then the game starts and the screen (of the AVD) turns white.
I do hear the game's music playing, although it stutters quite a lot (about five interruptions per sec.). The white screen never goes away.

(Perhaps I'm not allowing the emulator enough RAM?)

Anyway... Basically I'm here to ask if anyone else has tried to run their apks in the AVD emulator, and if so, whether or not it was successful.

Have you tried giving it more ram? After that just change the screen size you selected... what are the display settings on it...?

[rwkay]

Currently we do not support AVD's, but since the recent SDK update added hardware support to the AVD we will reexamine that, but until then it is not fully supported if you get it working then good on you..

Russell

[jjsonique]

Currently we do not support AVD's, but since the recent SDK update added hardware support to the AVD we will reexamine that, but until then it is not fully supported if you get it working then good on you..

Russell

Wait, so we can't even test the compiled apks on AVDs (unless the SDK update will allow it)? AVD testing is pretty essential to make sure the game works/looks as planned at the many different possible resolutions Android devices have. Unless Studio is using a virtual resolution that scales well between different resolutions/aspect-ratios/DPIs?

[cotycrg]

Currently we do not support AVD's, but since the recent SDK update added hardware support to the AVD we will reexamine that, but until then it is not fully supported if you get it working then good on you..

Russell

Wait, so we can't even test the compiled apks on AVDs (unless the SDK update will allow it)? AVD testing is pretty essential to make sure the game works/looks as planned at the many different possible resolutions Android devices have. Unless Studio is using a virtual resolution that scales well between different resolutions/aspect-ratios/DPIs?

Just test the windows version of the game in multiple resolutions. Or resize the HTML5's versions window over and over and make sure it looks right at any resolution..

[rwkay]

You can test final APK's just using an AVD to hit the built in Test or Debug buttons (Green or Red arrows on IDE) is not supported...

Also be aware that the AVD will probably be horribly slow (though I have not tested the newer hardware accelerated AVD so that may work very well not sure).

Russell

[jjsonique]

You can test final APK's just using an AVD to hit the built in Test or Debug buttons (Green or Red arrows on IDE) is not supported...

Also be aware that the AVD will probably be horribly slow (though I have not tested the newer hardware accelerated AVD so that may work very well not sure).

Russell

Oh, good, thanks. I haven't bought the Android module yet, but that something that would've influenced my decision. It'd be great of course to able to launch to an AVD through the Test or Debug buttons, but as long as manually installed Studio-made apks on AVDs should work, that's fine for testing.

Just test the windows version of the game in multiple resolutions. Or resize the HTML5's versions window over and over and make sure it looks right at any resolution.

Well, in addition to height x width, there's also DPI variations across android screens which can effect things -- the DPI might not be an issue depending on how Studio renders things, but I'd like to be able to do some AVD testing with different settings just to be sure - good to know we should be able to.

Also be aware that the AVD will probably be horribly slow (though I have not tested the newer hardware accelerated AVD so that may work very well not sure).

Oh yes, I'm familiar with the slowness of the AVD - I won't expect much there.

Edited by jjsonique, 23 May 2012 - 08:23 PM.

[jjsonique]

Just a note that I've tried this now, and I'm seeing the same thing on the emulator with a installed apk from GM:S - actually, as well as the loading graphics, I get a brief flash of the background graphic I've set in my titlescreen room, but then I get the white screen. I tried several different avd configs, varied the RAM, still the same thing. The same app (it just displays one background, scaled for device's aspect ratio) works fine on my actual Nexus S, as well as iPhone 3gs, Windows, Mac and HTML. So I guess there's something in particular that's tripping the emulator up? I ran DDMS, but didn't see any obvious errors. There as a "OpenGL Error: Graphics::Flush(1): 0x0500" message from the app (in green, not the usual red of a true error message) in the emulator that I thought might be a clue, but the same message shows up for the app running on the Nexus S, where the screen is fine, so that doesn't seem to be it.

[Hugo_Peters]

I'm using BlueStacks beta, works perfectly with both final .apk's AND the YoYo Runner!! (Downloaded in 3 secs! ZING!)
Also gets 60 FPS on my Dell Studio XPS 435T

Edited by Hugo_Peters, 17 June 2012 - 10:31 PM.

[Jobo]

Also be aware that the AVD will probably be horribly slow (though I have not tested the newer hardware accelerated AVD so that may work very well not sure).

The AVD is as a fact incredibly slow. My experience in using the AVD lies in Android SDK development.
We're talking very low fps. I suggest using differently sized Android phones if you're able to.

[cotycrg]

If you're using Google's official AVD's, yes it's going to be HORRIBLY slow. This is because you're technically emulating the android OS via interpretation. Everything would turn out 100% as if it were running on a device..but be extremely slow in comparison.

I seriously would NEVER recommend using it unless you need to test a very specific device and simply cannot get your hands on it. But honestly that would be an extremely rare situation.

Just change around view port sizes dynamically to make sure your game fits different sizes. And if you're worried about "DPI" you need to stop being silly. Just make things/UI/buttons bigger if the resolution is smaller. It's almost always as simple as that.

[Research]

The fact is that AVD is not for test game...
BlueStacks is great for this.

Edited by Research, 18 June 2012 - 02:35 AM.

[Hugo_Peters]

I'm using BlueStacks beta, works perfectly with both final .apk's AND the YoYo Runner!! (Downloaded in 3 secs! ZING!)
Also gets 60 FPS on my Dell Studio XPS 435T

[jjsonique]

Great, I'll try out BlueStacks - thanks for the tip.

[jjsonique]

Just change around view port sizes dynamically to make sure your game fits different sizes. And if you're worried about "DPI" you need to stop being silly. Just make things/UI/buttons bigger if the resolution is smaller. It's almost always as simple as that.

For DPI, it's not a matter of adjusting for a smaller resolution, DPI is separate from resolution. Different devices can have the exact same screen dimensions, but different DPIs that will make graphic assets render differently if an app is not 'DPI independent'. See this image from Google's own docs about screen resolution/DPI:



Those are at the same screen resolution but different DPIs, so the app's graphic assets render differently because the app is not 'DPI independent'. Again, if Game Maker is DPI-independent, great, but it's worth testing to see. That's what I'd want the AVD for, not for testing full gameplay (which agreed would be horrible due to AVD slowness), but for testing screen layouts at resolutions/DPIs I don't have access to. If BlueStack allows me to do that, great. If others can confirm that GM:S are DPI-independent, even more great, that would mean testing different screen resolutions will be all that would be needed, as you suggest.

Edited by jjsonique, 18 June 2012 - 05:35 PM.

[Manuel777]

I have filled a bug report asking for something like screen_get_dpi(), but it just got assigned.. maybe filling several reports will get the guys working on it hehe

[Hgameguy]

I'm using BlueStacks beta, works perfectly with both final .apk's AND the YoYo Runner!! (Downloaded in 3 secs! ZING!)
Also gets 60 FPS on my Dell Studio XPS 435T

Wow! Sounds neat! I'll have to try this out.

BTW - Does BlueStacks allow different devices and screen sizes to be emulated or are you stuck with some standard setting?

[cotycrg]

Just change around view port sizes dynamically to make sure your game fits different sizes. And if you're worried about "DPI" you need to stop being silly. Just make things/UI/buttons bigger if the resolution is smaller. It's almost always as simple as that.

For DPI, it's not a matter of adjusting for a smaller resolution, DPI is separate from resolution. Different devices can have the exact same screen dimensions, but different DPIs that will make graphic assets render differently if an app is not 'DPI independent'. See this image from Google's own docs about screen resolution/DPI:



Those are at the same screen resolution but different DPIs, so the app's graphic assets render differently because the app is not 'DPI independent'. Again, if Game Maker is DPI-independent, great, but it's worth testing to see. That's what I'd want the AVD for, not for testing full gameplay (which agreed would be horrible due to AVD slowness), but for testing screen layouts at resolutions/DPIs I don't have access to. If BlueStack allows me to do that, great. If others can confirm that GM:S are DPI-independent, even more great, that would mean testing different screen resolutions will be all that would be needed, as you suggest.

Yes..it is a matter of making things for a smaller resolution.

You aren't going to find an 8" tablet that runs at 480x240, and you're not going to find a 3" phone running at 1980x1080. Yeah those are extreme examples, but you get what I mean. I, personally, don't see the big deal with this. I guess a get_dpi() function would be fun for 100% accurate measurements in inch/cm sizes. But really it's not that big of a deal. Just make the game adjust if the game really needs to.

By default, GM:Studio will scale the game to the device's screen size. (So that smaller resolution, will be stretched).

What Google is really concerned about is if people make games for 1080p tablets in mind, and then release the same app on a 480p device. Everything would be tiny. Just make 2 or 3 graphical assets and have the game adjust when needed, or make different apps and make the screen size of the device depend on what apk the device can download.

[Manuel777]

By default, GM:Studio will scale the game to the device's screen size. (So that smaller resolution, will be stretched).

What Google is really concerned about is if people make games for 1080p tablets in mind, and then release the same app on a 480p device. Everything would be tiny. Just make 2 or 3 graphical assets and have the game adjust when needed, or make different apps and make the screen size of the device depend on what apk the device can download.

Well, how do you know when to use different sprite sizes if you cant measure dpi?
It would all be simpler if we have some way to get the screen's dpi.. No need to make different apk's nor whatsoever..

For me let GM do the scaling is out of the question, since most of my games use a very strict sprite size-ratio and style (sort of neo-retro), and when scaled they simply look like crap. I do not always need a dpi function, only on very specific situations, but it would be awesome.

[scurvycapn]

With high resolution phones these days, DPI does matter. Going by the resolution alone and guessing does not cut it. My 4.65" phone has a 1280x720 resolution, while my 10" tablet has a 1280x800 resolution. The screen of the tablet is many times larger than the phone, but only has 80 more horizontal lines of vertical resolution. Say my game has a 10x10 grid of squares. On the tablet, it would be quite easy to select the proper square as they are of a decent size. On the phone though, they are quite tiny and it would be very easy for the user to click on the wrong square.

Here is an example illustration of the difference between the phone and tablet. Slightly different resolutions, but extremely different DPIs. Without the ability to tell the density, I have no idea how the user's experience will be. I would need to give them some option of phone vs tablet to allow for different assets to be used or something similar.


Things such as menu buttons can look quite silly too. Sure, I want the buttons to be at a pretty big size relative to the screen on a phone, but on a tablet they would look comically huge. Instead, I'd want some lower res buttons centered down near the bottom with the background of my title screen visible in all its glory. Instead, I'd have huge buttons blocking the view when it would be completely unnecessary.

Also, even just plain old text can be a concern. What is a good, legible size on a phone would be oversized on a tablet with a lower DPI.