@Oaf
We’re considering Moai too, as have similar problems and other with Corona SDK (unfortunately 
). Would be nice too hear about your experience.
Thanks [import]uid: 9058 topic_id: 23302 reply_id: 110006[/import]
@Oaf, @rbelluso, just sent you some follow up questions about your project over e-mail, as we were seeing 30fps on level 15 on a 1st gen iPad. Let’s continue the conversation on that e-mail thread.
@rune7, looks like you filed casenum 13916 and you were talking to Danny, so let me find out where we are at. Will send you a note soon.
@Andriy, have you submitted a test case via our bug base?
[import]uid: 26 topic_id: 23302 reply_id: 110188[/import]
I’m subscribing to this thread, I’ve got clients asking me to make similar tile-based games, but with this potential roadblock, I may not be able to take on the job or use Corona to do it. Please let me know if there is any significant update. I also bought Lime but never got the chance to use it due to the “performance issues” that they still have noted on their front page of their website. [import]uid: 6084 topic_id: 23302 reply_id: 110189[/import]
Still looking into this. When we have more info, will post an update. [import]uid: 26 topic_id: 23302 reply_id: 110815[/import]
My own app has 200 x 200 tiles. (allowing for zooming right out where they are all visible)
Doesn’t sound much when you say it like that, but it is 40000 objects
The main screen can take 2 seconds to appear, every time I return from a director scene change.
(iPad 2: I hear that the iPad 2.5 is slower again…)
I’ve watched this thread about blazing performance since it started, and it seems that the majority of responses are ‘huh? : it’s not faster for me…’
So to be clear… if I have to render up to 40K static images , which can individually change to other images on ‘touch’, what is the best way to do it?
Old sprite engine, or new? Or does it actually turn out to make no difference in this case?
(beta versions gave all the tiles a listener.
that was way too slow.
Now I have a single listener at the screen level and derive the chosen item by co-ordinates)
[import]uid: 108660 topic_id: 23302 reply_id: 110827[/import]
Hi,
didn’t get any follow up yet from your team on this subject.
I was thinking of another alternative, if you can provide one easily:
Allow a new method to compile a new image based on a display group or using some canvas-like solution and either allow to save it to disk or allow to use it as a regular image.
Using this, I can dynamically create a few large images from the non interactive layers, and load only them to the map instead of the thousands of tiles that were used to create them. This will reduce the tile count significantly on expanse of the texture memory used and load time. I’ve tested it manually and it shows better performance than current solution can provide on single core devices. Problem is, I can’t do it on runtime. [import]uid: 118978 topic_id: 23302 reply_id: 111149[/import]
We’re still waiting to hear back from Ansca. In the meantime, we’ve been evaluating all sorts of different engines. One in particular is looking very good, especially in terms of tilemap performance - I’ll PM you details.
We also looked at the huge tile route - and you’re right, it does definitely improve performance - but we found we couldn’t implement the levels we wanted 'cos they just took up too many big tiles.
As for saving out to disk, I don’t think you can do that under ios [import]uid: 276 topic_id: 23302 reply_id: 111154[/import]
@Oaf: can u mail me your results too? info AT digidingo.com
thanks! [import]uid: 90610 topic_id: 23302 reply_id: 111156[/import]
Hi, thanks. Please sent me your findings to info@tiltangames.com [import]uid: 118978 topic_id: 23302 reply_id: 111158[/import]
Hi @Oaf, I would be very grateful if you could send your test results to me too: info AT no-sheet DOT com. Thanks a bunch! 
[import]uid: 80100 topic_id: 23302 reply_id: 111189[/import]
Hi all, wanted to give a quick update.
As @oaf and @rune7 noticed, there are some culling issues when you move the scene.
The culling code itself has some unnecessary overhead (and the culling itself had bugs). Specifically, it’s triggering extra calculations that shouldn’t happen, so we’re working on a fix. Right now, the changes look like they’ll be fairly aggressive, so they won’t make it into the next public release. Instead, we’ll add them into a daily build soon after the public release.
As a side note, one thing we realized from a design perspective is that each tile in an ImageGroup is a display object, but that seems like overkill. You might want to manipulate properties (x,y,alpha,etc) of the entire map, but it does *not* seem like you would want to do that on specific *individual* tiles. Are there compelling use cases where you would? [import]uid: 26 topic_id: 23302 reply_id: 111208[/import]
>>As a side note, one thing we realized from a design perspective is that each tile in an ImageGroup is a display object, but that seems like overkill. You might want to manipulate properties (x,y,alpha,etc) of the entire map, but it does *not* seem like you would want to do that on specific *individual* tiles. Are there compelling use cases where you would?<<
My entire app depends on that exact functionality.
The user interacts with the ‘map’ and where they touch, things change.
I don’t use the objects as sprites except so far as to allow the image to change on touch.
Some change their alpha, some change their image. [import]uid: 108660 topic_id: 23302 reply_id: 111209[/import]
Hi,
I think, we can distinguish between two cases:
- If an image group is used for background/foreground layer, I do not need to have physics properties for it (I build dedicated physics layer for that using some logic), nor do I need to perform any operation on individual tiles there. only move the entire layer based on the camera point of view.
I can think one might want to perform tile replacement within this group (to indicate that some action has happened, such as hidden door, trap door etc), but this can probably be overcome using additional sparsly populated layers if needed. - The second option is when we can pack all interactive objects to single image group - in this case, individual objects will need to have their own characteristics to manipulate.
I think that for a quick solution, we can do pretty well with having a solution only for the first case.
Going forward, I would try to attack the second case by allowing collisions between groups (if possible by box2D framework), or by improving current culling of objects outside the screen.
For example, in my case, a typical scene can have between 1500 to 5000 tiles (I reduced it from 25k originally by pre-merging image tiles to larger image tiles where possible). However, only few hundred of those are viewable at any point in time. the rest should reside in an inactive state/group until brought to view.
Thanks. [import]uid: 118978 topic_id: 23302 reply_id: 111210[/import]
Jeff,
Do you have a large map which the user scrolls or is it a fixed map the size of the screen or something similar?
How many Tiles does your map have and what is the average FPS you get?
[import]uid: 118978 topic_id: 23302 reply_id: 111212[/import]
What I’d love is a large map that the user could scroll.
But the tiled area is 200 x 200 , 40K tiles
In proto type it was WAY too slow to have these things with their own listeners, so right now I have something like 96 x 72 on screen.
When the user ‘scrolls’ its done by changing the currentFrame of all the tiles.
And I reckons thats too slow too.
FPS is not a concept that applies to my app: I have a ‘time to redraw once’
[import]uid: 108660 topic_id: 23302 reply_id: 111215[/import]
My app also depends on being able to adjust properties of specific tiles – not just the map at large. I’m allowing players to pick up and place tiles in the world… [import]uid: 82003 topic_id: 23302 reply_id: 111239[/import]
OK, so how much time does it take to redraw a scene? how many times you do it in a second?
I’m trying to see if I can modify my implementation somehow to improve frame rate.
The smallest tiles I have are 40x40, so on htc-one for example (1280x720) I can at worst case have 627 viewable tiles for each layer (assuming they are not aligned to the screen borders). with 7 layers this results with less than 4400 tiles in view. But, my layers are not completely populated. And I’ve reconstructed the scene to use 3 steps of tile sizes 40x40, 120x120 and 240x240 where possible, resulting in significant drop in overall number of tiles and that brings the amount of viewed tiles to less than 500 most of the time.
The only other thing I can think of is to impement my own off screen culling, but doing it over the API is slow and will not work smoothly. It needs to be implemented natively. [import]uid: 118978 topic_id: 23302 reply_id: 111295[/import]
Okay, so an update. The culling code was horribly inefficient, so I’ve reimplemented it.
In the test case that @oaf has supplied, there is significant improvement on the really bad level, smoothly running north of 55 fps on my old iPhone 3GS (previously it was stuttering really badly).
These changes won’t make it into the public release as we’ve locked it down except for showstopper bugs. I’ll get this into a daily build soon after post-release. [import]uid: 26 topic_id: 23302 reply_id: 111478[/import]
That’s great news. Can’t wait to get my paws on it! [import]uid: 276 topic_id: 23302 reply_id: 111482[/import]
@Walter: thanks a lot for your news and listening to us!
Can’t wait to see the results in the daily build.
it would be awesome if you could have a look at:
developer.anscamobile.com/forum/2011/12/12/performance-degradation-new-public-release
this is really a show stopper. we had Grooh running perfectly on the samsung galaxy, but out of nowhere, we had a fps drop from 60 to sth like 15. we are still waiting to release it.
thanks once again, and sorry for the thread hijack. [import]uid: 90610 topic_id: 23302 reply_id: 111485[/import]