Is it normal my CPU is this high?

Hello. I'm about to make a quick topic since it's over 6AM here but I'm testing my game and I want to optimize it however I can.

A premise: yes, I have read all the articles which talk about optimization.

The game I am making is a top-down puzzle game featuring a vacuum cleaner.

The game is mainly supported by these groups of objects:

- The player, which is followed by a trail made of particles

- the dust, which is made out of semi-small pink coins (the pink is tinted directly in the sprite).

- the room, which contains a good number of aesthetic objects.

Now, I have read how to optimize most of the features. For example, I have reduced many events and removed all the unnecessary "every tick". I was able to make the dust bigger to reduce the amount of it in the room. Deleted many redundant terms and unnecessary values like "wait for 0.000x seconds".

Overall I was satisfied of the result. Until checked the CPU Usage: Over 95%, while the GPU was just 7%.

Now, the CPU is holding all the calculations. It makes sense that it can't be less than 20%.

But 95%? I thought it was too high.

So I made a test, one of those that help you to find out "whodunnit", or which part of the game is stressing the CPU.

So I've started by removing event sheets.

Alright, I have found 2-3 event sheets that take a lot of calculation.

From 95 to 80% of CPU usage.

The room now only has two event sheets, one is used to seeing the percentage without going into debug mode.

Let's start deleting some assets.

Ok, by removing particles I get from 80% to 77%. The gpu dropped from 7% to 5%.

Let's remove all the tiled backgrounds. Not much happened.

Let's remove collisions and other invisible objects. No much happened.

Let's remove the dust: from 77% to 70%. Ok, I definitely need to look at how the dust works in-game.

Now, let's remove all the necessary objects to make the room functional: from 70% to 68%.

Lastly, let's remove all the assets: From 68% to 65%.

Now, thanks to this test I now know where to fix most of the features. But one question pervaded me: Isn't 65% a bit too much?

For a top-down, pixel art game like mine, generally speaking, what is the possible amount of cpu required? I mean, we are talking about a 2D game, not a CryEngine cinematic game.

I checked what, according to the debug tests, makes the game so heavy with the cpu.

The engine and the "draw calls" seem to be the cause of this number.

Considering I am testing a project directly from the editor... does it mean the "draw calls" shouldn't be this heavy after exporting the game due to the compression?

In any case, How else can I do to make the CPU usage as small as possible?

Thank you for reading!

You mean the framerate was set to "unlimited"? Yeah, that option should only be used for stress-testing.

Check the refresh rate of your monitor - if it's high like 120-240Hz, as an experiment try reducing it to 60. See if this improves the CPU usage even further.

Now that you mentioned, there is a motivation I turned off the v-sync.

I was just about to check now, the game has less than 35% of CPU usage, 3% of GPU Usage and 60 fps - but they are not fixed. Sometimes it's 57 or 58, and you can see the stutter coming from the game. Maybe my hope is that, by lowering the cpu usage, I won't see this stutter again.

(The screen is already at 60Hz).

Vsync is a limit to only render as many frames as your hardware can display per second, because additional frames won't be shown anyway. In Construct, a frame, or tick, is basically a run through all your events before repeating. If you turn it off, then your device will try to do that as fast as it can, regardless of what can actually be displayed. So of course it will use up all the processing power it can.

Vsync is a limit to only render as many frames as your hardware can display per second, because additional frames won't be shown anyway. In Construct, a frame, or tick, is basically a run through all your events before repeating. If you turn it off, then your device will try to do that as fast as it can, regardless of what can actually be displayed. So of course it will use up all the processing power it can.

Yes, it makes sense. I have seen the game running at over 500 fps with full ticks on.

However, I've noticed that with v-sync on, the 60 fps are not stable, at least not immediately. How come?

pcgamer.com/what-is-microstutter-and-how-do-i-fix-it

Basically, on a 60 fps sync, even though your system is capable of 60+ fps, if for whatever reason it fails to render any given frame on time for 60 fps (this can be a memory issue sometimes, or simply high load, background processes or overhead, there are many possible reasons that can cause this), it will skip that frame resulting in an effective 30 fps (half) for that instant, which is very noticable as stutter. Over the course of a second, it might only skip one or two, resulting in the 59, 58 fps you sometimes see. This is an oversimplified explanation, and there is a lot more you can read about if you want.

For one thing, frame buffering is a type of vsync that should minimize these issues, but I'm not familiar if that's implemented on the software side or hardware side as far as Construct is concerned, so check your graphics card settings.

nvidia.com/en-us/geforce/technologies/adaptive-vsync/technology

Also see if you can enable adaptive vsync on the hardware side, that could be another possible simple fix.

pcgamer.com/what-is-microstutter-and-how-do-i-fix-it

Basically, on a 60 fps sync, even though your system is capable of 60+ fps, if for whatever reason it fails to render any given frame on time for 60 fps (this can be a memory issue sometimes, or simply high load, background processes or overhead, there are many possible reasons that can cause this), it will skip that frame resulting in an effective 30 fps (half) for that instant, which is very noticable as stutter. Over the course of a second, it might only skip one or two, resulting in the 59, 58 fps you sometimes see. This is an oversimplified explanation, and there is a lot more you can read about if you want.

For one thing, frame buffering is a type of vsync that should minimize these issues, but I'm not familiar if that's implemented on the software side or hardware side as far as Construct is concerned, so check your graphics card settings.

https://www.nvidia.com/en-us/geforce/technologies/adaptive-vsync/technology/

Also see if you can enable adaptive vsync on the hardware side, that could be another possible simple fix.

Yes, I have adaptive vsync turned on!

I wonder, however, how this can affect other people who play my game.

For example. Maybe I find a way to fix this issue with the frame, but it may be just for my PC, because it's dependent on the screen Hz and other factors.

EDIT: I have come to a realization that this had to be done more than a year ago...... And it's probably a principle I didn't consider because I was of a different approach.

By comparing other Construct 3 short projects like Kiwi Story, segmented boss fight, Demonoire, etc, I noticed that all these projects use widely the tilemaps, in particular for aesthetic matters but also for other things as well.

My game doesn't use it. Yes, all the "objects" in the game that make the map are real objects.

This also explains why the objects seem not to move properly when the camera follows the player (just a fraction of a millisecond, but enough to notice it).

I imagine this also explains the high amount of CPU usage.

In my mind, I probably had the idea of making a map as I used to in some 3D map makers - place the object and move it however you wanted. But if this isn't the best case for the game, then I should better use only tilemaps, right?

I mean, technically speaking for Construct 3, an object with no collision, no effects, no anything still acts differently compared to a group of tiles, am I right?

If I turn the game by using mostly tilemaps, should I see better improvements?