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.
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)
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
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
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
and as a summary of the summary: the low and mid systems are made of "good" choices; the high system is a pile of crap, with most of its parts apparently chosen entirely by cost rather than actual quality or suitability for purpose (including one of the worst mice ever made, which is pretty critical part to get right in a gaming rig:P).
Technically, he's right. You're talking about bunnies and other movement options, and those all have a very deliberate and specific behaviour. Something that takes weeks of playtesting refinement is hardly a bug, whether you personally like it or not.:)
I think he's misquoting an interview I did last year on the T-ball thing: I compared it to softball, and in context that was an extremely fair analogy: softball is there for people who CAN'T hack it in baseball - IOW, the vast majority. FPS gaming is somewhat unique as far as "competitive" fields go, in that the bulk of it is explicitly targeted at the moderately-skilled rather than the elite, and it'll be a while yet before that attitude changes.
Sadly, I find it somewhat less than surprising that "Best Gameplay" is nowhere to be found. If I was a bit more optimistic, I'd pretend that's what they meant by "Best FPS", but I've been around gaming way too long for that.:/
This really does seem an awful lot like a quick stab at a "hey, let's see if we can get a CS-equivalent for UT2K3" scheme, because the game as it stands IS shockingly unpopular given its relatively recent release.
Still, gl to anyone who goes for it. Who knows: maybe one of the FPS variants WON'T just be YA clone of CS. There's an awful lot of truth to this...
The fact of the matter is that it's been YEARS since Epic or id (sorry JC) did anything even remotely innovative with gameplay: TA's HeadHunters mode, UT's Bombing Run, Instagib, etc, are all just ripped straight from mods (and in the case of Instagib even copying the name) without bothering to credit or even acknowledge the original authors. If this is the only way "new" gametypes are going to appear in FPS's on a widespread/"official" basis (and it certainly looks like it) then at least gamers will get to see something that they might not otherwise; and at least Epic will (potentially) for once mention the people who ARE creating the gameplay rather than just quietly swiping it.
An interesting and predominantly accurate assessment of things within the context of Netrek, but it's both theoretical and inaccurate as far as FPS games go.
Even the densest of developers is (finally) WELL aware that you can't trust the client. Your first two points are already exactly the behaviour of any well-designed engine (e.g. Q3, though if you read this JC, how about you put the network code and the renderer's cheat vars on opposite sides of a conditional compile in Doom3...) The third is a game design issue: rocket launchers work that way, lightning guns don't.
The Netrek model works *for Netrek* for a combination of reasons, mostly that it (a) has VERY slow gameplay (even compared to VQ3, let alone ProMode) and (b) doesn't have dominating hitscan weaponry (i.e. no railgun / sniper rifle).
The Netrek developers didn't magically "understand all this" while the rest of us passed it by, oblivious to the potential problems. Yes, they did a pretty decent job of it all, but don't confuse the implicit benefits of the TYPE of game they made with some silver bullet solution for ALL games. That's like saying MUDs came up with the solution to all cheating just because an aimbot doesn't help you in one...
Until such time as the GPL is actually enforced, this kind of talk is nothing but a pointless ego-wank for people trying to impress us with how liberal and/or hip to the community they are.
On a small scale, codifying the GPL just takes the decision on that enforcement out of the hands of the people who produced the code in the first place and give it to an overworked legal system that most of us wouldn't trust as far we can throw it anyway.
On a larger scale, if ALL end-user code has to be open you adversely impact all sorts of things that you never considered in your knee-jerk reaction. Okay, so you might want Word opened so that we can get of these BS proprietary formats; or Outlook opened so the damn thing doesn't propogate infections faster than an open wound in the Black Hole of Calcutta. That's great, and there are real benefits there. Meanwhile though, online gaming goes into the shitter as every client instantly becomes 100% untrustworthy.
And what would it really help, as far as the GNU "ethic" goes? The same people that steal GPL'd code today would continue to do so: whether it's one guy and his pet project with a very limited audience (e.g. MQW) or a megacorp that loves the GPL for helping them cut development cost/time but doesn't go for "that hippy ideology" of actually returning the favour.
Scum will be scum no matter what you do with the laws. "Breaking" the GPL is already illegal, and it's not stopping them so far.
Seems to me that the only reason the utter drivel of the original article even gets a mention (and thanks for wasting 5 minutes of my life, BTW) is that those with an axe to grind about MS will get wood over the idea.
Re:In a nutshell: OpenGL2 good; "Pure" OpenGL bad
on
OpenGL 2.0 White Papers
·
· Score: 2, Interesting
Ah, the joys of electricity...:)
So, yeah: the Stanford PS stuff would be a very nice fit, from the looks of things. Certainly, something along those lines is needed, and it might as well be something that's actually be thrashed around a bit.
One thing that needs to be stressed wrt OpenML is that it's NOT necessarily what we want in OpenGL. While there's a clear overlap in some areas, the ARB needs to make sure that they don't end up kitchen-sinking it. The concern here is dependencies: in the same way that you try to keep classes as loosely coupled as possible, you also don't want your specs tied to each other so that changes in OpenML end up being mirrored slavishly in OpenGL irrespective of whether they actually add real value *from an OpenGL perspective* or not.
I'm absolutely NOT going to buy into the "xyz existing feature should be cut out" approach. Are the non-indexed primitives fundamentally worthless for "real" work? Yeah, pretty much. But they're also an easy way for newbies to mess around with OpenGL and get instant results. Those of us who suffered through the POS that was D3D's execute buffers would prefer that people not need 80 lines of code just to draw a single triangle. Every language needs its "Hello World", and that's basically the function that immediate mode serves.
Even display lists, which I haven't used in many years now, seem to have a place - I gather that on a fair number of non-"consumer class" systems they're still the way to go for a lot of things.
The "focus on this stuff which must be done the best/fastest" argument is a load of bollocks. Developers and IHV's already know what the important fast path is, and have done for years: it's glDrawElements on fully-featured data in CVAs.
The "fewer code paths mean there are fewer ways implementors can screw up their drivers" claim is fundamentally flawed, because we would certainly hope that any vendor who DOES drop "legacy" support goes out of business, so those "old" code paths will still be in every driver. Or at least, every driver for the cards *I'll* own...
Basically, given a decent shading language, we're pretty much set in terms of features. That's BY FAR the most important part of this.
GLsync (i.e. NV_fence extended and renamed) is a nice thing, although it's as much a matter of doing the Right Thing for the future as anything else, since we can EASILY saturate GeForce2-class cards ATM. Saving a few microseconds in setup/transform is all well and good, but since the true bottleneck for common apps (i.e. games) right now is memory bandwidth, the actual gains are basically non-existent. Still, there are other apps that DO benefit greatly from the improved parallelism, and like I say it's the Right Thing anyway.
The pack/unpack features are nice for certain effects, but they're clearly an example of "add this predominantly useless feature just to shut D3D people up". While a pack processor MAY lend itself to something useful (though given what's available through the pixel/vertex shaders that's a bit iffy), the unpack aspects seem almost completely pointless to me. Basically, the amount of "useful" work you can do in software is close to nil, and ANY glReadPixels-style call is going to bog because you're stalling the pipeline. That the other costs of such an action can be minimised is all very lovely, but next to the stall they're absolutely trivial.
The memory management is a *shrug* feature. Useful in some places, and I expect I'll whore certain aspects of it once it's available, but in reality it's nothing like as big a deal as some people seem to think - again, most of it is "D3D has this and we don't". Strangely enough though, this perceived lack doesn't stop my renderer or, say, Quake3's consistently outperforming any D3D-based one, does it?:)
In a nutshell: OpenGL2 good; "Pure" OpenGL bad
on
OpenGL 2.0 White Papers
·
· Score: 4, Interesting
Honestly, the only really annoying thing about working with OpenGL lately is the headaches that come from pixel/vertex shaders. We certainly need a vendor-independent way to support those, because damned if I'm going to rewrite mine for ATI cards - they'll simply be treated as "not supporting vertex programs".
The synchronisation stuff is pretty handy: certainly, NV_fence has been very useful over the past year or so, and again: vendor-specific paths BAD.:)
Some of the changes seem to be as much to persuade some-ignorant developers to use OpenGL over D3D - the "black box" aspects of OpenGL are one the more DESIRABLE things about it. Changing those because some D3D guy is saying "I do xyz in D3D and I want the exact same concept to work well in GL because I'm too thick to actually use the right approach for that renderer" seems simply wrong to me.
Uh-oh: UPS just kicked in. Yay mountain storms...
"Pure" OpenGL2 is a terrible mistake. Give vendors the option NOT to support something, and they won't. Then all your old apps+games are up shit creek.
Will finish later when I have stable power again...
There's a lot to be said of platform-neutral environments. Typically tho, what's said is: "It doesn't f**king work". C++ is standard only as long as you're willing to stay with the language as it was 5 years ago, since we're constantly forced to use (eg) SunCC 4 or MSVC 6 or some other hopelessly broken compiler because of broken legacy code that NEEDS it; and Java has never been anything other than "write once, debug everywhere".
Being language-neutral on top of that is also a great thing for a VM, although it's no shock that the VM is going to be biased towards one language over the others. But let's face it: anyone using Java doesn't need hard-realtime performance anyway, otherwise they wouldn't be using Java in the first place. Same as if they were VB devs. So it makes sense that the bias would be towards C++.
The IVM runs DAMN fast, supports a truly open, pretty well-designed, widely-available graphics library: it's got a lot going for it.
But it'll have to bully its way past Java to get wide acceptance even if it's 10x better; and to truly become a standard it ironically needs to be adopted by, yes, THEM. The people whose browser has 80+% of the market. Of course, since it's GPL'd that's hosed it right there.
Then there are the same security issues that you see with every inet VM: how sure can I be as a user that some site's little applet didn't just funnel a ton of info back to them, that it won't do nasty things to me, etc. THOSE are the sorts of things that always bother me about "active" content: take a look sometime at how trivial it is to totally ruin someone's machine with an ActiveX control.
As an "Internet VM", I have as much use for this as I do for ANY objects-on-Web-pages "solution", which is to say, damn close to none. I have ONE site that I'm willing to run Java from: ESPN for it's baseball applet. Every "enabling" technology that people use for this stuff tends to end up meaning "enabling inept web designers to create gimmicky pages that don't work", especially when they end up using scripting and crapplets to mimic the most *basic* HTML functionality like hyperlinks. (No, I'm not joking. I've seen it happen).
OTOH, for an *intra*net I would definitely consider something like this, and I'd prefer it over Java any day of the week. And for little noddy apps, being able to use my language of choice and still have portability AND much better performance, well, that sounds pretty good to me too.
So I think it's a useful bit of tech: just that it'll never go anywhere in the role they're pushing for it. That's not necessarily a bad thing though.:)
There are two sides to this quality thing though. The latest version of FooBar requires a newer Wingbat. So I install that, and poof - all of a sudden, YooHoo develops subtle failures, or crashes a bit more often than it used to, because YooHoo is linked against libWingbat.1, which is now symlinked to 1.5 rather than 1.4.
That kind of thing has happened WAY too many times. I think it's SLOWLY improving as developers get more of a clue, but even the last install I did a couple of months ago took a day or two to get everything patched up and using the right libs, which Joe Average totally isn't going to be up for.
Yep, I go with the mouse theory too. I've been using computers 40-60 hours a week for 15 years, not a hint of a problem. I switched to an "ergonomic" Intellimouse about a year ago because cleaning the old Logi every couple of hours was too much hassle (think Quake, and cats). 3 months later, crippling pains in the fingers and wrist, even the shoulder, of that arm.
Either the mouse, or I suddenly started spending a lot more time on pr0n sites. One of the two, certainly...:)
> In a game like Quake II, the ability to see through walls would hardly give you any advantage
?!
You can make a case for it not being a big help in TDM and FFA, but knowing where the opponent is in DM (which is to say, out-thinking them to be ready for their attack; or knowing that they're at upper RL) and hence lower RL is safe to get) is one of the most fundamental aspects of the game. For CA, it can absolutely determine who wins and who loses, just like CS; and for CTF it can easily mean the difference between fragging that enemy flag carrier who's hiding in a tunnel near his base so your team can cap or him getting away long enough for his team to return their own flag.
The poll is a joke. It didn't stop Asus releasing the cheat drivers last time, and it won't stop them doing it again this time. And it doesn't even have a "Cowboy Neal" option.:)
Asus make decent motherboards, but fuck 'em for this: Abit's and Iwill's are just as good, and no way will Asus ever see a penny from me in the future. I don't support companies with ethical problems (I used to spend $200-300 a month at Amazon, but it's been a long time now since they saw an order from me. I wonder why...)
We WILL stop this in OSP/CPMA if we have to (we've made sure id are aware of it, so hopefully they'll handle it in the upcoming PR), and I expect the Punkbuster guys will do the same for CS if Valve don't.
> Anyone who's ever played CS knows the intensity of crouching behind a box
Man, I wish it was possible to mod PARTS of a post up, cos that one is (9, Utterly hilarious).:)
Not everyone is into prettiness over gameplay, or making games where even newbies can get cheap frags without having to develop skills.
http://www.promode.org
Yes, I'm biased.:)
I know what you mean about the reviews though. Some of the Q3 sites are the same way about mods: every week there's a new one they hype up as the "greatest mod ever". Coincidentally hosted by them to get a few extra impressions...
The scene isn't hardcore any more because the GAMES aren't any more. Most popular game by an order of magnitude? CounterStrike, where Joe Newbie can kill Thresh just as easily as the other way round.
Gaming's a casual pastime for most these days. You can't really expect the "voices" of those people to be any less so, can you? I mean, if they were into this stuff enough to care about what they wrote, they'd care about what they played too.:)
That's fairly close to the truth, yeah. id's pretty much responsible for the current state of consumer-level OpenGL.
But let's get this one pet hate cleared up first: DirectX != Direct3D. D3D is the (formerly steaming) pile that JUST does graphics. Windows games, even OpenGL-based ones, will use the other parts of DX (sound, input) no matter which renderer they use.
OpenGL is still much nicer to develop for than Direct3D, and doesn't suffer from the backwards-compatibility issues of D3D (I have OpenGL code from 6 years ago that still runs fine, whereas 90% of the D3D code from >3 years ago just crashes), but the two are pretty much functionally equivalent these days. Given that there was a lot more development for D3D even before that was the case, you're unlikely to see people switching to OpenGL any more; and with the marketing muscle behind D3D, new outfits are more likely to go with it.
(A couple of years ago when MS became a publisher as well as a developer, we talked to them at GDC: their attitude at the time, and I expect it's the same today, was: "If you want use to publish your game, you have to use D3D. We're not interested in OpenGL games". That's a pretty strong incentive for a lot of independents and smaller houses. There were a lot of rumours of "cash incentives" for teams using OpenGL to switch, but let's not go there).
Note to zealots: you might as well skip to the next post right now. The rest of this isn't going to be pretty...
Getting back to the Linux side of things: SDL isn't even remotely close to being ready for primetime. I'm not saying it's a worthless effort, but at the moment it's just not very good. Add to that the development cycle of a typical project, which is getting close to 2 years these days, and that might give you a rough idea as when you MIGHT begin to see decent games that are Linux native.
Assuming that anyone bothers, after the Q3 sales figures.
(Those of you who are going to try and justify that with "waaah... but... but... the Windows version came out first" - STFU. That wasn't the problem, and your attempts to pass the buck on it like that are pathetic).
A DirectX layer in Linux isn't going to cut it. Hell, almost none of my D3D games work properly on W2K, let alone anything else. And while I *might* consider playing somthing like The Sims under WineX (if there was a hope in hell of it actually working before I'd long since lost interest in the game) I certainly wouldn't be willing to give up 60% of my framerate in an FPS.
At the moment, the future of OpenGL (and hence Linux gaming in general) is in the hands of Nvidia. Yeah, those people that you constantly whine about because they don't open-source their drivers. As the hardware eveloves and supports more cool tricks, the specifications for those and the drivers to implement them need to be written. For instance, had Nvidia chosen not to expose the combiners of the GF2 or the VS of the GF3 in OpenGL, that would have been it.
GLX is a wonderful thing. And ooh, it's been shipping in a form SOMEWHAT usable by newbies for, wow, nearly a month now.
As it stands, the best we can hope for in the Linux world ATM is that it might "kinda" be supported. Certainly, no serious company is going to develop ON it, or make it their platform of choice. It's still hopelessly lacking in decent tools for content creation (yeah, the GIMP is nice - that covers 5% of it) and development tools (emacs - the Windows of the Unix world; and don't even get me started on gdb), but more importantly it hasn't shown any signs of a decent-sized PAYING customer base. id took a gamble on Linux, and it wasn't worth the effort. How long do you think it'll be before the next company decides it's worth a shot?
Sorry that I'm so down on this, but WineX or something along those lines is a total waste of time. It's a half-assed solution trying to simply hide the real problems with Linux gaming rather than address them.
Here's my advice to the people involved with it: scrap this pointless exercise and do something useful instead. Help out with SDL. Write some decent tools. Remind people that it's free as in speech, not free as in beer, and that games will be neither of those.
Judging by the "success" of Wine, by the time this thing becomes usable in 2004 there'll be 3 games that run on it, none of them being DirectX 12 ones, and even my dual 6GHz Jackhammer system will only get 35fps...
arQon
(waiting for the "-1, Unpleasant truth" moderation):)
Slashdot Mirror
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.
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)
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. :P
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.
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
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
and as a summary of the summary: the low and mid systems are made of "good" choices; the high system is a pile of crap, with most of its parts apparently chosen entirely by cost rather than actual quality or suitability for purpose (including one of the worst mice ever made, which is pretty critical part to get right in a gaming rig :P).
Technically, he's right. You're talking about bunnies and other movement options, and those all have a very deliberate and specific behaviour. Something that takes weeks of playtesting refinement is hardly a bug, whether you personally like it or not. :)
I think he's misquoting an interview I did last year on the T-ball thing: I compared it to softball, and in context that was an extremely fair analogy: softball is there for people who CAN'T hack it in baseball - IOW, the vast majority.
FPS gaming is somewhat unique as far as "competitive" fields go, in that the bulk of it is explicitly targeted at the moderately-skilled rather than the elite, and it'll be a while yet before that attitude changes.
Sadly, I find it somewhat less than surprising that "Best Gameplay" is nowhere to be found. :/
If I was a bit more optimistic, I'd pretend that's what they meant by "Best FPS", but I've been around gaming way too long for that.
This really does seem an awful lot like a quick stab at a "hey, let's see if we can get a CS-equivalent for UT2K3" scheme, because the game as it stands IS shockingly unpopular given its relatively recent release.
Still, gl to anyone who goes for it. Who knows: maybe one of the FPS variants WON'T just be YA clone of CS. There's an awful lot of truth to this...
The fact of the matter is that it's been YEARS since Epic or id (sorry JC) did anything even remotely innovative with gameplay: TA's HeadHunters mode, UT's Bombing Run, Instagib, etc, are all just ripped straight from mods (and in the case of Instagib even copying the name) without bothering to credit or even acknowledge the original authors. If this is the only way "new" gametypes are going to appear in FPS's on a widespread/"official" basis (and it certainly looks like it) then at least gamers will get to see something that they might not otherwise; and at least Epic will (potentially) for once mention the people who ARE creating the gameplay rather than just quietly swiping it.
An interesting and predominantly accurate assessment of things within the context of Netrek, but it's both theoretical and inaccurate as far as FPS games go.
Even the densest of developers is (finally) WELL aware that you can't trust the client.
Your first two points are already exactly the behaviour of any well-designed engine (e.g. Q3, though if you read this JC, how about you put the network code and the renderer's cheat vars on opposite sides of a conditional compile in Doom3...)
The third is a game design issue: rocket launchers work that way, lightning guns don't.
The Netrek model works *for Netrek* for a combination of reasons, mostly that it (a) has VERY slow gameplay (even compared to VQ3, let alone ProMode) and (b) doesn't have dominating hitscan weaponry (i.e. no railgun / sniper rifle).
The Netrek developers didn't magically "understand all this" while the rest of us passed it by, oblivious to the potential problems. Yes, they did a pretty decent job of it all, but don't confuse the implicit benefits of the TYPE of game they made with some silver bullet solution for ALL games. That's like saying MUDs came up with the solution to all cheating just because an aimbot doesn't help you in one...
Until such time as the GPL is actually enforced, this kind of talk is nothing but a pointless ego-wank for people trying to impress us with how liberal and/or hip to the community they are.
On a small scale, codifying the GPL just takes the decision on that enforcement out of the hands of the people who produced the code in the first place and give it to an overworked legal system that most of us wouldn't trust as far we can throw it anyway.
On a larger scale, if ALL end-user code has to be open you adversely impact all sorts of things that you never considered in your knee-jerk reaction. Okay, so you might want Word opened so that we can get of these BS proprietary formats; or Outlook opened so the damn thing doesn't propogate infections faster than an open wound in the Black Hole of Calcutta. That's great, and there are real benefits there. Meanwhile though, online gaming goes into the shitter as every client instantly becomes 100% untrustworthy.
And what would it really help, as far as the GNU "ethic" goes? The same people that steal GPL'd code today would continue to do so: whether it's one guy and his pet project with a very limited audience (e.g. MQW) or a megacorp that loves the GPL for helping them cut development cost/time but doesn't go for "that hippy ideology" of actually returning the favour.
Scum will be scum no matter what you do with the laws. "Breaking" the GPL is already illegal, and it's not stopping them so far.
Seems to me that the only reason the utter drivel of the original article even gets a mention (and thanks for wasting 5 minutes of my life, BTW) is that those with an axe to grind about MS will get wood over the idea.
Ah, the joys of electricity... :)
:)
So, yeah: the Stanford PS stuff would be a very nice fit, from the looks of things. Certainly, something along those lines is needed, and it might as well be something that's actually be thrashed around a bit.
One thing that needs to be stressed wrt OpenML is that it's NOT necessarily what we want in OpenGL. While there's a clear overlap in some areas, the ARB needs to make sure that they don't end up kitchen-sinking it. The concern here is dependencies: in the same way that you try to keep classes as loosely coupled as possible, you also don't want your specs tied to each other so that changes in OpenML end up being mirrored slavishly in OpenGL irrespective of whether they actually add real value *from an OpenGL perspective* or not.
I'm absolutely NOT going to buy into the "xyz existing feature should be cut out" approach. Are the non-indexed primitives fundamentally worthless for "real" work? Yeah, pretty much. But they're also an easy way for newbies to mess around with OpenGL and get instant results. Those of us who suffered through the POS that was D3D's execute buffers would prefer that people not need 80 lines of code just to draw a single triangle. Every language needs its "Hello World", and that's basically the function that immediate mode serves.
Even display lists, which I haven't used in many years now, seem to have a place - I gather that on a fair number of non-"consumer class" systems they're still the way to go for a lot of things.
The "focus on this stuff which must be done the best/fastest" argument is a load of bollocks. Developers and IHV's already know what the important fast path is, and have done for years: it's glDrawElements on fully-featured data in CVAs.
The "fewer code paths mean there are fewer ways implementors can screw up their drivers" claim is fundamentally flawed, because we would certainly hope that any vendor who DOES drop "legacy" support goes out of business, so those "old" code paths will still be in every driver. Or at least, every driver for the cards *I'll* own...
Basically, given a decent shading language, we're pretty much set in terms of features. That's BY FAR the most important part of this.
GLsync (i.e. NV_fence extended and renamed) is a nice thing, although it's as much a matter of doing the Right Thing for the future as anything else, since we can EASILY saturate GeForce2-class cards ATM. Saving a few microseconds in setup/transform is all well and good, but since the true bottleneck for common apps (i.e. games) right now is memory bandwidth, the actual gains are basically non-existent. Still, there are other apps that DO benefit greatly from the improved parallelism, and like I say it's the Right Thing anyway.
The pack/unpack features are nice for certain effects, but they're clearly an example of "add this predominantly useless feature just to shut D3D people up". While a pack processor MAY lend itself to something useful (though given what's available through the pixel/vertex shaders that's a bit iffy), the unpack aspects seem almost completely pointless to me. Basically, the amount of "useful" work you can do in software is close to nil, and ANY glReadPixels-style call is going to bog because you're stalling the pipeline. That the other costs of such an action can be minimised is all very lovely, but next to the stall they're absolutely trivial.
The memory management is a *shrug* feature. Useful in some places, and I expect I'll whore certain aspects of it once it's available, but in reality it's nothing like as big a deal as some people seem to think - again, most of it is "D3D has this and we don't". Strangely enough though, this perceived lack doesn't stop my renderer or, say, Quake3's consistently outperforming any D3D-based one, does it?
Honestly, the only really annoying thing about working with OpenGL lately is the headaches that come from pixel/vertex shaders. We certainly need a vendor-independent way to support those, because damned if I'm going to rewrite mine for ATI cards - they'll simply be treated as "not supporting vertex programs".
:)
The synchronisation stuff is pretty handy: certainly, NV_fence has been very useful over the past year or so, and again: vendor-specific paths BAD.
Some of the changes seem to be as much to persuade some-ignorant developers to use OpenGL over D3D - the "black box" aspects of OpenGL are one the more DESIRABLE things about it. Changing those because some D3D guy is saying "I do xyz in D3D and I want the exact same concept to work well in GL because I'm too thick to actually use the right approach for that renderer" seems simply wrong to me.
Uh-oh: UPS just kicked in. Yay mountain storms...
"Pure" OpenGL2 is a terrible mistake. Give vendors the option NOT to support something, and they won't. Then all your old apps+games are up shit creek.
Will finish later when I have stable power again...
There's a lot to be said of platform-neutral environments. Typically tho, what's said is: "It doesn't f**king work". C++ is standard only as long as you're willing to stay with the language as it was 5 years ago, since we're constantly forced to use (eg) SunCC 4 or MSVC 6 or some other hopelessly broken compiler because of broken legacy code that NEEDS it; and Java has never been anything other than "write once, debug everywhere". :)
Being language-neutral on top of that is also a great thing for a VM, although it's no shock that the VM is going to be biased towards one language over the others. But let's face it: anyone using Java doesn't need hard-realtime performance anyway, otherwise they wouldn't be using Java in the first place. Same as if they were VB devs. So it makes sense that the bias would be towards C++.
The IVM runs DAMN fast, supports a truly open, pretty well-designed, widely-available graphics library: it's got a lot going for it.
But it'll have to bully its way past Java to get wide acceptance even if it's 10x better; and to truly become a standard it ironically needs to be adopted by, yes, THEM. The people whose browser has 80+% of the market. Of course, since it's GPL'd that's hosed it right there.
Then there are the same security issues that you see with every inet VM: how sure can I be as a user that some site's little applet didn't just funnel a ton of info back to them, that it won't do nasty things to me, etc. THOSE are the sorts of things that always bother me about "active" content: take a look sometime at how trivial it is to totally ruin someone's machine with an ActiveX control.
As an "Internet VM", I have as much use for this as I do for ANY objects-on-Web-pages "solution", which is to say, damn close to none. I have ONE site that I'm willing to run Java from: ESPN for it's baseball applet. Every "enabling" technology that people use for this stuff tends to end up meaning "enabling inept web designers to create gimmicky pages that don't work", especially when they end up using scripting and crapplets to mimic the most *basic* HTML functionality like hyperlinks. (No, I'm not joking. I've seen it happen).
OTOH, for an *intra*net I would definitely consider something like this, and I'd prefer it over Java any day of the week. And for little noddy apps, being able to use my language of choice and still have portability AND much better performance, well, that sounds pretty good to me too.
So I think it's a useful bit of tech: just that it'll never go anywhere in the role they're pushing for it. That's not necessarily a bad thing though.
There are two sides to this quality thing though. The latest version of FooBar requires a newer Wingbat. So I install that, and poof - all of a sudden, YooHoo develops subtle failures, or crashes a bit more often than it used to, because YooHoo is linked against libWingbat.1, which is now symlinked to 1.5 rather than 1.4.
That kind of thing has happened WAY too many times. I think it's SLOWLY improving as developers get more of a clue, but even the last install I did a couple of months ago took a day or two to get everything patched up and using the right libs, which Joe Average totally isn't going to be up for.
Yep, I go with the mouse theory too. I've been using computers 40-60 hours a week for 15 years, not a hint of a problem. I switched to an "ergonomic" Intellimouse about a year ago because cleaning the old Logi every couple of hours was too much hassle (think Quake, and cats). 3 months later, crippling pains in the fingers and wrist, even the shoulder, of that arm. :)
Either the mouse, or I suddenly started spending a lot more time on pr0n sites. One of the two, certainly...
> In a game like Quake II, the ability to see through walls would hardly give you any advantage
:)
:)
?!
You can make a case for it not being a big help in TDM and FFA, but knowing where the opponent is in DM (which is to say, out-thinking them to be ready for their attack; or knowing that they're at upper RL) and hence lower RL is safe to get) is one of the most fundamental aspects of the game. For CA, it can absolutely determine who wins and who loses, just like CS; and for CTF it can easily mean the difference between fragging that enemy flag carrier who's hiding in a tunnel near his base so your team can cap or him getting away long enough for his team to return their own flag.
The poll is a joke. It didn't stop Asus releasing the cheat drivers last time, and it won't stop them doing it again this time. And it doesn't even have a "Cowboy Neal" option.
Asus make decent motherboards, but fuck 'em for this: Abit's and Iwill's are just as good, and no way will Asus ever see a penny from me in the future. I don't support companies with ethical problems (I used to spend $200-300 a month at Amazon, but it's been a long time now since they saw an order from me. I wonder why...)
We WILL stop this in OSP/CPMA if we have to (we've made sure id are aware of it, so hopefully they'll handle it in the upcoming PR), and I expect the Punkbuster guys will do the same for CS if Valve don't.
> Anyone who's ever played CS knows the intensity of crouching behind a box
Man, I wish it was possible to mod PARTS of a post up, cos that one is (9, Utterly hilarious).
Well, this reply will never show up for anyone who's got a clue about threshold :) but chewie, it's really nice to see that some people get it. :)
Like I've said before, WineX is not the answer, because *DirectX* isn't the answer.
Not everyone is into prettiness over gameplay, or making games where even newbies can get cheap frags without having to develop skills. :)
:)
http://www.promode.org
Yes, I'm biased.
I know what you mean about the reviews though. Some of the Q3 sites are the same way about mods: every week there's a new one they hype up as the "greatest mod ever". Coincidentally hosted by them to get a few extra impressions...
The scene isn't hardcore any more because the GAMES aren't any more. Most popular game by an order of magnitude? CounterStrike, where Joe Newbie can kill Thresh just as easily as the other way round.
Gaming's a casual pastime for most these days. You can't really expect the "voices" of those people to be any less so, can you? I mean, if they were into this stuff enough to care about what they wrote, they'd care about what they played too.
That's fairly close to the truth, yeah. id's pretty much responsible for the current state of consumer-level OpenGL.
:)
But let's get this one pet hate cleared up first: DirectX != Direct3D. D3D is the (formerly steaming) pile that JUST does graphics. Windows games, even OpenGL-based ones, will use the other parts of DX (sound, input) no matter which renderer they use.
OpenGL is still much nicer to develop for than Direct3D, and doesn't suffer from the backwards-compatibility issues of D3D (I have OpenGL code from 6 years ago that still runs fine, whereas 90% of the D3D code from >3 years ago just crashes), but the two are pretty much functionally equivalent these days. Given that there was a lot more development for D3D even before that was the case, you're unlikely to see people switching to OpenGL any more; and with the marketing muscle behind D3D, new outfits are more likely to go with it.
(A couple of years ago when MS became a publisher as well as a developer, we talked to them at GDC: their attitude at the time, and I expect it's the same today, was: "If you want use to publish your game, you have to use D3D. We're not interested in OpenGL games". That's a pretty strong incentive for a lot of independents and smaller houses. There were a lot of rumours of "cash incentives" for teams using OpenGL to switch, but let's not go there).
Note to zealots: you might as well skip to the next post right now. The rest of this isn't going to be pretty...
Getting back to the Linux side of things: SDL isn't even remotely close to being ready for primetime. I'm not saying it's a worthless effort, but at the moment it's just not very good. Add to that the development cycle of a typical project, which is getting close to 2 years these days, and that might give you a rough idea as when you MIGHT begin to see decent games that are Linux native.
Assuming that anyone bothers, after the Q3 sales figures.
(Those of you who are going to try and justify that with "waaah... but... but... the Windows version came out first" - STFU. That wasn't the problem, and your attempts to pass the buck on it like that are pathetic).
A DirectX layer in Linux isn't going to cut it. Hell, almost none of my D3D games work properly on W2K, let alone anything else. And while I *might* consider playing somthing like The Sims under WineX (if there was a hope in hell of it actually working before I'd long since lost interest in the game) I certainly wouldn't be willing to give up 60% of my framerate in an FPS.
At the moment, the future of OpenGL (and hence Linux gaming in general) is in the hands of Nvidia. Yeah, those people that you constantly whine about because they don't open-source their drivers. As the hardware eveloves and supports more cool tricks, the specifications for those and the drivers to implement them need to be written. For instance, had Nvidia chosen not to expose the combiners of the GF2 or the VS of the GF3 in OpenGL, that would have been it.
GLX is a wonderful thing. And ooh, it's been shipping in a form SOMEWHAT usable by newbies for, wow, nearly a month now.
As it stands, the best we can hope for in the Linux world ATM is that it might "kinda" be supported. Certainly, no serious company is going to develop ON it, or make it their platform of choice. It's still hopelessly lacking in decent tools for content creation (yeah, the GIMP is nice - that covers 5% of it) and development tools (emacs - the Windows of the Unix world; and don't even get me started on gdb), but more importantly it hasn't shown any signs of a decent-sized PAYING customer base. id took a gamble on Linux, and it wasn't worth the effort. How long do you think it'll be before the next company decides it's worth a shot?
Sorry that I'm so down on this, but WineX or something along those lines is a total waste of time. It's a half-assed solution trying to simply hide the real problems with Linux gaming rather than address them.
Here's my advice to the people involved with it: scrap this pointless exercise and do something useful instead. Help out with SDL. Write some decent tools. Remind people that it's free as in speech, not free as in beer, and that games will be neither of those.
Judging by the "success" of Wine, by the time this thing becomes usable in 2004 there'll be 3 games that run on it, none of them being DirectX 12 ones, and even my dual 6GHz Jackhammer system will only get 35fps...
arQon
(waiting for the "-1, Unpleasant truth" moderation)