Game Performance Question

OZApps

This is the one things that every one talks about and strives to achieve, however...

I have a question, what would the difference be between using Box2D bodies vs creating your own shapes/sprites in terms of performance.

1. With Box2D bodies (Kinematic) you can update the same and then with a command, the entire world is updated
2. Any collosions are raised as an event, so you don't have to check every now and then for AABB or CircleVsCircle, etc collisions

However with your own engine,
you have to create the objects like in box2D, but then check for all collisions yourself

my points of consideration are that Box2D is a C/C++ library where as collision detection done by us is Lua code.

Any ideas on the difference in terms of performance? or is that minimal and does not matter?


Secondly,
on a similar topic as on other threads about enter_frame loops,

What are the differences between a central enter_frame loop and enter_frame for each class object. Specially since our Lua app is going to run on a single threaded application, these would not get parallel execution, but serial (one after the other)

pseudocode:

main_loop
do_one()
do_two()
do_three()
end

VS

main_loop
end

class one
enter_frame
do_one()
end
end

class two
enter_frame
do_two()
end
end

class three
enter_frame
do_three()
end
end

incipient

I can't give much information here, but just a little on how I use them.

I have used collisions before but did not need physics, so I went with TNT Engine instead of Box2D. I thought the lack of physics calculations (which are very complicated!) would make the game run faster

For performance of enter_frame, I believe there is no big difference between having one central event, or having a few smaller events. If you are running thousands of objects there might be a difference. I use both, depending on what makes code more readable.

for example, I had a "cloud" object that had to move across the stage, and create little "rain drop" objects at the position of the cloud which fell to the ground. I used an internal enter_frame for the cloud because when the cloud was created (in init) I registered the listener, and then within the clouds class it was able to move itself across the stage (newx = oldx+1) and also create rain drops (if random(0,1)=1 then create raindrop). The raindrop also had its own enter_frame to make it "fall" to the ground.

If i had tried to do this all within one central enter_frame to do this, it would have had a very negative impact on performance to try and pass the references for the clouds and raindrops back to the central enter_frame to do the action. This would also make reading the code a LOT harder to find out what was being called from where.

For other parts of the project i did it within a central enter_frame because i had easy access to the objects, and they needed to interact with each other.

The amazing @ar2rsawseen will be able to give a final answer on what is technically the fastest

Hope this helps someone

OZApps

@incipent, the example that you say of a rain drop can be looked at as

main_loop
createRainDrop() --> Checks if a new rain drop needs to be created or not
moveRainDrops() --> Moves all raindrops present on screen
moveClouds() --> if you have multiple cloud objects to move
end

and each of the functions could do what you were discussing, so it is readable and...

Does it have any difference in performance, that remains the question

incipient

Haha you do seem to have a point @OZApps. I am not sure why it did not work out like that for me...

You could try a very simple case test to see which is better (I am not on my computer so I can't check now). Create 1000 sprites and move their positions around in one enter_frame, and test again using 10 enter_frames to move 100 sprites - compare framerates If it runs smoothly on both, keep turning up the number of sprites until you see some difference, or the framerate gets too low (<10?). You could also do the test using mathematical calculations instead of sprites if you wanted to remove the graphics aspect.

ar2rsawseen

Of course c++ collision detection works better than Lua (although with LuaJIT they should be quite similar)
And yes plain collision should be faster then Box2d with all the massive additions (keeping up with the whole state of the world, where in plain collision you can check only for collision with specific boxes you need)
So if you don't need physics it will be better to use plain c++ collision detection, as TNT Collision engine

About multiple enter frames, from the enter frame even stand of point, there should be no difference. But well calling multiple functions is always worse then calling one, although on c++ level that probably does not make much difference anyway

eezing

With concern to enter frames, I've edited my recent post:

http://giderosmobile.com/forum/discussion/4506/two-ways-to-move-a-bunch-of-sprites-benchmarked#Item_6

SinisterSoft

If you have lots of sprites and want to keep the game running at 60 frames per secons (60hz) *recommended* then you should use one event for them all - not each having their own. You might not notice the slow down on your own phone - but on a 3GS, or low entry android phone maye have slow down or a lower frame rate.

If you have an ios version of your game then consider using tntcollision (and give a donation) as luajit on ios is not as fast as luajit on Android (on Android I don't think it makes a difference with tntcollision or not - especially for simple square/rectangular objects).

The biggest slowdown - is Z sorting (if you need it) - having a Z variable for each sprite object with the ability to sort it at a specific time...

eg stage.spriteparentname:sortChildrenZ([depth]) -- depth is number of generations to go, 1 being the default

(just the generation below that sprite, not children of children) might be a useful addition (as would a built-in 4x4 matrix for simulated 3D ). With (optional) Z sorting games like Mercs and Cabal would be easy.





Maybe Z sorting could be added as a plugin for pro users?

OZApps

@sinistersoft, the walls in merc and gameplay reminded me of Commando and Ikari Warriors, though at the time I would drool over the colours and sound that Amiga offered over the humble speccy, After seeing Cabal on the NES, I think that speccy indeed had some of the best graphics (also due to the lack of colors, devs focused on the graphics.) On winning the round why does the hero runs as if he got his crotch on fire (very awkward).