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."
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.
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.
Finally, proof that Apple is over priced, under powered hardware. Why does Carmack hate Apple so much? ...
BTW, if Apple loved PPC so much, why did they announce the switch to Pentium M ? :)
He said that Apple *is* over priced, under powered hardware, which is true. He didn't say it will stay that way forever.
839*929
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.
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.
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.
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.
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...
dunno. doom was one excellent game and quake was fun online.
world was created 5 seconds before this post as it is.
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.
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.