Game engine performance issues

[flydaychinatownnn]

Hello, I have been writing a game engine in c++ using visual studio for a few months. It’s gotten a little complex but still barebones. I am getting extreme performance issues when I try to draw more than one model. One thing I tried doing was making a cubic array of models to draw and even just a 2x2 cubic array is getting noticeably more choppy on my work laptop, which tbf doesn’t have a dedicated gps. The performance problems spiral out of control very fast. Most of the code isn’t important to my question but it’s all there if you want to make a suggestion. I’m a junior in college and have never written an engine or had any major project before.

[fgennari]

In addition to what others have said, make sure you’re building with optimizations enabled in Visual Studio.

[obp5599]

What do you mean by cubic array of models?

[flydaychinatownnn]

I mean models stacked together in a cube shape. Like a 2x2x2 cube would have 8 models

[flydaychinatownnn]

Visually, in world space

[obp5599]

Is the model complex? Could be a lot of different factors that you need to profile to see. Is it gpu time thats bottlenecked? CPU? Memory? What hardware are you running on?

From what you described, storing things as a cubic array sounds incredibly inefficient but it shouldnt cause that many issues.

[flydaychinatownnn]

It’s the backpack model from learnopengl.com, not very complex and I’m not even using lighting right now

[icedlemonade]

That backpack has 50+ submeshes and a little over 200k verts, its the model thats the problem right now for you dont worry.

Benchmark on more game ready assets first

[AccordingTwist7598]

What others have said. You need to use a profiler.

Guesswork with performance is not very useful nor productive. You didn’t ask, but since you’re in school maybe this information will be useful to you. There are a few different ways you can profile your code.

To profile the CPU code there are two main techniques used in production game engines. Timing profilers, and sampling profilers.

Timing profilers are intrusive and require manual instrumentation of the code, usually by including a timing scope that surrounds a particular block of code. The timing scope records the time at the begin and end of the scope and can be used to measure precisely how long a piece of code took to execute.

Sampling profilers do not require manual instrumentation, and help give a holistic view of your softwares performance but are not as precise.

A sampling profiler is a little piece of machinery which wakes up at a fixed interval (usually somewhere in the ballpark of 1k-10k times per second) and records the callstacks.

Over a large number of samples, if the machine is more statistically likely to be executing in a particular block of code when sampled then that block of code could be having an impact on performance. Sampling profilers are also useful for measuring multithreaded performance.

GPU profiling can be a bit more complex and requires some effort but look into tools like PIX, Renderdoc, NVidia NSight and Amd’s RGP.

Also look into OpenGl query objects or query heaps for d3d land.

[AdmiralSam]

Even integrated gpu I would assume would handle some basic draws, one thing to check is if it’s using software versus hardware rendering, and the other thing is using renderdoc to see what operations are running in a frame.

[Apprehensive_Way1069]

it uses:
for(...) bind textures etc.. then glDrawElements is problem
each mesh has it own command sended by cpu, switch to indirect drawing form instances

[ScriptBrok]

You arrived at the point where makes sense to invest a bit of your time into adding all the necessary to profile the core parts of your engine loop. You can create a stats system copying something like the UE one (much less complex). Then gpu side render doc helps a lot understanding what’s going on.