I have to correct you right there. Creating 90,000 rects is nothing.
For example,
local newRect = display.newRect local pixel = {} local pixelSize = 2 local startX, startY = 20, 20 for i = 1, 300 do for j = 1, 300 do pixel[#pixel+1] = newRect( startX+i\*pixelSize, startY+j\*pixelSize, pixelSize, pixelSize ) pixel[#pixel]:setFillColor(1) end end
Adding zoom or something else on top of that isn’t that hard either.
You only need to create the amount of rectangles that are visible on the screen, much like a tiled game.
When you slide your image to the left, the column of pixels / rectangles that falls outside of the screen area is moved to the right side off the screen and updated to the right colors for these pixels (by reading the color values from an array that holds all pixel colors).
By the way, replacing each pixel with a full display object is okay, as long as you keep the number of pixels visible on the screen under 2000, tested on a 3 year old iPhone SE and 5 year old iPad.
At the moment, these are the plugins that I use. Alas, despite the good harware, the engine can not cope with a large number of objects on the screen. For example, the Corona SDK cannot cope with drawing 3,500 objects, even if these objects are bitmaps. It will slow down and sink the FPS from each player’s action.
First of all: wow! I didn’t know Corona has gotten getPixel/setPixel functionality! When did this happen???
Second: but then the problem is solved, no? If you use this plugin then you only display one single bitmap with 90000 pixels, and not 90000 image with a single color each.
Are you 100% sure about that? Because from what see and read in the docs, it behaves the other getPixel/setPixel methods I’ve used in other software for the past 20 years - designed specifically to not create displayObjects but instead paint pixels in an existing texture.
Quick chime in. You can absolutely make an app like that with Corona and it will run fine.
Those apps very likely do not render off-screen selectable/paintable blocks. Your game should not either. Once you cull off-screen content there will be no issue with performance.
I think the real question here is, “What techniques should be applied to implement this?” I’m seeing good responses above that all seem on track.
Best of luck on this. Be sure to share in-progress updates with us.
Also, if you get stuck, the best way to get help is to make a demo that shows the issue you’re encountering, zip it up, and share it here. Folks will be more included to run and examine it that dig into partial code posts or just provide their own example. i.e. It is nicer to look at and help with existing samples as long as they are small and focused.
Memory Bitmap plugin does not solve the problem. Because if you make setPixel 5000 times for example, then performance will drop. Similar loss of FPS with 5000 squares on the screen and using setPixel.
Thank you all for the answers! The best option is to draw one picture in parts, 1500 squares on the screen.
The Memory Bitmap plugin will most likely work in the same way, using the principle of creating squares. Because of this, performance drops. So the setPixel method is not justified.
Ah, it’s a shame that the setPixel function is too slow then.
In that case I would go for only drawing the visible on-screen pixels and my wrap-around idea mentioned above. Let me know if you have any problems with that.