Best coding method to move 100 coins across the screen over and over again?

Games
#1

Ok, I posted a previous topic about collision detection between separate groups and I could not get it to work so now my new post is how to efficiently move 100 coins across the screen without losing performance and fps?

Since I cannot put 100 coins in a display group and move just the display group because I would lose the physics collision detection, I have to leave them out of a group and move them individually across the screen in the “enterFrame” event listener. However, when I test it on my ITouch 3G, the performance sucks. It slows down and my game is not playable.

Again, what would be the best method to move 100 coins across the screen? I tried to use transitions and translate but they all give me performance problems like the “enterFrame” event listener. My BEST method was to place the 100 coins in a display group and move the group across the screen and there was no performance lag in my ITouch 3G, however, I lost my physics collision detection and that is key in my game because I want to detect when the character hits a coin and make the coin disappear.

Another idea I was thinking, but I haven’t done it yet. Would it be better to keep my coins static and just move my character and camera instead towards the coins like those Doodle Jump games? I’m thinking that would be more efficient, however, how would I do that? If I place my coins static on the screen, how would I move my character towards the coins and still simulate a Parallax Scrolling effect?

Note: I’m using the Director class and placing my 100 coins in the localGroup object. My character is also placed in the local group object.

Here is my code. I have an outer loop and inner loop running because I have different shapes for my coins and each shape is stored in a table. The outer table stores the inner table shapes. As you can see, running for loops in the enterFrame event listener is not efficient and it’s taking a toll on my performance:

[code]

function MoveCoinsTable(coinsTable, xOffset, yOffset, turboOffset)
if (PlayState.InGame == true) then
if (PlayState.MoveCoinsStarted == false) then
PlayState.MoveCoinsStarted = true

local index1 = 1
for index1 = 1, #coinsTable + 1, 1 do
if (coinsTable[index1] ~= nil) then
local innerCoinsTable = coinsTable[index1]
local index2 = 1

for index2 = 1, #innerCoinsTable + 1, 1 do
if (innerCoinsTable[index2] ~= nil) then
local coin = innerCoinsTable[index2]

coin.x = coin.x - (xOffset * (.50 + (turboOffset / 4)))

if ((coin.x + (coin.width / 2)) <= 0) then
coin.x = _W + (coin.width / 2)
end

end
end

if (index1 == #coinsTable and index2 == #innerCoinsTable) then
PlayState.MoveCoinsStarted = false
end
end
end
end
end
end

– Code to get 100 coins
local _coinsTable = Coins.GetCoins()

local tPrevious = system.getTimer()

function MoveEnvironment(event)
if (PlayState.InGame == true) then
local tDelta = event.time - tPrevious
tPrevious = event.time
local turboOffset = 50

local xOffset = ( 0.20 * tDelta )
local yOffset = ( 0.15 * tDelta )

MoveCoinsTable(_coinsTable, xOffset, yOffset, turboOffset)

end
end

Runtime:addEventListener(“enterFrame”, MoveEnvironment)

[/code] [import]uid: 87837 topic_id: 17109 reply_id: 317109[/import]

#2

Simply put:

Don’t use all 100 coins at once.

Unless they all need to be onscreen at the same time, you don’t need to have all 100 coins doing stuff that drags the performance down. [import]uid: 89724 topic_id: 17109 reply_id: 64386[/import]

#3

I cannot understand the *logic* of what you are trying to achieve, however one of the reasons for lagging performance is that enterFrame is called about 30 times a second and you are inside of that handler looping through

index1 = 1, #coinsTable+1
index2 = 1, innerCoinsTable + 1

lets say the first loop was 1, 100 and the second loop was 1, 50

you have 100*50 = 5000 items being processed in 1/30 th of a second.

So you need to optimise your routine or break it down into slices using coroutines and call them in 30 slices in a second. There are many suggestions for optimisation. You can have a large number of objects, it is about how you manage then that will give you speed and performance.

cheers,

?:slight_smile: [import]uid: 3826 topic_id: 17109 reply_id: 64393[/import]

#4

Just an FYI, after 3 weeks of trying to figure out the performance problems I was seeing in my game in tryin to move 100 coins across the screen, here is what i discovered.

The real reason for my initial slow down in performance was due to me using the physics engine on all 100 coins. I guess there is a performance issue when you use physics on too many objects. If I move the same 100 coins across the screen without physics, they move fine and actually they move REALLY FAST. No performance slow down.

The whole reason I used the physics engine in the first place was because I wanted to leverage the already existing collision detection code to determine if a coin was hit by my main character. Now, that I realized the whole issue in performance was using the physics engine in Corona SDK, I now have to re-develop my own collision detection logic or wait for jstrahan to develop his hit collision detection module.

I just wanted to put this on the thread to inform other developers about the current issues with using physics with too many objects. [import]uid: 87837 topic_id: 17109 reply_id: 67555[/import]

#5

@bruceleroyjr The game we are working on has hundreds of physics objects on screen at a time. The ONLY time you should have a performance problem (and it IS a big performance problem, I know) is when approximately 30 or more physics objects are colliding.

Not sure what else is going on in your game, but as far as the coins go if you don’t already have them set to isSensor=true then you should. And, are the physics bodies of the individual coins touching each other? We had a similar problem where we positioned objects too close to each other and their physics bodies were touching and causing non-stop collisions. We shrunk the bodies a couple of pixels and the performance problem was gone.

I don’t know about your game loop, but typically it’s easier to move the player and keep everything else static. Then have the camera follow the player. Jon Beebe posted a few lines of code for a camera a long time ago. We’ve used that in our game loop and it works great. There are major performance problems with the physics engine, but you should only see that when things are colliding. [import]uid: 40137 topic_id: 17109 reply_id: 67561[/import]

#6

Have you tried making them sensors? I have over 100 physics objects onscreen in my app, but the majority of them are sensors and apparently that’s easier to handle. [import]uid: 89724 topic_id: 17109 reply_id: 67562[/import]

#7

Thank you mmathias6410. I re-looked at my code and you were right. My coins were set to “dynamic” body type and were place too close to one another, so when they were moving, they were actually colliding to one another on each move, which was causing the pre-mature collision events and I’m assuming the performance slow down I was seeing. I had to put a debug print statement in the collision function to see the pre-mature collision between the coins.

Instead of me adjusting the pixel spacing between the coins, I just changed them to “static” body type and now they are not colliding to one another while they are moving. Also, yes, I have them all set with isSensor = true.

I’ll have to test this new build tonight on my IPod 3G to see if this fix improves my performance and gameplay. I notice the simulator loaded my code faster so it looks like its working. I’ve been stuck with this coin/collision problem for 3 weeks. I’m crossing my fingers that it works. =)

