Personal Edit: I have verified with Corona that this is not an imposed SDK limitation and is likely a simple performance issue. The source of which is currently unknown.
Using the latest public build (2013.4.3) I noted that the animation seems less smooth on larger resolution displays and that my game is now running at 30 frames per second.
Is this an intentional crippleware effect from using the starter trial license? Perhaps a bug? The game ran fine on my previous build (2012.something).
Hi @evesoftware1,
There was no “crippleware” to the FPS introduced with Starter, so I think there’s some other issue here. The following Code Exchange module hasn’t been updated in some time, but it should still allow you to check your actual FPS and see the values it’s reporting.
http://developer.coronalabs.com/code/output-fps-and-texture-memory-usage-your-app
Also, you mention that the performance seems slower on “larger resolution displays”. Can you give me a list of your test devices, your config.lua setup, how you’re coding these animations, or whatever else seems relevant?
Thanks,
Brent Sorrentino
Thanks for the quick response Brent!
it’s locking in around 30FPS when the game is being played on the device and approaching 70 on the simulator. I did a little bit more testing though and it seems to be a simple performance issue and not an imposed limitation. When I blank the screen, the device displays 60-70 fps.
A side note: I thought the screen refresh was vsync’d so it’s unusual for me to see it fluctuate so much.
This code on the same device with an earlier Corona version ran incredibly smoothly and there hasn’t been any changes to my own code aside from small, specific changes (changing default to defaultFile for buttons to conform to the new API guidelines.)
I’m using transition.to() for the animations, but the animations aren’t affecting the FPS at all (it stays at 30FPS whether they’re animating or not). I’m not sure what to attribute the new performance issues to.
My device is an ASUS transformer prime TF201. It has a fair amount of processing power and has a nvidia graphics chipset. When I force hardware 2D rendering it does not increase application performance. I’m going to try and test the new build on another device (Samsung Note phablet) to see if the issue is present on that one as well. I just need to find the dang thing.
Perhaps now Tony could take back a few harsh words said so needlessly. What you see on the “compare plans” page is what it is. I would never suspect they’d be crippling the software intentionally in order to gain sales. The are a business, and every business needs to survive, but they also pride on being developers trying to help developers. I know that many of the littlest and nuanced things that we’ve asked them for, they’ve been able to provide because they know we could make good use of it, and it’s that little edge that makes the difference between this and other engines.
They did remove in-app sales for the bottom-tier, verifying they did implement restrictions to the basic software package. I would expect that a restructure of pricing and introducing a free bottom-tier would include such restrictions. My intent is more to get to the bottom of the problem, though.
I have no intent on bashing the company, especially considering how much this tool regularly improves my productivity.
I can verify that 2 builds using the same code (aside from aforementioned changes for API update reasons) one runs at half the framerate on 2 separate devices:
ASUS Transformer Prime TF201
Samsung Galaxy Note Phone
I would not mind so much but it seems to be an actual drawing performance issue that leads to inconsistent framerate. If I was locked in at 30FPS, movement would be consistent, smooth, and locked to 1/2 vsync. However the inconsistent drawing refresh creates a jerky and awful feeling when playing.
Hi @evesoftware, Raphael,
“tony arnold” has been blocked. There is clear evidence of a single person creating and using numerous aliases/accounts to post comments that are disruptive and add nothing to the discussion. We have a policy of allowing constructive and frank discussions, but spamming/trolling the forums is not allowed.
I apologize for this. When I’ve resolved this, I’ll get back to addressing your questions, @eve.
Thanks for your understanding,
Brent Sorrentino
Thanks. Feel free to modify the title to indicate this is a performance issue and not an imposed limit as well. I don’t want to give the wrong impression
Noticing some performance issues in the simulator too in my main menu that I had not mentioned earlier. It’s usually smooth as well on the device, however on both the device and the simulator it’s taking a performance hit.
There is no secret “crippling” of features/performance in the Starter version. We do make upgrades and fix bugs and sometimes those affect performance which we didn’t notice. If you do see what you feel is a performance change, please try to duplicate the issue with our sample code or submit a bug report with a small project that demonstrates the issue and details on the changes you see and how to reproduce the problem.
Tom – I would like to assist in hunting this performance issue down. I think the demos would not demonstrate this bug because they (for the most part) all use low resolution, non-retina graphics and few on-screen objects. I am using a grid of 8x13 buttons arranged like this:
My devices are all high resolution (see full snapshot here: http://www.markhamilton.info/wp-content/uploads/2013/04/Screenshot_2013-04-05-11-42-52.jpg ) so they require high pixel density game assets.
So in essence you would like me to create a demo that creates such a grid using high-resolution graphics, submit a bug report with it, then you (collectively) would be able to test the performance difference between 2012.* and 2013.* builds? Should I include the framecounter module that Brent recommended?
Hi @evesoftware1,
So, just a quick recap, the performance seemed to change drastically after using “defaultFile” with the new widgets? Did you add any other high-resolution “HD” graphics or something that would chew up texture memory and thus drag down performance?
Thanks,
Brent
That is correct. No asset changes were made
OK, and if you’re using widgets, how many do you use? Just a few, or many? Are you ensuring that they are properly removed from memory on scene change, and all references/listeners cleared? I know that sounds “obvious” but I just want to confirm.
During game mode: 105 buttons, 1 text object. All are removed as well as their tap handlers and memory usage doesn’t ever go above 1.1MB. If I start out in this scene mode there are no scene transitions being used and it just creates and enters the scene without effect. This will jump between 25 and 32 FPS, roughly.
During the main menu: between 30-40 physics objects, 4 buttons, one label. They get spawned and removed as needed. I have tested that the objects get removed and the object count never grows wildly. The frame counter varies from 30 to 50 and sometimes peaks at 70.
I may do another test here and see if using lower resolution textures impacts the framerate.
Also important to note is that there are no animations in the main game mode until you tap on something. Then, the bricks will collapse into their new positions (which is when the low framerate is noticeable). However when the objects are static the FPS is still affected despite the objects being static.
Half resolution graphics improve performance significantly. I can’t really measure how much it does, but subjectively speaking it’s feeling slightly smoother. It’s not hitting 60FPS like it was before, though.
OK, next test… can you run this function under a timer of 1000 ms and watch the values of *texture* memory in specific, between scenes?
[lua]
local function memPrinting()
collectgarbage(“collect”)
local memUsage_str = string.format( “MEMORY = %.3f KB”, collectgarbage( “count” ) )
print( memUsage_str, "TEXTURE = "…(system.getInfo(“textureMemoryUsed”)/1048576) )
end
timer.performWithDelay( 1000, memPrinting, 0 )
[/lua]
menu:enterScene
menu:orderScene
MEMORY = 647.854 KB TEXTURE = 0.28564453125
MEMORY = 653.914 KB TEXTURE = 0.28564453125
MEMORY = 660.094 KB TEXTURE = 0.28564453125
MEMORY = 661.168 KB TEXTURE = 0.28564453125
MEMORY = 663.965 KB TEXTURE = 0.28564453125
MEMORY = 663.707 KB TEXTURE = 0.28564453125
MEMORY = 663.715 KB TEXTURE = 0.28564453125
MEMORY = 663.223 KB TEXTURE = 0.28564453125
MEMORY = 663.219 KB TEXTURE = 0.28564453125
MEMORY = 661.730 KB TEXTURE = 0.28564453125
MEMORY = 662.738 KB TEXTURE = 0.28564453125
MEMORY = 663.262 KB TEXTURE = 0.28564453125
menu:exitScene
ENTERING NEXT SCENE
gamebricks:enterScene
MEMORY = 655.088 KB TEXTURE = 1.28564453125
Transition complete
MEMORY = 651.852 KB TEXTURE = 0.28564453125
MEMORY = 651.742 KB TEXTURE = 0.28564453125
MEMORY = 651.742 KB TEXTURE = 0.28564453125
MEMORY = 651.742 KB TEXTURE = 0.28564453125
MEMORY = 651.742 KB TEXTURE = 0.28564453125
MEMORY = 651.742 KB TEXTURE = 0.28564453125
MEMORY = 651.742 KB TEXTURE = 0.28564453125
MEMORY = 651.742 KB TEXTURE = 0.28564453125
MEMORY = 651.742 KB TEXTURE = 0.28564453125
MEMORY = 651.742 KB TEXTURE = 0.28564453125
MEMORY = 651.742 KB TEXTURE = 0.28564453125
MEMORY = 651.742 KB TEXTURE = 0.28564453125
MEMORY = 651.742 KB TEXTURE = 0.28564453125
MEMORY = 651.742 KB TEXTURE = 0.28564453125
MEMORY = 651.742 KB TEXTURE = 0.28564453125
MEMORY = 651.742 KB TEXTURE = 0.28564453125
MEMORY = 651.742 KB TEXTURE = 0.28564453125
MEMORY = 651.742 KB TEXTURE = 0.28564453125
MEMORY = 651.742 KB TEXTURE = 0.28564453125
MEMORY = 651.742 KB TEXTURE = 0.28564453125
MEMORY = 651.742 KB TEXTURE = 0.28564453125
MEMORY = 651.742 KB TEXTURE = 0.28564453125
MEMORY = 651.742 KB TEXTURE = 0.28564453125
MEMORY = 651.742 KB TEXTURE = 0.28564453125
MEMORY = 651.742 KB TEXTURE = 0.28564453125
MEMORY = 651.742 KB TEXTURE = 0.28564453125
MEMORY = 651.742 KB TEXTURE = 0.28564453125
MEMORY = 651.742 KB TEXTURE = 0.28564453125
Emphasis placed on transitions. You’ll see high texture memory usage during a custom scene transition that I created which creates a custom fading wipe effect.
Another sidenote:
Changing the performance mode on my TF201 (which regulates clock speed of the processor) has no impact on framerate indicating it’s probably a rendering issue rather than something hinging on CPU performance.
This is puzzling. 
Are these values using the half-resolution graphics, or full?
