Re: Blazing Sprite and Tile Performance

Solar2D General Questions/Discussion
#1

Hello all,

This is in regards to the post by Walter a few days ago:

http://blog.anscamobile.com/2012/02/blazing-sprite-and-tile-performance/

So here is the problem. We are developing a 2D scrolling tile-based physics game and we are struggling to improve the framerate. We are trying to implement these new performance improvements as described by Walter but without detailed documentation we are getting no where.

We’ve found that by making the tiles bigger it does indeed speed the game up. And it looks better, too! Everything is 1.5x bigger, and on the iphone 4 the framerate has gone from 22 to 26 fps. However, it is still way too slow for 3G.

There’s a problem with Corona, which really limits what you can do with scrolling tile-based games. Simply, it’s drawing the tiles that make up the levels in a very inefficient way, which means we couldn’t use this approach at all.

So, to get around this, we had to use a small number of big images to make up the level, rather than lots of little ones. We also looked at culling as much physics collision data as we could.

We were able to get 30 fps on 3G by using these methods!

Once we heard about the “Blazing Sprite and Tile Performance” updates for Corona, we got really excited to implement them. So we bought a pro license, got the latest build and pre-release tools, and got to work.

We reverted back to the original (slower) Corona drawing method because we thought Corona had been optimized per Walter. However, the performance at the moment is worse than the previous version. Our previous large-tile version was around 30 fps on iPhone 4. Now it’s running at 20. We’ve got pre-release versions of the tools, meaning everything renders correctly again, but there’s no documentation or examples on how to use the new performance features, we’re just working from sketchy details and blog posts, so we’re obviously doing something not quite right somewhere.

We’re going to carry on implementing new levels in the meantime, and hopefully in the near future proper documentation will be forthcoming.

Can anyone help us out? We want to at least get 30 fps but obviously more than 30 would be even better!

Thanks in advance.

Rob
Roentgen, LLC

[import]uid: 134650 topic_id: 23302 reply_id: 323302[/import]

#2

Hey Rob, can you describe how you are drawing tiles to the screen? What was your old method vs. new? How were your graphics organized, what are their dimensions et c.?

In my game, I had display groups with 4-6 images in them, each image as its own, separate, non-^2 png. I also manually culled any objects that were offscreen. I had that running between 20-30 fps with a couple hundred groups instantiated on the screen.

With the new build, I put all of the graphics into a single 1024x1024 imagesheet and took out the culling routine, and now get between 30-60 fps (it’s hard to get an accurate measurement.)

I don’t use the physics engine at all so I don’t know what kind of impact that would have on the new build. [import]uid: 120 topic_id: 23302 reply_id: 93320[/import]

#3

noted. can you send us some test cases to test agains.

old/new cases so we can test against our harness.

cicaza [at] anscamobile [dot] com

thanks. [import]uid: 24 topic_id: 23302 reply_id: 93345[/import]

#4

Having created a sprite using the new method, there doesnt seem to be any way to change the frame it uses to be another image.

.frame is read only
.currentFrame does not exist

Any idea when this functionality will be back?
[import]uid: 108660 topic_id: 23302 reply_id: 93490[/import]

#5

Carlos, I’ll zip up the source to the project Rob’s talking about and email it over to you later today :slight_smile:

Thanks,

M [import]uid: 276 topic_id: 23302 reply_id: 93771[/import]

#6

We are having some major performance issues since we upgraded to build 761+ for our game and builds later than this do little, if nothing, to improve the situation. I am hoping that someone may be able to shed some light and offer suggestions as to what the problem is and whether it is my lack of knowledge of the new imageSheet / imageGroup ‘performance improvements’ or in fact that there is an issue with the new builds.

A little background:

Our game is a tiled based game with average map sizes of 30 x 60 [individual tiles are 96 x48] built using Tiled and loaded using Lime. The physics for the maps are created in PhysEd (the imported data averages about 130-200 polygons for the ‘landscape’) and added to the landscape tiles as a whole as
the landscape is more than a little curvy (applying physics to individual tiles wasn’t viable). We make use of the Lime API to ‘spawn’ our game objects at level start but after that it’s running in our code and only calling Lime (map:update()) to track the player in the map.

The game was originally developed using build 704 and we had some issues even with screenCulling enabled in Lime, so we tried to use much bigger tiles (much bigger!) and we did get a performance boost, mainly because Lime was culling far less tiles at once, but it did bring with it something of a texture memory issue, especially on 3G.

