[TESTERS WANTED] Speeding up rendering

[will]

I have begun to look at improving the framerate.

I would like YOU to test my very first change on your system.

If you are comfortable building from source, please take 5 minutes to test this very simple change.  This change is not at all indicative of the final performance I am aiming for, it is simply to validate if we are moving in the right direction.

This is a very simple change to source/glest_game/graphics/renderer.h/.cpp

Please use the "?" key to see your rendering FPS BEFORE applying the patch, and then after.

Please report before and after FPS, and your graphics card make, model and RAM size.

Thank you very very very much!

[tomreyn]

Can you explain how to retrieve (and optionally, how to apply) the patch, please? Do I have to git pull or can I just download a Gnu diff compatible patch file via HTTP somewhere?

[tomreyn]

Can you explain how to retrieve (and optionally, how to apply) the patch, please? Do I have to git pull or can I just download a Gnu diff compatible patch file via HTTP somewhere?

Thanks for helping me with this on IRC. On a SVN working copy it's really as easy as:

Code: [Select]

svn -r2455 up ./
cd source/glest_game/graphics/
rm renderer.{h,cpp}
wget https://raw.github.com/williame/megaglest/2a5b19e900c628ccf87aebd18e1e32457688ae8d/source/glest_game/graphics/renderer.{h,cpp}
cd ../../../
rm -f build/CMakeCache.txt
./build-mg.sh
cd mk/linux/
# ulimit -c unlimited
./megaglest


[will]

and we're all dying to know your CPU, GPU spec and FPS results....

also, please note if fog-of-war is broken by this test patch?

[tomreyn]

So, for me, the original r2455 code does 30 FPS in-game (single player game without bots, faction 'Egypt', map 'Conflict', tileset 'Desert2', fog of war off, initial camera focus + angle, no camera / unit movements) with either normal startup or with --disable-vbo on ATI Radeon X1650 XT (RV560, radeon/gallium open source drivers) in full screen mode at 1680x1050 pixel on Ubuntu 11.04 with Linux 2.6.38-10-generic (x86_64) on Intel Core 2 Quad Q9400 (4 x 2.66 GHz), with 6 GB RAM free.

With exactly the same setup (hardware, software, glestuser.ini and custom game configuration) with will's terrain rendering patches applied, and whether or not I run with --disable-vbo, I get 45 FPS in-game - that's a 50% gain. Sweet.

[will]

(note - the test code doesn't use getVBOSupported() in the _loadVBO() function so it always runs the fast path.  That would be a quick fix to test the non-VBO but vertex-array approach.  Also, fog-of-war is broken by the patch.  That's just because the patch isn't production ready, not some fundemental problem)

(secondly, we still have a 100 or more textures for the tilesets.  If the surface atlas automagically packed these into a single texture or two - lived up to its name - then I think the FPS will go over 60 on such a system as tomreyn's)

[will]

interesting old discussion with Silnarm: https://forum.megaglest.org/index.php?topic=6260.msg68664#msg68664

note that I don't advocate making a mega-texture, but rather a proper texture atlas.

Also the fog-of-war should be a single texture with a few nice curves on it, representing all the possible adjacencies.  Each tile in the FOW texture should be 64x64.

Then every time the FOW changes the fowTexCoords VBO in my patch needs a partial update.

[tomreyn]

I've run some more tests, including on my laptop (Intel GMA).

Regarding the terrain rendering patch I can sum up that on my two tested hardwares, I did not come across a situation where the patch decreased performance by more than 1 FPS in-game. However, on both platforms, when I was using high resolutions, the builds which had this patch performed noticeably to remarkably better (with fog of war off) than the original code does.

[softcoder]

Added this code to svn as default rendering for cards with VBO support.

[tomreyn]

Thanks. How can I determine whether my hardware + driver support VBO?

[Coldfusionstorm]

Added this code to svn as default rendering for cards with VBO support.

  This!

[softcoder]

I guess I need to add something in the video info page to explictly display which internal settings are on/off (due to driver features or overriden ini / commandline settings)

[tomreyn]

I think this would be very useful for examining possible issues. Sorry about it. ;-)

[softcoder]

Done, added some internal video name/value pair info in the video screen. These will only make sense to dev's and those familiar with what those values actually do. The top parameter in the VBO flag

[will]

How did you handle fow, softcoder?

[softcoder]

just had to simply re-arange the order of indexes, instead of looping 0 - 3 whenbuilding the indexes + vertices + normals i added:

Code: [Select]

int loopIndexes[4] = { 2,0,3,1 };
for(int i=0; i < 4; i++) {
        index[i] = layer->vertices.size();
SurfaceCell *corner = tc[loopIndexes[i]];


[tomreyn]

<tomreyn> woot, i got 60 RenderFPS (UpdateFPS is just 40 though) with r2464 on my Desktop with either FOW on or off and either an easy CPU player or none at all. r2455 with Will's terrain rendering patch gave me 45 FPS with identical settings (without a bot)

[Omega]

<tomreyn> woot, i got 60 RenderFPS (UpdateFPS is just 40 though) with r2464 on my Desktop with either FOW on or off and either an easy CPU player or none at all. r2455 with Will's terrain rendering patch gave me 45 FPS with identical settings (without a bot)

Assuming that updateFPS means the world update, it's always a constant 40, and unrelated to the render FPS (and if changed, skill cycles may be wonky in timing).

[titi]

On big(128x128)  and even worse on huge (256x256) maps the fps are very low now!
This happens because the whole terrain is rendered at teh moment ....
Softcoder is already looking at it and we discussed some more ideas.
For example how to get more detailed textures in a compatible way  without loosing any speed .

[softcoder]

One other big problem is that this code was assuming the texturehandle was the same for cells that used the same texture file. WRONG (I just discovered this). Each cell always creates a unique texture and 'copies' the pixels from a loaded tileset texture (but the handle is always different) so the rendering of layers is not really happening.

I am looking further into this.

EDIT:

Ok svn tester, give it a try, on my NVidia 9800 I now get 340 fps compared with 250 fps on original render code (before will's change). This latest change uses 'layers' as will has shown but not VBO's rather vertex arrays on the visible cells textures. The improvement seems noticable for me with fog of war off and on.

[will]

Strange, in my layers i printed the layer info out and they are definitely shared sometimes.  I thought the surface atlas was deduping the load?

[Coldfusionstorm]

On big(128x128)  and even worse on huge (256x256) maps the fps are very low now!
This happens because the whole terrain is rendered at teh moment ....
Softcoder is already looking at it and we discussed some more ideas.
For example how to get more detailed textures in a compatible way  without loosing any speed .

This is GREAT news!, i am however working on a "trick" to see if i can get better textures myself.

[will]

Vertex arrays are a step backwards.  Do the atlas, quadtree and fustrum culling we talked about instead.

[softcoder]

Will, yes all in good time! I was actually 'somewhat' wrong about the texture duplicates. There are many duplicates indeed, but also many are unique. In general I just wanted to improve the current rendering, since the texture atlas will take a little time to develop I wanted to fix what we had so its at least better than before.

What we have now is not a step backwards, but not the final either.

[AnimalWarrioR]

if you fixed it'll be great! since the game on large maps is too slow! so we're playing at 64x64 map for two players in Tileset desert to avoid the terrible lag!