Now I am interested in reading a custom file inside config.lua to retrive FPS setting. That will be useful.
Joshua,
When would you be able to share with us the new update with the physics frame rate improvements that you made? I’m looking forward to test it out 
Thanks,
I’m still working on it. It’s taking me much longer than anticipated.
I did manage to improve the framerate (with my device) from 40 FPS to 45 FPS and make rendering a lot smoother, but I’m not satisfied with that. I’m still trying my best to get it to 60 FPS. The biggest problem I was having was that the Direct3D thread (which I don’t have much control over) would call into my code late every few frames which was making 60 FPS impossible. After a lot of experimentation, I think I’ve found a way to reduce how often Direct3D renders late (I still can’t 100% prevent it) which involves reworking our Direct3D surface handing code. I’m also going to change our code to be more tolerant of Direct3D’s lateness on WP8, such as if the rendering thread is too late and it’s time to render another frame, then give up rendering the last frame, call enterFrame in Lua, step the physics world, and attempt to render the next frame. This makes physics run at a smooth 60 FPS because we’re always stepping the physics world on-time. And so far, I’m only seeing rendering get skipped a few times per second, which isn’t noticeable at 60 FPS. In any case, that’s where I’m at.
I’ll let you know when I’ve got a solution. I’m hoping I’ll have something ready for you by the end of this week. Sorry about the delay. Unfortunately, it’s difficult to estimate something like this.
I understand, thanks for the details. I prefer to wait a little longer for better performance.
BTW: regarding the simplified native/lua communication wrapper that you came up with - do you think that the time schedule of 2-3 weeks that you were estimating a week ago is doable? Microsoft allowed me a one month delay for the release candidate version. So until August 1st I’ll have to submit a hidden full featured app to the Windows Phone Store with IAPs implemented…
I should be able to do the simplified Native/Lua bridge via hash tables within a few days.
It’s faster because I don’t have to create a C++/CX wrapper around the Lua library.
How is the rest of WP8 features working out for you? Any other issues?
Whoa, that would be great! Thanks a ton!
Apart from the physics slow downs everything else works well. I’m really happy with the audio performance. There are just two other minor glitches that I noticed:
-
sometimes transitions stop a little bit earlier than they should - without completing the whole animation. I think it might have something to do with the timer adjustments issue that you were mentioning. Maybe they are deployed later, but stop on time?
-
when I hit the middle start (windows) hardware button, sometimes I don’t get a lua applicationSuspend event, although sometimes I do. Also - this button (in contradiction to the closing back button) should suspend an application (I get a native deactivate application event) but when I open the app again - but it loads up again from the beginning
When you have the communication bridge ready, could you also guide me then in a few steps on how to use it? Thanks,
>> I’m really happy with the audio performance.
Oh good. We wrote our own OpenAL library for WinRT from scratch and I’m glad this initial version is working out so well. We even threw in AL_PITCH support, which is a hidden API in Corona, but some Corona developers are actively using it. We just don’t support the hidden positional audio feature on WP8.
http://coronalabs.com/blog/2011/07/27/the-secretundocumented-audio-apis-in-corona-sdk/
The only issue with audio that I’ve noticed is that if you suspend/resume several times with streaming audio running (like music), then sometimes the streaming audio stops running upon resume. You might want to give it a quick try on your end to see if you can reproduce it too.
>> sometimes transitions stop a little bit earlier than they should
Right, that’s the timer issue I was telling you about last week. The next version I’m going to give you will resolve this.
>> sometimes I don’t get a lua applicationSuspend event
Yeah, this is a loose-end I haven’t had time to figure out yet. I got it working reliably when pressing the Search button and backing out of the app, but I’ve noticed the Home button always force quits the app, which appears to be WP8’s default behavior. That is, the Home button does not work like how it does on Android. I think Microsoft is changing his behavior in 8.1 to make it work more like Android, but I don’t yet know if that Home button behavior change is for both 8.0 and 8.1 built apps or just for 8.1 *.AppX apps.
>> When you have the communication bridge ready, could you also guide me then in a few steps on how to use it?
Absolutely!
I’m using AL_PITCH as well and so I was happy that it was implemented.
I tested the music pausing - yep, when I paused my game 10 times, there was one time when the music didn’t resume, but on the next pause/resume it started playing again.
Regarding the home (start) button functionality - according to MS documentation it shouldn’t close the app (like the back button), but should push it to the background:
http://msdn.microsoft.com/en-us/library/windowsphone/develop/dn148258(v=vs.105).aspx
>> I’m using AL_PITCH as well and so I was happy that it was implemented.
I’m glad AL_PITCH is working for you.
>> I tested the music pausing - yep, when I paused my game 10 times, there was one time when the music didn’t resume, but on the next pause/resume it started playing again.
I’m starting to think that this might be a core Corona issue that might happen on other platforms based on what I’m seeing in our code. I’ve seen a similar bug report on iOS and Android in the past. If you suspend/resume several times on iOS or Android, does the streaming music sometimes stop too?
>> according to MS documentation it shouldn’t close the app (like the back button), but should push it to the background:
But it will. Microsoft does not guarantee that the app will be resumed when returning to your app after pressing the Start button. They threaten that the device might decide to “tombstone” it. To prove it, put break points in your “App.xaml.cs” file’s Constructor, Deactivated, and Closing event handlers and launch your app. Notice that when you press the Start/Home button, it’ll Deactivate as expected, but when you go back into your app, it’ll break in your App class’ constructor. This proves that the Application was terminated and being re-created when re-launched. The same behavior can be observed with a WP8 app made with Microsoft’s project templates. It’s not caused by our Corona library.
Microsoft documents this here under the “Deactivated” section…
http://msdn.microsoft.com/en-us/library/windowsphone/develop/ff817008(v=vs.105).aspx
In my experience, this tombstoning behavior always happens when pressing the Start button. I’ve yet to see a WP8 device resume an app afterwards, but I wonder if it might have something to do with how much RAM is available on the device. The Lumia 920 that I typically test with is considered a low memory device.
I’ll work on this later. The XAML events we’re currently depending on to raise system events in Lua work in all cases *except* for the Start/Home button. So, we’ll just have to hook into other events to get it working right. Just another to-do item on the list. We’ll get to it. 
One more thing app pressing the Start/Home button. I figured out what’s going on. If you press the Start/Home button and then tap on your app from the app listing, it will *always* restart your app. However, if you hold down the Back button to bring up the “Fast App Switcher” and tap on your app from there, then it will resume.
http://msdn.microsoft.com/en-us/library/windowsphone/develop/jj735579(v=vs.105).aspx
I remember figuring that out a while ago and I guess I forgot how it works again because I’m used to Android’s behavior.
I remember other WP8 app developers complaining to Microsoft about this, asking them to change the behavior to be more like Android on 8.1.
Pressing the Back button after pressing the Start/Home button will resume your app too.
Oh! I didn’t even know about the “fast app switcher” to be honest Yep - it works like you say. It’s resuming the app instead of relaunching it. Thanks for the info.
Regarding the music pause/resume on iOS - I haven’t noticed this behaviour, but maybe it’s just not as frequent as on WP8. Can’t say.
>> Yep - it works like you say. It’s resuming the app instead of relaunching it. Thanks for the info.
No problem! Honestly, I keeping forgetting that this is how WP8 works too because I’m so used to Android’s behavior.
>> Regarding the music pause/resume on iOS - I haven’t noticed this behavior
Okay. Fair enough. I do know that we have some old closed out bugs on this on Android and iOS. I’ll dig into how this issue was resolved on those platforms later.
In the meantime (and if you don’t mind), you should be able to work-around this issue by calling audio.pause() on your streaming music upon “applicationSuspend” and then upon “applicationResume” call audio.play(). That’s how Corona developers used to worked-around this on iOS and Android in the past.
Other than that, how is everything else working out for you on WP8?
Oh and in regards to 60 FPS. I’m still struggling to achieve this. It’s proving to be quite difficult to do this on WP8. Every solution I’ve tried has had some kind of negative impact on something else.
At this point, I’m thinking that if I can’t come up with a reasonable solution by the end of today, then I should punt on this issue and starting working on that Native/Lua bridge instead and the other nagging issues (like timers elapsing too soon, audio not resuming, etc.). That way I’m not blocking you from implementing in-app purchase and other tasks. Does that sound reasonable at the moment?
I agree, I think it would be the best decision for now. But could you include the improvement you already achieved in the next update?
But there’s sth more - I’ve just tried to upload a test xap package made with CoronaCards to my MS dev center but the package didn’t pass the validation:
1028: The native API api-ms-win-core-debug-l1-1-1.dll:OutputDebugStringA() isn’t allowed in assembly CoronaLabs.Corona.Component.dll. Update it and then try again.
1028: The native API api-ms-win-core-localization-l1-2-0.dll:FormatMessageA() isn’t allowed in assembly lua.dll. Update it and then try again.
1028: The native API api-ms-win-core-synch-l1-2-0.dll:CreateMutexExA() isn’t allowed in assembly almixer.dll. Update it and then try again.
Should I make a build in a specific way to skip these APIs, or it’s on your side to remove it?
It’s on my side to remove. I didn’t realize ASCII version of those functions were not allowed on the app store. Interesting since those functions are publicly available. Anyways, I’ll change them over to Unicode wide character version next week. Thanks for bringing this up.
Oh and yes, I’ll add the other timer improvements I talked about before.
Here’s a current update on the 60 FPS issue so far. I can only get it to render at 60 FPS if I do absolutely nothing on the main UI thread. As soon as I do anything interesting on the main UI thread (or perhaps any thread?), even if only by a 3-4 milliseconds, it seems to have a negative impact on the Direct3D rendering thread and I can only get about 40-45 FPS. Even if I happen to do everything with the 16 millisecond timeframe needed for 60 FPS, the rendering thread still skips a frame on every few frames. That’s incredibly frustrating and it makes it sound like 60 FPS might be impossible with a XAML based app… at least on the phone I’m testing with.
The alternative solution that I was talking to you about before was to update Corona and its physics on-time 60 times a second and render when I can (because the rendering thread appears to be lazy and is out of my control). With this approach, I can update Corona on-time 60 times a second, but only render 40 times a second. So, from a Lua and physics standpoint everything appears to be running at 60 FPS, but the display will only render at 40 FPS. Still better than 30 FPS, but it’s still not truly 60 FPS.
Is it better if you don’t use physics at all?
@Joshua, I meant the improvements to fps that you made. If there are no visible slow downs now then maybe 40fps would appear smooth enough for our needs, at least for now. I’d be happy to test it.
The main issue in my game is that the physics frame-rate slow downs are getting bigger after time. It looks that after every following level load I have worse physics performance.
I though that it might be caused by a memory leak, but I checked and I have only 2-5kb leaks so it shouldn’t be an issue. When I load the first level, physics response is decent, some slow downs appear, but nothing serious. But after I load the level several times - the slow downs are getting more and more visible. I even tried to call physics.stop() and remove all scenes before loading the next level but it doesn’t help the performance.
I don’t have this issue with the same code on iOS, only on WP8, and I’m curious if the changes that you already made to the physic speed calculations would help to solve that issue.
Without physics, such as our “Graphics\Fishies” sample app, I’m seeing about 5-10 frame improvement. So, it renders at about 45-50 FPS. Interesting since the other app I was testing only adds about 1-2 millisecond overhead with physics, well within the 16 millisecond time period needed for 60 FPS.