I can narrow down it to last few months.
Currently: transitions are failing and slowing down a lot.
And other thing - sprites are slowing down too much.
I can make a example performance test scene - to show off my problem.
Rob, can you let me know if there any ongoing “transition” and “sprite” fixes and know bugs?
Just a thought… could your hiccup be when GC kicks in? Maybe that changed between versions.
@efgames.net, we most certainly would be interested in a test case that shows your slowdowns. There have not been any signifiant changes to those areas recently. But I also don’t know what time frame you’re talking about. In the OP he was talking about going from 2744 to 3077. A lot can happen in that range, but we never plan to do anything that would lead to worse performance.
Rob
I have a few test-cases for different problems. I`ll prepare and post them here as well.
First one is most easy one - https://forums.coronalabs.com/topic/69646-20173109-building-for-win32-duplicate-main-execution-bug/
Second one is sprites - I have a big atlases and small atlases - with small - all ok, with big ones - is not. I`ll prepare a simple test-project tommorow.
We will also need to know more about the environment where this is happening? In the simulator? on device?
What version of Corona?
Windows or Mac (and OS versions)
And of course the test case would be great.
For issue #1, lets keep it on it’s own thread and keep this to the slowness issue.
Rob
Hey Rob,
I gathered a test scene: https://www.youtube.com/watch?v=6mlpxk9CdC8
Maybe cashing indexes of frames in atlas is not used? ( or not properly, or lua specific issue - you know better)
(bug - amount of frames are slowing down too much)
You can notice that molten metal is stop flowing at 0.25 here: https://www.youtube.com/watch?v=xcX7Ewv0f1c
If you like - I can make a test scene with that too as well. But I suspect you aware of this problem - since “transition” changes are in http://developer.coronalabs.com/corona-daily-builds/summary =)
(bug - “transition” is not reliable)
Should I make a another thread about them? Or this is something that is knowed? Or it is something that “is not important to fix this year”?
Since my games always on edge of CoronaSDK performance - would be great to know my limits here. Pity - I had to give up using “transition” for this project. As always - I`m using gameplay features to limit stuff on screen to control lag.
Here is a example of a game that I`m working atm(physics kicks in at 1:30): https://www.youtube.com/watch?v=OsoWGlmb5O8&feature=youtu.be&t=87
Transitions are ok for simplistic animation but when you are talking about lots of animating objects the library is doing too much extra work per frame which slows things down.
For hundreds of objects you will definitely have to bin off transition library and do it yourself in enter frame to get decent performance.
Can you explain this:
"But I suspect you aware of this problem - since “transition” changes are in http://developer.coronalabs.com/corona-daily-builds/summary =)
(bug - “transition” is not reliable)"
a bit better?
Rob
I use it for few things - when it failed at metal casting example - there are just two of them.
I use lot of sprites objects.
You suggesting me to write my own sprite library?
I was going to say have you tried just using an enter frame event and using setFrame() for your animation? I have 500+ animations now running at full speed on mobile by ditching transitions and “doing it myself”. This is on top of some 20k other display objects.
Number of frames (at least when changed manually, I can’t comment on sprite animations from the Corona side) should have no slowdown as it is a free operation as it is the same texture.
Regarding atlas size, generally the larger the better (try not to go over 2048x2048 as you will hit issues on older devices) as this has less draw calls.
Bug it self or that transition is on chage list?
Bug - transition failing to call onComplete, if there is a lag in game. As Example - caused by too many sprites with too many frames on stage.
Thing is - that 120 works fine in my test, but only if frames count is low.
Nope, I didnt. Should I? How many frames in your atlases(in average)?
I`ll try this today - using sprite.setFrame instead of realying on sprite methods.
My largest one has 146 frames. I use a few different atlases
Graphically, I am pushing a whole lot more through the open GL pipeline than your example and I can easily sustain 60 fps on simulator. I limit to 30 fps on device to conserve battery.
My game size is roughly 9000 x 4500 px so only a percentage ever fits on screen.
My smallest one is 150+, biggest is 300+.
I tryed to run my test without sprite:play() - and it is same results. Weird!
Are you using display.newSprite? Or you wrote totaly your own?
Can you take a look at my testScene?
https://www.dropbox.com/s/zzilcwjpgbncs31/TestWin32.zip?dl=0 (currently with commented sprite:play() method)
I`m now extracting your APK to check your atlases. =)
Your performance degradation is coming from your shader (and the fact that everything is global!). Global is some 30% slower than local.
Comment this out and I get 1000 sprites at 60fps solid
There are plenty small little optimisations to be made but the shader is your killer here.
Hope this helps.
Indeed. That is my killer. Tnx!
This is a just a test - it is not a game sources =)
I would like to have a option to redraw them in real time. Or atleast at loading stage - like duplicating atlases with shader on.
Then for gameplay I guess I have to display.save() atlases with shader already applied to them.
Tnx!
I resolved my problem with lag - https://www.youtube.com/watch?v=o6v0TCiX8kQ&feature=youtu.be
By prerendering atlases with applied shaders before using them in “display.newSprite”.