game LAGS on physics collision

CoronaCards (Corona in native apps) CoronaCards for WP8
#61

Olaf,

I’ve been playing around with some of our physics apps.  I’ve discovered that the physics performance runs perfectly at 30 FPS, but at 60 FPS, physics objects appear to move at half the speed compared to 30 FPS.  Kind of an odd phenomenon that I’ve never seen happen on any other platform.  I tested this with our “ManyCrates” and “Chains” sample apps included with the Corona Simulator.  I’ll investigate to see what’s going on.  In the meantime, you’ll likely see better performance if your comment out the “fps” setting in your “config.lua”.  I know it seems crazy, but it actually improved performance.  (You’ll still have to avoid text updates and prints to see the impovement.)

#62

Okay.  I think I know what’s going on.  By default, physics is framerate based, meaning that if the framerate slows down (ie: less than the configured FPS) then you’ll see the physics system slow down too.  Due to WP8 timer lateness issues that I was telling you about before, it looks like we’re not quite achieving 60 FPS which would cause a slow-down effect.

You can work-around this issue by changing the physics system to be time based.  You can do this by doing the following…

physics.start()

physics.setTimeStep(0)  – Setting this to zero makes it time based.

That said, I’m not sure if this is the issue you are seeing.  I’m not seeing any collision performance issues like you.  I’m seeing a framerate problem where we’re unable to achieve 60 FPS consistently causing physics system slowdowns.  (I’m going to look into improving the framerate later.)

Anyways, I hope the above info is useful.

#63

Thanks Joshua, I’ll test it out today and will let you know the results. Should I make this physics.setTimeStep(0) call after every physics.start() call or just once after the first start?

#64

OK, so it seems that the lags are caused by what you were saying - inconsistent physics frame rate. When I call physics.setTimeStep(0) (I do it once at the beginning) - it seems to look better (consistent frame rate), although it has consistently jitter motion as well. There are no slow downs but it’s generally not so smooth looking.

I tried to comment out the fps settings in config.lua, but here I get the same results running 30fps as with 60fps: there are frame rate slow downs if I don’t call setTimeStep(0), but once I call it - slow downs disappear, although the motion isn’t that smooth in general.

Does it make any sense?

#65

Okay.  So it definitely sounds like a framerate issue then at this point.

I’m not seeing the jitter effect that you are seeing.  At least not with our physics sample apps.  Although, you probably would see an effect like that if you loaded an image during gameplay.  Are you loading all images and imagesheets into memory before starting your game?

And regarding the physics.setTimeStep() function, you only have to call it once.  You don’t have to call it after every physics.start() as you have observed.  The system remember what you’ve last set it to.

#66

Yes, all my objects are preloaded as an imageSheet so this shouldn’t be an issue. The jitter I’m observing isn’t that obvious but it’s the general feeling that the motion isn’t super smooth as it is with the frame-rate based physics simulation (apart from the slow-down parts, of course).

Maybe it’s because the time base simulation is a bit offset to 60 or 30 fps, and that’s why the movement calculations don’t look that smooth? I don’t know, just guessing. If you could check later what’s causing the the frame-rate simulation slow-down, it would be great. Thanks.

#67

After some testing I noticed that there are tiny slow downs also in a time based physics simulation. They are not so obvious like the ones in a frame rate based simulation, but it seems that something is causing the phycis frame rate inconsistency here as well. Just letting know.

#68

Olaf,

I’ve been spending time looking into improving rendering performance for the last couple of days and improving framerate/timer accuracy.  Particularly for 60 FPS apps.  I’ve noticed that on my Lumia 920 it was taking at least about 20 milliseconds to update/render per render pass and most of that time was with synchronizing the UI thread with the rendering thread.  I’ve managed to reduce that time by 10 milliseconds, making a huge performance improvement.  I’m now getting about ~45 FPS on a Lumia 920.  Unfortunately, I don’t think it’s possible to get it to render any faster on that particular device.  At least with a XAML based app, because Corona is competing with Microsoft’s XAML UI framework for the rendering thread (i.e.: there is only 1 rendering thread on WP8 and it must be shared) and about every few render passes there is an “additional” 10-15 millisecond delay until XAML UI blocks us.  Note that in order to achieve 60 FPS, we must be able to render every 16 milliseconds, and that delay is making it impossible.

