The Best Looking Open-Source Game?

[Drago]

Really? Where? Need Code...

There you go:

https://github.com/dhewm/dhewm3

I believe iodoom3 consumed dhewm patches:

http://git.iodoom.org/iodoom3/iodoom3

[Michael]

As a developer of 0 A.D., I'll have to say I quite like 0 A.D. It's far from the most technically impressive engine, but it's getting better (I've been adding some more usable shader support recently), and the artists are doing a great job

I'm interested in adding a usable graphics benchmarking mode into it some time, to compare across different hardware and OSes and drivers (mainly to identify performance-related bugs in our code or in drivers, and to choose sensible default graphics settings), so it could be good to get input from people with experience developing or running benchmarks. I think the biggest issue is that performance depends heavily on implementation detail - e.g. we can render with GLSL shaders or with equivalent ARB shaders (GL_ARB_fragment_program etc), with similar performance in most environments, but the GLSL is ~30% faster than ARB on proprietary NVIDIA drivers (for unknown reasons). Or e.g. changing the implementation of alpha testing can make rendering significantly faster on some Intel GPUs, and slightly slower on other Intel ones, and no different on NVIDIA ones. How can we do a fair comparison when there are so many unpredictable variables?

Maybe the best approach is for the benchmark to try every combination and report the best? but what if drivers are buggy and some combinations don't even give correct rendering, so fastest isn't best? We already collect a load of data from the game (OpenGL capabilities, in-game FPS, etc), so it's easy to collect and analyse whatever data the benchmark generates, but I'm not really sure what the best approach would be.

Please see my other posts in this thread with the Alien Arena developer about what's ideally needed. Thanks.

[Asariati]

There you go:

https://github.com/dhewm/dhewm3

I believe iodoom3 consumed dhewm patches:
http://git.iodoom.org/iodoom3/iodoom3

Nice! Thanks for the links!

[Nobu]

Nobu: "I want to see TA-Spring (...) +1 for [del]C&C[/del] TA-Spring 1944; Fight, win, prevail! "

I don't appreciate you taking my words out of context; I said "I want to see TA-Spring and 0A.D. merge somehow", and that is exactly what I meant.

However, I wouldn't mind seeing phoronix take advantage of some of the Spring Engine games. (they really need to pick a name and stick with it...)

[MaxToTheMax]

Great for the fixes, thanks!

The way I start-up and then quit on idTech3 games is via:


timedemo 1
set demodone "quit"
set demoloop1 "demo demo088-test1; set nextdemo vstr demodone"
vstr demoloop1

would that work here?

No, it would not. There is no vstr feature, nor is there a nextdemo feature.

If you did this:

timedemo 1
map demo088-test1.dm2

Then the game would run a timedemo and output some statistics when it's done. However, in order to make the game quit, Phoronix would have to wait for the demo to finish and then pipe a "quit" command into the game's stdin, or I could add a demoquit cvar or something.

I'm working on a scripting system which would make all of this much easier to deal with. Gameplay scripting isn't done yet but scripts can already emit console commands to automate stuff like this, which will be useful for server admins. None of this is in SVN yet though, because I haven't yet ported it to Windows.

For the 0AD developer, if you don't understand what Michael is asking for: the timedemo feature found in many quake-based engines allows you to play back a demo, but it does it differently. Instead of playing it back in "realtime," it simply draws a new frame for each "snapshot" in the demo. In Quake II (and Alien Arena,) 10 snapshots are generated per second. I think in Quake III it's 20. So if you can render at 100 FPS, in Quake II playing a demo in timedemo mode makes the playback 10x as fast. So to get an average framerate, you just need to time the timedemo. This feature was added specifically for performance testing and it is invaluable to developers looking to optimize their code. If your game engine doesn't have this feature, it's definitely worth adding (or fixing, LOL.)

[oibaf]

+1 for 0 A.D. benchmarking. I also added a ticket on its trac some time ago: http://trac.wildfiregames.com/ticket/837

A wonderfoul gallery of screenshot of 0 A.D. is here: http://www.moddb.com/games/0-ad/images

Also 0 A.D. is one of the few game to be 100% free (GPL engine + CC-BY-SA art).

[Michael]

No, it would not. There is no vstr feature, nor is there a nextdemo feature.

If you did this:

timedemo 1
map demo088-test1.dm2

Then the game would run a timedemo and output some statistics when it's done. However, in order to make the game quit, Phoronix would have to wait for the demo to finish and then pipe a "quit" command into the game's stdin, or I could add a demoquit cvar or something.