We were delighted to hear about build 759+ as it seemed to address all of the performance issues we were having, and the videos and blog about it seemed to suggest this was the answer to our problems. So we duly subscribed and bought a Pro licence to get these improvements.

We switched back to our normal tileset size, and obtained a Lime 3.5 Beta that makes use of imageSheets (and corrected an issue of corrupt rendering of maps in 3.4). Amazingly, performance actually decreased (21fps vs 25 in 704) and we also seemed to be getting a ‘stutter’ of the display when scrolling. By this time we were using build 765.

All game graphics and UI were recoded to make use of imageSheets and even that brought little improvement and still a stutter, so the next thing we tried was to modify Lime 3.5 to use imageGroups (instead of displayGroups that Lime has always used) and it seemed to make framerate worse, not better, and the
stutter is even worse.

We have studied how to use imageSheets and imageGroups and read the blog on their use, so their use is correctly implemented to the best of our knowledge. So this leaves us puzzled somewhat as to why a ‘performance improvement’ isnt improving anything for us, despite the lengths we have gone to, to embrace the changes. Between builds the game code changed very little and any change wouldnt account for the degrade in performance.

So if anyone can perhaps shed some light or make comment or suggestions, it would be most appreciated. [import]uid: 276 topic_id: 23302 reply_id: 93774[/import]

#7

Tracking thread :slight_smile: [import]uid: 12704 topic_id: 23302 reply_id: 93827[/import]

#8

Tracking this, too. Have similar problems. [import]uid: 133261 topic_id: 23302 reply_id: 99252[/import]

#9

I’m also building a tile based game with maps size of 50x80 tiles on average (each tile 40x40). also did not observe performance boost from the new API, though i kept the new code version.

