Greed was built on the engine I wrote for Raven/Origin's Shadowcaster game, while the other Id guys were working on Spear of Destiny, the commercial Wolfenstein game.
The reason softdisk got the technology was that they were still making lots of noise about suing us for doing Keen while we were working at softdisk. Our original parting deal was that we were going to continue doing the Gamer's Edge games for a while, basically for free, as penance. We weren't savvy enough to get anything binding down on paper, so even when it was all wrapped up, there was room for twisting our arm a bit. (another trivia bit -- George Broussard at Apogee arranged to have Apogee produce one of the Gamer's Edge titles for us, so we could focus more on Wolfenstein).
We finally arranged a technology transfer of the latest engine code for free and clear severing of our ties. After they showed that just having the technology was not a guarantee of success, they had the nerve to come back and ask for more, but by then we were able to just tell them to go away.
BTW, Duke Nukem does not have a Softdisk heritage, it was by Todd Replogle (sp?), who was strictly Apogee-grown.
AFAIK (we met at Space Access this year), Brian is not interested in advanced engine work. For his goals, simple monoprop peroxide is far and away the most direct route.
For reference, while the theoretical Isp is usually listed around 155, we typically only see 115 or so at sea level with less than 300 psi chamber pressure.
> hybrid (ie, plastic/nitrous oxide) propellants?
Peroxide makes a pretty good hybrid oxidizer, with better Isp and density-Isp than nitrous based hybrids, plus it auto-ignites after decomposition. Vec Isp may be as high as 275 with 90% peroxide, but sea level will be down around 200-225, depending on chamber pressures. We fired a couple peroxide / polyethylene hybrid grains last year, but we haven't pursued it much.
There is a very tantalizing possibility of using aluminum hydride as a hybrid graid with peroxide, giving a theoretical vacuum Isp of over 400 (!!!), and it is non-toxic. We are probably going to look into this one of these days.
> buckyballs
Not much use. Buckytube composites may make for very mass efficient tanks and structures in the not too distant future.
> multi-atomic nitrogen
If it can ever be produced affordably, a 600 Isp monoprop would sure be nice. Easy to go boom, though.
> fluorine
Ick. Very toxic, very corrosive. Flourine / lithium hybrids can get over 500 Isp, but it would be very dangerous.
I feel that the best way to take advantage of exotic developments is to build a fully functional vehicle with conventional materials, so if a wonder material / propellent does materialize, you are well poised to take advantage of it.
There are some colorful comments here about how studios will never-ever-ever replace tools like renderman on render farms with hardware accelerated rendering. These comments are wrong.
The current generation of cards do not have the necessary flexibility, but cards released before the end of the year will be able to do floating point calculations, which is the last gating factor. Peercy's (IMHO seminal) paper showed that given dependent texture reads and floating point pixels, you can implement renderman shaders on real time rendering hardware by decomposing it into lots of passes. It may take hundreds of rendering passes in some cases, meaning that it won't be real time, but it can be done, and will be vastly faster than doing it all in software. It doesn't get you absolutely every last picky detail, but most users will take a couple orders of magnitude improvement in price performance and cycle time over getting to specify, say, the exact filter kernel jitter points.
There will always be some market for the finest possible rendering, using ray tracing, global illumination, etc in a software renderer. This is analogous to the remaining market for vector supercomputers. For some applications, it is still the right thing if you can afford it. The bulk of the frames will migrate to the cheaper platforms.
Note that this doesn't mean that technical directors at the film studios will have to learn a new language -- there will be translators that will go from existing langauges. Instead of sending their RIB code to the renderfarm, you will send it to a program that decomposes it for hardware acceleration. They will return image files just like everyone is used to.
Multi chip and multi card solutions are also coming, meaning that you will be able to fit more frame rendering power in a single tower case than Pixar's entire rendering farm. Next year.
I had originally estimated that it would take a few years for the tools to mature to the point that they would actually be used in production work, but some companies have done some very smart things, and I expect that production frames will be rendered on PC graphics cards before the end of next year. It will be for TV first, but it will show up in film eventually.
We know for sure that we will be excluding some of the game buying public with fairly stiff hardware requirements, but we still think it is the right thing to do.
The requirement for GF1/Radeon 7500 as an absolute minimum is fundamental to the way the technology works, and was non-negotiable for the advances that I wanted to make. At the very beginning of development, I worked a bit on elaborate schemes to try and get some level of compatibility with Voodoo / TNT / Rage128 class hardware, but it would have looked like crap, and I decided it wasn't worth it.
The comfortable minimum performance level on this class of hardware is determined by what the artists and level designers produce. It would be possible to carefully craft a DOOM engine game that ran at good speed on an original SDR GF1, but it would cramp the artistic freedom of the designers a lot as they worried more about performance than aesthetics and gameplay.
Our "full impact" platform from the beginning has been targeted at GF3/Xbox level hardware. Slower hardware can disable features, and faster hardware gets higher frame rates and rendering quality. Even at this target, designers need to be more cognizant of performance than they were with Q3, and we expect some licensee to take an even more aggressive performance stance for games shipping in following years.
Games using the new engine will be on shelves FIVEYEARS (or more) after the initial design decisions were made. We had a couple licensees make two generations of products with the Q3 engine, and we expect that to hold true for DOOM as well. The hardware-only decision for Q3 was controversial at the time, but I feel it clearly turned out to be correct. I am confident the target for DOOM will also be seen as correct once there is a little perspective on it.
Unrelated linux note: yes, there will almost certainly be a linux binary for the game. It will probably only work on the nvidia drivers initially, but I will assist any project attempting to get the necessary driver support on on other cards.
This batch of comments from me have let people draw conclusions that leave me scratching me head wondering how they managed to get from what I said to what they heard.
Other people have outlined the issues in detail in comments already, but the crux is that, even with driver quality removed from the discussion (not counting conformance issues, running at fill limited resolutions), GF4 hardware is still faster than 8500 hardware on basically everything I tested. The 8500 SHOULD have been faster on paper, but isn't in real life.
The hardware we used at E3 was not an 8500, and while the drivers were still a bit raw, the performance was very good indeed.
Take with a grain of salt any comment from me that has been paraphrased, but if it is an actual in-context quote from email, I try very hard to be precise in my statements. Read carefully.
>Anyone know if any of these milestones were achieved? >Or if not, what armadillo's latest estimates are for the same things?
The estimate from day one was:
Year one: VTVL demonstrator Year two: manned rocket ships Year three: space shots
The VTVL demonstrator went faster than expected, and it looked like we were going to lift a person off the ground before the end of the first year. We had a couple crashes and redesigns that set us back a bit, and we were forced to make a major change in our catalyst packs to allow us to get enough back-to-back flights without changes before putting a person on it, so we haven't yet made that "milestone bunny hop".
However, while we were waiting for some things along that development path, we wound up developing some other technologies that weren't even in the original plan -- our recent work on biprop engines wasn't really scheduled until year three or later, and the rocket rotor work is looking like it will allow some big improvements in our upcoming designs.
The current goal of record is to set some of the manned aviation 3000 meter time-to-climb records before the end of this year.
He came to Space Access to meet with us, and it was interesting talking with him. He is certainly not an engineer, but he is actually building a lot of hardware, which is more than can be said for most folks in the space crowd.
The abject stupidities in his original design that got him a lot of flack (Fins at the top! 1.2 T/W ratio without guidance!) are now gone, and he has decided to have a testing plan before launching himself, so I think he has a decent shot at flying something and living to talk about it. I wish him luck.
An interesting question: is it easier to motivate a learned individual that never does anything, or educate an ignorant individual that actually produces things?
>Are you now using an inertial guidance system or is there a better alternative? >I assume that GPS does not provide enough accuracy for low speed guidance
We are currently using a Crossbow inertial unit with fiber optic gyros for the fast attitude stabilization.
We have flown GPS on a couple flights, but the update rate is too slow for active control. I do feel that in the longer term, carrier wave interferometry GPS sensors will offer the most cost effective attitude sensors, but right now they are $15,000+ system. If I was doing this on a much tighter budget, I would consider trying to build a fast updating CW GPS system from available cheap GPS cores, but that is a project of significant complexity all by itself.
I have integrated a new laser altimeter with the electronics box, but we haven't flown it yet. I am looking forward to this, because it will allow us to begin working on auto-hover and auto-land control software.
I am going to have to save the parent post, because it is such a perfect example of the mindset that has made progress in aerospace so damn slow. I couldn't have said it better if I was trying to intentionally construct the stereotype. This ties directly in to the quote I had in the article -- "rocket science" has been mythologized out of all proportion to its true difficulty.
First, you are severely understating the achievements of the Wright brothers. They had to invent almost everything from scratch, including much of the theory, and there was no existence proof to show that it was possible at all. I'm really not an aviation buff, so I'm sure someone else can recount the challenges better, but it is worth noting that at the time the Wrights did their work, there was also a high profile, government funded effort underway headed by Samuel Langley. With the "best minds in the country" and government resources behind it, they still didn't make the breakthroughs.
I contend that building and flying an X-Prize class vehicle (100 km suborbital, three passengers, reusable) today is a much less daunting task than the original invention of the airplane.
We have existence proofs of what is being attempted. There is no question that it is possible, because it has been demonstrated in many different forms. The only question is how cheap it can be done.
There is a massive amount of information available. Today, anyone can go read up on things that NOBODY knew back when they were building the early rocket systems.
Obviously, computers and electronics are vastly better. Our current electronics box has all the necessary sensors and actuators for flying a spaceship, and it cost less than $15,000 to put together (yes, it runs linux).
It isn't as blatant, but other manufacturing areas have also made great progress. I had a batch of a dozen small motors made at a CNC job shop for only $1000. Even counting everything that goes into them, the total cost including valve is less than $300 each. These may well be better than the peroxide thrusters used on the Mercury capsules. It was amusing to hear the NASA pad manager tell stories about having to go bang on the Mercury thrusters with a wrench to get them to stop sputtering. Don't think that all NASA hardware performs as designed.
Pressure vessels are significantly improved. A common all-carbon-fiber tank for natural gas vehicles has a better compressed volume to mass ratio than anything that could be built in the sixties. Filament winding can make large structures that are both stronger and cheaper than the classic welded structures.
There are direct spinoffs from government rocketry development. To drill the tiny, high aspect cooling passages for the Agena upper stage engine, they had to invent brand new machining technologies. Today, you can get the same techniques done at standard industrial job shops. As far as expensive materials go, the Agena engine was made out of aluminum.
The general industrial infrastructure is also a heck of a lot better. I can order damn near anything I need for our work from McMaster-Carr at 4:00 in the morning, and it shows up two days later.
NASA spent $50 million to set up the tracking and telemetry networks for Mercury. You can get far, far better results today with a GPS and satellite modem. There are billions of dollars of space based assets already at our disposal.
I could go on for quite a while on why we would have an easier time today just replicating the efforts of the past, but that is only part of the issue. What we are aiming for in the near term is far smaller in scope than any of the projects that the public normally associates with space. Even with all the advantages of today, it would be absurd to think that we could put together a space shuttle or a Saturn V. I hesitate to make analogies, but we are effectively working on building little microprocessors instead of big mainframes. 100 km straight up and down (that gives a 5G reentry, which, while not for your grandmother, doesn't take a superhero) is just not all that hard.
Yes, there are lots of challenges to be met, and we will doubtless run into all sorts of things that we haven't even considered. We will solve them as we go. People do hard things all the time, in many different fields. The reason "rocket science" looks so much harder is just lack of familiarity.
Because the existing way of doing things in space costs tens to hundreds of millions of dollars a shot, there just isn't an opportunity for radical experimentation. The optimization problem is slowly trending towards a stable local minimum, with little chance of getting out to the global minimum. Imagine trying to develop software if you only got to compile and run your app four times a year. Imagine how much that would slow down progress, and what contortions you would go through if $100 million was riding on each run.
Build fast. Test often. Stay flexible. Mind the critical path.
"Mr. Carmack also plays computer games in the office with his coworkers"
I played Q3 quite a bit, but not much since then. The team focus of TeamArena and Wolfenstein just isn't my favorite type of game.
"Polygon counts"
The Doom engine is not an ultra-high poly count engine, because it is built around dynamic lighting and shadowing, but it is still a large step up from our previous games. Typical scenes will have around 150,000 polygons, versus 10,000 for Q3. There will certainly be other games with higher raw polygon counts, but that is really focusing on the trees, not the forest (image quality). The large numbers that have occasionally been tossed around are the polygon counts for the high detail characters that are used in the generation of normal maps for the real time rendering. Some characters are over 500,000 polygons in their original form.
"It looks like the type of game that is so thrilling to play that gamers will do so over and over again, even though it lacks a narrative plot."
Unlike everything we have done before, the new Doom actually DOES have a real plot, and I think it is going to be presented well. I don't really expect most people to believe us at this point, but wait and see...
"The new Doom likely will require a no less powerful chip than the soon-to-be-released Nvidia GeForce3"
It is designed for full impact on a GeForce-3, but it still runs on a GeForce-1 or Radeon.
They didn't reproduce the graph of our revenues from the print version, but that was also way off base. I guess they estimated them based on our title sales, but while Doom II remains our best selling title, we have much better royalty arrangements now than we did back then, so we make more money today.
Probably everyone reading this has done some "game design" while talking with friends. In an evening, you can lay out the basic character of a game -- what the player does, what the environments are like, what the obstacles are, what the tools in the game are like, what the plot is, what the style of the game is, and a few unique hooks for the game.
There is not a hell of a lot of difference between what the best designer in the world produces, and what a quite a few reasonably clued in players would produce at this point. This is the "abstract creativity" aspect. This part just isn't all that valuable. Not worthless, but it isn't the thing to wrap a company around.
The real value in design is the give and take during implementation and testing. It isn't the couple dozen decisions made at the start, it is the thousands of little decisions made as the product is being brought to life, and constantly modified as things evolve around it. If you took two game designs, one good and one bad, and gave them to two development teams, one good and one bad, the good dev team could make a good, fun product out of a bad design, but the bad dev team could ruin the most clever design. The focus should be on the development process, not the (initial) design.
The games with 500 page design documents before any implementation are also kidding themselves, because you can't make all the detail decisions without actually experiencing a lot of the interactions.
Putting creativity on a pedestal can also be an excuse for laziness. There is a lot of cultural belief that creativity comes from inspiration, and can't be rushed. Not true. Inspiration is just your subconscious putting things together, and that can be made into an active process with a little introspection.
Focused, hard work is the real key to success. Keep your eyes on the goal, and just keep taking the next step towards completing it. If you aren't sure which way to do something, do it both ways and see which works better.
>But with great success came great antipathy, not just for John, but also for many of his
>employees.
The employees did sort of get a raw deal by association, but to ascribe all of the antipathy towards Romero to jealousy is really missing the point.
>Daikatana and Deus Ex were finally released in 2000. Predictably, Daikatana was slammed while
>Deus Ex received many awards. Both made money for Eidos
Deus Ex made money. Daikatana lost an immense amount of money. We followed the PC-Data sales numbers for a little while, and it was really, really grim. It might have made a comback when it went to the bargain bin, but even if it had turned into the best selling game of the year, it wouldn't have covered the sunk costs at Ion.
My view:
Ion storm failued due to lack of focus, which came from the top. They had some great employees (we hired some of them!), but games don't get done without someone in a position of authority forcing everything together. Romero's primary mistake was believing that abstract creative design was a primary, or even significant, part of a successful game. The "strategic creativity" in a game is less than 1% of the effort, and if you put that on a pedestal, you will deephasise where all the real work needs to be done.
I think Romero has a chance at a comeback with his current foray into handheld games. I don't think he ever lost the enthusiasm for games, but if he can recapture the personal work ethic that he had early on, he can probably still do some pretty cool things.
>Cutting edge graphics, where did you go? Please tell me there's more to the 3D world than IR,
>WildCat II, and GeForce3. Has *nothing* (other than cost) really changed over the past five
>years? It's almost as though I haven't missed anything in the 28 months I've been away from 3D
Dependent texture reads are the only really new thing in the last year or two (and only really got worked out right in the Radeon 8500), but next year is going to see floating point pixel formats, which was going to be one of Bali's truly important points. We should also see highly scalable boards built on consumer chips, which has been promised for years, but (with the exception of some 3dfx high end systems) not delivered properly.
Thanks for the kind comments, it helps me brace a bit for some of the really vile hate mail that is already starting to come in from the people worried about cheating.
Bill Heineman is preparing the mac source code for Q2 for a release.
We will see about getting the 3.21 changes we missed into an updated release.
I am also happy to say that another old game's code will be released under the GPL soon. We can always hope that it becomes a trend...
One of the suppliers to Armadillo Aerospace told me about an experiment that he tried. He was looking over the logs to his (very low traffic) site, and he wondered how an anonymized hit would show up in the logs. He went through Safeweb, and saw a properly obscured address in the logs.
One hour later, he also got a hit to the same page from cia.gov.
I'm sure this isn't standard practice for every access, but his site was probably on a hot list of some sort due to the aerospace content.
The rockets we are currently firing use hydrogen peroxide, which produces nothing but water and oxygen in the exhaust. Not even the most rabid greenie could argue with that.
Hydrogen / oxygen rockets also produce water and excess hydrogen. Alcohol / ocygen rockets leave a few other things similar to auto exhaust, but not really worse.
Solid rockets leave some bad stuff, and some propellants are truly nasty, like nitrogen tetroxide and hydrazine, but those are also much more expensive, so wouldn't be used in a cost effective program.
> I think it's only been established that Id didn't do well with the Linux gaming market
All linux games sales EVER don't add up to one medium selling windows title. We are one of the creditors that aren't likely to see money that Loki owes us, so we have some idea just how grim it is.
That isn't saying that it can't change in the future, or that doing linux ports isn't a Good Thing, but it isn't an economic motivator at the present time.
I'm still developing everything with OpenGL, and I'm still targeting mac and linux as well as windows, but I want to rationally address some points in the API debate:
D3D is clunky, etc
Not really true anymore. MS made large strides with each release, and DX8 can't be called a lousy API anymore. One can argue various points, but they are minor points. Anti-Microsoft forces have a bad habit of focusing on early problems, and not tracking the improvements that have been made in current versions. My rant of five years ago doesn't apply to the world of today.
I do think that the world would be a slightly better place if Microsoft had pulled an embrace-and-extend on OpenGL instead of developing a brand new API that had to be rewritten a half dozen times, but its water under the bridge now.
Open for more sales, etc
It has been pretty clearly demonstrated that the mac market is barely viable and the linux market is not viable for game developers to pursue. Linux ports will be done out of good will, not profit motives. From an economic standpoint, a developer is not making a bad call if they ignore the existence of all platforms but windows.
DX8 Gives more features
Some people have an odd view that an API gives you features. Assuming you don't care about software emulation, hardware gives you features, and an API exposes them. If you try to use vertex programs or bump env map on a TNT, DX8 doesn't magically make it work. DX8's hardware independence is also looking a bit silly now as they make point releases to support ATI's new hardware. They might as well say D3D-GF3 or D3D-R200 instead of DX8 and DX8.1.
All of Nvidia's new features have showed up as OpenGL extensions before they show up as new D3D features.
Divergent extensions haven't been a problem up until very recently. All of the vendors tended to support all the extensions they could, and if they had unique functionality, like register combiners, they made their own extension. The current status of vertex programs does piss me off, though. I really wish ATI would have just adopted Nvidia's extension, even if it meant not exposing every last bit of their hardware.
Abstraction in a high performance environment can be dangerous. If you insist that all hardware behave the same, you prevent vendors from making significant improvements. If the spec for behavior comes from people that aren't hardware oriented, it can be a huge burden. D3D still suffers somewhat due to this, with some semantics and odd features that make hardware guys wince.
The Good News
We are rapidly approaching a real golden age for graphics programming. Currently, cards and API's are a complex mess of hundreds of states and function calls, but the next two years will see the addition of the final primitive functionality needed to allow arbitrarily complex operations with graceful performance degradation.
At that point, a higher level graphics API will finally make good sense. There is debate over exactly what it is going to look like, but the model will be like C. Just like any CPU can compile any C program (with various levels of efficiency), any graphics card past this point will be able to run any shader. Some hardware vendors are a bit concerned about this, because bullet point features that you have that the other guy doesn't are a major marketing feature, but the direction is a technical inevitability. They will just have to compete on price and performance. Oh, darn.
It's a Turing machine point. Even if OpenGL 2.0 and DX10 don't adopt the same shader description language, they will be functionally equivalent, and could be automatically translated.
There is lots of other goop like texture specification and context management that will still be different between API, but the core day-to-day work of a graphics programmer will be basically above the disputes.
We were surprised at Wolf3D mods, but we knew it was going to happen with DOOM. I worked with some of the Wolf3D map editor guys before DOOM was even released, but they didn't wind up making the popular level editors.
The editor and utility source code was released quite early, but it was all for NeXT workstations in Objective-C, so it had to wait for someone to rewrite it for more conventional systems.
>It (DOOM) was designed by talented people with good skills and academic degrees in
>computer science.
None of us had degrees in computer science. Romero, Adrian, and I don't have any degrees at all, and Kevin's is in political science.
>It even had a simple but multithreaded "operating system" of its own to handle asynchronous
>updates of graphics and playing sound while performing the game simulation.
No. We made the startup sequence busy and techie in a sort of imitation of the NeXT workstations we were using at the time, but there was no multithreading going on. The sound was done with interrupt driven processing, which doesn't qualify.
With the source code open for years, this should have been easy to check.
>a resolution of only 320x240
320x200
I would take issue with some of the other vague statements made later on, but they aren't pointed enough to debate.
Taking things one step at a time is critical for success.
We have a pretty clear plan of attack to take us to X-Prize level vehicles. There will be several intermediate vehicles to learn from along the way, but I am pretty confident that we can do it, and that I can pay for it. The regulatory approval is still uncertain. Things get much more questionable after that.
The next step would be using the X-Prize vehicle as a booster for a upper stage(s) that launch a microsat into orbit. That requires many times for dV, and the regulatory environment, telemetry, and logistics become a lot more challenging. This would get fairly expensive, because making a reusable upper stage(s) is a whole new level of problem, and you just can't test a lot of the systems without going all the way. Even on a shoestring, it could easily get to $100k for each attempt, after you factor everything in. Realistically, it will take a lot of attempts to learn everything you need to know. A lot of people will talk about how straightforward it is, but I have a healthy respect for the challenges. Smart money probably wouldn't bet on any "garage shop" getting to orbit, but it certainly isn't impossible.
After that, you could either work towards reusable upper stages, or scale everything up to the point you could try to orbit a passenger or a semi-useful LEO satellite.
Sure, if all that works out, I would love to make a moon shot, but that qualifies as day-dreaming, not planning. The idea that Dennis Wingo has floated recently about M class asteroids rich in platinum group metals possibly being able to have survived impact on the moon without vaporizing under some conditions is Very Very Interesting.
The extent of my "business planning" for the rockets is along the lines of "If you actually make something really, really cool, you will wind up making money on it somehow". Hopelessly naive? Possibly. We'll see. I hate being involved in business, so we would probably just partner with some of the existing companies interested in suborbital rides or sounding rocket business.
In the short term, watch for us getting a man off the ground in the upscaled lander frame within a couple months.
On topic: I think pretty highly of the DaVinci project, and I would say they are definitely one of the leading contenders. Brian Feeney talks about some technical issues on open mailing lists, which is a good sign. My biggest concern for them would be that, from my experience with JP Aerospace, getting two successful rockoon launches off within the 14 days required by the X-Prize is going to involve a good sized helping of luck.
The standard lighting model in DOOM, with all features enabled, but no custom shaders, takes five passes on a GF1/2 or Radeon, either two or three passes on a GF3, and should be possible in a clear + single pass on ATI's new part.
It is still unclear how the total performance picture will look.
Lots of pixels are still rendered with no textures at all (stencil shadows), or only a single texture (blended effects), so the pass advantage will only show up on some subset of all the drawing.
If ATI doesn't do as good of a job with the memory interface, or doesn't get the clock rate up as high as NVidia, they will still lose.
The pixel operations are a step more flexible than Nvidia's current options, but it is still clearly not where things are going to be going soon in terms of generality.
Developers are just going to need to sweat out the diversity or go for a least common denominator for the next couple years.
I fully expect the next generation engine after the current DOOM engine will be targeted at the properly general purpose graphics processors that I have been pushing towards over the last several years.
Hardware vendors are sort of reticent to give up being able to "out feature" the opposition, but the arguments for the final flexibility steps are too strong to ignore.
>Then we get NASA and the US Government refusing
>to allow private launches so that people have to
>go off-shore to launch to try to claim the X
>Prize!!!
Actually, it's worse than that.
The US government (NASA doesn't have anything to do with it) claims authority over all actions of its citizens, even when they aren't inside national boundaries.
If you launched an X-Prize vehicle from another country or from international waters without getting FAA/AST clearance, you are still in trouble (and wouldn't be eligable for the prize).
Slashdot Mirror
Here is an interesting bit of history:
Greed was built on the engine I wrote for Raven/Origin's Shadowcaster game, while the other Id guys were working on Spear of Destiny, the commercial Wolfenstein game.
The reason softdisk got the technology was that they were still making lots of noise about suing us for doing Keen while we were working at softdisk. Our original parting deal was that we were going to continue doing the Gamer's Edge games for a while, basically for free, as penance. We weren't savvy enough to get anything binding down on paper, so even when it was all wrapped up, there was room for twisting our arm a bit. (another trivia bit -- George Broussard at Apogee arranged to have Apogee produce one of the Gamer's Edge titles for us, so we could focus more on Wolfenstein).
We finally arranged a technology transfer of the latest engine code for free and clear severing of our ties. After they showed that just having the technology was not a guarantee of success, they had the nerve to come back and ask for more, but by then we were able to just tell them to go away.
BTW, Duke Nukem does not have a Softdisk heritage, it was by Todd Replogle (sp?), who was strictly Apogee-grown.
John Carmack
AFAIK (we met at Space Access this year), Brian is not interested in advanced engine work. For his goals, simple monoprop peroxide is far and away the most direct route.
For reference, while the theoretical Isp is usually listed around 155, we typically only see 115 or so at sea level with less than 300 psi chamber pressure.
> hybrid (ie, plastic/nitrous oxide) propellants?
Peroxide makes a pretty good hybrid oxidizer, with better Isp and density-Isp than nitrous based hybrids, plus it auto-ignites after decomposition. Vec Isp may be as high as 275 with 90% peroxide, but sea level will be down around 200-225, depending on chamber pressures. We fired a couple peroxide / polyethylene hybrid grains last year, but we haven't pursued it much.
There is a very tantalizing possibility of using aluminum hydride as a hybrid graid with peroxide, giving a theoretical vacuum Isp of over 400 (!!!), and it is non-toxic. We are probably going to look into this one of these days.
> buckyballs
Not much use. Buckytube composites may make for very mass efficient tanks and structures in the not too distant future.
> multi-atomic nitrogen
If it can ever be produced affordably, a 600 Isp monoprop would sure be nice. Easy to go boom, though.
> fluorine
Ick. Very toxic, very corrosive. Flourine / lithium hybrids can get over 500 Isp, but it would be very dangerous.
I feel that the best way to take advantage of exotic developments is to build a fully functional vehicle with conventional materials, so if a wonder material / propellent does materialize, you are well poised to take advantage of it.
John Carmack
There are some colorful comments here about how studios will never-ever-ever replace tools like renderman on render farms with hardware accelerated rendering. These comments are wrong.
The current generation of cards do not have the necessary flexibility, but cards released before the end of the year will be able to do floating point calculations, which is the last gating factor. Peercy's (IMHO seminal) paper showed that given dependent texture reads and floating point pixels, you can implement renderman shaders on real time rendering hardware by decomposing it into lots of passes. It may take hundreds of rendering passes in some cases, meaning that it won't be real time, but it can be done, and will be vastly faster than doing it all in software. It doesn't get you absolutely every last picky detail, but most users will take a couple orders of magnitude improvement in price performance and cycle time over getting to specify, say, the exact filter kernel jitter points.
There will always be some market for the finest possible rendering, using ray tracing, global illumination, etc in a software renderer. This is analogous to the remaining market for vector supercomputers. For some applications, it is still the right thing if you can afford it. The bulk of the frames will migrate to the cheaper platforms.
Note that this doesn't mean that technical directors at the film studios will have to learn a new language -- there will be translators that will go from existing langauges. Instead of sending their RIB code to the renderfarm, you will send it to a program that decomposes it for hardware acceleration. They will return image files just like everyone is used to.
Multi chip and multi card solutions are also coming, meaning that you will be able to fit more frame rendering power in a single tower case than Pixar's entire rendering farm. Next year.
I had originally estimated that it would take a few years for the tools to mature to the point that they would actually be used in production work, but some companies have done some very smart things, and I expect that production frames will be rendered on PC graphics cards before the end of next year. It will be for TV first, but it will show up in film eventually.
John Carmack
We know for sure that we will be excluding some of the game buying public with fairly stiff hardware requirements, but we still think it is the right thing to do.
The requirement for GF1/Radeon 7500 as an absolute minimum is fundamental to the way the technology works, and was non-negotiable for the advances that I wanted to make. At the very beginning of development, I worked a bit on elaborate schemes to try and get some level of compatibility with Voodoo / TNT / Rage128 class hardware, but it would have looked like crap, and I decided it wasn't worth it.
The comfortable minimum performance level on this class of hardware is determined by what the artists and level designers produce. It would be possible to carefully craft a DOOM engine game that ran at good speed on an original SDR GF1, but it would cramp the artistic freedom of the designers a lot as they worried more about performance than aesthetics and gameplay.
Our "full impact" platform from the beginning has been targeted at GF3/Xbox level hardware. Slower hardware can disable features, and faster hardware gets higher frame rates and rendering quality. Even at this target, designers need to be more cognizant of performance than they were with Q3, and we expect some licensee to take an even more aggressive performance stance for games shipping in following years.
Games using the new engine will be on shelves FIVEYEARS (or more) after the initial design decisions were made. We had a couple licensees make two generations of products with the Q3 engine, and we expect that to hold true for DOOM as well. The hardware-only decision for Q3 was controversial at the time, but I feel it clearly turned out to be correct. I am confident the target for DOOM will also be seen as correct once there is a little perspective on it.
Unrelated linux note: yes, there will almost certainly be a linux binary for the game. It will probably only work on the nvidia drivers initially, but I will assist any project attempting to get the necessary driver support on on other cards.
John Carmack
This batch of comments from me have let people draw conclusions that leave me scratching me head wondering how they managed to get from what I said to what they heard.
Other people have outlined the issues in detail in comments already, but the crux is that, even with driver quality removed from the discussion (not counting conformance issues, running at fill limited resolutions), GF4 hardware is still faster than 8500 hardware on basically everything I tested. The 8500 SHOULD have been faster on paper, but isn't in real life.
The hardware we used at E3 was not an 8500, and while the drivers were still a bit raw, the performance was very good indeed.
Take with a grain of salt any comment from me that has been paraphrased, but if it is an actual in-context quote from email, I try very hard to be precise in my statements. Read carefully.
John Carmack
>Anyone know if any of these milestones were achieved?
>Or if not, what armadillo's latest estimates are for the same things?
The estimate from day one was:
Year one: VTVL demonstrator
Year two: manned rocket ships
Year three: space shots
The VTVL demonstrator went faster than expected, and it looked like we were going to lift a person off the ground before the end of the first year. We had a couple crashes and redesigns that set us back a bit, and we were forced to make a major change in our catalyst packs to allow us to get enough back-to-back flights without changes before putting a person on it, so we haven't yet made that "milestone bunny hop".
However, while we were waiting for some things along that development path, we wound up developing some other technologies that weren't even in the original plan -- our recent work on biprop engines wasn't really scheduled until year three or later, and the rocket rotor work is looking like it will allow some big improvements in our upcoming designs.
The current goal of record is to set some of the manned aviation 3000 meter time-to-climb records before the end of this year.
John Carmack
He came to Space Access to meet with us, and it was interesting talking with him. He is certainly not an engineer, but he is actually building a lot of hardware, which is more than can be said for most folks in the space crowd.
The abject stupidities in his original design that got him a lot of flack (Fins at the top! 1.2 T/W ratio without guidance!) are now gone, and he has decided to have a testing plan before launching himself, so I think he has a decent shot at flying something and living to talk about it. I wish him luck.
An interesting question: is it easier to motivate a learned individual that never does anything, or educate an ignorant individual that actually produces things?
John Carmack
>Are you now using an inertial guidance system or is there a better alternative?
>I assume that GPS does not provide enough accuracy for low speed guidance
We are currently using a Crossbow inertial unit with fiber optic gyros for the fast attitude stabilization.
We have flown GPS on a couple flights, but the update rate is too slow for active control. I do feel that in the longer term, carrier wave interferometry GPS sensors will offer the most cost effective attitude sensors, but right now they are $15,000+ system. If I was doing this on a much tighter budget, I would consider trying to build a fast updating CW GPS system from available cheap GPS cores, but that is a project of significant complexity all by itself.
I have integrated a new laser altimeter with the electronics box, but we haven't flown it yet. I am looking forward to this, because it will allow us to begin working on auto-hover and auto-land control software.
John Carmack
I am going to have to save the parent post, because it is such a perfect example of the mindset that has made progress in aerospace so damn slow. I couldn't have said it better if I was trying to intentionally construct the stereotype. This ties directly in to the quote I had in the article -- "rocket science" has been mythologized out of all proportion to its true difficulty.
First, you are severely understating the achievements of the Wright brothers. They had to invent almost everything from scratch, including much of the theory, and there was no existence proof to show that it was possible at all. I'm really not an aviation buff, so I'm sure someone else can recount the challenges better, but it is worth noting that at the time the Wrights did their work, there was also a high profile, government funded effort underway headed by Samuel Langley. With the "best minds in the country" and government resources behind it, they still didn't make the breakthroughs.
I contend that building and flying an X-Prize class vehicle (100 km suborbital, three passengers, reusable) today is a much less daunting task than the original invention of the airplane.
We have existence proofs of what is being attempted. There is no question that it is possible, because it has been demonstrated in many different forms. The only question is how cheap it can be done.
There is a massive amount of information available. Today, anyone can go read up on things that NOBODY knew back when they were building the early rocket systems.
Obviously, computers and electronics are vastly better. Our current electronics box has all the necessary sensors and actuators for flying a spaceship, and it cost less than $15,000 to put together (yes, it runs linux).
It isn't as blatant, but other manufacturing areas have also made great progress. I had a batch of a dozen small motors made at a CNC job shop for only $1000. Even counting everything that goes into them, the total cost including valve is less than $300 each. These may well be better than the peroxide thrusters used on the Mercury capsules. It was amusing to hear the NASA pad manager tell stories about having to go bang on the Mercury thrusters with a wrench to get them to stop sputtering. Don't think that all NASA hardware performs as designed.
Pressure vessels are significantly improved. A common all-carbon-fiber tank for natural gas vehicles has a better compressed volume to mass ratio than anything that could be built in the sixties. Filament winding can make large structures that are both stronger and cheaper than the classic welded structures.
There are direct spinoffs from government rocketry development. To drill the tiny, high aspect cooling passages for the Agena upper stage engine, they had to invent brand new machining technologies. Today, you can get the same techniques done at standard industrial job shops. As far as expensive materials go, the Agena engine was made out of aluminum.
The general industrial infrastructure is also a heck of a lot better. I can order damn near anything I need for our work from McMaster-Carr at 4:00 in the morning, and it shows up two days later.
NASA spent $50 million to set up the tracking and telemetry networks for Mercury. You can get far, far better results today with a GPS and satellite modem. There are billions of dollars of space based assets already at our disposal.
I could go on for quite a while on why we would have an easier time today just replicating the efforts of the past, but that is only part of the issue. What we are aiming for in the near term is far smaller in scope than any of the projects that the public normally associates with space. Even with all the advantages of today, it would be absurd to think that we could put together a space shuttle or a Saturn V. I hesitate to make analogies, but we are effectively working on building little microprocessors instead of big mainframes. 100 km straight up and down (that gives a 5G reentry, which, while not for your grandmother, doesn't take a superhero) is just not all that hard.
Yes, there are lots of challenges to be met, and we will doubtless run into all sorts of things that we haven't even considered. We will solve them as we go. People do hard things all the time, in many different fields. The reason "rocket science" looks so much harder is just lack of familiarity.
Because the existing way of doing things in space costs tens to hundreds of millions of dollars a shot, there just isn't an opportunity for radical experimentation. The optimization problem is slowly trending towards a stable local minimum, with little chance of getting out to the global minimum. Imagine trying to develop software if you only got to compile and run your app four times a year. Imagine how much that would slow down progress, and what contortions you would go through if $100 million was riding on each run.
Build fast. Test often. Stay flexible. Mind the critical path.
John Carmack
I am helping a hardware vendor optimize the E3 build of Doom right now, but I'll make a pass of replys and comments later on tonight...
(yes, the Id net connection is slashdotted at the moment)
John Carmack
A few corrections to the article:
"My own graphics technology"
is OpenGL.
"Mr. Carmack also plays computer games in the office with his coworkers"
I played Q3 quite a bit, but not much since then. The team focus of TeamArena and Wolfenstein just isn't my favorite type of game.
"Polygon counts"
The Doom engine is not an ultra-high poly count engine, because it is built around dynamic lighting and shadowing, but it is still a large step up from our previous games. Typical scenes will have around 150,000 polygons, versus 10,000 for Q3. There will certainly be other games with higher raw polygon counts, but that is really focusing on the trees, not the forest (image quality). The large numbers that have occasionally been tossed around are the polygon counts for the high detail characters that are used in the generation of normal maps for the real time rendering. Some characters are over 500,000 polygons in their original form.
"It looks like the type of game that is so thrilling to play that gamers will do so over and over again, even though it lacks a narrative plot."
Unlike everything we have done before, the new Doom actually DOES have a real plot, and I think it is going to be presented well. I don't really expect most people to believe us at this point, but wait and see...
"The new Doom likely will require a no less powerful chip than the soon-to-be-released Nvidia GeForce3"
It is designed for full impact on a GeForce-3, but it still runs on a GeForce-1 or Radeon.
They didn't reproduce the graph of our revenues from the print version, but that was also way off base. I guess they estimated them based on our title sales, but while Doom II remains our best selling title, we have much better royalty arrangements now than we did back then, so we make more money today.
John Carmack
> Clever design + bad dev team = Deer Hunter, so there is an argument to be made for both sides
That is a really good example. I might quibble that that was market creativity, rather than game design creativity, but it is still a good point.
John Carmack
To elaborate a bit:
Probably everyone reading this has done some "game design" while talking with friends. In an evening, you can lay out the basic character of a game -- what the player does, what the environments are like, what the obstacles are, what the tools in the game are like, what the plot is, what the style of the game is, and a few unique hooks for the game.
There is not a hell of a lot of difference between what the best designer in the world produces, and what a quite a few reasonably clued in players would produce at this point. This is the "abstract creativity" aspect. This part just isn't all that valuable. Not worthless, but it isn't the thing to wrap a company around.
The real value in design is the give and take during implementation and testing. It isn't the couple dozen decisions made at the start, it is the thousands of little decisions made as the product is being brought to life, and constantly modified as things evolve around it. If you took two game designs, one good and one bad, and gave them to two development teams, one good and one bad, the good dev team could make a good, fun product out of a bad design, but the bad dev team could ruin the most clever design. The focus should be on the development process, not the (initial) design.
The games with 500 page design documents before any implementation are also kidding themselves, because you can't make all the detail decisions without actually experiencing a lot of the interactions.
Putting creativity on a pedestal can also be an excuse for laziness. There is a lot of cultural belief that creativity comes from inspiration, and can't be rushed. Not true. Inspiration is just your subconscious putting things together, and that can be made into an active process with a little introspection.
Focused, hard work is the real key to success. Keep your eyes on the goal, and just keep taking the next step towards completing it. If you aren't sure which way to do something, do it both ways and see which works better.
John Carmack
From the article:
>But with great success came great antipathy, not just for John, but also for many of his
>employees.
The employees did sort of get a raw deal by association, but to ascribe all of the antipathy towards Romero to jealousy is really missing the point.
>Daikatana and Deus Ex were finally released in 2000. Predictably, Daikatana was slammed while
>Deus Ex received many awards. Both made money for Eidos
Deus Ex made money. Daikatana lost an immense amount of money. We followed the PC-Data sales numbers for a little while, and it was really, really grim. It might have made a comback when it went to the bargain bin, but even if it had turned into the best selling game of the year, it wouldn't have covered the sunk costs at Ion.
My view:
Ion storm failued due to lack of focus, which came from the top. They had some great employees (we hired some of them!), but games don't get done without someone in a position of authority forcing everything together. Romero's primary mistake was believing that abstract creative design was a primary, or even significant, part of a successful game. The "strategic creativity" in a game is less than 1% of the effort, and if you put that on a pedestal, you will deephasise where all the real work needs to be done.
I think Romero has a chance at a comeback with his current foray into handheld games. I don't think he ever lost the enthusiasm for games, but if he can recapture the personal work ethic that he had early on, he can probably still do some pretty cool things.
John Carmack
>Cutting edge graphics, where did you go? Please tell me there's more to the 3D world than IR,
>WildCat II, and GeForce3. Has *nothing* (other than cost) really changed over the past five
>years? It's almost as though I haven't missed anything in the 28 months I've been away from 3D
Dependent texture reads are the only really new thing in the last year or two (and only really got worked out right in the Radeon 8500), but next year is going to see floating point pixel formats, which was going to be one of Bali's truly important points. We should also see highly scalable boards built on consumer chips, which has been promised for years, but (with the exception of some 3dfx high end systems) not delivered properly.
John Carmack
Thanks for the kind comments, it helps me brace a bit for some of the really vile hate mail that is already starting to come in from the people worried about cheating.
Bill Heineman is preparing the mac source code for Q2 for a release.
We will see about getting the 3.21 changes we missed into an updated release.
I am also happy to say that another old game's code will be released under the GPL soon. We can always hope that it becomes a trend...
John Carmack
I have a very interesting tale about this.
One of the suppliers to Armadillo Aerospace told me about an experiment that he tried. He was looking over the logs to his (very low traffic) site, and he wondered how an anonymized hit would show up in the logs. He went through Safeweb, and saw a properly obscured address in the logs.
One hour later, he also got a hit to the same page from cia.gov.
I'm sure this isn't standard practice for every access, but his site was probably on a hot list of some sort due to the aerospace content.
John Carmack
The rockets we are currently firing use hydrogen peroxide, which produces nothing but water and oxygen in the exhaust. Not even the most rabid greenie could argue with that.
Hydrogen / oxygen rockets also produce water and excess hydrogen. Alcohol / ocygen rockets leave a few other things similar to auto exhaust, but not really worse.
Solid rockets leave some bad stuff, and some propellants are truly nasty, like nitrogen tetroxide and hydrazine, but those are also much more expensive, so wouldn't be used in a cost effective program.
John Carmack
> I think it's only been established that Id didn't do well with the Linux gaming market
All linux games sales EVER don't add up to one medium selling windows title. We are one of the creditors that aren't likely to see money that Loki owes us, so we have some idea just how grim it is.
That isn't saying that it can't change in the future, or that doing linux ports isn't a Good Thing, but it isn't an economic motivator at the present time.
John Carmack
I'm still developing everything with OpenGL, and I'm still targeting mac and linux as well as windows, but I want to rationally address some points in the API debate:
D3D is clunky, etc
Not really true anymore. MS made large strides with each release, and DX8 can't be called a lousy API anymore. One can argue various points, but they are minor points. Anti-Microsoft forces have a bad habit of focusing on early problems, and not tracking the improvements that have been made in current versions. My rant of five years ago doesn't apply to the world of today.
I do think that the world would be a slightly better place if Microsoft had pulled an embrace-and-extend on OpenGL instead of developing a brand new API that had to be rewritten a half dozen times, but its water under the bridge now.
Open for more sales, etc
It has been pretty clearly demonstrated that the mac market is barely viable and the linux market is not viable for game developers to pursue. Linux ports will be done out of good will, not profit motives. From an economic standpoint, a developer is not making a bad call if they ignore the existence of all platforms but windows.
DX8 Gives more features
Some people have an odd view that an API gives you features. Assuming you don't care about software emulation, hardware gives you features, and an API exposes them. If you try to use vertex programs or bump env map on a TNT, DX8 doesn't magically make it work. DX8's hardware independence is also looking a bit silly now as they make point releases to support ATI's new hardware. They might as well say D3D-GF3 or D3D-R200 instead of DX8 and DX8.1.
All of Nvidia's new features have showed up as OpenGL extensions before they show up as new D3D features.
Divergent extensions haven't been a problem up until very recently. All of the vendors tended to support all the extensions they could, and if they had unique functionality, like register combiners, they made their own extension. The current status of vertex programs does piss me off, though. I really wish ATI would have just adopted Nvidia's extension, even if it meant not exposing every last bit of their hardware.
Abstraction in a high performance environment can be dangerous. If you insist that all hardware behave the same, you prevent vendors from making significant improvements. If the spec for behavior comes from people that aren't hardware oriented, it can be a huge burden. D3D still suffers somewhat due to this, with some semantics and odd features that make hardware guys wince.
The Good News
We are rapidly approaching a real golden age for graphics programming. Currently, cards and API's are a complex mess of hundreds of states and function calls, but the next two years will see the addition of the final primitive functionality needed to allow arbitrarily complex operations with graceful performance degradation.
At that point, a higher level graphics API will finally make good sense. There is debate over exactly what it is going to look like, but the model will be like C. Just like any CPU can compile any C program (with various levels of efficiency), any graphics card past this point will be able to run any shader. Some hardware vendors are a bit concerned about this, because bullet point features that you have that the other guy doesn't are a major marketing feature, but the direction is a technical inevitability. They will just have to compete on price and performance. Oh, darn.
It's a Turing machine point. Even if OpenGL 2.0 and DX10 don't adopt the same shader description language, they will be functionally equivalent, and could be automatically translated.
There is lots of other goop like texture specification and context management that will still be different between API, but the core day-to-day work of a graphics programmer will be basically above the disputes.
John Carmack
We were surprised at Wolf3D mods, but we knew it was going to happen with DOOM. I worked with some of the Wolf3D map editor guys before DOOM was even released, but they didn't wind up making the popular level editors.
The editor and utility source code was released quite early, but it was all for NeXT workstations in Objective-C, so it had to wait for someone to rewrite it for more conventional systems.
John Carmack
>It (DOOM) was designed by talented people with good skills and academic degrees in
>computer science.
None of us had degrees in computer science. Romero, Adrian, and I don't have any degrees at all, and Kevin's is in political science.
>It even had a simple but multithreaded "operating system" of its own to handle asynchronous
>updates of graphics and playing sound while performing the game simulation.
No. We made the startup sequence busy and techie in a sort of imitation of the NeXT workstations we were using at the time, but there was no multithreading going on. The sound was done with interrupt driven processing, which doesn't qualify.
With the source code open for years, this should have been easy to check.
>a resolution of only 320x240
320x200
I would take issue with some of the other vague statements made later on, but they aren't pointed enough to debate.
John Carmack
Taking things one step at a time is critical for success.
We have a pretty clear plan of attack to take us to X-Prize level vehicles. There will be several intermediate vehicles to learn from along the way, but I am pretty confident that we can do it, and that I can pay for it. The regulatory approval is still uncertain. Things get much more questionable after that.
The next step would be using the X-Prize vehicle as a booster for a upper stage(s) that launch a microsat into orbit. That requires many times for dV, and the regulatory environment, telemetry, and logistics become a lot more challenging. This would get fairly expensive, because making a reusable upper stage(s) is a whole new level of problem, and you just can't test a lot of the systems without going all the way. Even on a shoestring, it could easily get to $100k for each attempt, after you factor everything in. Realistically, it will take a lot of attempts to learn everything you need to know. A lot of people will talk about how straightforward it is, but I have a healthy respect for the challenges. Smart money probably wouldn't bet on any "garage shop" getting to orbit, but it certainly isn't impossible.
After that, you could either work towards reusable upper stages, or scale everything up to the point you could try to orbit a passenger or a semi-useful LEO satellite.
Sure, if all that works out, I would love to make a moon shot, but that qualifies as day-dreaming, not planning. The idea that Dennis Wingo has floated recently about M class asteroids rich in platinum group metals possibly being able to have survived impact on the moon without vaporizing under some conditions is Very Very Interesting.
The extent of my "business planning" for the rockets is along the lines of "If you actually make something really, really cool, you will wind up making money on it somehow". Hopelessly naive? Possibly. We'll see. I hate being involved in business, so we would probably just partner with some of the existing companies interested in suborbital rides or sounding rocket business.
In the short term, watch for us getting a man off the ground in the upscaled lander frame within a couple months.
On topic: I think pretty highly of the DaVinci project, and I would say they are definitely one of the leading contenders. Brian Feeney talks about some technical issues on open mailing lists, which is a good sign. My biggest concern for them would be that, from my experience with JP Aerospace, getting two successful rockoon launches off within the 14 days required by the X-Prize is going to involve a good sized helping of luck.
John Carmack
The standard lighting model in DOOM, with all features enabled, but no custom shaders, takes five passes on a GF1/2 or Radeon, either two or three passes on a GF3, and should be possible in a clear + single pass on ATI's new part.
It is still unclear how the total performance picture will look.
Lots of pixels are still rendered with no textures at all (stencil shadows), or only a single texture (blended effects), so the pass advantage will only show up on some subset of all the drawing.
If ATI doesn't do as good of a job with the memory interface, or doesn't get the clock rate up as high as NVidia, they will still lose.
The pixel operations are a step more flexible than Nvidia's current options, but it is still clearly not where things are going to be going soon in terms of generality.
Developers are just going to need to sweat out the diversity or go for a least common denominator for the next couple years.
I fully expect the next generation engine after the current DOOM engine will be targeted at the properly general purpose graphics processors that I have been pushing towards over the last several years.
Hardware vendors are sort of reticent to give up being able to "out feature" the opposition, but the arguments for the final flexibility steps are too strong to ignore.
John Carmack
>Then we get NASA and the US Government refusing
>to allow private launches so that people have to
>go off-shore to launch to try to claim the X
>Prize!!!
Actually, it's worse than that.
The US government (NASA doesn't have anything to do with it) claims authority over all actions of its citizens, even when they aren't inside national boundaries.
If you launched an X-Prize vehicle from another country or from international waters without getting FAA/AST clearance, you are still in trouble (and wouldn't be eligable for the prize).
John Carmack