UPDATE: It worked. I got my coins to move with transition.to, physics collision detection and no major performance problem on my IPad 2. I got it working on my IPod 3GS, but there are slow down moments. In general, the physics engine definitely needs optimization for lots of physics objects that move. [import]uid: 87837 topic_id: 17109 reply_id: 67577[/import]

#8

In general, the physics engine definitely needs optimization for lots of physics objects that move.
I’ve worked on AAA console titles that don’t allow a 100 simultaneous physics collisions. :slight_smile: [import]uid: 41286 topic_id: 17109 reply_id: 67692[/import]

#9

@ foniks That’s understandable. However, it has been done with other implementations of Box2D as explained in several of the links in this thread:

#10

Unless I’m missing something, that thread describes decoupling physics from frame rate. In your original case above, you would still get atrocious performance, it just wouldn’t cause the game to try and simulate all the frames (i.e. all objects will have moved the appropriate distance over a fixed period of time). [import]uid: 41286 topic_id: 17109 reply_id: 67712[/import]

#11

@foniks

Yes, I was referring to your comment about 100 simultaneous physics collisions, not the above game loop. I agree that game loop would still result in bad performance. [import]uid: 40137 topic_id: 17109 reply_id: 67745[/import]

#12

Thank you everyone for the feedback and help. This is really awesome to have a development community that is supportive and helpful.

I’ve already modified my code above to not execute a loop on every frame. I now just execute it once and use the transition.to() method to move my coins across the screen. In addition, the other culprit in my performance problem was my coins pre-maturely colliding during transition. Thanks to mmathias6410. I was able to debug and re-code the logic to not collide to one another during transition.

Here are the lessons learned from my coding ordeal:

  1. Avoid using loops in your code during time sensitive areas. I initially used loops because I didn’t want to manually specify my x and y coordinates on each coin. However, by not using loops, it has dramatically improved my game performance. Although, I still speculate that because I’m using physics also with the loops, it does add an extra overhead to performance. Remember, like I mentioned before, I did run a test without physics on and my game ran fine on my IPod 3GS with the same looping logic :wink:

  2. Be sure to add enough spaces between your physics object if you are grouping them together and using the collision detection event listener. If you are going to group physics objects together and transition them with collision detection on, make sure there are enough spaces between them or set the physics objects to “static” body type so they don’t move during your transition. Like I said before, I had no idea they were actually colliding with one another during the transition until I implemented some debug print statements in my code and saw that on every move, they were pre-maturely colliding, which in turn was causing Corona to compute heavily on collision events that weren’t needed.

I’m still in the process of optimizing my code more. Definitely, it’s been a learning experience that I hope all of you can avoid =) [import]uid: 87837 topic_id: 17109 reply_id: 67790[/import]