OpenTomb
OpenTomb copied to clipboard
opentomb
Speed issues
I have noticed that after my recent changes with collision shapes and flags, FPS has significantly dropped, especially when Lara is in spikes, and even in death state. This is certainly not Lua issue, as collision callback function never enters if Lara has no HP, so most likely it's Bullet slowing down with bodies without contact response?
Yes, I noticed it too. I have a significant drop in frame rate at the beginning of some TR5 levels. If I do nothing and just wait then it improves after some time.
Seems that sliding is very expensive now. Indeed, it looks like a Bullet issue.
On the second thought, I have no slowdown on the same slope after some time. Seems that there is something at the beginning of the level.
I guess it's one of the collision flags which produces this bug. Possibly, CF_CHARACTER_OBJECT is too expensive to be applied to every NPC (however, all NPCs are disabled until triggered, so you surely shouldn't get any slowdowns on level start-up).
Try The Base. When Lara start to slide she's awfully slow. But after the grating falls everything returns to normal.
This seems to be exactly the time required to pre-activate all entities. So, this slowdown happens during level initialization.
I've noticed that these entities have ghost collision mesh at the beginning but turned to dynamic collision mesh after initialization. I've tried to look at it in the process using r_coll and voila, I've got a crash:
#0 0x08360f93 in btDiscreteDynamicsWorld::calculateSimulationIslands() ()
#1 0x08366aa4 in btDiscreteDynamicsWorld::internalSingleStepSimulation(float) ()
#2 0x0836037f in btDiscreteDynamicsWorld::stepSimulation(float, int, float) ()
#3 0x08303237 in Game_Frame (time=0.0543360002) at src/game.cpp:842
#4 0x08229666 in Engine_Frame (time=0.0543360002) at src/engine.cpp:522
#5 0x08336c6a in main () at src/main_SDL.cpp:26
Ok, I misinterpreted the colors. What I really meant was that these entities were Island sleeping before that commit and become Active after it. According to Bullet wiki
Found the reason:
diff --git a/src/entity.cpp b/src/entity.cpp
index 0fa757b..c626724 100644
--- a/src/entity.cpp
+++ b/src/entity.cpp
@@ -152,7 +152,7 @@ void Entity::genRigidBody()
switch(m_self->collision_type)
{
case COLLISION_TYPE_KINEMATIC:
- m_bt.bt_body.back()->setCollisionFlags(btCollisionObject::CF_KINEMATIC_OBJECT);
+ //m_bt.bt_body.back()->setCollisionFlags(btCollisionObject::CF_KINEMATIC_OBJECT);^M
break;
case COLLISION_TYPE_ACTOR:
With this patch it doesn't crash, entities have the same colors and it works as fast as before.
Hmmm, very strange... Theoretically, kinematics should work as fast as statics, maybe a bit slower, but they slow down everything too much...
I'll make additional tests, maybe flags need to be ORed instead of direct set.
P.S.: Yes, white meshes usually mean that body is either dynamic or bear some other kind of activity... Hair is red because I forced disabling of deactivation in case if Lara hangs for a long time on a ledge. Green meshes generally mean object is static (I have no idea what "island sleeping" means, seems like some english physics term).
Here's excerpt from Bullet wiki:
If you are using kinematic bodies, then getWorldTransform is called every simulation step. This means that your kinematic body's motionstate should have a mechanism to push the current position of the kinematic body into the motionstate
Perhaps, this is very expensive in OpenTomb.
Also, all entities begin as white and become green after initialization. Before that commit they were green all the time.
Yes, I noticed that. Also Lara in TR2-5 become blue, if you start running immediately after starting up. I guess it's some special character behaviour as well.
Yep, seems that ORing flag values does the trick. However, I still get ultra-low FPS when I'm in spikes...
This is certainly not Lua issue, as collision callback function never enters if Lara has no HP
Entity::checkCollisionCallbacks called every time even when Lara has no HP in "undead" state. The crumbled floor still falls even in that state. And that function is called every frame when Lara is dead on spikes.
Compiler optimization can have a dramatic impact on Bullet performance. I mean that any optimization level affect at least some places but not the others. Just recompiling it might greatly improve performance in one place and at the same time make it much worse somewhere else.