Big performance issue on Windows only ! (works on Linux)

Hello everyone :slight_smile:

I’m working on Linux on a game project that is running perfectly well at 60fps on Ubuntu. Tonight I tried the game on Windows which is on the same machine and I’m really surprise that it can barely reach 5 fps ! :eek:
Tried it also on my laptop with other graphic card and same issue.

I have not that much in the scene: one half cube for the ground and walls, two characters with quite a lot of bones (250 each) but only a few for the skin deformation, no texture right now, one light to see something and that’s all.

The debug on Windows shows the physics at 90%, logics at 5%, animations at 1%, and other at 0%.
It gets faster if I set the “Max Logic steps” at 1 instead of 5 in the world setting but it still stay around 25fps.

Did I something wrong? What could it be?
I don’t have any errors in the console except 10 times the warning “removing controller with non-zero m_registerCount: -1”.

For some reason near and radar sensors are much much faster on linux than windows.

that sounds like a bug, those are used all the time.

I am partial to collision.hitObject list now, with a sphere.


I wonder what is faster? a sensor that detects collisions with objects, and does getVectTo, and compares it to its own rotation.col to see if its within radar angle distance, or radar on windows?

Those statistics seem pretty self-explanatory…? I mean, we can’t be sure without blend files to confirm, but if the profiler indicates the slow-down is mainly due to physics, then that’s where your issue must lie. Did the profiler indicate similar results on Linux, despite running at 60 FPS?

I imagine if you have two characters with 250 bones each, they must be really high-poly (not much point to have 250 bones for a 400 polygon object). Is that the case? Are they physics-enabled? Are you using sensors as sdf mentioned, or any other logic bricks or scripts? I’d imagine you must be to have 5% logic usage.

No, on Linux, the debug profile is very different:

physics 0% and it goes to 5%-30% when collisions are activated
logic 10%
animation 30%
rasterizer 5%
overhead 3%
gpu latency 50%
other 0%

Collisions are the only physics thing I’m using.
There is 20 boxes with Sensor physics type attached on each character, and other boxes in Static to detect the sensor one.

The characters are low poly, bones are only used for game mechanics, to drive the hitbox. There are also bones used for better deformation (like elbows, biceps, shoulders) that I can remove but the profile doesn’t seems to tell that is too high when it’s working on Linux (animation 30%, 4ms).

Here is the files but it’s really rough. I’m not even sure it will work everywhere (and if you are on Windows with a pad, unplug it, it makes errors, I know I did it very bad for the moment… :))
You can start the game.blend and see if it’s running well on your computer.

Ooook reboot on Windows, I delete more than half of the boxes with a collision sensor and the ones in static and : 60 fps but the physics profile is still high (30%) when it should be like on Linux at 0%.

Why there is a so big difference on Windows?

I can’t use less collision for this prototype. I even need more… I could probably optimize it and activate the hitbox only when it is needed and only the ones I need. Not everyone all the time like it is right now. It may be enough, I hope.

I didn’t find it but can we at least deactivate/activate sensors during game?

Check if there are dynamic shapes stuck inside other physics shapes (static or dynamic). Usually when physics consumes that much time it is because of a permanent compenetration between objects.

are you using sensor physics type? do the objects need to be impacted or just detected?

the dececting object can even fake impact using applyforce.

You can using states (every sensor in an inactive state will not be evaluated).

Yes I’m using sensor type. What do you mean by impacted?

I need that my objects that have the sensor type detect each time they collide objects with static physics type.

Ace Dragon > good idea. Never tried the states, it should help :slight_smile:

Yes, my setup is like that. My character rig has constantly sensor and static type object that are colliding. But the property is set to find object with a specific game property. Is it computing collision even if the game property that is set doesn’t match? that’s why it’s so slow?

It’s working quite good for me, except that so player can’t pass ladder!

Ups, sorry, not the real thread:D

This is a very simplified setup of what I did in my game prototype:
When several sensor cubes reach other cube objects that has the property that the collision sensor is looking for, it does a script. Even in that example, the frame rate drops a lot. This time, both on Linux and Windows.

Is it possible to optimize that? 10 cubes, only detecting collision, that’s nothing. Did I something wrong?

Why are they overlapping like that?
( each sensor)

and each sensor is printing “Collide”

print is a very heavy operation from what I understand

tadaz it’s fixed


collide_sensor_fast.blend (498 KB)

Thanks for the file :wink:

Tried it on my game and it helps a bit BUT I find out why it was so slow: it was because my character mesh itself was in “static” instead of “no collision”. So, it was exactly what pgi said… I just only check my hitboxes, not the other meshes! It’s so stupid…
That plus the optimisations of BPR make the game runs at 60 also on Windows! :cool:

I still don’t understand why the difference between Windows and Linux is so strong. Anyway, a big thank to you all :slight_smile: