General slowdown with larger project?

I'm worrying a bit for my game project. It's becoming quite code-filled across several event sheets, and I'm noticing that even if I run an old level file that used to be able to put out ~500 fps in Unlimited mode, it now is just above 200 most of the time, but the level itself doesn't use more code than before.

Will the project just keep slowing down as I expand on it (levels and a few bits of "code" are already external)? Is there something I can do to avoid this global slowdown of the game? I tried lots of stuff to try and pinpoint places where the sudden drop could occur, but it doesn't really get better until I remove basically everything in the game. Could I possibly make MORE event sheets so that instead of just disabling groups to skip code, I skip including other event sheets? Would that help?

I just don't know how Construct works on this level.

Something to add: If I run a layout without any code included with it it still doesn't put out that much FPS. Should I be very sad yet?

When your game drops under 60 fps, panic.

As long as it runs > to 60, don't care. You're just displaying more stuff then human brain can handle, so nothing to care about really.

See, it's not that simple. I've been making content that doesn't really encompass maybe 20% of the project in the end and I've already gotten a drop on an untouched level from 500 to 200, to me that implies that if I finished the game it could be struggling to get above 30 fps at the best of times, even if a layout runs very few events.

Do you have copies of the older versions where the frame rate was higher?

You might want to try some experiments. First, after making a backup, I would try first disabling, then deleting all code and see if it makes a difference on the frame rate if its been disabled or deleted. Then I would also try deleting everything from the .cap while incrementally checking the frame rate to try to find if there's anything in particular that deleting helps the frame rate a lot. Then when you finish deleting everything, compare it to the FPS of a fresh .cap.

If you can get the frame rate hit to be there even in a .cap with nothing else in it, maybe someone can help fix it if it's a bug in construct.

I've tried most of those things and it's always a steady increase in FPS, suggestion it's because the project is growing. If I remove most of what's in the game it reaches thousands of FPS, but if I just remove some I might get 10 fps increase until I remove enough to not really make it a working game anymore.

So it doesn't seem to indicate a single culprit, no.

Hmm... did you try after disabling/deleting the code, keeping the objects in the project, but not having any instances in the layout, then trying again after deleting the actual objects from the .cap? Those two should be about the same.

If there isn't anything there of note either, then my best guess would be to incrementally disable parts of the code to discover what's taking up the most cpu time and to try to find ways of optimizing it. It may be 10 fps here and there, but then if you make 10 optimizations that's 100 fps.

Tried that stuff. What confuses me is, as I said, the level I'm testing on isn't running anything new since a long time, so there's code being skipped and everything as usual, but the game still slows down as if all the code within the CAP weighs down on the whole thing.

Is this not intended to be possible with Construct (kind of)? I mean, can it only be my fault?

I assume this is the iconoclasts that we're talking about (and therefore you can't post the .cap), and that game should definitely be possible with construct. More code elsewhere in the .cap really shouldn't affect other layouts than the ones the code is in.

About how many layouts, events, objects and event sheets does your .cap have?

Nine layouts which I didn't really need all of them of, and 18 sheets. All levels are external, so is dialog and a bunch of cutscene code that can be saved in dialog files. The layout count hasn't grown because it started with seperate layouts for some sheets to counteract the past bug where too many objects in an event sheet could crash Construct when opening the expression editor.

Three more test ideas:

What happens if you try making a whole bunch more event sheets that aren't included/attached to anything, and copying and pasting code from other event sheets into them?

What happens if you make a new layout, and add a whole bunch of new unique objects to it?

And what happens if you add lots more layouts?

Not much happens, but there's still the matter of running a single, new, blank layout and only reaching ~500 than the ~2500 I get if I remove everything except a layout with maybe one or two sprites in it.

It's just natural that you get much lower framerates in a project compared to a nearly empty project.

What basically counts is the balance between cpu and gpu usage.

Every event of a layout (+ the included event sheets) will be checked on every tick. If the condition results to true, the actions are performed, otherwise ignored. So even an event that has no actions costs cpu time. We are talking of microseconds, but overall it can sum up to a reasonable value.

It is common practice to just set values/colors/sizes/etc on every tick. This is ok, because most of the time the gpu needs far more time than the code. But when you are about to finetune your project it might help to group these actions under an event that results to true only when a change is needed. This way only the condition costs time (a much smaller amont of time) when there is no need for a change.

On the gpu side, the more shaders you use the less effective the card. A pixel shader applies its code to every pixel (even the transparent ones) of the object it is applied to. This costs a lot of the gpu's processing power. Gfx cards have a limited amount of shader units to prevent overloading, but even if you just use a few shaders they will drop the framerate at a high amount. (Just try a clean new cap and apply the warp fx to the layer)

So try to avoid to much shaders. If you need an effect for a few dozen of objects, it is the better way to group those on a layer and apply the effect to the layer, instead of having a few dozen effects applied to the objects.

That's what comes to my mind right now, maybe there's something I forgot.

Thanks for helping, but the problem, as discussed, still occurs on levels not using any events at all, and I don't use pixel shaders except for one place.

Speaking of "levels", do you mean Contruct's layouts, or your external levels, which loads into single "playground" layout with a number of included sheets and events? If so, try load every single level in separate layout and include events only specifed for this level.

I mean, if you load, for exemple, "level 1-1", and layout which load that level has included sheets like "level 1 Boss", "level 2-2", etc., it probably will use extra CPU even if it doesn't perform any actions (well, as I think)