Yes, I use a custom culling solution.
The problem I see isn’t so much about fitting more or less tiles on a screen, but having to perform operations on all the tiles in the world. When you make 4K display objects as tiles, and the player moves across a scrollable level, all of those tiles have to be moving through the screen space. Logically, the CPU has to access and modify the positions of 4K tiles, whether they are visible on the screen or not. If you increase the world size to 8K, the CPU has to do twice as much. This is only made worse by the large performance cost of accessing object properties. If the game is using physics to check the player for collisions with certain tiles, the problem gets much worse, and again the workload goes up as the number of display objects does.
My solution is to keep track of the player’s location in the world, and to store all of the world’s information in multiple gigantic two-dimensional arrays. When the player moves right, the 35x26 tiles move left. When the leftmost tiles move off the screen, they are deleted and a column of new tiles is created along the right. The game counts forwards along the gigantic world arrays from the player’s stored location in order to get the relevant x and y indexes, so that it can figure out what those tiles are supposed to be and load their graphics. And that is it; the display objects are involved in no other data storage or operations what-so-ever.
Collision detection, rather than accessing the properties of the display object tiles, which is expensive, compares the player’s location to the world array information to either side of that location. This is nice and fast, it doesn’t access display objects, and it doesn’t rely on the complex mysterious maths and multiple iterations of the physics engine- it’s all simple math.
So if playerLocX = 100 and playerLocY = 100, and the player is running right, all the game has to ask is “does world[playerLocX + 1][playerLocY] = obstacle?” It doesn’t bother checking with what OpenGL happens to have on the screen, or the properties of any of those things.
I’m not saying Lime does any of these things or doesn’t. I’ve never used Lime. But I think these things are the major causes of the poor performance we always run up against.
EDIT: The new youtube video is still processing, so it may be a few minutes. EDIT2: Youtube ate the video. Uploading a new one.
I have a constant amount of imageRects covering the display area and dynamically update them, yes. I’m not using any groups at all, at the moment. I suppose I should start using them. I can’t use image groups, but do the old display groups confer any notable performance gain? [import]uid: 99903 topic_id: 29569 reply_id: 119143[/import]