This is a real bottleneck of the system. on previous generation devices, It causes unexpected behaviors and weird movement if you’re using time based movement! (the player character can pass through physical objects if the game had a momentary hickup due to other intensive CPU task (loading a sound data to buffer or something similar).
any alternatives or improvement approaches would be greatly appreciated. [import]uid: 118978 topic_id: 23302 reply_id: 102033[/import]

#10

Tracking thread [import]uid: 9058 topic_id: 23302 reply_id: 102084[/import]

#11

Given the number of people watching this, how about a response from Ansca?

It’s been over a month since we delivered the project source…

Carlos?
[import]uid: 276 topic_id: 23302 reply_id: 102087[/import]

#12

Oaf, just a quick comment here - Carlos is not with the company day to day anymore. I asked Rob to send me the source and I had one of our team members look at it, but he had some questions. I am looking at that today and will send an update. [import]uid: 10668 topic_id: 23302 reply_id: 102113[/import]

#13

Cool ok, thanks :slight_smile:

The code’s probably changed a lot since then, so if you or a team member wants to contact me directly, I can easily arrange an up to date code drop. [import]uid: 276 topic_id: 23302 reply_id: 102114[/import]

#14

If anyone at Ansca would like or requires a copy of the latest Lime code please give me a shout. Would really like to know if there is anything I am doing wrong with the new APIs - graham AT glitchgames DOT co DOT uk [import]uid: 119420 topic_id: 23302 reply_id: 102648[/import]

#15

Ansca or Anyone who have tried to build an action tile based game on corona.
i have tried multiple methods to crank my game performance on Android, to no avail. when building a custom map even small in size (like 50x50) with some sprites, the game barely moves on the devices (both samsung tablet 10.1 and defy+ phone).
if I use time based movement, unpredictable behavior occurs and the game is unplayable. on the simulator the game runs fine of course. it seems that tile culling is not working on the device or not having the impact i expected.
the only way i could find to improve performance is to create a predefined map (on external tool) and split it to 4-8 sections and load them instead of the thousands small tiles. this works ok on predefined map but significantly handicaps any use of random map (which i believe is mandatory for game longevity)

i do not have iphone/ipad so i couldn’t check this out. does it worth the effort and money to port the game to iphone and try to salvage the game? or will i encounter the same performance on iphone/ipad as well?
currently, corona does not seems to work for these type of games.
any advise will be most welcome [import]uid: 118978 topic_id: 23302 reply_id: 103662[/import]

#16

Performance is significantly better on iOS. I’ve recently tried a build on Android, and even the small/fast levels are unplayable - even on something capable like the Kindle.

We also experimented with the ‘huge tile’ approach, but it eats lots of memory.

Ansca now have a copy of the latest source for our game, so hopefully they’ll have some answers soon.

While I’m here - as well as the tile culling, I also noticed that if you keep the screen completely still - in that there’s no scrolling occurring, the frame rate leaps to 60. As soon as you cause the screen to scroll, it dives again.

[import]uid: 276 topic_id: 23302 reply_id: 103663[/import]

#17

Ive read a lot of probably conflicting information about the new sprite and tile stuff.
So here’s the basic question/s I need to answer (again) before I refactor a lot of code.

Scenario:
I have an array of 200 x 200 values which make up a map.
Im handling the array, although I gather I could have used lime.
I handle it myself because its not a map, the values could change rather a lot.

Right now, my redraw code has a maximum of 90 x 70 items visible on screen.
I use sprites even though I don’t need physics, because changing the image is simple: I just change the frame.

But when moving to a new area, I have two choices:

  • allow the ‘scroll’ to occur and redraw the visible grid by changing all visible tiles (done… slow…)
  • allow the ‘scroll’ to occur and draw the missing data on demand (not tried… difficult)
  • create the whole 200 x 200 area and allow that to get dragged about (not tried… suspect memory issues and speed issues)

The question/s are:
Is the new system actually any faster if you don’t use animation? (some say yes, some say no)
Under the new system, if I create a tile map of 200 x 200 tiles, made up up 40 x 40 pixel items, will it be painfully slow.?
Will Corona cull the non-visible ones and keep the speed up?
What does culling mean in real terms?
And if it culls non-visible items, will they magically appear if the group is moved to expose perviously invisible items?
[import]uid: 108660 topic_id: 23302 reply_id: 103834[/import]

#18

Hi Ansca,

Any updates on the performance front? I’ve done the following in my tests and optimizations, but go very little out of it. the main issue is still the fact that the graphics takes too long to draw the scene to the screen.

  1. I’ve moved all tiles, both static and sprites to use the new image sheet where possible. from an average of 15K tiles on a typical scene, over 90% are now in the new image sheets. performance gain was negligible.
  2. I’ve used a profiler I bought to see if there is a problem in the logic code. it found some minor points to optimize, but in general, over 60% of the time is taken by the graphic engine. in most cases the game logic takes only around 25% and the rest is spent somewhere (I am not able to see what Ansca code is taking the rest).
  3. I’ve hidden 80% of the tiles after creation. no significant improvement. their existence on the scene view seems to cause the problem. Being visible or not does not matter.
  4. smaller maps have better performance, so it is connected to the amount of tiles created. But, having even only a quarter of the map is still quite slow.

please advise.
[import]uid: 118978 topic_id: 23302 reply_id: 109866[/import]

#19

I’m afraid we’ve not had any joy with Ansca addressing this problem (other than “we’re prioritising paid support requests” - sorry, but I’m not paying for a fix to what I consider a fundamental feature in a 2D engine).

So, all we can do is:

  • reduce the tile count in our levels as much as possible. As a very rough guide - below 2000 will get you 30 fps, below 1000 will get you 60 fps. (That’s iOS. For Android you’ll need to reduce further).

  • consider using bigger tiles, at the expense of memory

  • hope Ansca eventually address the problem, or

  • move the project to use another engine :frowning: We’re evaluating Moai as an alternative, as we’re told it’s easy to port the existing Lua to it. Which is a shame, as we really like Corona, but we’ve been waiting about three months for some kind of feedback or solution on this, and we’ve heard nothing.

[import]uid: 276 topic_id: 23302 reply_id: 109894[/import]

#20

Thanks for your input. That’s bad news for me. I cannot effectively reduce my Tile count to below 2K. I have an engine that generates detailed maps with around 15K tiles. going down to 2K will ruin the game. I’ve manually created 12 levels to test large tiles to extreme - I’ve created 8 very large tiles as background, merging a few layers. total tile count was a few hundreds and on Android, mid level unit (defy+) i get ~20FPS. Without it i get 2FPS :slight_smile: So, it improves performance significantly, but load time is doubled and texture memory is almost doubled as well. what’s worse, its not scalable and it ruins some of the game features.

I just bought a new mac and ipad to start developing for the iOS in the hope that it will show better performance and I can finally ship something out. I was planning to buy the pro license this week to start working on this version. perhaps I will need to spend some time on checking Moai. problem there i heard is around the initial setup.
Well, I will delay buying the pro license and check Moai. Thanks. Will appreciate if you get a hold on a good migration manual. [import]uid: 118978 topic_id: 23302 reply_id: 109899[/import]