CopperCube 6 Game Engine

CopperCube 6 Game Engine

评价数不足
Optimizing for DX9
由 RedBerylFTW 制作
Tips for optimizing DX9 games for performance
   
奖励
收藏
已收藏
取消收藏
Optimizing
So you want to make a DirectX9 game...
You know why you're here. You probably saw this nifty engine available for free and you got to work making the game you were dreaming about. But then, like most of us, you ran into one of the biggest problems with this engine. Lag. Luckily for you, I've got some pointers to help you increase performance without sacrificing complexity.

Here are some must-knows about DirectX9
Models and Visuals
This is the age of Vulkan and DirectX 12, so you're probably very accustomed to having a mostly unlimited polygon budget. Since CopperCube only has the DirectX 9 and OpenGL rendering options available, you'll have to really pay extra attention to where you do and don't need polygons. Just like the retro dev days of yore.

To put this into perspective, one average Quake 2 level has a maximum of 10k polygons. But don't let that discourage you. DirectX 9 isn't limited to Quake 2 standards, and you can definitely afford more than that. Remember that DirectX 9 is the rendering api that powered games like Alan Wake, Battlefield Bad Company 2, Fallout New Vegas, Far Cry 3 and a hell of a lot more.

I personally recommend keeping your maximum polygon count per scene under 50k. It is entirely possible to do this without sacrificing quality where it matters. The player character should usually be a higher detail than the environment. You can go above this, but you should try to stay under it.

Use primitive objects like boxes for collision instead of mesh collision. The actual processing difference is tremendous. Mesh Collision can create enormous performance problems.

If you're using buildings that have multiple faces on one flat side, try to reduce that flat side down to one or two faces. You want as little subdivision as possible on more simple geometry.

Triangulate your complex models. This doesn't get said enough. Computers are very stupid, and quad vertex faces require extra instructions to render when they're deformed. DX9 doesn't like quads and wasn't optimized for them.

Animated meshes need their bones to function, but having too many bones can drag on your performance in unexpected ways. Try to reduce the number of bones you use. Animating every finger on your hands is fine for a first-person shooter, but not every model in every game needs perfectly animated fingers. Look at GTA San Andreas for reference.

One of the best available GPUs in 2005 was the GTX 7800 512mb model. In the "Scene Metrics" CopperCube window, you can see the amount of vram necessary for the current scene. Try to keep that under 512mb, and only go above if you absolutely have to. I know that doesn't sound like a lot since most GPUs now have anywhere from 4-34gb vram, but you aren't trying to maximize your GPU. You're trying to create a functional game under the limitations of the engine.
A/V and Compression
I know, it sounds very appealing to use the highest resolution textures with absolutely no compression because you want your game to look as shiny as possible. But this isn't a modern rendering API, and you aren't a AAA corporation. You aren't going to achieve the fidelity of a modern DirectX 12 or Vulkan game made in Unreal or Unity. But just like all of the developers who were once limited by the PS2, the Dreamcast, the Gamecube or the Xbox; you can still make your game look great. Here are some recommendations for textures to keep your performance strong without looking like your game was made for a microwave.

For linear games with smaller scenes:
Character Texture max 1024x1024, Compress between 30-60%
Environment texture max 512x512, Compress up to %30
Light map 512x512

For open world games with larger scenes:
Character texture max 512x512 Compress between %10-15
Environment texture max 256x256 Compress up to %10
Light map 128x128

For retro looking games:
All 64x64, compress %5

As for sound, you're probably very familiar with WAV and MP3 format audio and that's great. But in order to prevent your audio from causing unnecessary performance issues, you'll want to use OGG files for most things. A couple of audio guidelines to keep you stable are;

MP3 files should be 32000hz at 160kbps with a constant bitrate.
OGG files should be 32000hz with a quality rate of 10 for dialogue and 8 for sound effects

Only use MP3 files for longer music. They take longer to load, which can drag performance. Load them as infrequently as possible.

Use OGG files for literally everything else. Talking, footsteps, gunshots, short sounds and other sound effects.
Actions/Behaviors/JavaScript
This is a little bit more advanced, but I'll try to simplify it. Most game functionality in CopperCube is processed via JavaScript, even when using pre-made actions and behaviors. CopperCube itself is written in C++, and JavaScript is an additional frontend scripting language designed to be more simple but still complex enough for advanced users. Here's how it works;
When you build a game, the engine compiles all of the necessary C++ code into the executable. When that happens, the JavaScript you use is interpreted into something the compiler can understand. If you're familiar with very modern JavaScript, you're probably expecting JIT compilation but I don't think that exists here. This is the reason JavaScript in CopperCube appears to have worse performance. It literally has worse performance. Does that mean you can't use a lot of Javascript? No, it doesn't. But it does mean you should minimize use of the pre-made actions and behaviors if you can. Here are some thumb rules to help minimize performance impact:

Try not to use multiple behaviors and actions for something that one behavior and action can handle.

Keep your variables inside of "Execute Javascript" actions. Every "Set or Change a Variable" action uses additional instructions, which can hurt performance.

If you can write your own Action/Behavior scripts, do that instead of using the defaults. You'll have more freedom to optimize your code. Remember; Less instructions = better performance.

Coppercube allows for coding HLSL and GLSL shaders, and the same logic applies. Minimize the number of instructions to be executed and you'll have better performance. Also, remember that DX9 has a different buffer limitation than later iterations.

And that's it. You've learned a few ways to optimize your game performance.