Mouse movement causing massive fps drops?

Freeman_Reigns

Simply moving the mouse is causing massive fps drops in my project. I think it might be linked to the hundreds of instances I have, although the drops happen regardless of whether they are on screen or not and the fps stays more or less stable when not moving it.

I'd greatly appreciate any help :)

cybereality

Must be a bug somewhere. I've worked a lot with the mouse and I've never seen this. What does the mouse do in your game and how many objects are listening for mouse events?

Freeman_Reigns

It's an RTS style game. Mouse is used for entering/exiting areas and clicking to select or move units or clicking UI elements. I have about 300 instances spawned that each have mouse entered and exited signals as well as an _input(event) function with left click and right click (if Input.is_action_just_pressed("")). I hope that I explained that properly.

Edit: I've since put the input(event) functions in a separate system node with signals to the units (probably the smarter thing to do) and that seems to have lessened the impact of the drops but they are still clearly there so it must be something else.

cybereality

Yeah, having a global control script is a better idea. Mouse enter/exit is good for a menu or UI, but probably not for 100's of items. Even so, it shouldn't be that slow.

Freeman_Reigns

They may not be related but I get a couple of error messages:

E 0:00:00.557 get_token_identifier: Condition "tk_rb[ofs].type != TK_IDENTIFIER" is true. Returned: StringName() <C++ Source> modules/gdscript/gdscript_tokenizer.cpp:1117 @ get_token_identifier()

E 0:00:00.562 get_message: Condition "symbols.size() < 2" is true. Returned: String() <C++ Source> modules/gdscript/gdscript.cpp:1920 @ get_message()

xyz

This is a job for the built-in profiler. Start your game, start the profiler, let it run for a short time. The profiler will track per-frame time spent in individual functions in your code. That way you can determine main bottlenecks and see when and where they happen. Once you know the culprits it'd be much easier to look for ways to optimize or work around them.

Freeman_Reigns

Ok, so Physics Frame is in red and reads 16.66 ms. I'm guessing that has something to do with the collision shapes on my instances, although I don't have anything in _process function.

xyz

16 ms is normal frame time at 60 fps. Physics Frame will typically be locked at this as it runs at fixed step. So that's normal. Red is just for color coding.

You want to look at the frames whose total time goes way over 16 ms. And then check the distribution of time within such frames. Locate the peaks in the graph and click/drag on them to select the frame at that point in time.

Freeman_Reigns

Thanks for the help. It looks like the Physics Time boosted the total frame time wayyy above 16 ms. I removed "velocity = move_and_slide(velocity)" from the _physics_process and that seems to have fixed the issue. I'm not sure how I could implement this now if not in physics process though...?

Edit: Ok so I added a check for a variable in the physics_process. Not sure if that's the ideal way to do it but it seems to be working well. Thank you for all the help :)