Very poor performance on MAC/PC builds. Test project included

Solar2D macOS Desktop
#21

On Windows, if I use a simple programme like RTSS to cap the FPS on my app at 60, the microstutter disappears. 

I really hope that this is something Corona staff can look at-- it’s not an issue with the developers’ apps but with the engine and suggesting that Corona is now open source and the community should fix this is not something that induces a lot of confidence for a developer who probably uses Corona because of how it’s advertised as a beginner-friendly framework.

I don’t use Corona because it’s open source but because it allows me to focus on designing my game and am willing to purchase whatever subscription/ license that’s necessary if that means that I can expect that these fairly serious issues with the engine will not be ignored. 

Basically, desktop apps that have any sort of constant motion of objects are downright impossible to build with Corona. 

#22

Seems fine on my MacBook Pro (Retina, 13-inch, Late 2013). Although a bit choppy when running on Windows 7 in Parallels.

On an i7 32gb Windows 10 machine with GTX 1060, it runs smoothly although not so much in the simulator.

I’m on Corona version 2019.3474.

Just downloading the latest daily build onto my work machine which only has integrated graphics - it’s taking ages so will report back later.

#23

It’s a tiny project and sometimes it can be a little subjective-- you might be able to see it if you are able to make a quick Android build and then compare it with your Mac build. 

I’ve tried running this in the last 30 or so minutes on a MBP 2015 OS HighSierra, 2 IMacs (2012) OS HighSierra, A Lenovo Win 8.1 AIO (i5, Nvidia 800a), HP laptop Win 10 (i5 , intel HD), Toshiba Ultrabook Win 7 (i5, SSD) and it’s been quite choppy on all these devices. 

All have at least 8GB of RAM and authentic OS installations. 

Extrapolate this to a much bigger project with faster scrolling, animations, particle effects etc. and it becomes unplayable…

#24

Tried it on the HP Laptop - it’s i7 16GB but integrated graphics. Agree the performance is terrible. Integrated graphics aren’t completely useless anymore and should be able to handle what you’re doing no problem. Certainly I see much better performance from Unity games on similar machines.

#25

I had posted regarding this issue earlier but then eventually deleted. @Rob could you please have a look at this and perhaps link us with one of your technical staffs. This is a rather serious issue and given how things are we can’t publish games on steam.  

#26

I ran the test project and built it as a MacOS app. I have a new MacBook Pro 15" 2018 2.6GHz i7 with 16gb of ram, dual GPU with a Radeon Pro and Intel UHD.

The performance was quite smooth in the simulator and I saw identical performance running the built MacOS app. I don’t see any chop at all. I’ll try it on a fairly low in Windows machine in a bit.

Rob

#27

Yes, please do that, Rob. We are typically not quick to post on the forum and do our absolute best to examine the code, optimise it and use best-practices all throughout to achieve good performance and we’ve been working for a very long time on Corona. 

There are three individuals on this topic who already claim to have experienced low performance with what’s nothing more than a tiny demo project so I have to say that the problem is quite real and if we are unable to fix this, our project-- which we started in December of 2017-- will be dead.

The game that we are unable to run properly on Desktop has over 150000 installs on Android + iOS and there were never any performance issues on mobile. 

We are, quite frankly, desperate for some help.

#28

short answer is:  your delta time is not precise enough.

long answer:  how well a delta time approach (as you use) works is entirely dependent on how “good” the system timer is.

most c libraries (upon which lua is built) query a hardware timer that (on PC’s) has a resolution of 1/64 sec (15.625ms).

(most “real” Windows games, ie native code, typically use a much higher precision performance counter w nsec resolution)

i’ll let you work out how well 1/64th resolution ticks would line up with a desired 30 or 60 fps framerate.  (hint:  it’s not good)

but it’s worse than that, because even THAT resolution isn’t guaranteed - it may only be 10ths of seconds, or whatever OS resets it to.

to “prove” it to yourself:  query the timer rapidly in a tight loop, notice all the duplicate values??  that’s your problem.

for i = 1,100 do print(string.format("%f",system.getTimer())) end

i don’t know exactly what results you’ll get on your system(s), but you’ll probably see a fair degree of “precision” (how many ‘significant digits’ are reported) but not much “resolution” (how many unique values are returned at what frequency).  google it, well-known problem.

#29

I ran it on an older Lenovo laptop and it was choppy, but it was also choppy in the simulator. I didn’t see much of a difference between the two.

Rob

#30

I don’t know the configuration of your laptop but do you reckon this project should be choppy on your device? I can confirm that I see the choppy scrolling on our simulators AND desktop builds but never on mobile builds.

For the test project, I’d imagine this is something that any device that can run the Corona simulator will be able to handle, no?

#31

