The Best Looking Open-Source Game?

[crazycheese]

Another vote for bringing benchmarking into Spring engine. Basically, this engine is on par or greater than those in CnC generals. It is very nice 3D RTS engine. Because you are benchmarking mostly FPS, adding something with CPU bottlenecking (3d rts strategy engine) would be good.

[crazycheese]

It turns out there's actually a new OpenArena release from this year that I discovered today when writing this article... It does have GLSL support, better bloom, and a few other refinements. Here's a result file showing the old OpenArena 0.8.5 versus the new OpenArena 0.8.8 results, the frame-rate drops a lot - http://openbenchmarking.org/result/1...PTS-NEWOPENA54

The test profile is already available for those who want: http://openbenchmarking.org/test/pts/openarena-1.5.0

Great, thanks!

Yes, the performance hit is fatal 3x-4x! O_o
Need to give new version a try.

Too bad OpenArena misses exactly some online functionality to connect players, like its done in Quake Live.
Im not talking they should do browser plugin. But they could have set up good site, add ads to support development and ... provide ways for people join, talk and make clans.

I feel that most of the userbase that could play OpenArena is either with Quake Live due to social features; with Warsow due to its very high style elitist game style; or with Xonotic due to its innovative and rebelling spirit.

I don´t like how things turn around Urban terror though. Linux treated as second class once, very very few enthusiasm releasing any updates. The engine handles bullets way unprecise, models look ok only for year 2001, level design..., lack of ANY good mods (zombiemod is here, but requires high amount of imagination - red team is still basically human) ONLY unique about urban terror are its jumping servers and maps. And problem with intel opensource driver that is not fixed in urt upstream.

[Philip]

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.

[Asariati]

iDTech4 was ported to 64 bit, cmake build system, patented code put back, GLSL renderer, etc...

Really? Where? Need Code...

[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).