Update on Performance?

Lime
#81

At present the new version of Lime is not using ImageGroups because of the limitations. i.e. they all objects must come from the same image, this will be tricky as Lime/Tiled uses multiple images for the different tilesets.

Currently I just use the ImageSheets and the Culling as that is on by default, Jonathan has told me that those are the two features that will probably help Lime the most. [import]uid: 119420 topic_id: 12910 reply_id: 99479[/import]

#82

My apologies in advance for a long and indulgent post. If bored, skip to the conclusion. If very bored, you probably haven’t reached these words so no harm done!

I have spent the last couple of days messing around with image sheets and image groups, and it is impossible to be 100% accurate regarding performance gains due to the bugs that prevent me doing direct code comparisions, but my findings are as follows (in each case, the differences between A and B are in italics):

The first test should have been a direct comparison between old and new methods, but was prevented by the fact there is a crashing bug when you combine new display groups, :setFrame and making sprites visible / invisible.

Comparison 1:
A) Old sprites, .currentFrame, old display group, visible / invisible toggle
B) Image sheet, new sprites, :setFrame(), old display group, visible / invisible toggle

Results:
A) 26 fps.
B) 26 fps. Interesting…

The second comparision came about as a result of me initially thinking the bug was caused purely by the :setFrame(), so I simply removed it, while using as many other new features as possible.

Comparison 2:
A) Old sprites, old display group, visible / invisible toggle
B) Image sheet, new sprites, new image group, visible / invisible toggle

Results:
A) 28 fps.
B) 60 fps. Note it could well be higher but of course the settings limit it to 60fps max.

The third comparison was to find a way to compare between the new methods but where the only variable was using old display groups or new image groups. To achieve this, due to the previously stated bug, instead of making sprites visible or invisible, I set ‘invisible’ ones to a frame that contained a tile with an alpha making it totally transparent.

Comparison 3:
A) Image sheet, new sprites, old display group, :setFrame(), blank tiles
B) Image sheet, new sprites, new image group, :setFrame(), blank tiles

Results:
A) 18 fps.
B) 45 fps.

The final comparison is just to test the difference between making a sprite visible and invisible, or using a blank, transparent tile - hopefully this will let me make a prediction about what sort of framerates might be possible when combining all the new features.

Comparison 4:
A) Old sprites, .currentFrame, old display group, visible / invisible toggle
B) Old sprites, .currentFrame, old display group, blank tile

Results:
A) 26 fps.
B) 18 fps.

Notes:

  • My tests are done in code for a platformer game, and does include collision code.
  • They were run on an iPad 2 in landscape format, with each layer of parallax being fullscreen using tiles of 32x32 pixels. A single layer uses 33x25 tiles (one more than you’d expect to account for offsets), or 825 sprites.
  • The demo contains 8 layers of this, for a grand total of 6600 sprites in the level graphics.
  • Not every layer is solidly packed with sprites. Each layer contains ‘holes’ where you can see the layers behind. This is because I was using a test level I knocked up quickly, which would emulate more realistically what I’d do in a game. It also is useful in that it shows the speed differences between hiding a sprite, or drawing a transparent one instead.
  • Every tile is redrawn every frame. This allows for per-tile animation without any overhead. I am a fan of this method for simplicity, and because you almost always know your worst-case scenario, but it is not the only way, naturally. Possibly I could optimise the code further by making the tiles themselves never animate, and only redrawing sprites when they move offscreen and wrap them to the other side. However, for the effort involved and the limitations imposed, I feel it is not worth-while.
  • I measured the FPS by finding the spot in the map with the lowest FPS and idling there a few seconds to let things stabilise, although for tests using blank tiles, realistically any location is as good as another. The FPS code itself is a library taken from this very site.

Conclusions:
Image sheets alone didn’t actually provide a speed benefit, something which concerned me enough to double and triple check my numbers. But upon re-reading John’s blog post, nowhere does it suggest there are performance gains from using image sheets, and I realised this makes sense. The benefits come from fewer disk reads, and simplification of the APIs. It does come at the cost of the additional complexities of making and defining texture atlases, however.

But image groups? They are exactly what is needed for performance gains!

My conclusion would be that although I am unable as yet to fully test and exploit the new features due to a bug, what I have seen is proving to be very, very impressive! I am more than happy eating my words about the potential speed gains Ansca could and did achieve (based as it was on the fact I already felt Corona is very quick all things considered), and it makes me happy for us all and the future of Corona!

But! If you are going to go to the trouble of making texture atlases, DO plan ahead for using image groups, when the final bugs are ironed out - you will be amazed :slight_smile:

[EDIT]I nowhere mention the benefits of culling used with the new commands. The reason is simple, I don’t use it nor need it, but that may well have a large effect on Tiled things, which hopefully someone else can look into. [import]uid: 46639 topic_id: 12910 reply_id: 99582[/import]

#83

@rakoonic, thank you so much for sharing the results. I’m assuming that these weren’t really Lime-specific results, I would suggest even crossposting this to the developer forum - as it’s the first list of test results I’ve seen so far. [import]uid: 49447 topic_id: 12910 reply_id: 99606[/import]

#84

Not a bad idea, so will do it in a minute. And yes you are right about it not being a Lime test, but I felt the results were worth sharing here, as I feel that Lime will benefit massively from the new features, as long as people are prepared to factor in a few things (eg it may have to drop multiple tilesets support, or fall back to slower code if they are present etc). [import]uid: 46639 topic_id: 12910 reply_id: 99607[/import]

#85

Thank you Rakoonic for doing the tests and providing the results! Very interesting indeed. I really really want to be able to use ImageGroups, I just wish we knew if the limitations of using only one image in them is a temporary thing or if it’s going to be a permanent thing. [import]uid: 119420 topic_id: 12910 reply_id: 99890[/import]

#86

I can’t see it ever being changed, because the whole point of an image group is that it is explicitly tied into an image sheet. Some of the Ansca guys explained how they get the benefits this way, and it basically confirms this (as it is tied into the underlying open gl implementation, so Ansca has no control over that).

Bear in mind though that for anything using a lot of sprites, if you somehow needed 2 image sheets, you’d still be better off using 2 image groups, 1 per sheet, and simply locking them together visually (make them both children of a normal display group and use that to manipulate them).

It might make a bit more work setting up, but the performance gains I’ve seen definitely make it worthwhile for anything CPU / graphics intensive.

I am also hoping the bug I brought to light will get dealt with relatively swiftly, as it is a proper crashee bug, and the guys seem to take them pretty seriously :wink: [import]uid: 46639 topic_id: 12910 reply_id: 99894[/import]

#87

Ah, I didn’t realise you could still put ImageGroups in regular display groups. This could still work with a little it of fiddling, but as you say the performance boosts really look worth it. [import]uid: 119420 topic_id: 12910 reply_id: 99897[/import]

#88

I’ve finally had Ansca accept my bug was corona and not my code, and it has been passed to the relevant people. With any luck I can get some proper full-speed tests up and running soon :slight_smile: [import]uid: 46639 topic_id: 12910 reply_id: 103449[/import]

#89

Just saw this at the latest blog entry :

http://www.coronalabs.com/blog/2012/06/15/state-of-corona/

“Once the public release is out, we’ll be starting our first feature cycle. In addition, we’ll be checking in various improvements that we didn’t get in before we locked down the code base, e.g. tile culling performance improvements , missing events for the new sprite API, etc.”

This is very very very disappointing. Walter had written at length about this feature and had shown us with a video that it works. Graham has updated his code to run on this feature set and now we are told it will not be in the next release. Am I the only one annoyed by this? [import]uid: 11904 topic_id: 12910 reply_id: 111948[/import]

#90

No @ksan you’re not the only one. In addittion to what you said I must add Corona has a yet to solve bug on the table about rendering grouped tiles that shows odd lines between the tiles in some devices and totally messes up any tile-based map. That’s why ChocoRun isn’t available for Android yet. But this isn’t an Android only bug, it also happens on an iPad 3. [import]uid: 13811 topic_id: 12910 reply_id: 111951[/import]

#91

@ksan, sounds like you haven’t tried 833 yet. Culling is in 833 for normal display objects. However, culling for objects in ImageGroups is not working well (see http://developer.anscamobile.com/forum/2012/03/14/re-blazing-sprite-and-tile-performance). Those improvements will be on a daily build after the public release.

If you are experiencing similar issues, chime in on that thread with more data points. [import]uid: 26 topic_id: 12910 reply_id: 111952[/import]

#92

@alejandro, the issue you are referring to is a general OpenGL one, not unique to Corona. You’ll hit it anytime you try to generate tile maps from texture atlases (aka spritesheets).

See @rakoonic’s explanation and my follow-up post on this thread for the full details: http://developer.anscamobile.com/forum/2011/06/03/lines-between-my-tiles#comment-112066
[import]uid: 26 topic_id: 12910 reply_id: 112068[/import]

#93

Nice to see that Walter, thank you! I’ll have a deep look into it and we’ll see if we can make Choco (and other people’s projects) look as nice as they should.

@Graham, we have some work on the table :wink: [import]uid: 13811 topic_id: 12910 reply_id: 112069[/import]