I'm working on a scripting system which would make all of this much easier to deal with. Gameplay scripting isn't done yet but scripts can already emit console commands to automate stuff like this, which will be useful for server admins. None of this is in SVN yet though, because I haven't yet ported it to Windows.

For the 0AD developer, if you don't understand what Michael is asking for: the timedemo feature found in many quake-based engines allows you to play back a demo, but it does it differently. Instead of playing it back in "realtime," it simply draws a new frame for each "snapshot" in the demo. In Quake II (and Alien Arena,) 10 snapshots are generated per second. I think in Quake III it's 20. So if you can render at 100 FPS, in Quake II playing a demo in timedemo mode makes the playback 10x as fast. So to get an average framerate, you just need to time the timedemo. This feature was added specifically for performance testing and it is invaluable to developers looking to optimize their code. If your game engine doesn't have this feature, it's definitely worth adding (or fixing, LOL.)

demoquit or something would work much better than keep monitoring the stdout for the fps and to then send it quit. Most other game engines allow this 'demo quit' functionality

[MaxToTheMax]

I have programmed the demoquit cvar, however I can't commit it until I get home (SVN is blocked on this wifi.) Should be in SVN within three hours or so.

You can build the game from SVN using these directions:

http://corent.proboards.com/index.cgi?action=display&board=aatech&thread=6401&page=1#56922

Demos (.dm2 files) go in ~/.codered/arena/demos.

You can play back a demo in benchmark mode with these commands:

timedemo 1
demoquit 1
map demo_name.dm2 //you MUST include the .dm2

Or from the command line:

crx +timedemo 1 +demoquit 1 +map demo_name.dm2

A word of advice on what kind of demo to record for benchmarking purposes: Our biggest bottleneck is mesh and player model rendering, so if you really want to stress the system, pick a small, crowded map with lots of meshes in it (dm-goregrinder is a good one,) and add lots and lots of bots. You can do this like so:

set maxclients 16
startmap dm-goregrinder

Wait for the map to load.

sv addbot; sv addbot; sv addbot; sv addbot; sv addbot; sv addbot; sv addbot; sv addbot; sv addbot

This will add a bunch of bots to the game, in addition to the ones already programmed into the map's bot file.

Then start recording a demo:

record demo_name //you must NOT include the .dm2

Play for a few minutes, then quit the game and your demo will appear in ~/.codered/arena/demos.

[Michael]

I have programmed the demoquit cvar, however I can't commit it until I get home (SVN is blocked on this wifi.) Should be in SVN within three hours or so.

You can build the game from SVN using these directions:

http://corent.proboards.com/index.cgi?action=display&board=aatech&thread=6401&page=1#56922

Demos (.dm2 files) go in ~/.codered/arena/demos.

You can play back a demo in benchmark mode with these commands:

timedemo 1
demoquit 1
map demo_name.dm2 //you MUST include the .dm2

Or from the command line:

crx +timedemo 1 +demoquit 1 +map demo_name.dm2

A word of advice on what kind of demo to record for benchmarking purposes: Our biggest bottleneck is mesh and player model rendering, so if you really want to stress the system, pick a small, crowded map with lots of meshes in it (dm-goregrinder is a good one,) and add lots and lots of bots. You can do this like so:

set maxclients 16
startmap dm-goregrinder

Wait for the map to load.

sv addbot; sv addbot; sv addbot; sv addbot; sv addbot; sv addbot; sv addbot; sv addbot; sv addbot

This will add a bunch of bots to the game, in addition to the ones already programmed into the map's bot file.

Then start recording a demo:

record demo_name //you must NOT include the .dm2

Play for a few minutes, then quit the game and your demo will appear in ~/.codered/arena/demos.

Thanks!!! Will check it out tomorrow to see how suitable it is... Hopefully it will all be working smooth and can then incorporate it into PTS right away tomorrow/this-weekend so that the test profile is included when testing out the graphics of some alien chip that arrived this week after suffering poison ivy

[MaxToTheMax]

What is your usual policy for benchmarking games with different graphics settings? The performance is radically different at each graphics level. It's like five different benchmarks. At lowest/low settings, the engine doesn't behave too differently from ioQuake3 (although with much more model detail.) I usually play at medium settings, because my 2010 Thinkpad T510 with nVidia graphics cannot get a solid 60 FPS at high or highest settings. Interestingly, low settings perform worse on my laptop than medium settings, because with low settings GLSL is not used. I would expect that to be reversed with Intel graphics.

And by the way, this is awesome news.