Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 internet speed test! ×

Comment Re:As an FPS gamer (Score 1) 113

The problem is assets, not code. A single competent developer can easily turn even something as old as the original *QW* engine into something that is technically on par with anything currently available, even massively-overhyped "awesome" engines like crysis.

A single competent developer can't make 400MB of high-quality textures though, or model and animate 30 monsters, or create the 500 sounds a game needs not counting the voices of humanoid creatures, and so on.

Even if you have several artists/modelers/etc capable of producing the sheer VOLUME of content you need, the chances of even one of them being in same class as a "pro" are very slim; and the chances of them being able to put in the same 10 hours a day for multiple months (or even years) that a dev house can are zero.

Comment Re:It's "bloody" fun! (Score 2, Informative) 113

Since there's no "-50: Hopelessly Wrong", I'll sacrifice modding parent as Overrated to post a reply that will hopefully re-clue anyone who reads and believes it.

Even with access only to the data you "should know", it's still TRIVIAL to mod a client in ways that provide significant advantages. No offense, but parent has absolutely no idea what he's talking about, and obviously no actual experience in this area.

Rather than listing 20 or 30 trivial cases that disprove your claim, I'll just take the most obvious one.
An enemy is clearly visible a hundred yards away. I think we can all agree that that's "information you should have as a player", right? My client knows where he is, because it has to draw him. So, with some trivial math, my client is capable of instantly targeting him and shooting for me.

You say it's not impossible to stop cheating, just "hard". Start with that one, then we'll move on to the more complex cases...

(And no, even just streaming the game doesn't in any way resolve this, even if it wasn't impractical. Trivial image analysis will pick out the enemy player by motion, color, etc)


Big Dipper "Star" Actually a Sextuplet System 88

Theosis sends word that an astronomer at the University of Rochester and his colleagues have made the surprise discovery that Alcor, one of the brightest stars in the Big Dipper, is actually two stars; and it is apparently gravitationally bound to the four-star Mizar system, making the whole group a sextuplet. This would make the Mizar-Alcor sextuplet the second-nearest such system known. The discovery is especially surprising because Alcor is one of the most studied stars in the sky. The Mizar-Alcor system has been involved in many "firsts" in the history of astronomy: "Benedetto Castelli, Galileo's protege and collaborator, first observed with a telescope that Mizar was not a single star in 1617, and Galileo observed it a week after hearing about this from Castelli, and noted it in his notebooks... Those two stars, called Mizar A and Mizar B, together with Alcor, in 1857 became the first binary stars ever photographed through a telescope. In 1890, Mizar A was discovered to itself be a binary, being the first binary to be discovered using spectroscopy. In 1908, spectroscopy revealed that Mizar B was also a pair of stars, making the group the first-known quintuple star system."

Comment Re:Saboteur, hey? (Score 1) 230

just for reference:

yes, i'm sure there'd be someone claiming it's "cheating". it's fairly apparent to me however that it really is the drivers just going in to Sulk Mode if they flag something as an error and the app doesn't clear that state.

q3 isn't just "fairly old", it's ancient in gaming terms - that's like dog years. :P

as i said, i don't blame nvidia - imo (and the arb's, iirc) the drivers are perfectly justified in reacting badly to unacknowledged errors. i doubt it was a "fix" per se for something specific, but simply noticing at some point that they WEREN'T flagging an error when they should have been, and correcting it.

no, id won't release a patch (or at least, haven't in the several years since this problem appeared) for the same reason that no other company supports product indefinitely for no/trivial return.
as you say though, carmack/id had the grace to open-source the engine shortly afterwards, and as a result it did eventually get fixed - which is handy, since i still play it to this day. :P

Comment Re:Saboteur, hey? (Score 5, Insightful) 230

For all that "the industry is being pushed", it's not ALWAYS the game developers' fault. For a "real" game (ie "not a crappy movie tie-in generic copypaste with new art") you can easily go through dozens of driver revisions during years of development, all of which work fine, and then have a new set come out after you ship the master which suddenly doesn't work with your game.

ATI, much though I love their hardware, border on completely indifferent to driver bugs, and nvidia aren't really that much better. Unless your game is a "showpiece" for their hardware, they simply don't care if something doesn't work the way it's supposed to or even has catastrophic errors in it. Case in point, every ATI driver release from April through OCTOBER this year *hemorrhaged* memory if you used VBOs a certain way. 6 months to fix a bug that critical is pretty miserable.
Yes, modern graphics drivers are horrifically complex, but still...

Sometimes it works the other way too. There's a tiny little bug in Quake3 that can make an invalid GL call at times: it "worked" for 7 years because the drivers gracefully ignored it, then suddenly started to cause *massive* slowdowns on nvidia cards (from 400+ fps to 100). Technically, it's id's "fault", but it's pretty hard to blame them for it - or to blame nvidia for the drivers going into Sulk Mode, since it IS an invalid call.

