Composer Scenes and Interstitial Advertisements on Android -> SLOWNESS

Solar2D Composer
#1

The title really explains it.  I’m using composer, and it’s been working excellently on both iOS and Android until I put in interstitials a few days ago.  My game is structured like this:

1. User plays Game (a scene), and is taken to a Game Over screen (a scene).  

2. On the Game Over screen, there’s a touch button to go back to the Main Menu screen (a scene).  User clicks on that button.

3. Main Menu screen does loading animation, then check if an interstitial from one of these networks (vungle, admob, chartboost, playhaven) can be shown.  If so, choose which ad to show.  Else, just continue on.

4. Show the interstitial (full-screen)

5. The Main Menu screen has a button to replay the Game.  (and the cycle continues)

iOS handles this perfectly.  I couldn’t be happier for that.  But on Android, after showing any interstitial (step 4), when the user touches the Game button, there is about a 3 second delay between switching to the Game scene.  My game is very fast paced, so this is game-breaking.   If no ad shows, it works fine.  BUUUUUUUUT: no ads = no money.  Which is bad.

Looking at the logs, the lengthy delay prints this out immediately afterwards:

wifi    : doString: SIGNAL_POLL

 

I have no idea what this means, but I’m guessing since it’s about wifi, it’s due to the ad networks.  I have no networking logic happening during the actual game or on touching the Game button, so I really have no idea why it pauses for so long.  

 

Does anyone have a good workaround or solution to this problem?

#2

Not sure about vungle or playhaven, but I know on Android I experienced this exact same thing and ended up “if i recall anyway” moving all the ad logic into a global function inside of main.lua and then just calling “ShowAd()” from the scene which allowed me to show the ad and move on all at the same time.

I created a global var of ShowingAd = true/false and when ShowAd() was called I set it to true and when the ad was gone I switched it to false, then inside of my scenes I simply added some pause logic using that flag so when I called ShowAd() and gotoscene at the same time the game wouldn’t start back up but would be ready to go as soon as they closed the ad.

That’s if I remember anyway lol

#3

my experience has been that it’s the suspend/resume on android that takes “forever”.  (flushing and reloading GL and AL)  some devices far worse than others.  it took some logging to track it all down and “convince” myself it wasn’t really due to anything else (sure, other stuff like network checks can contribute, but might not be the root issue)

for a while anyway, i was only using Chartboost (the Lua version) for interstitials, since it’s all “internal” to Corona so you don’t suspend/resume during a separate activity for the ad display.  but limiting your ad network choice isn’t a good solution.

if you feel similar “slowness” while popping out to other stuff (an email share, for example, even without sending anything on the network, et al) then suspect suspend/resume.

if that does turn out to be your problem, then best you can do is try to reduce the “load” of restocking texture/audio on resume.  what this means in practice is to throw out all the conventional wisdom about cache-on-first-load for performance - only load when needed, so it only has to REload what is absolutely necessary.  thus, may slow down elsewhere, for on-demand loads - definitely a trade-off balancing act.

fwiw, hth

#4

This is actually exactly what I’m doing for displaying ads.  A global function with a boolean flag so it doesn’t show in the middle of the game.  I don’t think that’s the problem though.  

I don’t think it’s suspend/resume either.  I have Runtime listeners in place, which stop eventing when the ads are showing, but immediately after the ad is finished showing, I start getting the Runtime events again.  I also have button animations, and those are showing up on the button touch as well.  

Your texture cache comment has me thinking.  I’m loading a large spritesheet (of full screen images) immediately in my main Lua file, and storing it in _G immediately on app start.  My Game scene is using display.newImageRect() using the _G spritesheet that was loaded on start.  It’s my guess that maybe on suspend, the spritesheet is released (although displaying mem usage doesn’t indicate this), and the game has to now reload the spritesheet since it wasn’t there anymore.  That would at least account for the delay.  There’s a few things I can do about this (from just thinking out loud):

  • Instead of using _G to hold my spritesheet data, use local variables in my main Lua file and write global functions to access the data.
  • Force reload the spritesheet data on system resume (I’d rather not, since it takes 3-5 seconds to load it)

Knowing this additional info, what do you think I should do about this?  

#5
  • Force reload the spritesheet data on system resume (I’d rather not, since it takes 3-5 seconds to load it)

No need, Corona is already doing this for you, Android requires them too.  (that’s what I was alluding to)

Seems suspicious – Is this “3-5 seconds” the same length of time that you’re experiencing as “ad lag”?

 

BTW, you won’t see anything reported in a (typical) texture memory monitor because your Lua code won’t get a chance to query in-between suspend/resume - it’ll only ever see the “whole system” once Corona internals have it fully established/re-established - that is, your Lua code is not running during suspend after GL contexts have been released.

 

