I have the same question and am hoping someone from Ansca can chime in.
Based on an old podcast I listened to that was a conversation with Carlos and Walter, they explicitly stated that calling an image multiple times, that reference the same image file, Corona will reuse the image bits and only load the image into memory once.
Info on the podcast here: http://mobileorchard.com/corona-easy-to-implement-high-performance-native-iphone-apps-written-in-lua/
Direct download here: http://podcast.mobileorchard.com/podcast/019-Corona.mp3
Earlier today I was playing with Fishies iPad and put 2000 fish swimming back and forth on the screen. On an iPad 2 I got 8 FPS. :) Cut the number of fish in half and I got about 16 FPS, cut it in half again --500 swimming fish -- and got 30 FPS.
I was hoping for more, but there may be many places where that code can be optimized -- it was probably written for clarity more than speed.
And just for the fun of it I "unrolled the loop" -- instead of doing the same chunk of code 500 times I put in 500 chunks of code. Each fish had it's own code. No speed up, but I didn't really expect any with that few iterations. :)
Jay
PS - You young whippersnappers have it easy. Back in the day we put graphics on the screen a pixel at a time, and while unrolling the loops expanded the size of your code, we could get noticeable speed increases from doing that.
Corona will reuse the image bits and only load the image into memory once.
Loading the image isn't what we're talking about; we're talking about how the code renders the image after it's been loaded. It's a subtle technical point that only people with low-level experience in OpenGL will understand, but you can draw multiple instances of the same image with a single draw call. OpenGL is optimized to handle lots of data in a single draw call faster than the same amount of data spread out over multiple draw calls.
This is one of the myriad reasons spritesheets are more efficient than separate images; if you have multiple sprites sharing a spritesheet then OpenGL will allow you to render all of those sprites with a single draw call. The question here is, does Corona do that?
I am well aware of that. But the question of a single draw call versus multiples in this case (the fishies) is implicit in the example.
According to the podcast, they are only loading the image once into memory, and reusing the OpenGL id of the bits, with the slight overhead of redrawing the fish (position, rotation, scale), a single draw call is to be expected.
Now, I guess the real question is "is" it actually making a single draw call, or is there something else going on in the code that "breaks" the batch?
I know in all the other engines I have used over the years, batching is very dependent on the requirements, to ensure a batch. If one little thing is wrong, the batch breaks.
Has anyone tested changing the Fishies example to actually load in a sprite sheet instead of the current display.newImage?
According to the podcast, they are only loading the image once into memory, and reusing the OpenGL id of the bits, with the slight overhead of redrawing the fish (position, rotation, scale), a single draw call is to be expected.
I still don't think you're getting it. Have you ever wrote anything in OpenGL? Not used rendering engines based on OpenGL, but actually made calls to OpenGL in your own code.
It is perfectly possible to use the same OpenGL id over and over in multiple draw calls. The code would look something like (warning: massively simplified pseudo-code)
1
2
3
4
5
| tex = opengl.load("fish.png")
opengl.draw(poly1, tex)
opengl.draw(poly2, tex)
opengl.draw(poly3, tex)
opengl.draw(poly4, tex) |
While I haven't written any OpenGL code myself, I do understand how it works, and my assumptions of a single draw call are based entirely on Carlos and Walters statements. That assumption may be completely wrong, but it is based on what they have said.
Without actually either hearing from Carlos, Walter or another Ansca engineer, or a method in Corona to get the number of draw calls, we are just speculating, based on our tests.
I wanted to find out how many draw calls were going on in my app, to verify that the sprite sheets were actually working as I expected, and was told there is no method to get the number of draw calls from Corona.
Do you have a method of getting the draw calls? Because that would be a good number to have, or see.
No I don't have any way of knowing that. That's why in my very first post in this thread I said "I sure hope that is what Corona does, maybe an engineer from Ansca can tell us for sure."
As for our speculations, I was simply disagreeing with you that the statement you quoted from that podcast has any relevance to draw calls.
No worries! I like discussions like this, because I learn by having to solidify my knowledge into words. Sometimes it proves me wrong and I like that. After 15 years making games, there is always something, on a basic level, for me to learn.
I would like an Ansca person to chime in on this as well.
What I really want is a call to be able to see how many draw calls there actually are.
If we told you, we'd have to eliminate you.
Now that's just not funny.
Why do Ansca staff like to reply super-funny (not) answers when we're expecting them to give us a valuable one? Is that all we get for being subscribers beside the game engine, "jokes" on a forum?
"If we told you, we'd have to eliminate you."
Responses like that might eliminate me as a customer, is that what you meant?
Seriously Dell's question should already be covered in the docs, we shouldn't need to ask basic questions like this in the forums. And certainly we shouldn't have to wait over a month for a response.
I was hoping for more, but there may be many places where that code can be optimized -- it was probably written for clarity more than speed.
The above statement is true.
While we do incremental performance increases, if you guys read my blog from April 14th, 2011 http://blog.anscamobile.com/2011/04/whoa-is-right-our-corona-sdk-gets-major-update/
One of the items that we are focusing on the next release is The next area of focus is graphic enhancements. Do I need to say more? We will focus from increasing our graphic pipeline performance, to adding shaders, to hard-core graphic features such built in curve-fitting all the way to raster and imaging enhancements. Photoshop anyone? UGHGH I get carried away sometimes… Oh behave !
Hope that answers your questions.
And seriously, guys, the funny statements, try answering forums, and support emails for a living, and you will see how much fun they are. I am notorious for it. They don't mean anything. It is the staff trying to vent on their long days. And in a startup, the days are 24/7/365 non-stop. But guess what? What other company you know off that the co-founders roll up their sleeve and take time to answer your forum post and try to monitor it on a daily basis to get a temperature reading on whats going on with their product. :-) It's all good. (See am venting ;-) Means no harm.
Carlos << yes one of the co-founder dweebs