Hi all,
Thought it would be good to have a thread where Graham and/or Ansca would post the status updates on performance fixes, as I assume it's a major issue for almost all of us using Corona and Lime.

It would also be good to know what sort of performance boost we could realistically expect as it will probably affect quite a lot of our own game design decisions, so we could plan ahead.

Finally, thanks to Graham for such a great work on Lime so far! :)

Nenad

Hey, this is a good idea. I will make sure I update it with any news I get/have.

I can't really say for sure what the boost would be for things like culling but I can say that if the performance problems currently are mainly down to all the redundant draw calls then it could be a huge boost.

Is there a sample app around that would show the problem -- or rather, show the current level of performance?

Because when I go to the store I don't need a car that goes 500 MPH, I only need one that goes fast enough.

If Lime is "fast enough" for my game, then there are no problems, right?

If I compile one of the sample apps from your site will I see the problem?

Jay

Most of the tutorials are showing quite small maps so they will run fine, if you run the Viewer app you should be able to see the performance of different style maps.

Is there a specific thread where thus has been discussed? I mean, as far as brainstorming fixes? I've been looking around and am not seeing it.

Sitting here without a computer that can run Corona so I can't try this right now, but can transition.to be used on a display group? Looking at the docs I think so. If so, can you create the tiles that appear on the screen and add them to a display group. Then when you need to scroll, insert the next row or column of tiles, do transition.to to scroll everything at once, and then remove the tiles from the group that scrolled off the screen.

This could be how Lime works now, it may be impossible because you can't scroll a group, or it may be too slow. But it's my best idea in the last half hour or so. :)

Jay

That method has been brought up, can't find the thread right now either but it is there somewhere :-)

It has been shown to be a pretty efficient method of scrolling however that was just for standard visual tiles, it didn't take into account physic objects or properties or anything like that.

So if you didn't have to account for physics would there be a performance problem? Or are there also other things?

Jay

The main performance problem I believe is really down to all the draw calls caused by the amount of tiles so if Lime were to use a tile-swapping solution rather than real scrolling that might speed things up but at the same time I would then have to come up with a clean solution to deal with physics and properties and everything else however all that may itself slow things down.

I believe the best solution would be real visual culling native to Corona, and I'm hoping now that Carlos has said the next release should be next week that after that they will be able to focus on the performance increases that he mentioned.

After the visual ( and physics culling hopefully ) is in place, we can then gauge the performance boost and then hopefully see what else, if anything, needs improving.

Did that test we spoke of help Graham ?

You still use Gtalk ?

if the physics are the problem (they disapear if you remove the object), can't you do it like this:
-the physics are on one layer, they don't disapear
-graphics are on a layer beneath the physics layer, and the tiles are created only when they are becoming visible

i,m creating a pinball like game, and all my physics are made using a transparent PNG, placed over the graphics in gumbo, can't you do that in lime?

@infuseddreams - I haven't really had time recently, will try to come back on more often though.

@r.pudlowski - That is a possibility, but currently I am going to wait to see what the performance increases are from Ansca first before I make quite a drastic change.