Slashdot Mirror
Open Source FPS Game Alien Arena 2009 Released
Alienkillerrace writes "The open sourced, freeware FPS game Alien Arena 2009 has been released (Windows and Linux). The improvements to the game engine are very significant, and have surely raised the bar for free games of this genre. All surfaces in the game are now rendered using GLSL, not only improving the visual quality, but the performance as well. Interesting new effects like post-process distortions using GLSL have been implemented, as well as light volumes, better per-pixel lighting (reminiscent of UT3), and shaded water. Equally notable is that the sound system has been completely rewritten using OpenAL, allowing for effects such as Doppler, and adding Ogg Vorbis support. The game is free to play and available for download on its official website. It has a stats system and a built-in IRC client in its front-end game browser."
I noticed that too. I also noticed that you can change the installation directory, as long as you have one of those input devices... What are they called now? Keyboards? Kids these days.
That I didn't mind nearly as much as the search toolbar they try to get you to install after the game is installed. Can't blame the guys for trying to get some compensation for their work, but I, like everyone else I'm sure, avoid those toolbars like the plague. (o:
Love sees no species.
I played for 15-20 minutes and, for me, it isn't all that fun for one simple reason: All of the weapons take only a few shots to kill someone, at most. Usually just one or two. So, it ends up being a twitch-fest. There's enough twitch games out there already.
Half-life, now there is a game that had deathmatch down. It took a while to kill someone. There weren't a lot of insta-kill weapons. A little slower paced. The "thinking man's deathmatch" if you will.
Graphically, it is pretty nice. For an open source game, it is fantastic.
Love sees no species.
Ignoring for a moment that doppler has been supported in Q3 engines since 2000 anyway, it really makes me cringe to see uninformed people touting OAL as an "upgrade" to ANYTHING, just because of its name. Pasting from a post of mine from our engine forum about a year ago:
(apologies for Wall Of Text if it comes out that way: /. seems to want to use HTML whitespace consolidation even in POT mode)
>>>
As some of you have noticed, over the years we've gone from "openal is off by default" to "openal is excluded from builds" to, finally, "openal is removed completely".
In many ways, this irritates me a lot. I like the CONCEPT of openal, and I especially like the idea that we could have HRTF etc in hardware someday "for free", and ideally I'd like to make oal the ONLY sound backend we supported and get rid of the "ugly" direct-DMA stuff.
There's just one tiny problem: openal simply isn't very good.
As I mentioned in the 1.43 notes, we've made some very significant speedups in the last year or so, and sound is one of the key contributors to that (aside from actually, yknow, WORKING properly now too :P). With my standard config, there's now NO difference in timedemo rates between having full sound and disabling it completely. If you've been around Q3 for a while, that's pretty staggering. Even if I drop to a quarter of that resolution and essentially take the graphics card out of the equation, the numbers are 478 fps with sound disabled, and ... 474 with it on.
That's 96 channels, and they're ALL used when timedemoing "four".
I tried one of the openal test programs, and clocked it at ~6% CPU, which I'd probably just about be willing to accept, except that it was only mixing 64 channels, and the entire thing was static (i.e. this is an absolute "best possible case", where it could potentially pre-mix to an absurd degree because it wasn't doing any dynamic spatialisation).
6% CPU vs 0% CPU, for 64 channels rather than 96, puts it *at a minimum* at ~10% CPU overhead when you're talking apples to apples, and that's not very encouraging. I don't expect it to MATCH cnq3's sound code by any stretch, but that's a pretty big difference and it's even worse if it IS using lazy spatialisation.
There are also questions about how "timely" it is. If positioning etc only updates 30 times a second, or sounds don't actually start playing until 50-100ms after they're added, that's fine for WoW but absolutely shit for Q3. There's no guarantees in the oal spec, or even ANY documented indication of what the "reference" implementation's behavior is, which means we'd have to wade through a bunch of (frankly, pretty sloppy and mediocre) code to actually find out. I have no intention of moving to oal just to end up spending weeks fixing it for Creative.
There are several other issues too: the bug that Q4 has with looped sounds is a direct result of bad design that would have to be worked around at the app level; likewise, oal requires app-level culling of sounds despite the fact that the app CANNOT do so correctly because only the oal implementation actually knows what the 0-volume falloff distance for any given sound is. That's just utterly incompetent design/implementation.
[snip]
Happily, Timbo (ioq3's developer) was kind enough to run the tests for me, and the numbers very nicely match the observations I've made here:
131.6 fps 2.0/7.6/35.0/3.6 ms no sound
113.5 fps 3.0/8.8/82.0/5.4 ms dma
104.1 fps 3.0/9.6/72.0/5.7 ms openal
So, "normal" Q3 sound (with some of our fixes from 141/142) is about 16% slower than no sound, which is historically what you'd expect; and oal is another 9% slower than that (while mixing only 2/3 as many channels, so the truth is more like 14%, for a total of ~30% slower than cnq3).
And that's why we no longer support oal at all.
I MAY someday revisit this. I doubt there are too many cases where the "missing" 32 channels are actually going to matter, simply beca