fabio

Ciao, credo di sì tra gli sviluppatori. In ogni caso puoi usare google translate.

Nice! I suppose that: celts_peace_1.ogghellenes_peace_1.oggiberians_peace_1.ogg are the ogg versions of the .wav available in the audio svn. They are using about 9,3MB and are encoded with libVorbis I 20050304 (1.1.1) and a nominal bitrate of 160Kb/s. It would be interesting to recode them from the .wav (supposed that the .wav are not transcoded from the .ogg) with latest aoTuV Beta6.03 using q-1 quality (48Kb/s nominal), it should save about 6,5MB, and see if someone is able to notice any difference.

Is there any news about this? Should I open a trac ticket for it?

shader-db: http://lists.freedesktop.org/archives/mesa-dev/2011-May/007694.html Maybe 0ad shaders could be submitted so there is a chance that mesa drivers can be optimized for it.

What about changing the name of the tarball of the released version? Specifically they are missing an official version number and packagers have to invent one (e.g. official Ubuntu packages are using 0.0.0+r09049-1~10.10~wfg1). Rather than using 0ad-r09530-alpha-... it could be 0ad-0.0.4-... for alpha 4 (the svn revision number is already visible on the menu screen) or if you want to include it in the package something like 0ad-0.0.4.9049-... (with r0 removed). The beta version could then use 0.X.0, while the final ones 1.0.0.

Try with: cd build/workspaces ./clean-workspaces.sh ./update-workspaces.sh

Gallium drivers are known to have shadow problems. Make sure you are using mesa 7.10.2 and if the problem persist you may want to try a snapshot from mesa git master.

You may try updating your graphics drivers.

I don't have an Intel HD graphics chip, but rather than 2010 i3 and i5 I would consider the newer Sandy Bridge i3 and i5 (the 2xxx series): their HD graphics 3000 GPU have far better graphics performance: http://www.anandtech.com/show/4084/intels-sandy-bridge-upheaval-in-the-mobile-landscape/5 The AMD Fusion E-350 also have a nice GPU (faster than Intel HD graphics but slower than the newer HD 2000/3000) but the CPU is a lot slower (Atom like) and not suggested for developing purpose.

Did you know Video DownloadHelper ? https://addons.mozilla.org/en-US/firefox/addon/video-downloadhelper/

Just wondering... what's the status of this work? If it is complete do you have a plan to upload it to Debian?

Is the opengl report automatically updated or it is run manually at times? I am asking because I can't see my updated graphics data (gallium RV530 should now have float texture).

Hi Kao, this looks like a different bug than the original one. However you may want to try newer mesa drivers and see if your problem is already fixed. I manage an Ubuntu PPA with free graphics drivers for this: Ubuntu Updated Graphics Drivers PPA If you are still able to reproduce the problem with the updated drivers you may want to let we know and also report a mesa bug.

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.