Perhaps we’re not talking about the same thing. Are you saying that you’re not getting a “back” key event at all? Because it’s working for me when I test it.
That’s it, I’m not getting the back key event. Just tried to make the settings you mentioned to see print in outputs, but I get no print from the onKeyEvent listener. Only this:
The program '[2056] TaskHost.exe' has exited with code 0 (0x0).
I tried :
print(event.phase) OutpuDebugString(event.phase) native.OutpuDebugString(event.phase)
but none of them printed an event.phase to the output. So I guess I’m not getting any event?
Confirmed - I’ve just placed print(“TEST PRINT”) in main lua chunk and it was displayed in the output. The print call from the key listener doesn’t show up at all, so there’s not key event registered when hitting the back button here. I do get the applicationExit event though, and it seems to save the game progress before it quits.
I’m testing it on WP8.1, maybe that’s why the key event doesn’t work here?
I’ve just re-tested this with the version you are using. You’re right. The “back” key event is no longer working. It used to work during GDC, but we broke it since then. Some kind of conflict with something else we’ve implemented since then. I’ll look into resolving this issue this week. Thanks for bringing this issue up.
OK, thanks for your help!
BTW: Do you have any other WP8 oriented performance tips that I should follow, which didn’t matter when deploying Corona builds for other platforms?
The only major performance issues I’ve seen on WP8 is with print() and display.newText(). Everything else is fine.
The only other possible gotcha (if it effects you at all) is that our timers on WP8 can actually invoke their Lua listeners earlier than scheduled. The reason we’ve set it up this way is because we’ve discovered that the native WP8 timers have a bad habit of elapsing much much later compared to other platforms, so we allowed it to finish early rather than extremely late. I hope my explanation makes sense. Now, this won’t be an issue if the timer you are using in Lua is set up to elapse infinitely because we’ve set it up to invoke your Lua listener as close to the configured interval as possible. But if you’ve set up your timer to be invoked only once, then this behavior might be unexpected. This is something we still want to tune on our end before the release because we want our timers to be as accurate as possible.
That makes sense. Will keep it in mind. Thanks.
I still get lags on collision events, even after removing text update calls. I’ll try to optimise my code to solve that.
>> I still get lags on collision events, even after removing text update calls. I’ll try to optimise my code to solve that.
Hmm… I’m interested to know what exactly is causing that too. Box2D itself appears to perform fine, but I’m wondering if there is something you’re invoking in the collision’s event that is causing the performance issue. If you can narrow it down to an API (like by commenting out lines until it performs good again), then I can track it down on my end. Thanks.
Was trying to do that, but it seems it’s not a single API that causing the issue but that the collision listener seems to ‘read’ the listener slowly. So when I have some more lines of parameter changes - it starts to be laggy. When I remove them it’s OK. Then if I keep them removed but enable some other calls - the lags come back. For instance a particle emmiter trigger causes a similar lag as some if statement with several conditions. Pretty basic calls without any for loops.
Or maybe this is just Lumia 625’s performance. I’ll try to narrow it down again, and will let you know if I come up with a particular reason.
My gameplay is pretty dense, so there’re collisions happening all the time. This said, it performs well on iOS and Android. Did you test Box2D in these kind of dense conditions? I believe that the lag wouldn’t be noticeable if I didn’t have other dynamically moving objects which make a good reference (when they slow down on other object’s collision).
Thanks for the feedback on this. I’ll see about playing around with the collisions later today.
Regarding the back key issue you mentioned above, I’ve narrowed it down. It won’t work if you’ve set up the CoronaPanel to render to a DrawingSurfaceBackgroundGrid. So, if you do the following in your MainPage, back key events will work again…
public MainPage() { // Initialize this page's components that were set up via the UI designer. InitializeComponent(); // Set up Corona to automatically start up when the control's Loaded event has been raised. fCoronaPanel.AutoLaunchEnabled = true; #if false // Set up the CoronaPanel control to render fullscreen via the DrawingSurfaceBackgroundGrid control. // This significantly improves the framerate and is the only means of achieving 60 FPS. fCoronaPanel.BackgroundRenderingEnabled = true; fDrawingSurfaceBackgroundGrid.SetBackgroundContentProvider(fCoronaPanel.BackgroundContentProvider); fDrawingSurfaceBackgroundGrid.SetBackgroundManipulationHandler(fCoronaPanel.BackgroundManipulationHandler); #endif }
Unfortunately, the above will also cause a huge performance issue and isn’t an acceptable solution. Disabling rendering to the background surface can cut your framerate down to about 30 FPS or worse. (Note that rendering to a CoronaPanel instead of the background makes sense if you’re adding nice 2D visualizations to business app, but not a fullscreen game like you’re doing.)
I’m going to try get this issue resolved by tomorrow.
Anyway it’s good to know that you found the lead. Thanks
Olaf,
The back key event issue has been solved. I should be able to send you a new version later this week.
Sounds great! Once you have it, would it possible that you put it in the same dropbox folder that David shared with me? Thanks!
Yes, I’ll arrange that with David.
Joshua,
I downloaded the new build and tested the back key - it works fine now, thanks!
Can you update my dropbox link too!