It says it’s an i7-5600 @2.6ghz with 8gb of ram but I’ve had it since at least 2014 and it has a terribly small hard drive. so I could be swapping a lot.

It seems like the more it runs the better it gets, but it’s not as smooth as it is on the Mac. Task Manager didn’t show any stress going on with regards to memory, gpu, disk etc. But keep in mind, Corona/Lua is single threaded and my Lenovo CPU is considered a low power CPU, so it’s not.

It’s possible depending on the Android device, that it’s faster than the PC you’re running on.

#32

davebollinger: if the issue is the delta time calculation why is the same stuttering visible when you remove it and just move everything by a constant value per frame? We shouldn’t be getting framedrops on such a simple project, no matter the machine.

#33

This.

The first thing I had done during testing was to take delta out of the equation and hardcode the value of translation. Speeding up or slowing down of the scrolling behaviour, as expected, was present, but the stuttering was still there and it is clearly nothing to do with how it’s been programmed. 

@Rob, any chance you can please have someone look into this at least briefly? I think it’s only reasonable to expect such a simple project to work without these issues on most machines.

#34

64-Bit Android is the priority. I’m not sure when we will have to time to look at this. I’ll put it on the list. But if I’m being honest, the queue of higher priority updates will not bubble this up any time soon. Corona is open source. So this is something I think the community can grab the source and see if they/you can find the problem. 

Rob

#35

i doubt that the choppy/stutter/jitter you’ve described is an actual dropped frame, rather it’s just inconsistent per-frame timings.  imagine one frame at 28fps, the next at 32fps, repeat - your AVERAGE framerate still works out to 30fps, but a fixed motion per-frame will appear jittery.

corona ITSELF is subject to the same hardware timer limitations - it’s frames are NOT perfectly 30fps.

i haven’t checked source but I’ll bet you it’s using an api like GetTickCount() or equivalent, which is totally inadequate for this use.

issue is:  fixed-motion with varying frame times - but whether you attempt to fix it via the first (dt motion) or the second (try to make frame-time fixed by sleeping dt), it just doesn’t matter if you can’t accurately calculate dt.  they are literally “reciprocals” of the exact same problem, and neither can be fixed without a better timer.

probably the best fix would be a native plugin for the QueryPerformanceCounter api then use THAT to calculate your dt for motion (it’s the easier route, since you can’t apply it to the frame rate dt without recompiling core - a way bigger task).

#36

I’ve never understood why frame rate was so wildy inaccurate but 1/64 resolution would certainly explain it.

Frame rate using enterFrame is +/- 25%

#37

It’s a shame that there is no straightforward way to cope with this-- my research over the last two days shows that this is obviously a phenomenon that is also seen in other engines like Unity etc so I’m not blaming Corona per se but just a little frustrated that there’s no workaround.

Clearly it’s not a performance issue as there are plenty of threads here dating back to 2014-15 regarding the stuttering even when trying to move a single display object across the screen but there doesn’t seem to have been a proper resolution so far. I confess I don’t have detailed knowledge of how these things work at the low-level but not having API access to more advanced features only makes it harder. 

#38

i’ll restate that a native plugin for QueryPerformanceCounter (on Win) and whatever it’s equiv is on OSX (mach_absolute_time?) would probably be easiest solution.  (that is, unless you have the clout to convince corona engineering to build equivalent into core)

baby steps:  the whole problem with a delta time correction in dev’s lua code, is that it must presume that it can do a “better” job of tracking time that corona internals which already attempt to calc delta time in order to deliver a stable frame rate.

iow, if corona itself could calc time precisely, then it could deliver precise frame rates, right?  (and you wouldn’t even need to worry about doing your own delta time correction in that case!)  but it can’t, so it’s folly to think that a dev’s lua code is going to do any better than corona internals, given roughly same quality timers to work with.

nyquist theorem will support that you need at least double the clock rate to reliably approximate a frame rate, and even that is barely enough, would just achieve an “average” of that frame rate, with significant jitter - and that’s what happens on Win builds now.  but what you really want is to precisely hit the “rising edge” of that timer signal, to get a rocky-steady frame rate, so you’d need your timer to be several orders of magnitude “finer” than your frame rate*, and GetTickCount (on Win) is NOT going to achieve that.

* (basically needs to be at least double your tolerance for a _single _frame’s timing, fe if you need your frame time to be 16.667ms +/- 0.01ms, then you need a timer of at least 0.005ms resolution, while GetTickCount is something like 10-17ms resolution)

#39

Well, I’m not sure about the rest, but I find this interesting and I’m learning a lot. Thanks @davebollinger! :smiley:

#40

Delta time will only correct for dropped frames/long frames.  It will not fix something inherently broken in the core.

It is a bit ridiculous that this is even a thing.  If you set 60 fps you’ll get frame times between 12 and 20 ms.