Slashdot Mirror
Carmack's QuakeCon Keynote Detailed
TheRaindog writes "In addition to announcing the Quake III source code's impending release, John Carmack's QuakeCon 2005 keynote also covered the programmer's thoughts on Microsoft and Sony's next-gen consoles, physics acceleration in games, and what he'd like to see from new graphics hardware."
mmmmmm.. Kenote! Delicious! [salive drool] mmmmmm.
yush
http://www.filerush.com/download.php?target=QuakeC onCarmackKeynote.zip
The actual keynote speech
The only things certain in war are Propaganda and Death. You can never be sure which is which though
I was a bit taken aback by Carmack's opposition to procedural textures. No, they can't do everything but they can be real timesavers when you need to add some overall realistic looking details. Things like dirt, "roughness" and stains can be done effectively using Brownian noise and the like, and you've got the infinite resolution, low-memory features of procedurally generated data. It's efficient and looks good, especially when I used it to create realistic terrain.
Of course procedural textures can never replace hand-painted detail, but layering on some infinite-resolution noise-detail onto a finite sized bitmap texture really brings materials to life.
Lets talk about Jon Carmack. Jon is the legendary programmer of such classic PC games as Wolfenstein, Doom, Duke nukem 3d, Quake 1, 2, and 3, unreal, and the upcoming doom3. Jon has single handedly created the genre known as the first-person-shooter. He has also popularized the OpenGL 3d format over Microsoft's competing Direct3d format, as well as caused public interest in 3d cards when he first released accelerated quake for the s3 virge chipset. Jon carmack has redefined gaming on PC's.
Now stop for a moment and think, What would have happened if Albert Einstein had worked creating amazing pinball games instead of creating the theory of relativity? Humanity would suffer! Jon carmack is unfortunately doing JUST THIS, using his gifts at computer coding to create games instead of furthering the knowledge of humanity. Carmack could have been working for NASA or the US military, but instead he simply sits around coding violent computer games.
Is this a waste of a special and rare talent? Sadly, the answer is yes.
Unfortunately, it doesn't stop there. Not only is Jon carmack not contributing to society, he is causing it's downfall. What was the main reason for the mass murder of dozens of people in columbine? Doom. It's always the same story: Troubled youth plays doom or quake, he arms himself to the teeth, he kills his classmates. This has happened hundreds of times in the US alone. Carmack is not only wasting his talents and intelligence; he is single-handedly causing the deaths of many young men and women. How does he sleep at night?
Carmack is a classic example of a very talented and intelligent human being that is bent on total world destruction. Incredibly, he has made millions of dollars getting people hooked on psychotic games where they compete on the internet to see who can dismember the most people. I believe there is something morally wrong when millions of people have computerized murder fantasies, and we have Jon Carmack to thank. Carmack has used his superior intellect to create mayhem in society. Many people play games such as quake so much that their minds are permanently warped. A cousin of mine has been in therapy for 6 months after he lost a 'death match' and became catatonic.
It is unfortunate that most people do not realize how much this man has damaged all the things we have worked hard for in America. Jon has wasted his intelligence, caused the deaths of innocent children, and warped this country forever. To top it off, he got rich in the process and is revered by millions of computer users worldwide. Perhaps one day the US government will see the light and confine Jon Carmack somewhere with no computers so he can no longer use his intelligence to wreak havoc on society.
Although Mr.Carmack says physics in game engines isn't easily scalable for level of detail, there is ongoing research about this producing good results. I remember a video from last years SIGGRAPH that had hundreds of plastic chairs falling from the sky, and bouncing realistically. The important part was it employed a level-of-detail hierarchy for interacting parts (i.e. an object doesn't have much physical detail if you don't touch it), but it will be some time before we can see such techniques in real time games.
Carmack doesn't deisgn games, he makes engines. Doom and Quake are tech demos for whatever his latest engine is. If you buy an id game expecting it to be anything else, you're doomed to disappointment. Even Id doesn't claim its anything else.
I still have more fans than freaks. WTF is wrong with you people?
I found his views on dual core processers fascinating. Until now I had always believed they could give major boosts in performance in games as soon as the developers made their games multi-threaded. Maybe I should put off buying that dual-core cpu for a bit longer.
His love for graphics is nice, but pity he lack s physics programming skills :)
That's why Jan Paul van Waveren takes care of it, in Doom 3 etc. Physics Middleware will be of big importance for next-gen consoles, and it will rock the world :)
http://www.continuousphysics.com/Bullet/phpBB2/ind ex.php
Yeah right! Is that what id was claiming BEFORE they released Doom 3? Hardly...
Taking advantage of Dual-core CPU is as easy as licensing middleware. In a budget of 5 million dollar, a 50.000 dollar licensing fee (or less) is peanuts. See www.havok.com or www.ageia.com, www.meqon.com
Carmack was less pleased with the PowerPC processors for the new consoles, questioning the choice of an in-order CPU architecture. He estimated the console CPUs' performance at about 50% that of a modern x86 processor
0 -2.ars
:)
Finally, proof that Apple is over priced, under powered hardware.
Why does Carmack hate Apple so much?
Read up on the flavor of PPC that is in the XBOX 360...
http://arstechnica.com/articles/paedia/cpu/xbox36
It's far different from the G4 and G5 that Apple currently uses.
BTW, if Apple loved PPC so much, why did they announce the switch to Pentium M ?
> ...as soon as the developers made their games multi-threaded
:)
This is considerably more difficult than one would think. Games typically have to perform tasks in a particular order, for example (extremely simplified): get inputs, move player, move AI players, move other objects, check for collisions, update parameters, display the next frame, loop.
Quite where we add this 2nd thread is difficult. Everything must happen in the same order in order for things like collision detection to function correctly. If we start a second thread to, say, calculate AI decisions and move the AI characters according to those decisions, we have to wait for that thread to complete before we can display the next frame. So it ends up that there are no advantages to utilising that second thread.
Now, I'm sure there are game developers on here who know how to utilise threads in games in a successful way. It'd be cool if one of them could inform the rest of us what the heck we're supposed to be doing with them
"You heard the man, Tubbs.. get undressed."
Good news, Carmack is a programer not a game designer.
Analogies don't equal equalities, they are merely somewhat analogous.
Ok, I'll feed you little troll....
Carmack came out against the current crop of PowerPC CPU's to be used in the X360 and PS3 that are very different from the CPU's that Apple have been using in their PowerPC based computers. The PPC's in the consoles do not support out of order execution and a raft of other features. IBM have designed simpler cores that are being packaged on multi-core chips that can be run quicker and in parallel.
Carmack has plenty to bash Apple for in regard to their OpenGL implementation I'm sure - just browse the Apple developers OpenGL mailing list sometime.
?
when has carmack said anything in that speech about next gen being too difficult.
He explains his view on why he thinks dedicated 'physics cards' would proove a non starter with him - and made some pretty good points, and any game programmer would understand him. I seriously just think your trying to advertise every physics engine out there.
It's worth pointing out that he doesn't design games because he's a renderer/technology programmer. Id (id? iD?) Software will have designers responsible for designing the gameplay and so on.
JC isn't really responsible for the shortcomings of the games *as games*, except in as much as the ability of the engines he makes for them limits & influences gameplay decisions by those designers...
Game dev and music blog
PowerPC CPU's to be used in the X360 and PS3
The PS3's processor is not a PPC. I believe the processor used is called a POS.
Why? If the AI isn't done in time, then the next frame is rendered with the character in the same position or moving at the same velocity. Seems quite realistic to me for the AI to have a real reaction time to things.
The problem being, that in that case the non-realistic image of a monster stuttering on screen then moving 2x its speed the next frame really does make it harder to sync up.
salesman ? I'm a coder, and the link is to a free forum and open source project. Open source, ever heard of that ? probably not, seeing your bad manners.
I'm advertising that the next-gen consoles can use their parallel power to run physics much faster.
e wtopic.php?t=62&sid=9dc86d5b23a3d1099165eddc7aa982 48
e wtopic.php?t=54
Just scroll down to the bottom of that link.
Secondly, the link is advertising a forum and open source physics. And half of the serious professional game programmers are on the forum.
Here is the doom 3 programmer: http://www.continuousphysics.com/Bullet/phpBB2/vi
Or what about Halo 2 ? http://www.continuousphysics.com/Bullet/phpBB2/vi
Personally I think you are a moron, because if you paid £1000 to get 30fps in 800x600, you obviously went to PC world.
- Each monster / NPC can run their AI in parallel and interact with the game system via the same API as the player.
- Collision detection can be performed in boxes smaller than the entire scene, all in parallel.
These two are just off the top of my head, but I'm sure there are more things that can be added.I am TheRaven on Soylent News
"Ladies and Gentlemen,
Yes, things related to the drawing and basic movement of the character need to be done in sync in the main thread. However, the higher level reasoning of the AI can be done completely in a seperate thread.
Think of how multiplayer is done today. Low level stuff, including how the acutal character movements are done, are handled by the main rendering thread. But all the high-level decisions (where the player goes, does he shoot or duck, etc.) are done by seperate threads (the player's brains). It's not really any different with AI NPCs.
- Add to unprocessed que
- Grep for coded expressions
- add symbol to character action queue
Thread 2: Charactor Thread- read action queue
- publish action
- recieve reaction
- update state
Thread 3-100: AI Threads- Read viewable universe state
- Process against goals
- publish action
- recieve reaction
- update state
Please don't read this too literally, it only a slashdot post, but this is meta-outline of how I'd start thinking about the game universe in a multi cpu system. Of course it would run like shit on a single CPU (all those context switches (ugh)), but it would really utilize a multicore system.Scared of flying, pointy things snce 1979!
Carmack was commenting on hardware vendors believing that more cores, more cpus, more hardware is good. But for the DEVELOPMENT OF A GAME in a GOOD AND REASONABLE TIME using a SIMPLE, ELEGANT, AND FAST METHODOLOGY, adding more cores and more cpus and more accelerators intruduces more places where bugs and glitches can occur, and thats only after you figure out a nice design, which will take longer to do and therefore cost more to make. It complicates things which shouldn't need to be. Not all companies want to introduce 3rd party code into their games for various reasons and you should not assume that everyone wants to.
What GFX cards need to have in future is MOTION BLUR, above all. That is the single reason why the game intro videos look like real movies, while the game gfx still look like... well like game gfx. The lack of image processing circuits in todays gfx cards is the problem that needs to be fixed in future.
"Two things inspire me to awe -- the starry heavens above and the moral universe within." - Albert Einstein
Quite where we add this 2nd thread is difficult. Everything must happen in the same order in order for things like collision detection to function correctly.
Not neccesarily. One big problem with games is that the typical order (beginscene/render/endscene/present) is implemented with a busy-wait loop in the present part. This is the part where all data has been sent to the graphics card and the driver waits in a loop until it gets a 'scene completed' message from the card. This is why games always run at 100% CPU.
Games that don't use threading well (only threading for network/input/sound) put stuff in the loop you describe. Draw a scene, the driver waits for an 'OK', then you update the player, update the AI characters, do collision, calculate all new positions and start drawing. Because the drawing takes eg. 10 ms per frame for 100 FPS developers limit the AI/collision part to run in something like 1 ms or else the frame rate starts dropping. So the real AT would be limited to say 10% of the CPU time.
For example the 'move AI' part could be a bunch of threads, calculating new positions based on direction, collision etc.
Right now games like DOOM3 typically only display a few NPC's at the same time because of the timing problem. If the move AI thread can just keep running on the second CPU while the first CPU waits within the driver a game could support a few 100 enemies on-screen.
Strategy games with complicated pathfinding with hundreds of units on-screen like Warcraft 3 or Age of Mythology would profit enormously, if programmed for multithreading.
I perfectly understand what you say. And I discussed with Carmack over email a few month ago, exactly about this topic. It doesn't mean I agree. First of all, graphics is already heavily parallel, but in this case it is handled purely inside the hardware. For physics, this can be too, but he argues about the fallback path. Not only consoles are choosing multi-core. Even Intel and Apple are going the multi-core direction, for a good reason I think. I think it just frighens more game developers to jump on the next-gen multi-code machines. Instead of moaning, its better to just prove him wrong. Half Life 2 had some good physics, I think that is the way to go.
"Jon is the legendary programmer of such classic PC games as Wolfenstein, Doom, Duke nukem 3d, Quake 1, 2, and 3, unreal, and the upcoming doom3."
Umm no. Maybe you're thinking of ADRIAN Carmack (not related) who left id and joined Epic to create unreal.
Oh and BTW Doom 3 has been released! Rejoice!
- sigh
I have to say, I enjoyed Doom 3 more than Halflife 2. Both good games. Halflife with so much more features and bells and wistles. But in the end Doom3 was just more fun. And a less pain in the ass to get going ;)
Just because I can imagine doing a hippopotamus, doesn't mean I'd like to do it.
same here - Firefox 1.0.6 runnning on 2.6.12-gentoo-r4 crashes as soon as I click the link.
Carmack's other wish-list item was that some attention be paid to the problems with handling small batches of data on today's GPUs. He said the graphics companies' typical answers to these problems, large batches and instancing, don't make for great games.
John Carmack's past pleas for graphics hardware changes have led to a number of developments, including the incorporation of floating-point color formats into DirectX 9-class graphics chips. We'll have to watch and see how the graphics companies address these two problems over the next couple of years.
These are topics that the whole graphics industry acknowledges. While he is wise to focus on these as core issues, I'm not sure if I would say that the industry responded to his plea when these things get addressed.
One other thing that I'm a little confused by is why game developers always seem to think multithreading games is going to be nearly impossible to take advantage of in the near term. I admit it won't be a piece of cake and there will be evil bugs, but I don't see it as this big mystery. It will be more work, but it seems with some thought it can be handled fairly nicely on first generation games of next gen consoles. If I were to tackle the problem I would not break up the rendering into separate threads since this is just going to be trouble, but I would reduce rendering to truely only do the rendering which some developers seem to get confused. I would make one or more physics threads, one or more AI threads, a sound thread, a rendering thread, a resource managment thread, and perhaps a culling thread which assisted the VPU with geometry occlusion if the CPU is ahead of the VPU. I'd also put in a semaphore queue mechanism so some of these could get a frame or two ahead without syncing.
That said I'm not a game developer so perhaps I'm just missing something. If that's the case please enlighten me.
If you look at it from a different angle, a lot of games already have very good multi-threaded support.
Start with online multi-user games. Instead of a remote server hosting a game which 5 different users around the world connected to it, all 5 instances of the client software run on the same machine as the server. Now take the final step and convert 4 of those clients from user-controlled to computer-controlled AI.
The beauty of this idea is that you're programming the single-user and multi-user game at the same time.
I'd love to mod you up, because yes, he is a programmer and graphics nut, who as far as I can tell, these days, leaves the game design largely up to other people. Somehow I think that he's come a long way from Commander Keen - engine development and game design can be now be totally removed from each other.
Who is this Anonymous Coward guy, and why does he insist on fighting with himself? Procedural Textures != Shaders. Shaders make use of both procedural textures and artist made textures. Shaders usually deform or change a target. Be it texture or verts.
"This is considerably more difficult than one would think. Games typically have to perform tasks in a particular order, for example (extremely simplified): get inputs, move player, move AI players, move other objects, check for collisions, update parameters, display the next frame, loop" - by fistynuts (457323) on Tuesday August 16, @06:27AM
IF this is the way things occur in games?
(waiting for the results of one variable to happen in order for the next variable result to occur?)
Then, you are dead-on & I agree 110%.
E.G. (simple example) ->
A=B+C
B=A+C
B cannot get anything done, until A gets its result...
Thus, putting A & B onto diff. threads is useless - the operations of both are not "parallelizeable" & blocking.
Perhaps this is indicating (assuming you're correct on how things are in games, & the AI for monsters for example) there's a "problem" in the AI as its technology implementation stands right now?
(E.G.-> Monsters AI being PURELY 'reactive' etc./et all is the "problem" & perhaps them being more "proactive" & less dependent on the user's input (& thus, their character's movements/actions) is the needed "correction" here).
OR
Perhaps, this indicates that the usage of threads has to be utilized possibly elsewhere in the game's engines.
APK
Bought that 512MB graphics card to get all of the features you've paid for in Doom3? Have you even found one that you can buy?
Conor "You're not married,you haven't got a girlfriend and you've never seen Star Trek? Good Lord!" - Patrick Stewart
Agreed, it's a bit disrespectful to the ones that make this site (the readers/posters). Without readers/posters this site would be nothing.
To quote Carmack "it's not about the magic source code that's there...It's about the execution". guess grafix companies should come should focus on physics acceleration in games rather than programmers spending hours creating procedural shaders. Personally, i'm more onto gameplay... will Q4 've better than Q3 & yea ofcourse the pandora's box (source code).. Maaa Preciouuuuuuus !! :-)
My favourite place : 127.0.0.1
it might be a badly written flash app that's killing your fox
Shame he didn't mention whether he's still committed to opengl - with his move to the xbox it left me wondering. JC and ID are single handedly responsible for the still mass market appeal of opengl, lets hope it stays that way.
I think a good place to look for examples of how multithreading could be applied in a game is to the MMORPGs and other online "worlds". Most of these present a large world by placing a grid over the landscape and having each grid square run by a separate server. The servers then communicate with their neighbours for things such as object handover. If it can be done with completely separate computers then it stands to reason that it can be done with less overhead where there are multiple processors sharing the same data.
Yeah Carmack's speech was a real ripper. Warms this old Aussie heart. Mate, I'd watch it again but I need another slab eh.
insecurity asks the wrong question irritation gives the wrong answer
Same kernel,distro and FF version, no crash.
Dude, have you played ANY iD game since Quake 1? They're all tech demos for new engines, that's all they ever have been. Carmack has admitted on serveral occassions that he thinks story and such don't belong in games, that they're a waste of time and effort. iD does NOT make games, they make the next level of graphics engines.
You spent over a thousand pounds for a system that would only run the game at 800x600? What did you do, crank AA and AF to max and set the detail level to "Ultra"? I played on Ultra with AA and AF set to a middle setting and I got a solid 25-30FPS on a machine that was a year old. Either you got ripped off by a retailer, or you don't know jack shit about what parts to buy.
Your problem is you have your OWN head so far up your ass you aren't able to read/hear what Carmack himself is saying. If you did, you'd know they're about the engines and they let OTHER companies take the engines to make good games. Quake 4 is being done by Raven. Raven did amazing things with the Quake 3 engine in the Jedi Knight games, they're going to be the ones to take the new engine and turn it into an actual game.
Thanks for trolling.
Although Mr.Carmack says physics in game engines isn't easily scalable for level of detail, there is ongoing research about this producing good results. I remember a video from last years SIGGRAPH that had hundreds of plastic chairs falling from the sky, and bouncing realistically. The important part was it employed a level-of-detail hierarchy for interacting parts (i.e. an object doesn't have much physical detail if you don't touch it), but it will be some time before we can see such techniques in real time games.
I think you're misunderstanding his point. When he talks about level-of-detail, this has more to do with game design than with algorithms. What he's claiming is that detailed physics has much more of an effect on actual gameplay than detailed rending does, and that it's harder to write a game which graceful downgrades the player's physical interaction with the world. But a graceful downgrading is necessary for people who don't have a fancy physics-accelerating card.
For example, you can take an older game and change its appearance by giving it higher resolution textures, more detailed meshes for the AI models etc., without having to redesign the actual gameplay. (e.g., the SHTUP and Rebirth mods for System Shock 2).
These steps are independent of each other and independent of the rest of the game. They can simply be dropped in, or not. The point is that if it's that straightforward to take a game forward in technology, it's even easier to go in reverse. So the player can choose low texture detail, etc., and the game may look worse, but it will still play the same.
The game physics on the other hand has historically been more closely connected to the way the player interacts with the world.. so it has a big effect on level design. If Half-Life 2 had a 'simple physics' option that would somehow revert the game physics to something equivalent to the physics in the original Half-Life (ignoring aside the difficulty in implementing such an option) then some areas would have to be substantially redesigned so that they would remain playable for people using the simple physics.
This is of course what he means by peripheral elements "such as flowing water" being accelerated. But I have two criticisms of this.
1) Yes, physics acceleration may affect mainly peripheral elements of the game. But in some ways, the same could be said about improved textures, filtering, etc. If it's done well, it can significantly improve the overall experience. If it's done poorly, the player will hardly notice.
2) As long as it's an upgrade of the basic design, it will probably be okay to let it affect critical elements as well. E.g.: due to the engine upgrade in the port of Half-Life to the Source engine, movable crates and such have a more realistic response than in the original implementation. It's not a big improvement, since the levels were really designed with that in mind. But it doesn't hurt.
For me, the real question is whether improved physics would really make a game more enjoyable. I think this depends more on graphics than on anything else. As objects are made to look more realistic, it becomes more satisfying for them to have real-seeming interactions.
If graphics get much better, accelerated physics will be important. But if for some reason graphics tend to stabilize (due to the end of Moore's Law, long load times caused by slow disk access, or whatever), then the usefulness of improving game physics is more questionable.
Go get 'er tiger. 2048 x 1536 @ 85 Hz. 250 quid bargain
-- Intelligence is soluble in alcohol
It's already available since at least yesterday. QuakeIII source
Yahh, hiii haaaaa! -Major Kong, from Dr. Strangelove
A FPS of 25-30 is not "solid" it's "pathetic". Maybe he was exagerating but:
6 month old videocard = $400, new videocard = $500
processor upgrade = $300
motherboard to mount new processor = $100
Mine is crashing too - with Flashblock installed. It can't be a flash thing.
b4n
Yeah, another "trick" that shitty programmers can overuse. Similar to image bloom, particle effects, and too much brown (see: Quake I, Deus Ex: IW). Keep your motion blur, thanks.
It's solid for how high I had the settings cranked.
Remember, performance is always relative when it comes to new graphics engines. They always require more power to get the same framerate or resolution than the previous generation did.
You can't compare Doom 3 to the Unreal 2 engine or to the Quake 3 engine in terms of performance. It's apples and oranges.
Is this a waste of a special and rare talent? Sadly, the answer is yes.
No, there are many as talented and more talented people working for NASA and the DoD. Most of these people don't opt for video games and in other fields of programming you don't get "rockstar" press. You are merely looking at one of the bigger fish in a small pond.
It's already available since at least yesterday. QuakeIII source
Uh, where?
You do realise that "Game Source" means the game rules / mod source and not the Quake III engine source? Is there a Quake III download marked "Quake III Source (GPL)" yet like the other two?
256 MB RAM is definitely not enough for games with demand for such extreme graphics and realism (did he say physics?)!
I doubt that the next generation games will look like movies; except for some graphic demos like the Unreal Engine 3.
Here's an old quote from Tim Sweeney:
"Off-the-shelf 32-bit Windows can only tractably access 2GB of user RAM per process. UT2003, which shipped in 2002, installed more than 2GB of data for the game, though at that time it was never all loaded into memory at once. It doesn't exactly take a leap of faith to see scenarios in 2005-2006 where a single game level or visible scene will require >2GB RAM at full detail."
http://www.beyond3d.com/interviews/sweeneyue3/
So let's wait and see how XBOX 360 and PS3 will fare...
Q3A 1.27g Game Source
This is the combined source code for Quake III Arena and Quake III: Team Arena. It can be used to build the 1.27g point release or the Team Arena release. It contains buildable project files and all related game source code as well as prebuilt tool executables.
2.2MB Win32
Doesn't say GPL, but it looks like the source to the game
This is the game source, not the engine source - which is what we are waiting for.
If only there was some way for you to be able to decide not to buy Carmack's games.
But I guess that's just impossible.
Procedural textures are so last century. Do you have a shrine to Perlin?
Doesn't say GPL, but it looks like the source to the game
Game, yes. Engine, NO.
Like I said: this is the source for mod developers. It contains the source for the server side game environment rules, the corresponding client side component of that and the logic for the menu UI. It does not contain any of the graphics engine code. It does not contain any of the AI code.
As you'll see here, "game source" was released back in 2000.
Check out Gabe Newell's comments (One of the key developers of Half-Life 2). He also thinks multi-core/cpu machines aren't going to be bringing a lot extra to the table for game machines for some time.
When Newell and Carmack, the lead developers of the two hottest game engines out there, agree on this point, you realize we might not be taking that leap forward in gaming that we all thought we were going to.
Is this the KDE project's competitor to Microsoft OneNote or something?
The role of the writer is not to say what we can all say, but what we are unable to say. -Anais Nin
If you guys had to pick one today, which would it be? Personally I've never liked XBox that much, and the games lineup for Playstation 3 is superior to XBox.
Full Tilt
dunno. doom was one excellent game and quake was fun online.
world was created 5 seconds before this post as it is.
Save that the Jedi Knight games had some of the most tedious, unimaginative, cut and paste level design I've ever seen in a video game (just like every ID single player game since Quake 2 then...) And if Doom 3 is only a tech Demo rather than any sort of attempt at a game and if, as you say, Id does not make games can I please have the £35 I paid for Doom 3 back. Because it definitely claims to be a game on the packaging and that's misrepresentation
irst and foremost on that list was full virtualization of texture mapping in graphics hardware. Carmack decried the "fallacy" that "procedural synthesis will be worth a damn," arguing that programmers spending hours creating procedural shaders isn't the best way forward. Instead, he said, tools should unleash artists. He called the current tiled texture analogy a crude form of compression, and argued that true unique texturing in graphics would be a massive leap in visual fidelity over current practices. To that end, Carmack asked for virtual page tables in graphics hardware with 64-bit addressing.
Damn. Could someone give me some Cliff's notes on this?
'Ol Corky here just can't handle it.
It doesn't exactly take a leap of faith to see scenarios in 2005-2006 where a single game level or visible scene will require >2GB RAM at full detail.
I've heard from plenty of people that you do need at least 2GB of RAM free for BF2 to be playable at the highest settings.
It really saddens me to see John Carmack nay-saying a bit about physics acceleration in games. Apparently, he conceeded he's a graphics guy and is afraid the bar is going to be set too high with physics but I think that is a huge cop-out. Just because something isn't your area of expertise you're going to spread FUD about how it might make games unstable and about how it might not be used correctly in games and how the first generation of hardware might cause problems? That is just plain weak. In my mind, the time of graphics has long since passed. I could (and would) be perfectly happy with the level of graphic detail acheieved in current games forever. I am much much much more interested in seeing game physics improve. Eye candy is neat but gets old very quickly. Realistic physics beget emergant gameplay. This idea is exemplified by Half-Life 2 which is one of the most interesting, immersive, and replayable games I've ever experienced. And no game is a better example of how boring amazing graphics can be than Doom3! I think John Carmack might want to re-examine his viewpoint and start stepping into the uncharted (for him) water of game physics or I stronly believe he's going to get left behind.
I find laziness to be an excellent motivator.
I won't mention that a 6800GT would run the game at 1600x1200 with Ultra quality and fairly high framerates. We'll forget about all those cards that can do exactly what you said and complain about the 2mb onboard video in my parents computer. OMG IT WON'T RUN DOOM3!!!!!
he said that if he knew what atomic theory would be used for ahead of time, he would have become a shoemaker instead.
Carmack doesn't deisgn games, he makes engines. Doom and Quake are tech demos for whatever his latest engine is.
But, does Carmack pass the engine to the design team with a small note that reads: P.S: It works best when you make everything Brown?
Multithreading could do away with loading screens. If the player approaches the end of the level, the other thread could start loading the data for the next level. Imagine huge worlds that are full of detail, uninterrupted by pesky loading screens.
I completely respect John Carmack, he's changed the game industry. That said, looking at Doom3 compared to HL2 and then (not that long after Doom3 came out, relatively speaking, a year?) FEAR which is dramatically better in every way and makes it look like it's a lot more than a year better, I think John is losing his step a little. You will need to use different tricks to multiprocess, you'll need to do things differently. Yep, it's hard if you start from scratch.
I think once you get things rolling, it'll make stuff a lot easier.
Game source != Engine source
Now before I get modded down, I be to remind whoever might read this that what I am saying is FACT. - bogaboga
Thank you. Thank you, thank you, thank you. Vote with your dollars, people. I know the grandparent was a troll, but still...people just come off as idiots when they get enraged about some product that's still their choice to buy or not.
I'm being redundant, but still. Mad props.
Until you realize that this would require twice the workset, trash cache locality and hog the graphics bus. It will not be a free operation.
I had no idea Jon Carmack knew so much about the symphony. But what does he think about computer games?
Thread 3-100: AI Threads
1. Read viewable universe state
I think that would introduce all of the issues multiplayer games have with network lag right into the game engine. If the AI characters aren't all working from the same data set (because it's changing while they're "thinking,") you're bound to have some pretty weird and difficult-to-debug timing issues. Even simple single-threaded code has a lot of wacky and unpredictable timing behavior on a PC, compared to actual real-time systems or purpose-built gaming consoles. This would make those timing issues much, much worse.
Carmack is a very smart guy. He addressed this sort of issue publicly in his finger journals (back before anyone said "blog") when he was trying to develop a version of Quake III that took advantage of multiple processors. Certain things in a game loop just have to be synchronized, and that causes bottlenecks that multiple processors can't help with.
If it were possible to write explicitly parallel code for dual-core CPUs, that could be a very different story. But it would also negate the advantage dual-core is supposed to provide, so the heck with it.
I wonder just what will be included...
Will it include the source code to Q3 Arena and Q3 Team Arena?
Will it include the ports to other platforms? (i.e. linux, mac)
Will this release mean that other Quake 3 engine games can go Open Source too? (e.g. Return To Castle Wolfienstien, Enemy Territory etc)
Id (id? iD?) Software
since you asked, its "id"
a long time ago they spelled it "Id"
they have NEVER EVER spelled it "iD"
(got that people? stop spelling it that way)
Piece of Shit sounds about right... ;)
Tim Sweeney would also agree. That makes the the lead developers for the top three game engines.
Stop Global Warming!
Just say no to irreversible processes!
World of warcraft does this for large portions of its world. Dungeon Siege also does this fairly well.
Tonights forecast: Dark. Continued dark throughout most of the evening, with some widely-scattered light towards morning
"Strange how much human accomplishment and progress comes from contemplation of the irrelevant."
- Scott Kim
Can we get a "-1 Wrong" moderation option?
Pssst...nobody has dev kits for the nintendo revolution yet so it will be pretty hard to comment on how good/bad it is.
Jon is the legendary programmer of such classic PC games as Wolfenstein, Doom, Duke nukem 3d,
Ken Silverman created the Build engine for Duke Nukem 3D, not Carmack. In fact, Carmack has never worked for 3D Realms.
Just a minor detail, everything else I can't speak about.
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
I'm not a game programmer, but I do a lot of multi-threaded development. In multi-threading you when you need to guarantee that things happen in a particular order, you use a specific multi-threading technique such as a semaphore. Without these techniques, thread-1 can get more CPU time than thread-2. So multi-threading adds logic complexity and overhead.
In some multi-threaded systems, each thread can act independently of all other threads. It doesn't matter whether thread-1 gets ahead of thread-2. In a game, there are dependencies because everything is time-synchronized. Each thread, though scheduled independently by the OS, must be in synchronization with the "game clock".
Further, there may be data dependencies between threads. To use the parent's example, the AI thread has to decide where the orc is going to be before the render thread can draw it. And both threads need to be synchronized to the game clock so that the orc doesn't suddenly look like it's taken a potion of haste (or slow).
My supposition is that at the present time it is easier to single-thread games based on performance as well as logic simplicity. As multi-core processors become prevalent, it will become advantageous from a performance perspective to use multiple threads to utilize these CPUs. That point is where the "cost" of increased logic complexity and thread synchronization is outweighed by the increased gameplay value.
was to RELEASE the internet to the public and let them sort it out. Otherwise it would've remained a way for four star generals to download college dorm porn :)
Honestly though, if they had held onto it, it would've remained nothing, give them credit for handing it off to people who come up with new things, instead of the military, who come up with ways to kill innocent (and occasionally the guilty) people in this world.
" What luck for rulers that men do not think" - Adolf Hitler
Good point. A physics driver could be build, that is compatible with the open source license, similar to an opengl / directx driver. But I agree, that should be sorted.
Oh My God!
They're Not Even Human!
The war with islam is a war on the beast
The war on terror is a war for peace
Crashes for me too on Fedora with Firefox 1.0.6. It's not a kernel/linux error. It's firefox. I can reproduce the same behavior on my Powerbook with 1.0.6. I filed a bug (Bug 304731) yesterday on this because it was crashing on another link from a slashdot posting yesterday as well (http://bluesecurity.com/community/gallery.asp). However, they closed the bug because the crash doesn't occur in Deer Park (next version of Firefox).
Best,
Arash
You my poor befuddled friend is what we call a classic buffoon. You have a very distorted view of the current world and an even more distorted view of what the world should be. Go hide in your hole with the rest of your genetically crippled cretins.
*--- Sometimes a majority only means that all the fools are on the same side. ---*
Games and displays should just push the framerate higher - any "motion blur" will then be due to your eyes not keeping up. The real world does not have motion blur. Movies do, because they're shot at a crappy 25 fps, and because each frame is exposed for a significant number of milliseconds - game graphics can be a lot better than the movies in this respect, although realtime rendering will never be as detailed as prerendering.
I quit!
Soul Reaver did that back in 1999. IIRC, Morrowind does as well.
"...always new atoms but always doing the same dance, remembering what the dance was yesterday." -Richard Feynman
'You spent over a thousand pounds for a system that would only run the game at 800x600? What did you do, crank AA and AF to max and set the detail level to "Ultra"? I played on Ultra with AA and AF set to a middle setting and I got a solid 25-30FPS on a machine that was a year old. Either you got ripped off by a retailer, or you don't know jack shit about what parts to buy.'
Most certainly the latter.
Full transcript courtesy of some poor schlub on Beyond3d.
Yes but can you image coding that in C? It would be a freakin' nightmare. I think that's John's real problem with threads and multi-core systems. It's probably why he's also down on ps3... for that you basically have to write small independent modules that work well in parallel; it's kinda the origami mindset... a Japanese developer might develop a beautiful, self-contained, self-directed NCP for ps3 whereas John's western mindset would make a page of AI code that gets everything sorta-ok.
What's needed for next-gen game programming is something like Java, where threads and game logic is ridiculously simple, but with the ability to micro-manage time slices and data formats. AFAIK a language like that doesn't exist yet. What's clear to me though is that if we start getting 4+ cpu machines game programming will be done in something besides C and C++, whatever that may be.
You are right of course... I'm not as bright as Carmack, and I'm sure he's spent ALOT longer thinking about this than me.
//token represents recieveing dice
The most obvious problem with my solution is to think of it like a Games Workshop game. There has to be some sort of turn basis, otherwise the winner is the one who can role the dice fastest.
But taking that metaphire further, there are no idle cycles in a games workshop style game. Even though only one player can update the universe at a time, everybody else is crunching numbers, trying to figure out a stratergy. A succesful player is one whos stratergy can adapt to the changing games state, rather than having to constantly have to rethink their stratergy with every move. In that sense we could update my AI thread thus:
Thread 3-100:
do{
do{
if(universe.updated)
{get viewable universe}
refine statergy;
}while(hasToken == false);
publish action;
recieve reaction;
update state;
pass token;
}while(true);
This removes a lot of the race conditions, as only one NPC can update the universe at a time, the rest are just reading. If the changes to the universe between each pass of the token are small (this should be a fair assumption as you would expect one cycle of token passing per frame) then a little inaccuracy between the universe read and 'reality' should be expected - we all blink don't we?
Scared of flying, pointy things snce 1979!
the pentium introduced the cmpxchng instruction. its used for doing synchronised atomic things. i belive simcity of the day used it for simulating huge (haha well relatively huge) cities with lots of threads so this is nothing new. its been done for freakn years.
just keep believing microsofts story for not supporting multiprocessor systems. unless you want to pay 5 figures for a "Server" hahaha fools Linux supports hyperthreading just fine in my pentium 4 mhaahaaa the latest ntpl threading lib supports starting like 200k threads in like 2 sec on a normal pentium4 and and stopping them. and on anything from a uniproc to a smp i can do syncing in all my progies with futex's. eg drag vol in mixer and watch it simultaneously move in all other programs visually as the programs use a futex to atomically syncronise volume level. or say a file changes size as its being copied and it grows, you can just watch the size below the icon, as it ticks up smoothly. all without needing to poll inefficiently. mwhhaaahaaa windos will be assimilateed
Yes, thank you! Why is this so hard to get right? (Though there was a time they spelled it "ID," as seen in the Wolfenstein 3d logo: http://www.d73online.co.uk/guy/art/wolftitle.gif)
And while we're at it, their name IS NOT pronounced "eye-dee." It rhymes with "kid."
Don't get me started on "gibs."
Definately. One of the first things you realise when you start concurrent programming is that 100% CPU usage is not possible. There are too many other bottlenecks. This really hurts the C/Assembler programmers mind set, but opens up spare cycles for a runtime based language like Java and .Net - although these are terrible languages for game prgramming.
Could this be the age of LISP or Haskel? Everytime I sit down and think about a language that could easily be handled by multicores I start designing LISP. (Those who don't know LISP are doomed to reinvent it). Clearly, the current runtime isn't there, but the language itself probably is - a few OpenGL modules?
Scared of flying, pointy things snce 1979!
do not download.
Revolution was already deemed a failure by the general, big publishing and development companies, which is why it was announced that most of said companies aren't bothering to develop for it. (Search slashdot for that article, I'm too lazy).
Oh good. So Carmack ISN'T the one obsessed with satanism. It's someone else at Id. For a longest time, I figured he sold his soul to be the great coder that he is.
What's so hard about it? I've done threaded Win32 code in C and C++, and multitasking embedded real-time stuff in C. To be brutally honest, if I can do it, it can't be that hard.
There's nothing about C or C++ that makes threading tricky - it's the nature of threading itself that is tricky. It's not possible to predict exactly what order threaded code gets executed in. That can lead to timing bugs that are nearly impossible to reproduce, let alone find and fix. And that's true no matter what language you're using.
"In Ultra quality, we load each texture; diffuse, specular, normal map at full resolution with no compression. In a typical DOOM 3 level, this can hover around a whopping 500MB of texture data. This will run on current hardware but obviously we cannot fit 500MB of texture data onto a 256MB card and the amount of texture data referenced in a give scene per frame ( 60 times a second ) can easily be 50MB+. This can cause some choppiness as a lot of memory bandwidth is being consumed. It does however look fantastic and it is certainly playable on high end systems but due to the hitching that can occur we chose to require a 512MB Video card before setting this automatically.
High quality uses compression ( DXT1,3,5 ) for specular and diffuse and no compression for normal maps. This looks very very close to Ultra quality but the compression does cause some loss."
The other option to keep some armchair graphics guru's obliviously quiet was to just never offer this ultra option, instead just compressing some lighting effects and no one would notice. BUT, because id does put a graphics setting in the options that people can see and it's called, "ultra" they are convinced they are missing something and spew their expert opions on how unreasonable id is.
In response id and companies like them can market themselves better. First, simply don't tell you about the compression of certin aspects of the graphics engine and give you an option that's called Super Ultra Mega Fantastic Quality. The lesson here is don't give more options but give less. Market your target audience with feel good language so they percieve a higher level of satisfaction instead of a percieved underachievement of some graphical utopia they can never quantify anyway.
Me? I'll take more options and disclosure rather than a marketing feel good approach.
it's the same with half life two
it was not a game but a tech demo to intrest other companys to use both their source engine and steam(ing pile of drm spyware crap)
This approach might work for some games, but it's definitely problematic for others. Consider that the accuracy of each AI's decisions about the world around them is going to be proportional to the number of AIs in it, both because the world will be changing more when there are more AIs, and because each AI will get fewer chances to refine_strategy() when there are many of them. That could lead to some truly freaky positive feedback loops in a game like Doom or GTA, where NPCs fight with each other. Everything might be hunky-dory up until a certain AI count threshhold, at which point the NPCs can't target each other accurately anymore. If more NPCs are being generated automatically, you're headed for a meltdown.
And since PCs don't all have equal amounts of CPU horsepower / memory bandwidth / etc, the meltdown threshhold would vary from one system to another. Apparent intelligence of NPCs might also vary with their quantity and with the system's speed. It seems unlikely that any particular game's design would call for such behavior.
It would probably be more efficient, more deterministic, and possibly simpler to debug, to use just N threads, where N is the number of CPU cores available - in modern systems, it would be 1 or 2. Each thread grabs the next unprocessed AI from a list, processes it (calls AICharacter.Think() or whatever), marks the AI as processed, and stores the result in a seprate copy of the world data. Once all AIs are processed, you make the new world data copy the current copy and go on to collision detection or what-have-you. Nothing would be wasted on context switches. The code would work fine on any number of CPU cores, but be faster on more. Only a few pretty trivial deadlocks/race-conditions to worry about.
You track them with your mouse. In order for moving the mouse around to look realistic, you need motion blur.
"Right now games like DOOM3 typically only display a few NPC's at the same time because of the timing problem."
Um, i don't believe that is why Doom3 has so few enemies at a time... The AI isn't that spectacular and companies like Croteam have games with 100s of enemies on screen with just as good AI implemented...
"Strategy games with complicated pathfinding with hundreds of units on-screen like Warcraft 3 or Age of Mythology would profit enormously, if programmed for multithreading."
This I could believe... I often play WC3 on my lan with my kids, we play custom maps like ones where you can churn out units without regard to unit cap or resources...
When the map fills up with units you can actually see the lag in between ordering units and when the cpu gets around to actualy pathing them and moving them... if we had a seperate CPU to do this while the main CPU worked on the mathematics of hit calculations, buffs, armor, etc... then I would expect to see up to 1000 or more units moving in real time in regards to response against given commands...
No problem here, I think the cause of the problem is Linux, install a much superior OS linux Windows and you will not have this problem.
"256 MB RAM is definitely not enough for games with demand for such extreme graphics and realism (did he say physics?)!"
Huh? http://en.wikipedia.org/wiki/Xbox_360#Memory/
"This is considered plagiarism."
It's already available since at least yesterday
The most recent Q3 game source from this page is file "Q3A 1.27g Game Source" and it has been available since 10/21/2002 . And there are no Q3 engine source available yet.
Yesterday? What you call yesterday is still the future for the rest of us. Hey, can't you do me a favor and check the lottery results published on your yesterday's newspaper?
DirectX simply solves a lot of this problem.
Direct3D's DrawPrimative calls, for example, execute asyncronously. They can be handeled by an additional processor. By simply creating a single threaded application, you can take advantage of a second CPU to feed your GPU where the actual rasterizing takes place. You achieve a pretty decent parallelism with little to no added effort.
Similar API tricker can be (or maybe already is) done with DirectSound and the like.
http://brandonbloom.name
I don't pretend to be an expert, but I am coding a simple network game.
The other day, I asked about what is the best way to free up the CPU for other tasks when my main game loop had accomplished everything and had no inputs to wait on until the next game redraw cycle.
The response I had was "if you free up CPU resources for the processor, the scheduler may take it as a sign to devote less resources for the game."
Dunno if its true or not, but if it is, perhaps that's part of the reason why games don't yield to other processes.
>Revolution was already deemed a failure by the general, big publishing and development companies, which is why it was announced that most of said companies aren't bothering to develop for it.
Good. That means that only good companies will bring out games on the Revolution.
I don't want general, big-company-made games. They're all graphics, effects, gore and sex without any substance, playability, storyline, content and pure gaming fun.
One of the problems with graphics is that there is no proper lighting/shading. Doom 3 makes an effort to present a good lighting result, but all other games miserably fail. No matter how realistic the physics are, it is the actual casting of shadows that determines the perceived realism of a 3d scene.
MDK2 did this, around 1998 or so. It seemed to have an impact on level design, though - the loading always happened in the middle of a longish winding tunnel, from which the player could not see either the area he was leaving or the new area he was approaching.
That was clever, but obviously it's got implications. It's necessary (through plot contriavance, level design contriavance, or otherwise) to ensure that the player couldn't outrun the loading, for example. In an FPS type game, that could put a sort of speed limit on the player, which could cramp the style of the level developers or mod developers. You can see why that sort of thing might be a deal-breaker for something like HL2.
LISP is already being used for videogames on the ps2 very successfully, in very well written, fun games:
Naughty Dog and LISP
--jeff++
ipv6 is my vpn
It's just a matter of the right design. For example:
1. A dynamic array of all active objects in the game.
2. An object processor class that gets object pointers from the list in a critical section (i.e. locked) state, then unlocks and processes.
Using this system, what happens is you spawn multiple threads that run object processors. Each processor locks access to the queue when it goes to get a pointer, grabs the next object on the list, and updates the index to the position in queue, then releases the lock and goes and does its thing. This way, no two threads grab the same object at the same time for processing.
Now, how about multiple kinds of processes i.e. Input, AI, Physics, Rendering?
Not a problem as long as you maintain the objects in an "always valid" state. I.e. you do collision detection after move but before returning the object. They don't even have to run at the same frequency, your AI can run at 10hz while your renderer runs at 60hz.
So, you spawn an input processor that delivers inputs to the objects. Your player and master AI both feed this process with targeted commands that are delivered to the objects in the same way. Your move processor handles movement and collision detection or flags objects for another processor. Your physics does the same, your renderer also does the same, etc. As long as you're doing a full traverse of the game world, and nothing is left in an invalid state, everything should be fine. You only need to perform locking for processors of the same type, ex: if a move processor has a locked object, the renderer doesn't care, it can read the current state and draw it before the copy is modified on return. As long as the previous state when the move thread took the pointer was valid, it should be fine. A bit complicated, but doable.
Here's the fun part: It's asynchronous. Spawn 2 threads on the CPU and 1 on the GPU. Asymmetric multiprocessing. Think it'll screw things up? Order of return doesn't matter here, it's first come first serve, so if the GPU thread is 4x faster, it can just grab objects 4x as often. As long as your algorithms return identical results it doesn't matter who does the job.
Of course in a game, not all objects update all the time. If you were using a physics driven system, what you'd want to do is have a vector queue instead. Then grab the kinetic vectors and apply them to the respective objects, check for collision and if so update the existing vectors and then spawn new vector objects into the queue as motion transfers. Cull out vectors below a certain magnitude as "residual noise". Put in friction and the system will keep itself manageable by dropping vectors as they become less significant.
I can't wait to build a physics engine running on this design, but I'm still developing my skills for a project of that magnitude.
Introducing the new Occam Fusion! Now with sqrt(-1) fewer blades!
http://games.slashdot.org/article.pl?sid=05/08/11/ 2019242&from=rss
Have a look there, lots of nice motion blur.
Introducing the new Occam Fusion! Now with sqrt(-1) fewer blades!
So is Carmack using some OpenGL driver on the XBox360, or has he finally been bought out by the Direct3D crowd?
If the latter, then we've lost one of the last true cross-platform 3D game developers.
"Nine times out of ten, starting a fire is not the best way to solve the problem." - my wife
The language Erlang is designed in such a way, with such built in rules that it prevents the most bugs from happening at all when you're programming concurrently.
Haskell has excellent potential to be extended with features that will give it concurrent processing bug prevention characteristics. I think there was a fork of Haskell that has a semi-commercial / GPL license called Concurrent Clean which claims to have that extension.
The new star on the firmament that's a candidate for language of the future is the Mozart programming system that is built on the language Oz and also consists of a book with what seems to be insightful stuff about concurrent programming in combination with other types of program construction. Haven't read or used it yet though.
- -- Truth addict for life.