Now, if this was a pure DirectX C++ WP8 app, no XAML, then I think it’s absolutely possible to achieve 60 FPS because we would then have absolute control over the rendering system (i.e.: not competing with a UI framework for rendering time).  But a XAML based app is needed if we want to support native UI and ad libraries in the future, which is a requirement for many Corona developers.  Plus, some features are only available on the .NET side, making a XAML based app required as well.

Interestingly enough, I know that Unity for WP8 is a XAML based app as well.  I remember chatting with them and Appcelerator last October, hearing that their WP8 apps were 30 FPS.  I can’t help but think that they’re running into the same issue I’ve mentioned above because they’re competing for the rendering threads time too.

In any case, I did make significant performance improvements and I plan on sending out another update in the middle of next week.  It should be noticeably smoother.

I’ll also talk with my Microsoft contacts on getting that version tested by them on a higher end WP8 device to see what the framerate is.  Interestingly enough, they consider my Lumia 920 a low-end device, so, I’d be interested to know how well it runs on their better devices.  Just note that it may take 1-2 weeks until I can those test results from them.

#69

Joshua, Thanks for the update and your effort! 'll test it out, but 10ms faster sounds like a good improvement. I didn’t realise that Unity WP8 apps run in 30fps only. Probably it’s the general problem then. If it runs smoothly at 30fps without slow-downs, that would be something acceptable in a gameplay. Because now, as I mentioned you before, I’m seeing slowdowns even at 30fps with frame rate simulation and tiny slow downs with time based simulation. Thanks in advance for sharing the next build wih David in the same Dropbox folder as you did last time.

#70

According to the statistics, Lumia 520 is the most popular windows phone. So it makes sense targeting this device and I presume 30fps would be the maximum for it.

Will we be able to set FPS in config.lua dynamically during startup or at the runtime in the future?

#71

>>  didn’t realize that Unity WP8 apps run in 30fps only.

That’s from what I was told last year.  I’m not sure how it is today.  I’ve briefly searched Unity’s forums on this topic and there does appear to be several developers struggling to get a good framerate.  It did seem like some developer managed to get it above 30 FPS though, but not quite reach 60 FPS either.  My general searches on the 60 FPS topic (non-Unity based) is that you really need to build a pure native C++ DirectX app to get that high framerate, which means you lose the other features I mentioned above.  In any case, I think that 10 millisecond improvement per render pass was a huge improvement, but I’ll let you guys be the judge of it on the next update I send out.

>> According to the statistics, Lumia 520 is the most popular windows phone.

Yeah, I’ll have to make sure to test it on that specific device.  I know that Microsoft is trying to tackle the low-cost phone market like Android did, so, achieving good performance on low-end devices I think is important too.

>> Will we be able to set FPS in config.lua dynamically during startup or at the runtime in the future?

That’s actually possible to do now on iOS and Android.  You can call the system.getInfo(“model”) function to fetch the device’s model name.  This is more useful on iOS than Android.  You’re not able to fetch device model on WP8 yet.  It’s on my to-do list.

#72

Lerg said: >> Will we be able to set FPS in config.lua dynamically during startup or at the runtime in the future?
 
That’s actually possible to do now on iOS and Android.  You can call the system.getInfo(“model”) function to fetch the device’s model name.  This is more useful on iOS than Android.  You’re not able to fetch device model on WP8 yet.  It’s on my to-do list.

:huh:  @Joshua.  I don’t think that’s what @Lerg was asking…

#73

You can make a call to system.getInfo() within the “config.lua” file and set parameters dynamically, such as FPS.  You can then set the FPS by the device’s model name.

#74

Now I am interested in reading a custom file inside config.lua to retrive FPS setting. That will be useful.

#75

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 :slight_smile:
Thanks,

#76

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.

#77

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…

#78

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?

#79

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,

#80

>> 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!