Hexagonal tile maps? [import]uid: 1560 topic_id: 12910 reply_id: 60754[/import]
Currently no. I would do it if Tiled supported it but currently it doesn’t. [import]uid: 5833 topic_id: 12910 reply_id: 60780[/import]
Interesting…I’ve been playing around with Lime and built a simple 1 level platformer with Tiles of 32x32. It does lag considerably (unplayable) on some hardware.
Would moving to 64x64 tiles (so theoretically half the amount of floor/wall/ceiling tiles) speed things up?
Am I correct in thinking the less tiles (Regardless of size) = better performance? If so, is there anything stopping you having a huge (e.g 640x32) tile to represent the floor, and would that be better than using 20 32px tiles?
On another note, I know you dont want to say too much yet Graham, but do you have some form of ballpark figure for when we’ll see the new features & bug fixes that you mentioned? I can imagine you wont want to be too specific so as not to disappoint, but would we be looking at within the next say month or so?
Thanks 
[import]uid: 61052 topic_id: 12910 reply_id: 64744[/import]
For the larger tile question, yes in theory that would help performance but would naturally remove some flexibility in your level design that you would need to accomodate for.
And for the new version, the plan was for it to have been out a long time ago but things got in the way and then I got word from Thorbjørn, the lead developer of Tiled, that a new feature would be coming in the next drop that I might want to take advantage of. I have since added it to Lime using the daily builds of Tiled. It allows for you to draw polygons etc in Tiled for Objects which you can set as physics objects for Lime making the creation of complex terrain etc much simpler - no more messing around with the dot-to-dot stuff in currently.
The next version of Tiled is slated for release sometime in November so Lime should be coming out soon [import]uid: 5833 topic_id: 12910 reply_id: 64749[/import]
Great news! Thanks for the fast response & keep up the great work…Lime has been an absolute pleasure to work with/on [import]uid: 61052 topic_id: 12910 reply_id: 64751[/import]
I’m glad it has, and developing it has been a whole lot of fun too. Been really nice working on something that people actually want to use [import]uid: 5833 topic_id: 12910 reply_id: 64851[/import]
sorry to bump this, but how is the hardware issue going with Lime?
quoting from:
“Please note, currently there are performance issues on hardware which Ansca and myself are looking into.”
[import]uid: 97745 topic_id: 12910 reply_id: 73330[/import]
I’m still fighting with it sadly.
Carlos has gotten in touch with me recently to update me on it too saying they are still working on performance improvements and have some ideas and will get back to me when there is something to show. [import]uid: 5833 topic_id: 12910 reply_id: 73736[/import]
Are the performance problems platform specific (i.e. Android)?
I’m not interested in working with Android devices at the mo, so I’ll happily purchase this if it’s performant on iOS devices. [import]uid: 5702 topic_id: 12910 reply_id: 74434[/import]
The performance is better on iOS over Android simply because the performance of Corona is better on iOS. Depending on the size and type of game you are hoping to make, and if you make some design decisions to try to work around the issues then you might be ok. What sort of thing are you hoping for? [import]uid: 5833 topic_id: 12910 reply_id: 74453[/import]
Graham - any news on performance updates?
To be honest though, if you want the fastest thing ever, then Lime (and indeed Corona) isn’t really the way to go.
I feel sorry for Graham to be honest, he’s had to include so much code to make things easy, and do the things people need, that inevitably the code gets slower and slower.
You are essentially using helper code (Lime) within a helper environment (Corona) - so performance is never going to be the best.
The only way people will get better performance is to write their own highly optimised code.
And it *is* possible - I just wrote the most stripped down code I can think of (that still imports Tiled levels properly) and I have the following level displaying at 60fps on a 2nd gen ipod touch. That is of course best case scenario (and doesn’t allow for stuff like game code etc, I literally just scroll the level each frame) but it does make me optimistic I can get a game like this running at 30fps on the older devices (the challenge then is to make it run at 60fps on newer ones!).
The funny thing is I came across the level and graphics while searching for a test level in google - obviously Lime is quite popular! http://justaddli.me/tutorial.php?t=0&id=20
Now, does it include lots of usability features? Absolutely not. All it is designed to do is take a tile map and display it as quickly as possible. Flexibility comes at a price, and Corona isn’t massively quick to begin with 
[import]uid: 46639 topic_id: 12910 reply_id: 78018[/import]
Yes, it’s on our radar.
The performance problem seems to be tied to the API overhead of submitting vertices to OpenGL. So currently, if you have a bunch of tiles on screen, for example, you’ll essentially hit an I/O performance wall.
The team is busy on several other priorities that are taking precedence right now, but we’re working on something called ImageSheets that will address this.
Will update when have more news. Okay, going back into the cave now… [import]uid: 26 topic_id: 12910 reply_id: 78027[/import]
Walter,
You have just made my day so much more exciting!
I am praying for something like the following lines of code to enter my existence:
local sourceImage = ("tiles.png") -- load texture without creating displayobject
local tileImage = imageSheet.newImage(512,512) -- create empty texture of 512 x 512 pixels
tileImage:copyPixels(sourceImage, {0,0,32,32}, {0,0,64,64}) -- this should be in a hug for-loop of course Please Walter, please Make it so!
Thomas [import]uid: 70134 topic_id: 12910 reply_id: 78029[/import]
Same experience here as Rakoonic:
I haven’t used Lime yet, but I have absolutely no problem whatsover getting smooth scrolling tilemap, even with 2 parallax backgrounds thrown in, with 32 x 32 px tiles on my iPhone 3G (not even a 3GS).
This is not to say Graham code sucks - I believe quite the contrary actually - but as is expected speed means keeping things lean and geared exactly towards your one purpose.
Compare it with a swiss army knife, you know the big ones that also have that plastic toothpick thingy? If you only need the toothpick, you’re better of not buying the big bulky army knife!
I’ll get round to posting my tilescrolling code here eventually, which is very very optimised, but first I want to release my own game with it. [import]uid: 70134 topic_id: 12910 reply_id: 78030[/import]
I agree mostly what rakoonic says. But Corona is not that entirely slow. I’m developing a platform game like super mario bros. and using, physics, Storyboard API, Gumbo and my own code. I’m getting great performance, fps 57 and no memory leaks.
Good news to hear you guys know where the bottle neck is and that you will be working on it. Good to hear.
[import]uid: 38820 topic_id: 12910 reply_id: 78037[/import]
I’m not saying Corona is slow in and of itself, just that if you compare it to writing the native code in X-code or something, it is necessarily slower - and the same for Lime. Are they bad? Not at all
But it is a trade-off, one which almost all of us are more than happy to take
@Walter - To be honest on my old ipod I have really yet to run into a performance bottleneck based on graphics as opposed to code. I am realistic in what I should expect graphically from an older device, but sometimes the code speed does make me a bit sad, but at the end of the day, it is only really a problem because as of yet I haven’t found a way to submit an app that prevents it being run on certain generations of devices (as opposed to versions of iOS) which means for example, my first app currently in submission is only for ipad for now until I can work around this. Granted I haven’t had a lot of time to look into this
@ glennbjr - cool, but you omitted the most relevant info, which device and world size (in tiles) 
I can get all kinds of shennanigans happening on an ipad2, but I’m still trying to make sure I target the older devices.
@thomas6 - that doesn’t help the situation that we are after with tile maps. Then you are limited to the maximum image size and VRAM of the device. The thing most of us are after (and working / worked on) is simply the ability to draw an unlimited size map, without certain speed hits. That’s not to say that image editing wouldn’t be awesome of course, for many many other things
I imagine walter’s solution will be something along the lines of a new display object type, similar to sprite sheets. You create it passing a sprite set or list of images, along with a properly defined data structure of the level (please please please allow a linear list so we can just use Tiled output directly - multiple formats FTW!) and you just instance it into a group or something. But, does it allow frame by frame animation of each tile, like wot my code does? 
All in all though, it is good to see that Ansca are paying attention - Graham must be biting his nails waiting for the update! [import]uid: 46639 topic_id: 12910 reply_id: 78080[/import]
Hi Rakoonic,
Actually you are wrong: my solution is actually the solution that has been used since 25 years: blitting the pixels to an image representing the screen. Every frame you copy the necessary tiles to a composite image, and offset this image for a subtile number of pixels. This keeps memory usage superlow, and the openGL vertex count equally low.
Working with graphics frameworks like Director and Flash for years I can say with confidence that API calls like this are highly likely to speed up scrolling speeds tenfold. [import]uid: 70134 topic_id: 12910 reply_id: 78082[/import]
I erm don’t really follow you.
You are saying it would be quicker to draw each on-screen tile into a single image then display that image, as opposed to simply display each on-screen tile?
Me thinks it is possible there may be some confusion over where the bottle neck would be in this case. You are assuming that the copy pixels operation into VRAM followed by a single actual image draw would be drastically faster than simply ignoring the VRAM copy pixels and drawing each tile individually.
From my experience there hasn’t been a need for combining tiles in code into a single image to display for a looooooong time. In fact, unsurprisingly, a lot of the old tricks for games like this were ditched when hardware acceleration came along (or repurposed - for example you don´t gain speed by creating the onscreen tiles into a single image before display, and in fact under normal circumstances it is redundant, but you could do things like wibble the ‘screen’ etc by using it as a texture into the *real* screen
Director and Flash are such high level environments that they work very very differently from something tied closely into open GL.
And I should know - I am a bit of a Director master. At least I was until I realised that it is going nowhere and ditched it sadly after many many years.
Also bear in mind that we are now talking about 2 similar but slightly different issues.
The only reason I am guessing that they are so closely linked in here is because Corona doesn’t give us access to the image object data itself - all images are (I guess) dumped straight into VRAM and left as-is. Director and Flash maintain versions of the image data in normal RAM, for editing and what-have-you - if you then want to display something you have changed or created using hardware 3D, the new image must then be sent to the graphics card, which incurs a significant speed hit - exactly what we want to avoid!
[EDIT] I should have asked for more details - give me a complete exammple of what you are suggesting in say Director (cos I am not really familiar with Flash). I want to make sure I haven’t misunderstood something. [import]uid: 46639 topic_id: 12910 reply_id: 78102[/import]
One last comment to clarify what I said earlier:
In OpenGL, the app can be either submission bound (how fast can you submit vertices) or fill limited (how many pixels can be touched). The slowdowns (generally on older phones) we are observing seem to be due to the former. So what is needed is a way to optimize how vertices are submitted.
Our goal is to allow you to have the same number of objects but provide new API’s so that Corona can optimize submission under the hood. Using these API’s, we anticipate some limitations on what you can do on a per-object basis (e.g. no per-object mask, no per-object blend mode) but you’ll be able to freely translate, rotate, the objects. [import]uid: 26 topic_id: 12910 reply_id: 78108[/import]
I have lime working on a test product, which in one level utilizes over 3500 vertices for multiple complex physics objects. Performance on ipod4g is well into high 50s (57avg, lowest is 54).
At one point I had 17581 vertices running at low/mid 40s FPS on ipod4g, but I trimmed it way down to make jaggier surfaces due to performance hit.
My current game is too complex for lime, so I’m not using it however on my next project I’m looking at it for it.
ng [import]uid: 61600 topic_id: 12910 reply_id: 78150[/import]