Performance Testing

[Dreikblack]

13 minutes ago, Josh said:

Are some of the icons not appearing on top of those transparent backgrounds?

Yep. This is how it  looked before:

13 minutes ago, Josh said:

What else should I be testing? Just the game in general, or something more specific?

I guess just in general. At most heavy map where fps drops almost by half it happens if few dynamic lights on screen. On RTX 2070 is low on any map tho.

900 here:

~500 here:

This map loads with New Game button.

Make sure you have latest version from "master" branch. Not sure why localization was not working for you tho. It should work fine if you have "English.local" at "Quake Tactics\Resources\Localization" and .exe in Quake Tactics folder

[Dreikblack]

btw 2500 fps on TestLevel now and 2200 on same map on prev build before z-sorting update. 1000 fps on Easy map which basically is just bigger. Also main menu have only ~1000 fps.

Take in mind maps are made with many cube brushes for every tile. Maybe it's not optimal but i started a project before Ultra got an Editor

[Dreikblack]

Added HUD toggle to see if visible GUI affects performance - barely any difference (F11 key be default).

Did test with RTX 2070:

150-160 in menu and at Easy map on both builds. 700 fps at TestLevel with disabled z-sorting and 650 on prev build with enabled z-sorting

[Josh]

I am going to comment out the z-sorting modification in the release of 0.9.7 that goes out on the stable build, and then we can go back to testing it. I am pretty sure I can make it smart enough to detect when there is a solid background, but I would rather have it working correctly in the stable build and then experiment with it some more on the beta branch.

[Josh]

I am testing your latest build on a GEForce 1080 at 1920x1080 resolution. Framerate is about 240.

Is there a simple way to disable the fog boxes?

[Dreikblack]

8 minutes ago, Josh said:

Is there a simple way to disable the fog boxes?

Replace AirTile.cpp content with:

#include "UltraEngine.h"
#include "AirTile.h"
#include "GroundTile.h"
#include "../../Game/GameEditor.h"
#include "../../Game/Game.h"

AirTile::AirTile() {
	name = TILE_AIR;
	walkable = false;
}

void AirTile::Start() {
	Tile::Start();
	auto entity = GetEntity();
	if (!entity) {
		return;
	}
	entity->AddTag(TILE_AIR);
	return;
}

void AirTile::initPosition() {
	tileHeight = TILE_LENGTH;
	Tile::initPosition();
}

void AirTile::updateVisibility(shared_ptr<Unit> movedUnit) {
	return;
}

bool AirTile::isVisible() {
	return true;// fogBox->GetHidden();
}

void AirTile::Update() {

}

shared_ptr<Component> AirTile::Copy() {
	return std::make_shared<AirTile>(*this);
}

Almost no difference for performance for me

[Josh]

Okay, I am just hitting "New Game" and leaving the camera in the starting area:

• With fog: 240
• Without fog: 253

Not a huge difference, so I will look at some other things and see what has the biggest impact.

[Dreikblack]

On beta after one of latest update fps is 5x lower now in the game, old builds have normal fps. Can't reproduce it in simple example yet

[Josh]

Yes, it is much lower. I expected the material painting to create a performance penalty, but not such a big one.

Testing the default start scene from Ultra 0.9.7 on a GEForce 1080

0.9.7: 194 FPS
0.9.8 with MAX_MATERIALS set to 1: 169 FPS
0.9.8 with MAX_MATERIALS set to 4: 37 FPS

Material painting is worth having reduced performance, when multiple materials are in use, but I would expect something more like a 20% reduction in performance, not nearly as much as we see here, and it's also not in use in this scene so the impact should be zero.

More testing...

[Josh]

The difference seems to be entirely due to the way the PBR shader is coded. If I look straight up to try to fill the screen with the sky, the framerate in my build of 0.9.8 is a little bit higher than 0.9.7, so it seems there is probably nothing in the C++ rendering code that is wrong...

[Josh]

I think the fragment shader does not like the fact I am declaring an array of four materials. I probably need to restructure it so only one material variable is used.

[Josh]

Simply restructuring the code brought the framerate back up to 193 / 127 when MAX_MATERIALS is set to 1 and 4. I would prefer for the extra materials to have no impact at all when they are not in use. Shader code performance often behaves in unpredictable ways. More testing...

[Josh]

Simply unrolling the loop raised the framerate to 153 when MAX_MATERIALS is set to 4. I had a strange feelings loops were slow but this is really surprising!

https://gamedev.stackexchange.com/questions/147206/glsl-shader-performance-reduced-by-loop

[Josh]

The readings I am taking here are at 1280x720 resolution with 200% scaling, so the pixel pipeline is 4x more expensive to render, BTW.

It seems to be as I feared. The multi-material code always incurs a significant cost, even when only one material is in use.

The solution is to define a separate version of the fragment shader for each number of materials that is active. That way the shader will only be compiled with the number of materials that will be used, and you won't be paying for extra materials you aren't using.

[Dreikblack]

After one of latest update in beta fps dropped for me about 20%, noticeable on any map in my project except main menu.

[Dreikblack]

Tested my game with 0.9.7 and last beta:

Demo map: 0.9.7 - 1000-800 fps, but a lot of level mats were broken (just white, idk i replaced shaders and replace Lambertian with Pbr). Beta - 860-650

Easy map: 0.9.7 - 900-1000, beta - 750

Test level (very small map, uploaded to master branch): 0.9.7 - 2200-1900, Beta - 1400-1200