That's an extreme example, but the point is that you're dependent on drivers that you don't "own" for your game to work, they frequently don't, and you've got no control over them at all.
If you're id / Epic / Valve, and pushing a AAA title that will prompt players to upgrade their cards, you can doubtless get someone at the IHV to look into the problems. If you're at a company like Pandemic that basically folded before even finishing the game, good luck with that even if you actually have any developers left to try to get a fix or hack up a workaround if a driver rev pulls the rug out from under you.

Of course, the developers COULD have been so completely half-assed that they didn't run a single build on an ATI card, in which case they should indeed be beaten to death with cluebats. :P

Comment OpenAL (Score 4, Interesting) 142

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.


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 because if there's THAT much noise where you are, you're not going to be able to pick the "extra" sounds out. Where that falls down is if it loses IMPORTANT sounds because it decides to play a gnat farting 2000 units away instead: and again, this is something that WE prioritise correctly ATM but oal has no mechanism for.
I could, potentially, create a "non-shit oal" dll that didn't have the performance problems, extend the spec/api/implementation to support priorities, fix the culling bugs, and so on, but I just don't find it a particularly interesting field and I have better things to do.
I MIGHT even be willing to put up with the performance TBH, but I'd still have to either work around the bugs at the app level or fork oal to fix it, which doesn't really benefit anyone, and again, is a waste of my time.

Obviously, just saying "screw it" and switching to oal anyway when it's so inferior in every way is as unacceptable to me as a player as it is to me as a developer, regardless of how much I'd LIKE to do so in the abstract, and that leaves me in a Catch-22. We can't switch to oal until it sucks less; and it won't suck less until someone actually fixes it, which apparently nobody is going to do unless it's us. (Creative, obviously, couldn't care less because their attitude is "buy a Fatal1ty Extreme Super Audigy Z5 Pro III Platinum Deluxe", which I'd actually be really happy to if it had HRTF and worked with Q3, but it won't because, Catch-22 again, we won't support oal in its current state).

So, in a nutshell, OpenAL is:
A Nice Idea, but
Slow as hell
Does not, and CANNOT, actually work correctly for several critical real-world scenarios because of some huge (and blatant) flaws in its design

It's important to understand that this doesn't mean it's unsuitable for EVERY game: I'd probably be perfectly willing to put up with the crapness for something like an RPG or an RTS, where the poor performance isn't especially meaningful; and you can make arbitrary decisions about cutoff ranges; and having sounds just randomly Not Actually Play (which is, yknow, kind of the whole POINT of a sound lib in the first place...) isn't the end of the world. But for a skill-based MP FPS game, OAL is the worst possible option there is.


Submission + - World's Most Powerful Single-kernel Linux System?

An anonymous reader writes: NASA has selected an SGI Altix supercomputer to help it meet future high-performance computing requirements. The new system will be the first supercomputer to operate 2,048 processor cores in SMP mode under control of one Linux kernel, creating the world's largest single-kernel Linux system. Driven by 1,024 Dual-Core Intel Itanium 2 processors, the new system will generate 13.1 TFLOPs of compute power. To accomplish this feat, SGI had to extend the Linux kernel's SMP support from 1,024 CPUs to 2,048 CPUs. Fancy that on your desktop!

Submission + - Backstabbing Your Boss: A How-To Guide

C.G. Lynch writes: "Hate your toxic, out of touch boss? Of course you do. And you think you can do a much better job. If you're willing to risk your career and reputation, then this short guide to getting your boss ousted, How to Stab Your Boss in the Back, is your ticket to a bigger office. Learn from recruiters and career coaches how to determine if your boss is vulnerable, impress your colleagues (and your boss's boss) with your superior leadership skills, and all the while keep your nose clean. If you succeed, more power to you (literally). If you get a pink slip instead, well, that's business. One hint: don't put your plans in e-mail; see the related story, 10 Things You Should Never Put in an Email, and Other Communication Tips."

Submission + - The Gigahertz Race is Back on

Anonymous Coward writes: "When CPU manufacturers ran up against the power wall in their designs, they announced that "the Gigahertz race is over; future products will run at slower clock speeds and gain performance through the use of multiple cores and other techniques that won't improve single-threaded application performance." Well, it seems that the gigahertz race is back on — This CNET story talks about how AMD has boosted the speed of their new Opterons to 3GHz. Of course, it the new chips also consume better than 20% more power than their last batch. The real question is: "What happens when they approach 4GHz this time?""

Feed Google Sued For Infringing On Just Granted 'Enhanced Hyperlink' Patent (

Wasting absolutely no time at all, a Kentucky-based company appears to have gone straight to court on Tuesday, the same day it was granted a patent for a "method for adding a user selectable function to a hyperlink, and proceeded to sue Google for infringement. The patent appears to cover the ability to pop up various choices if you mouseover a hyperlink -- something that's pretty common these days and certainly not particularly difficult to implement. Does anyone really believe that a 20 year monopoly needed to be granted to some company in order to put in place the proper incentives for this functionality to be created?

Slashdot Top Deals

May Euell Gibbons eat your only copy of the manual!