Alien Arena 2011 Game Released

[phoronix]

Phoronix: Alien Arena 2011 Game Released

Last weekend we reported that Alien Arena 2011 was coming this week, and over the night it has in fact arrived. Alien Arena 2011 brings rag-doll physics using the Open Dynamics Physics Engine, two new maps, updated player models and skins, faster particle rendering, new in-game music, updated/improved shaders, and many other key improvements...

http://www.phoronix.com/vr.php?view=ODkyMQ

[Irritant]

Thanks for the news Michael!

Here are some screenies:




video - http://www.youtube.com/watch?v=YNvep_oWFbs

[yogi_berra]

Thanks for the news Michael!

It's almost 2011, would you please stop using autotools?

[Melcar]

Downloading now .

[curaga]

It's almost 2011, would you please stop using autotools?

What's your preferred build system of the week?


Cmake - ya just time how long it takes to figure out how to set prefix and destdir
Scons - impossible to pass custom PKG_CONFIG_PATH etc to the build. Also really hard to set prefix, destdir, etc. Also python, ewww.

Oh and if something breaks, it's a load harder to fix in the above two than in autotools.

[yogi_berra]

What's your preferred build system of the week?


Cmake - ya just time how long it takes to figure out how to set prefix and destdir
Scons - impossible to pass custom PKG_CONFIG_PATH etc to the build. Also really hard to set prefix, destdir, etc. Also python, ewww.

Oh and if something breaks, it's a load harder to fix in the above two than in autotools.

Cmake exports project files for the significant IDE's on all platforms when you are ready to enter the 21'st century.

Scons: export PKG_CONFIG_PATH=/path/to/the/21st/century

[Svartalf]

What's your preferred build system of the week?

CMake's shaping up that way.

Cmake - ya just time how long it takes to figure out how to set prefix and destdir

-DCMAKE_INSTALL_PREFIX=<foo>

Not hard... This isn't to say that CMake's the answer for things- but it seems that it's a better one than many. And I'll challenge you to cobble together a CMake set over an autotools one for a new project. I've tried to do autotools setups- and fix them when they're broken. CMake actually seemed easier for my circumstances.

Scons - impossible to pass custom PKG_CONFIG_PATH etc to the build. Also really hard to set prefix, destdir, etc. Also python, ewww.

The python part's no different than m4/bash that autotools uses... I will give you the others, though- Scons is of somewhat limited usefulness if you're doing something "fancy". For that, CMake or autotools is better.

Oh and if something breaks, it's a load harder to fix in the above two than in autotools.

That's familiarity. autotools is a baroque answer to a problem that's just simply less screwy than imake was. More to the point, autotools is really only Linux/POSIX centric. It doesn't do well outside of that- and sadly, you DO have to deal with Windows for some things... (We won't get into the fact that autotools is two kludges on top of ./configure that were done to compensate for ./configure and Makefile deficiencies...)

[curaga]

CMake's shaping up that way.

-DCMAKE_INSTALL_PREFIX=<foo>

Not hard... This isn't to say that CMake's the answer for things- but it seems that it's a better one than many. And I'll challenge you to cobble together a CMake set over an autotools one for a new project. I've tried to do autotools setups- and fix them when they're broken. CMake actually seemed easier for my circumstances.

I was implying that CMake's documentation sucks
It was rather hard for me to find those out when I built my first cmake-using package.

Contrast this with ./configure --help, which is very clear to a newbie in comparison.

Of course autotools has had a decade or two of refinement.


FWIW, the easiest new-project setup for me has been qmake.

That's familiarity. autotools is a baroque answer to a problem that's just simply less screwy than imake was. More to the point, autotools is really only Linux/POSIX centric. It doesn't do well outside of that- and sadly, you DO have to deal with Windows for some things... (We won't get into the fact that autotools is two kludges on top of ./configure that were done to compensate for ./configure and Makefile deficiencies...)

Do you mean building on Windows? I'd rather avoid doing that, and just cross-compile from my linux box. So far I've managed to avoid it, and things have worked fairly well.

[dfblogic]

It's almost 2011, would you please stop using autotools?

(and other autotools related posts)

For a detailed defense for using autotools, see Autotools, by John Calcote. But, briefly, from the preface, page xix: The primary purpose of the Autotools is to make life simpler for the end user (i.e. not the programmer.) For Alien Arena, a major goal was to improve our Linux builds for distro package maintainers (who, in my book, are unsung heroes.) It is no big news, I have discovered, that no developers really like Autotools all that much. It would be great for GNU and the rest of the Open Source Community to adopt easier to use build tools. But, I am pretty sure, Alien Arena is not going to be a leader in that cause.

[yogi_berra]

a major goal was to improve our Linux builds for distro package maintainers (who, in my book, are unsung heroes.)

Package maintainers for deb and rpm can handle scons and cmake with very few problems. They usually know what they are doing.

It would be great for GNU and the rest of the Open Source Community to adopt easier to use build tools. But, I am pretty sure, Alien Arena is not going to be a leader in that cause.

Few non-gnu projects are using autotools, and for good reason. Who wants to learn five different archaic scripting languages that are poorly documented just to build something when one language works just fine?