If you decide this sounds like the source of your problem, you could try an experiment (to the extent feasible) of breaking up your spritesheet so that only SOME of it is loaded fulltime at start, loading the rest on-demand only on the screens that need it (and removing afterwards), would reduce the workload on resume.

 

hth

#6

So I’ve tried a few things out here…including force reloading the spritesheet on system resume…so I really have no idea what’s going on.  This might be an internal Corona thing.  I’ve also tried splitting up the spritesheet into 4 different ones, and even that didn’t change anything.  These 4 different spritesheets were all under 2048x2048, which is the max texture dimensions for this device (Nexus 7) as noted by Corona.

However, I’ve noticed as well that the same problem occurs when suspending the app and resuming the app manually, as well as displaying an ad.  So there’s definitely something up with suspend/resume.  

I have no idea where to go with this.

#7

Not sure about vungle or playhaven, but I know on Android I experienced this exact same thing and ended up “if i recall anyway” moving all the ad logic into a global function inside of main.lua and then just calling “ShowAd()” from the scene which allowed me to show the ad and move on all at the same time.

I created a global var of ShowingAd = true/false and when ShowAd() was called I set it to true and when the ad was gone I switched it to false, then inside of my scenes I simply added some pause logic using that flag so when I called ShowAd() and gotoscene at the same time the game wouldn’t start back up but would be ready to go as soon as they closed the ad.

That’s if I remember anyway lol

#8

my experience has been that it’s the suspend/resume on android that takes “forever”.  (flushing and reloading GL and AL)  some devices far worse than others.  it took some logging to track it all down and “convince” myself it wasn’t really due to anything else (sure, other stuff like network checks can contribute, but might not be the root issue)

for a while anyway, i was only using Chartboost (the Lua version) for interstitials, since it’s all “internal” to Corona so you don’t suspend/resume during a separate activity for the ad display.  but limiting your ad network choice isn’t a good solution.

if you feel similar “slowness” while popping out to other stuff (an email share, for example, even without sending anything on the network, et al) then suspect suspend/resume.

if that does turn out to be your problem, then best you can do is try to reduce the “load” of restocking texture/audio on resume.  what this means in practice is to throw out all the conventional wisdom about cache-on-first-load for performance - only load when needed, so it only has to REload what is absolutely necessary.  thus, may slow down elsewhere, for on-demand loads - definitely a trade-off balancing act.

fwiw, hth

#9

This is actually exactly what I’m doing for displaying ads.  A global function with a boolean flag so it doesn’t show in the middle of the game.  I don’t think that’s the problem though.  

I don’t think it’s suspend/resume either.  I have Runtime listeners in place, which stop eventing when the ads are showing, but immediately after the ad is finished showing, I start getting the Runtime events again.  I also have button animations, and those are showing up on the button touch as well.  

Your texture cache comment has me thinking.  I’m loading a large spritesheet (of full screen images) immediately in my main Lua file, and storing it in _G immediately on app start.  My Game scene is using display.newImageRect() using the _G spritesheet that was loaded on start.  It’s my guess that maybe on suspend, the spritesheet is released (although displaying mem usage doesn’t indicate this), and the game has to now reload the spritesheet since it wasn’t there anymore.  That would at least account for the delay.  There’s a few things I can do about this (from just thinking out loud):

  • Instead of using _G to hold my spritesheet data, use local variables in my main Lua file and write global functions to access the data.
  • Force reload the spritesheet data on system resume (I’d rather not, since it takes 3-5 seconds to load it)

Knowing this additional info, what do you think I should do about this?  

#10
  • Force reload the spritesheet data on system resume (I’d rather not, since it takes 3-5 seconds to load it)

No need, Corona is already doing this for you, Android requires them too.  (that’s what I was alluding to)

Seems suspicious – Is this “3-5 seconds” the same length of time that you’re experiencing as “ad lag”?

 

BTW, you won’t see anything reported in a (typical) texture memory monitor because your Lua code won’t get a chance to query in-between suspend/resume - it’ll only ever see the “whole system” once Corona internals have it fully established/re-established - that is, your Lua code is not running during suspend after GL contexts have been released.

 

If you decide this sounds like the source of your problem, you could try an experiment (to the extent feasible) of breaking up your spritesheet so that only SOME of it is loaded fulltime at start, loading the rest on-demand only on the screens that need it (and removing afterwards), would reduce the workload on resume.

 

hth

#11

So I’ve tried a few things out here…including force reloading the spritesheet on system resume…so I really have no idea what’s going on.  This might be an internal Corona thing.  I’ve also tried splitting up the spritesheet into 4 different ones, and even that didn’t change anything.  These 4 different spritesheets were all under 2048x2048, which is the max texture dimensions for this device (Nexus 7) as noted by Corona.

However, I’ve noticed as well that the same problem occurs when suspending the app and resuming the app manually, as well as displaying an ad.  So there’s definitely something up with suspend/resume.  

I have no idea where to go with this.