fabio

I think there are some OpenGL extensions to speed up this case: ARB_draw_instanced and ARB_instanced_arrays. They are also available on mesa drivers.

The circular minimaps are broken here. Example on current build from svn on Linux with Death Canion: Is it a known issue or it's only for me?

Correct. Since mesa 7.9 r300g is the default driver, so hopefully more users will use it. Adding the fallback for r300c is anyway a good idea since r300g is still also not supported on non-Linux Unixes.

I tried r300c from mesa 7.9 branch but there are the same problems. I'd say, however, to ignore problems with r300c, it's known to have bugs and this driver is no longer supported, see e.g. https://bugs.freedesktop.org/show_bug.cgi?id=25588 .

Note that on r300c it works perfectly with fixed renderpath but it shows the errors I talked before with shader. Are these problems really driver bugs or is a 0 A.D. faulty trying to run in shader mode on a card without the requisite (no GLSL, etc...).

One minor note: the default.cfg file still shows info about the vertexshader render path which is now replaced by shader.

New effects are great! Just a minor bug: when shooting with the Lithobolos to a gazelle, if she doesn't get killed the smoke is still shown for little time, but after the final shot that kill her (poor gazelle ) the smoke line instantly disappear.

I noticed I got black stone bases also with the r300g driver, but they appear fixed now that I am at 0ad r9179 with the same driver version. I then updated the r300g driver to cd2857fae16e1352f39b37f611797e66619d3fe5 and run 0ad under gdb with a breakpoint at radeon_program_tex.c:155 (that line has moved in the meantime) but I never got here (with both 0ad standard/modified FP). I'll attach the updated r300g debug output anyway. Also interesting that with classic r300 there is no FOW, all the map is visible from the start (it's OK on the minimap however). This is a driver bug, but I was expecting that for performance reasons the black on FOW was forced by the game engine and never sent in any way to the graphic driver. r300g-debug.txt r300g-debug-no-tex-mul.txt

With r300c trees and other objects (stone bases) are all black. Enabling shadows fixes the blacks, but shadow are completely borked. With r300c with TEX and MUL disabled trees are OK but stone bases are still black. Shadows still are still broken. I think these are r300c regression (the shader compiler is shared between r300g/c and nobody still tests r300c when the compiler changes...). Taking number from this is probably meaningless.

r300g (mesa master up to 4a7f013f9db793dab8dbc9f71646dab49f12ed2f) debug outputs attached. 0ad run with: RADEON_DEBUG=info,fp,vp,pstat ./0ad -quickstart -autostart=Oasis > r300g-debug.txt 2>&1 r300g-debug.txt r300g-debug-no-tex-mul.txt

Or maybe it's a limit of mesa shader compiler. It would be nice to compare my numbers with other drivers/cards.

I added it to comment 13. On Miletus this is the fastest combination, while on Oasis it is faster but still slower than fixed and vertexshader.

And here are the screenshots for Oasis with info on render pressing F11 3 times. It looks like there is some game randomizations anyway for trees, stones and animals: default vertexshader fixed

Here are some better datas: Common setting on local.cfg: windowed = true I also added renderpath = VALUEwhere VALUE is shader, vertexshader and fixed Data taken on first screen pressing SHIFT-F and then F11 after starting 0ad with: ./0ad -quickstart -autostart=MAP MAP renderpath FPS render (msec/frame) Miletus def/shader 12 77-80 vertexshader 13 72-73 fixed 13-14 68-69 def + comm shad 14 66-67 Oasis def/shader 10 96-98 vertexshader 12-13 77-78 fixed 13-14 70-71 def + comm shad 12 80-81 Let me know if you need any other data. EDIT: added def + comm shad data (default + commented shader) as requested on comment 16.

On my Radeon X1600 with gallium r300g driver the shader renderpath gives about 5-40% slower FPS depending on the map, but other than that I see no obvious bugs.

Nice to have random map since I already know the current maps. I tried the Latium map and it's working fine. I would have expected a slow map generation but it's as fast as the regular maps. I noticed some issues, not related to random maps. Warning and missing textures: WARNING: CTerrainTextureManager: Couldn't find terrain cliff_medit_beach ERROR: Failed to find file: "art/textures/skins/props/head/pers_fem_a.dds" ERROR: Failed to find file: "art/textures/skins/props/head/pers_fem_b.dds" Also I choose the Demo AI with Iberian opponents. For some reasons they created a huge amount of women, but not any soldiers, and sent many of them to my hq.

The Phoronix effect...: http://www.phoronix.com/scan.php?page=news_item&px=OTIwOA Could you highlight/mark extensions currently used by 0 A.D. in the report?

A WWII mod would also be nice... it always comes to my mind when I load a desert map.

Ykkrosh thanks for looking into (and fixing) this!

Update: it looks like this is a mesa bug, a developer would like to have a simple test case for this: https://bugs.freedesktop.org/show_bug.cgi?id=31159#c1

You may also dual license new content with CC-BY-SA 3.0+ and GPLv3+ (so that other GPL-content games car reuse it). However you can't do this with content derived from 0 A.D. because it's only CC-BY-SA.

Note that NC licenses are also not compatible with Debian. Best would be to require only CC-BY-SA v3.0+ which is compatible and already used by 0 A.D. itself.

Was he able to restore the data from the disk? It's possible even if the disk is partially damaged, there are company that do that...

Yes Unfortunately that's all.

Very nice! Can you also shows the OS? Anyway I am not able to compile 0ad on Linux since yesterday, it stops to: SimContext.cpp ParamNode.cpp ComponentManagerSerialization.cpp Linking simulation2