Re:Iron Man's Suit Defies Physics -- Mostly
on
The Science of Iron Man
·
· Score: 2, Interesting
Hydrogen peroxide powered rocket packs fly for around 30 seconds, because they have a specific impulse of around 125, meaning that one pound of propellant can make 125 pound-seconds of thrust, meaning that it takes about two pounds of propellant for every second you are in the air. Mass ratios are low for anything strapped to a human, so the exponential nature of the rocket equation can be safely ignored.
A pretty hot (both literally and figuratively) bipropellant rocket could manage about twice the specific impulse, and you could carry somewhat heavier tanks, but two minutes of flight on a rocket pack is probably about the upper limit with conventional propellants.
However, an actual jet pack that used atmospheric oxygen could have an Isp ten times higher, allowing theoretical flights of fifteen minutes or so. Here, it really is a matter of technical development, since jet engines have thrust to weight ratios too low to make it practical. There is movement on this technical front, but it will still take a while.
Tracing into an SVO structure can be done with almost a Bresenham algorithm, and when you reach whatever depth of descent you want (a critical factor, you aren't going all the way to final detail on every trace), you pop out whatever data is stored there (probably some vector quantized BRDF sort of thingy) and run a "fragment program" on it.
The data sets for a game world represented like this would be massive, but it is intrinsically well suited for streaming, even over the internet, which may well be the dominant media distribution channel in the timeframe we are looking at.
In our current generation codebase we have moved to completely separate representations for rendering and physics, and I expect that to continue in the future. The requirements are different enough to merit different internal storage.
Give me a little credit here. I am not suggesting that everyone blindly intersects rays with a huge list of triangles. That would be absurd, and I assumed everyone understood that. What you might have missed is that I'm not proposing a sparse voxel octree as some form of bounding hierarchy to reduce intersection tests against triangles, I am proposing that it REPLACE hierarchies of triangles or other primitives for some data sets, and this brings about significant improvements (data size) that you wouldn't have with even infinitely fast conventional ray tracing. I'm also not trying to say that this is some novel brainstorm of mine, but I have some practical experience with the direction, and I think it has promise.
One of my major points is that this is all still theoretical. I don't know what is going to be the right architecture for next gen systems. Neither do you, or Intel, Nvidia, Microsoft, Sony, or Nintendo. If I had to place a bet, it is that rasterization will still be dominant, but it is a Good Thing to have lots of people doing research into various alternatives. All the players have their own agendas, but we will all know the big win when we see it.
We (Id) have put in our application like everyone else, so I don't have any inside information at this point. I think Steve is still pissed at me over some negative comments I made about iPod development tools a while ago. Just based on the blurbs, it looks very good -- a simulator plus debugging on the native device is the best of both worlds, and a 70% royalty deal for apps over iTunes is quite good.
The iTunes distribution channel is really a more important aspect than a lot of people understand. The ability to distribute larger applications than the over-the-air limits and effectively market your title with more than a dozen character deck name, combined with the reasonable income split make this look like a very interesting market. This type of developer / customer interaction is probably the wave of the future for mobile devices, it will be interesting to see how quickly the other players can react. Based on our experiences with the carriers, I am betting not very quickly.
There is certainly no plans for a commercially supported linux version of Rage, but there will very likely be a linux executable made available. It isn't running at the moment, but we have had it compiled in the past. Running on additional platforms usually provides some code quality advantages, and it really only takes one interested programmer to make it happen.
The PC version is still OpenGL, but it is possible that could change before release. The actual API code is not very large, and the vertex / fragment code can be easily translated between cg/hlsl/glsl as necessary. I am going to at least consider OpenGL 3.0 as a target, if Nvidia, ATI, and Intel all have decent support. There really won't be any performance difference between GL 2.0 / GL 3.0 / D3D, so the api decision will be based on secondary factors, of which inertia is one.
I'm not sure where that quote came from -- IdTech 5 as a whole is not a clean sheet of paper design, there are some good sized chunks that have clear heritage to Doom 3 / Q4 / ETQW. The rendering engine is certainly from-scratch, but that is a rather small chunk of a complete engine today.
I was always somewhat hesitant about broad licensing because I feared something exactly like this, where a developer thinks they see something in an engine, but it doesn't turn out the way they expected, and they sue. It is possible that explicit promises were made and broken, but it is also possible that the licensee just failed for the same reasons that most game development project fail, and is looking for a scapegoat. Game development is hard, engine license or no engine license.
During Doom 3's development, our licensees had access to our source control server, so there was never a question of them not having access to what we are using. They would have been foolish to try to use daily builds, but the option was available to them.
Game programs have been somewhat useful for finding employees, but we don't actually think that the students are learning particularly valuable skills in the programs.
A CS or EE degree will almost certainly serve you better throughout your life than a game/media degree, but if getting into the industry immediately is your overriding concern, a game program will help with contacts and opportunities.
Exceptional merit will eventually be noticed (perhaps not as quickly as you would like, though), and a degree of any sort is not required if you can conclusively demonstrate that you will contribute great value to a company. However, many entry level positions are filled based on people's opinions about potential, and honest assessments from faculty that work with lots of students does carry some weight.
The best advice is "be amazing", but "diligent and experienced" counts for quite a bit.
As a follow up, some people aren't realizing that it isn't necessary to actually have a chemical reaction and form an organic peroxide molecule to make an explosive. A solution of oxidizer and fuel can easily be a shock sensitive explosive. This requires higher concentration peroxide than is available off the shelf, but concentrating a modest amount is not very challenging.
The feasibility of this really isn't open for debate. There is no doubt that you can reliably mix two liquids and produce a high explosive that can be detonated with a sharp impact.
A quest for perfect safety from all conceivable threats is, of course, ridiculous, but I'm sure there will be many more added security measures thrown in as a result of this, to little real benefit and much general annoyance. Personally, I would have been completely comfortable flying immediately after 9/11 with absolutely no additional security measures. Statistics and probability leave me with no fear of terrorism.
I had fairly low expectations, and there were even some plans in palce to guide me away from any press after the premier if I didn't like the movie, so I wouldn't say something "unproductive", but I was pleasantly surprised.
No, it isn't an oscar movie, but it definitely isn't Super Mario Brothers / Street Fighter / Double Dragon.
I do wish they had kept the true satanic / hellish theme, but I think they did a credible job with their alternate direction.
Personally, I think the Q3 code is pretty clean on the whole. It was a commercial product done under time pressure, so it isn't a polished gem, but I consider it good.
Anyone working on the Q3 codebase today should just delete all the asm code and use the C implementations. Making a commercial game with fairly high end requirements go 10% faster is sometimes worth writing some asm code, but years later when the frame rate pressure is essentially gone, the asm code should just be dumped in the name of maintainability. All the comments in the world wouldn't change this decision a bit.
>But there's really little reason to use asm >anymore, since the autovectorization in gcc is >very nice.
I was pretty much with you until that point. I fully agree that there is little reason to use asm anymore (I haven't written any in years -- Jan Paul did all the SIMD work for Doom 3). Knowledge of asm is good to allow you to manipulate compiler output by changing your C++ code, but there isn't much call for writing it by hand.
However, autovectorization in gcc is a particularly bad argument against writing asm code. Scalar compiler code is much, much closer to hand codeed asm in performance than compiler generated SIMD code is. Optimized SIMD coding almost always requires significant transformations that compilers can't really do on their own.
The argument about inline asm hurting compiler optimizations is only true if you are trying to use short snippets of asm, which is generally a bad idea. Asm code that doesn't loop a lot isn't likely to contribute significantly to your performance, with the exception of things like ftol replacements.
All the quenching problems were with our mixed-monoprop scheme that used low concentration (50%) peroxide mixed with a small amount of methanol.
If you can get high concentration peroxide (85%+), there are no catalyst quenching problems. We started out with 90% peroxide, and we would still be using it (and would have saved a year of work...) if we had a willing supplier. The original supplier we used went out of business, and the remaining domestic supplier didn't want to do business with us, even for >$100,000 orders.
We did a number of peroxide / kerosene biprop tests back in August / September 2002 before we ran out of high concentration peroxide.
We are pretty happy with liquid oxygen now, but if Bezos is sure that supply won't be an issue, peroxide/kerosene is certainly not a bad choice. The sole drawback I would note is that it will put a lower limit on his operating expenses, and a LOX based system could potentially undercut him, although that would only be an issue when ticket prices are getting down towards $10k.
John Carmack
Rapid prototyping, etc
on
Fab
·
· Score: 3, Interesting
I have a good sized CNC mill in my garage that I use practically every week to make various rocket parts. It is certainly cool, but the realities of tool reach, work holding, and chip removal make it more of a "super power tool", rather than a free-form-fab.
The various technologies that essentially rasterize arbitrary parts are what excite the imagination, but I don't expect any radical changes in society any time soon from them. Stereolithography is pretty mature, and getting arbitrary parts rasterized in plastic is fairly common today. However, in 99% of the cases, these are still used as models / proof of concept / R&D, not actual manufacturing, because they are drastically more expensive than, say, injection molding, and more mechanically limited. There are a lot of technologies touted for rasterizing 3D metal parts, but I spent some time recently trying to find a place to fab modest sized rocket engines, and none of the companies I spoke with were able to handle it for various reasons.
I do expect this to become very exciting, but it is several years away. The excitement won't be about fabricating things that you currently buy (conventional mass production will retain significant cost benefits), but allowing low cost R&D. When you can send an arbitrary 3D CAD model over the net to a company with a metal rapid prototyping machine (they will remain expensive for quite some time) and get your part overnighted to you in a couple days with no setup fees, you will be able to iterate design cycles twice a week at quite low expense. You can do this today with plastic, and in some limited cases of small metal parts, but when you can start doing it in significant engineering materials that can be used in functional prototype machines, lots of new opportunities will arise.
>How much do you want to bet a bunch of those developers drop support for PPC Macs far sooner than the >aforementioned "3-5 year" period and claim that the games demand the "performance" of the faster Intel >machines. We already saw that when Doom 3 was released for the Mac. It supported only the very fastest >Macs while leaving many other current and/or new Macs out in the lurch.
Does he think we just sit around and say "Lets just not support the rest of these macs because we want to screw the user base!"
We work with Apple, ATI, and Nvidia to make everything run as well as possible. Doom 3 had AltiVec code in it, and there were driver changes to make things work better. The bottom line is that the compiler / cpu / system / graphics card combinations available for macs has just never been as fast as the equivalent x86/windows systems. The performance gap is not a myth or the result of malicious developers trying to make your platform of choice look bad.
Yes, it is always possible to make an application faster, but expecting developers to work harder on the mac platform than on windows is not reasonable. The xbox version of Doom required extensive effort in both programming and content to get good performance, but it was justified because of the market. In hindsight, we probably should have waited and ported the xbox version of the game to the mac, which would have played on a broader range of hardware. Of course, then we would have taken criticism for only giving the mac community the "crippled, cut down version".
I'm proud that there is "a relative dearth of patent applications for the video game industry, especially considering how technology-dependent the video game industry is, and given its size in terms of annual sales."
Before issuing a condemnation, I try hard to think about it from their point of view -- the laws of the land set the rules of the game, and lawyers are deeply confused at why some of us aren't using all the tools that the game gives us.
Patents are usually discussed in the context of someone "stealing" an idea from the long suffering lone inventor that devoted his life to creating this one brilliant idea, blah blah blah.
But in the majority of cases in software, patents effect independent invention. Get a dozen sharp programmers together, give them all a hard problem to work on, and a bunch of them will come up with solutions that would probably be patentable, and be similar enough that the first programmer to file the patent could sue the others for patent infringement.
Why should society reward that? What benefit does it bring? It doesn't help bring more, better, or cheaper products to market. Those all come from competition, not arbitrary monopolies. The programmer that filed the patent didn't work any harder because a patent might be available, solving the problem was his job and he had to do it anyway. Getting a patent is uncorrelated to any positive attributes, and just serves to allow either money or wasted effort to be extorted from generally unsuspecting and innocent people or companies.
Yes, it is a legal tool that may help you against your competitors, but I'll have no part of it. Its basically mugging someone.
I could waste hours going on about this. I really need to just write a position paper some day that I can cut and paste when this topic comes up.
I just read that book recently, and while I enjoyed most of it, I found the chapter on the theories about the emergence of DNA extremely "hand wavey". The clay mineral culture idea was only presented as one possibility, but it didn't sound very convincing. If anyone has pointers to more compelling theories, I would be interested in reading them.
I always hated biology / life science in school because most of it was name memorization, but at the molecular biology level, it all starts looking digital...
I did try running that benchmark, but it won't load on the i730 (score one more for run-anywhere...).
One of our test platforms is a fairly high end Sony Ericsson, which is 10x as fast as our Motorola base platform. For a 128x128 screen, the Motorola renders about 4 fps and the Sony renders about 40 fps. Compare with Wolfenstein-3D performance (the DoomRPG engine has some extra graphics features, but it is still in that general class) at that resolution on older systems. A 386-16 would go significantly faster.
Note that the "As fast as a..." comparisons from the benchmark are against purely interpreted java on the P3, which is about 1/10th the speed of a native implementation, and benchmarks that focus on expression and control operations will overestimate relative performance for applications that are array access heavy. Still, if a java app on that phone performed like a P3-100mhz, it would be pretty impressive.
It is true that a good JIT (which the phones don't have) can make java code go nearly as fast as C/C++ code that is written in the same style. The "in the same style" part is often overlooked -- in lower level languages you often have options for implementation with pointers and CPU tailoring that would make the code look very different, but go significantly faster.
I still generally like java, and maximizing performance is only important in a rather limited subset of software engineering.
I did the Academy of Interactive Arts and Sciences awards show a few years ago -- I was inducted into the hall of fame one year, then the next year I inducted Will Wright.
I hated it, but it is a big industry, and there is a broad range of people involved. Honestly, I'm almost certainly in the minority. One developer that I was talking to backstage was very bullish about how important it was to legitimize the industry with events like this, but I just don't have any empathy for what I perceive as "Hollywood envy".
Some award show issues are just a result of stupidity -- I felt so bad watching Hironobu Sakaguchi of Squaresoft, a non-native english speaker, being forced to read a long speech written by some PR type about me. I threw out what they gave me to say about Will, and wrote something more to the point myself.
I do feel that there is a rather fundamental mismatch with big awards shows for game development, because game development isn't a performing art. You expect actors and musicians to show well, because that is what they do. Why aren't awards for authors the same glamorous events that the movie / TV / music ones are? Game developers are much closer to authors than actors.
We had a pretty good money offer to put a sponsored add in the Quake 1 entry level. We decided not to just on the basis of it being tacky, which was for the best, considering the company (some random early internet company) dissapeared into obscurity.
I don't have any fundamental problem with product placement in games, but it isn't something we pursue. I would just as soon have real brands in realistic settings instead of made up ones.
I am extremely proud of Doom 3. I think it is the best game we have ever made, and it exceeded all of my expectations. That is a rather trite phrase, but it is literally true -- I had a good set of expectations for how the game would turn out based on the technologies that it was built on, and it wound up being just plain better than that.
We think a lot of people will like it.
I don't follow gaming message boards, because, at its best, entertainment is going to be a subjective thing that can't win for everyone, while at worst, a particular game just becomes a random symbol for petty tribal behavior. This slashdot story is about as close as I want to go...
Amidst all the various Doom ports and expansions, we are starting up on our next game. It will have a new rendering engine, which will be keeping me busy for a while, but the only other thing we are saying for now is that it won't be a sequel to any of our previous work. We have a really solid team that did a lot of maturing through Doom's development, so I have high hopes that it won't be another four year odyssey.
Slashdot Mirror
Hydrogen peroxide powered rocket packs fly for around 30 seconds, because they have a specific impulse of around 125, meaning that one pound of propellant can make 125 pound-seconds of thrust, meaning that it takes about two pounds of propellant for every second you are in the air. Mass ratios are low for anything strapped to a human, so the exponential nature of the rocket equation can be safely ignored.
A pretty hot (both literally and figuratively) bipropellant rocket could manage about twice the specific impulse, and you could carry somewhat heavier tanks, but two minutes of flight on a rocket pack is probably about the upper limit with conventional propellants.
However, an actual jet pack that used atmospheric oxygen could have an Isp ten times higher, allowing theoretical flights of fifteen minutes or so. Here, it really is a matter of technical development, since jet engines have thrust to weight ratios too low to make it practical. There is movement on this technical front, but it will still take a while.
John Carmack
Not that I give a damn about being carbon neutral, but our rocket engines do burn ethanol.
John Carmack
Tracing into an SVO structure can be done with almost a Bresenham algorithm, and when you reach whatever depth of descent you want (a critical factor, you aren't going all the way to final detail on every trace), you pop out whatever data is stored there (probably some vector quantized BRDF sort of thingy) and run a "fragment program" on it.
The data sets for a game world represented like this would be massive, but it is intrinsically well suited for streaming, even over the internet, which may well be the dominant media distribution channel in the timeframe we are looking at.
John Carmack
In our current generation codebase we have moved to completely separate representations for rendering and physics, and I expect that to continue in the future. The requirements are different enough to merit different internal storage.
John Carmack
Give me a little credit here. I am not suggesting that everyone blindly intersects rays with a huge list of triangles. That would be absurd, and I assumed everyone understood that. What you might have missed is that I'm not proposing a sparse voxel octree as some form of bounding hierarchy to reduce intersection tests against triangles, I am proposing that it REPLACE hierarchies of triangles or other primitives for some data sets, and this brings about significant improvements (data size) that you wouldn't have with even infinitely fast conventional ray tracing. I'm also not trying to say that this is some novel brainstorm of mine, but I have some practical experience with the direction, and I think it has promise.
One of my major points is that this is all still theoretical. I don't know what is going to be the right architecture for next gen systems. Neither do you, or Intel, Nvidia, Microsoft, Sony, or Nintendo. If I had to place a bet, it is that rasterization will still be dominant, but it is a Good Thing to have lots of people doing research into various alternatives. All the players have their own agendas, but we will all know the big win when we see it.
John Carmack
We (Id) have put in our application like everyone else, so I don't have any inside information at this point. I think Steve is still pissed at me over some negative comments I made about iPod development tools a while ago. Just based on the blurbs, it looks very good -- a simulator plus debugging on the native device is the best of both worlds, and a 70% royalty deal for apps over iTunes is quite good.
The iTunes distribution channel is really a more important aspect than a lot of people understand. The ability to distribute larger applications than the over-the-air limits and effectively market your title with more than a dozen character deck name, combined with the reasonable income split make this look like a very interesting market. This type of developer / customer interaction is probably the wave of the future for mobile devices, it will be interesting to see how quickly the other players can react. Based on our experiences with the carriers, I am betting not very quickly.
John Carmack
There is certainly no plans for a commercially supported linux version of Rage, but there will very likely be a linux executable made available. It isn't running at the moment, but we have had it compiled in the past. Running on additional platforms usually provides some code quality advantages, and it really only takes one interested programmer to make it happen.
The PC version is still OpenGL, but it is possible that could change before release. The actual API code is not very large, and the vertex / fragment code can be easily translated between cg/hlsl/glsl as necessary. I am going to at least consider OpenGL 3.0 as a target, if Nvidia, ATI, and Intel all have decent support. There really won't be any performance difference between GL 2.0 / GL 3.0 / D3D, so the api decision will be based on secondary factors, of which inertia is one.
John Carmack
I'm not sure where that quote came from -- IdTech 5 as a whole is not a clean sheet of paper design, there are some good sized chunks that have clear heritage to Doom 3 / Q4 / ETQW. The rendering engine is certainly from-scratch, but that is a rather small chunk of a complete engine today.
I was always somewhat hesitant about broad licensing because I feared something exactly like this, where a developer thinks they see something in an engine, but it doesn't turn out the way they expected, and they sue. It is possible that explicit promises were made and broken, but it is also possible that the licensee just failed for the same reasons that most game development project fail, and is looking for a scapegoat. Game development is hard, engine license or no engine license.
During Doom 3's development, our licensees had access to our source control server, so there was never a question of them not having access to what we are using. They would have been foolish to try to use daily builds, but the option was available to them.
John Carmack
Game programs have been somewhat useful for finding employees, but we don't actually think that the students are learning particularly valuable skills in the programs.
A CS or EE degree will almost certainly serve you better throughout your life than a game/media degree, but if getting into the industry immediately is your overriding concern, a game program will help with contacts and opportunities.
Exceptional merit will eventually be noticed (perhaps not as quickly as you would like, though), and a degree of any sort is not required if you can conclusively demonstrate that you will contribute great value to a company. However, many entry level positions are filled based on people's opinions about potential, and honest assessments from faculty that work with lots of students does carry some weight.
The best advice is "be amazing", but "diligent and experienced" counts for quite a bit.
John Carmack
As a follow up, some people aren't realizing that it isn't necessary to actually have a chemical reaction and form an organic peroxide molecule to make an explosive. A solution of oxidizer and fuel can easily be a shock sensitive explosive. This requires higher concentration peroxide than is available off the shelf, but concentrating a modest amount is not very challenging.
The feasibility of this really isn't open for debate. There is no doubt that you can reliably mix two liquids and produce a high explosive that can be detonated with a sharp impact.
A quest for perfect safety from all conceivable threats is, of course, ridiculous, but I'm sure there will be many more added security measures thrown in as a result of this, to little real benefit and much general annoyance. Personally, I would have been completely comfortable flying immediately after 9/11 with absolutely no additional security measures. Statistics and probability leave me with no fear of terrorism.
John Carmack
I had fairly low expectations, and there were even some plans in palce to guide me away from any press after the premier if I didn't like the movie, so I wouldn't say something "unproductive", but I was pleasantly surprised.
No, it isn't an oscar movie, but it definitely isn't Super Mario Brothers / Street Fighter / Double Dragon.
I do wish they had kept the true satanic / hellish theme, but I think they did a credible job with their alternate direction.
John Carmack
Thank you.
John Carmack
Personally, I think the Q3 code is pretty clean on the whole. It was a commercial product done under time pressure, so it isn't a polished gem, but I consider it good.
Anyone working on the Q3 codebase today should just delete all the asm code and use the C implementations. Making a commercial game with fairly high end requirements go 10% faster is sometimes worth writing some asm code, but years later when the frame rate pressure is essentially gone, the asm code should just be dumped in the name of maintainability. All the comments in the world wouldn't change this decision a bit.
>But there's really little reason to use asm
>anymore, since the autovectorization in gcc is
>very nice.
I was pretty much with you until that point. I fully agree that there is little reason to use asm anymore (I haven't written any in years -- Jan Paul did all the SIMD work for Doom 3). Knowledge of asm is good to allow you to manipulate compiler output by changing your C++ code, but there isn't much call for writing it by hand.
However, autovectorization in gcc is a particularly bad argument against writing asm code. Scalar compiler code is much, much closer to hand codeed asm in performance than compiler generated SIMD code is. Optimized SIMD coding almost always requires significant transformations that compilers can't really do on their own.
The argument about inline asm hurting compiler optimizations is only true if you are trying to use short snippets of asm, which is generally a bad idea. Asm code that doesn't loop a lot isn't likely to contribute significantly to your performance, with the exception of things like ftol replacements.
John Carmack
Yes, there was a budget title (Paintball somthing or another) that was developed based on the Q1 source that purchased a commercial license.
We didn't charge much, but I still think they should have just saved the money and released their source.
John Carmack
All the quenching problems were with our mixed-monoprop scheme that used low concentration (50%) peroxide mixed with a small amount of methanol.
If you can get high concentration peroxide (85%+), there are no catalyst quenching problems. We started out with 90% peroxide, and we would still be using it (and would have saved a year of work...) if we had a willing supplier. The original supplier we used went out of business, and the remaining domestic supplier didn't want to do business with us, even for >$100,000 orders.
We did a number of peroxide / kerosene biprop tests back in August / September 2002 before we ran out of high concentration peroxide.
We are pretty happy with liquid oxygen now, but if Bezos is sure that supply won't be an issue, peroxide/kerosene is certainly not a bad choice. The sole drawback I would note is that it will put a lower limit on his operating expenses, and a LOX based system could potentially undercut him, although that would only be an issue when ticket prices are getting down towards $10k.
John Carmack
I have a good sized CNC mill in my garage that I use practically every week to make various rocket parts. It is certainly cool, but the realities of tool reach, work holding, and chip removal make it more of a "super power tool", rather than a free-form-fab.
The various technologies that essentially rasterize arbitrary parts are what excite the imagination, but I don't expect any radical changes in society any time soon from them. Stereolithography is pretty mature, and getting arbitrary parts rasterized in plastic is fairly common today. However, in 99% of the cases, these are still used as models / proof of concept / R&D, not actual manufacturing, because they are drastically more expensive than, say, injection molding, and more mechanically limited. There are a lot of technologies touted for rasterizing 3D metal parts, but I spent some time recently trying to find a place to fab modest sized rocket engines, and none of the companies I spoke with were able to handle it for various reasons.
I do expect this to become very exciting, but it is several years away. The excitement won't be about fabricating things that you currently buy (conventional mass production will retain significant cost benefits), but allowing low cost R&D. When you can send an arbitrary 3D CAD model over the net to a company with a metal rapid prototyping machine (they will remain expensive for quite some time) and get your part overnighted to you in a couple days with no setup fees, you will be able to iterate design cycles twice a week at quite low expense. You can do this today with plastic, and in some limited cases of small metal parts, but when you can start doing it in significant engineering materials that can be used in functional prototype machines, lots of new opportunities will arise.
John Carmack
>How much do you want to bet a bunch of those developers drop support for PPC Macs far sooner than the
>aforementioned "3-5 year" period and claim that the games demand the "performance" of the faster Intel
>machines. We already saw that when Doom 3 was released for the Mac. It supported only the very fastest
>Macs while leaving many other current and/or new Macs out in the lurch.
Does he think we just sit around and say "Lets just not support the rest of these macs because we want to screw the user base!"
We work with Apple, ATI, and Nvidia to make everything run as well as possible. Doom 3 had AltiVec code in it, and there were driver changes to make things work better. The bottom line is that the compiler / cpu / system / graphics card combinations available for macs has just never been as fast as the equivalent x86/windows systems. The performance gap is not a myth or the result of malicious developers trying to make your platform of choice look bad.
Yes, it is always possible to make an application faster, but expecting developers to work harder on the mac platform than on windows is not reasonable. The xbox version of Doom required extensive effort in both programming and content to get good performance, but it was justified because of the market. In hindsight, we probably should have waited and ported the xbox version of the game to the mac, which would have played on a broader range of hardware. Of course, then we would have taken criticism for only giving the mac community the "crippled, cut down version".
John Carmack
I'm proud that there is "a relative dearth of patent applications for the video game industry, especially considering how technology-dependent the video game industry is, and given its size in terms of annual sales."
Before issuing a condemnation, I try hard to think about it from their point of view -- the laws of the land set the rules of the game, and lawyers are deeply confused at why some of us aren't using all the tools that the game gives us.
Patents are usually discussed in the context of someone "stealing" an idea from the long suffering lone inventor that devoted his life to creating this one brilliant idea, blah blah blah.
But in the majority of cases in software, patents effect independent invention. Get a dozen sharp programmers together, give them all a hard problem to work on, and a bunch of them will come up with solutions that would probably be patentable, and be similar enough that the first programmer to file the patent could sue the others for patent infringement.
Why should society reward that? What benefit does it bring? It doesn't help bring more, better, or cheaper products to market. Those all come from competition, not arbitrary monopolies. The programmer that filed the patent didn't work any harder because a patent might be available, solving the problem was his job and he had to do it anyway. Getting a patent is uncorrelated to any positive attributes, and just serves to allow either money or wasted effort to be extorted from generally unsuspecting and innocent people or companies.
Yes, it is a legal tool that may help you against your competitors, but I'll have no part of it. Its basically mugging someone.
I could waste hours going on about this. I really need to just write a position paper some day that I can cut and paste when this topic comes up.
John Carmack
I just read that book recently, and while I enjoyed most of it, I found the chapter on the theories about the emergence of DNA extremely "hand wavey". The clay mineral culture idea was only presented as one possibility, but it didn't sound very convincing. If anyone has pointers to more compelling theories, I would be interested in reading them.
I always hated biology / life science in school because most of it was name memorization, but at the molecular biology level, it all starts looking digital...
John Carmack
I did try running that benchmark, but it won't load on the i730 (score one more for run-anywhere...).
..." comparisons from the benchmark are against purely interpreted java on the P3, which is about 1/10th the speed of a native implementation, and benchmarks that focus on expression and control operations will overestimate relative performance for applications that are array access heavy. Still, if a java app on that phone performed like a P3-100mhz, it would be pretty impressive.
One of our test platforms is a fairly high end Sony Ericsson, which is 10x as fast as our Motorola base platform. For a 128x128 screen, the Motorola renders about 4 fps and the Sony renders about 40 fps. Compare with Wolfenstein-3D performance (the DoomRPG engine has some extra graphics features, but it is still in that general class) at that resolution on older systems. A 386-16 would go significantly faster.
Note that the "As fast as a
It is true that a good JIT (which the phones don't have) can make java code go nearly as fast as C/C++ code that is written in the same style. The "in the same style" part is often overlooked -- in lower level languages you often have options for implementation with pointers and CPU tailoring that would make the code look very different, but go significantly faster.
I still generally like java, and maximizing performance is only important in a rather limited subset of software engineering.
John Carmack
I did the Academy of Interactive Arts and Sciences awards show a few years ago -- I was inducted into the hall of fame one year, then the next year I inducted Will Wright.
I hated it, but it is a big industry, and there is a broad range of people involved. Honestly, I'm almost certainly in the minority. One developer that I was talking to backstage was very bullish about how important it was to legitimize the industry with events like this, but I just don't have any empathy for what I perceive as "Hollywood envy".
Some award show issues are just a result of stupidity -- I felt so bad watching Hironobu Sakaguchi of Squaresoft, a non-native english speaker, being forced to read a long speech written by some PR type about me. I threw out what they gave me to say about Will, and wrote something more to the point myself.
I do feel that there is a rather fundamental mismatch with big awards shows for game development, because game development isn't a performing art. You expect actors and musicians to show well, because that is what they do. Why aren't awards for authors the same glamorous events that the movie / TV / music ones are? Game developers are much closer to authors than actors.
John Carmack
We had a pretty good money offer to put a sponsored add in the Quake 1 entry level. We decided not to just on the basis of it being tacky, which was for the best, considering the company (some random early internet company) dissapeared into obscurity.
I don't have any fundamental problem with product placement in games, but it isn't something we pursue. I would just as soon have real brands in realistic settings instead of made up ones.
John Carmack
I said the same thing -- the puffs from the flying tank look just like a bad particle system that dropped points far too sparsely. Strange.
John Carmack
I am extremely proud of Doom 3. I think it is the best game we have ever made, and it exceeded all of my expectations. That is a rather trite phrase, but it is literally true -- I had a good set of expectations for how the game would turn out based on the technologies that it was built on, and it wound up being just plain better than that.
We think a lot of people will like it.
I don't follow gaming message boards, because, at its best, entertainment is going to be a subjective thing that can't win for everyone, while at worst, a particular game just becomes a random symbol for petty tribal behavior. This slashdot story is about as close as I want to go...
Amidst all the various Doom ports and expansions, we are starting up on our next game. It will have a new rendering engine, which will be keeping me busy for a while, but the only other thing we are saying for now is that it won't be a sequel to any of our previous work. We have a really solid team that did a lot of maturing through Doom's development, so I have high hopes that it won't be another four year odyssey.
John Carmack
By the end of the year. There are still a lot of higher priority things, but it is coming soon.
Hopefully punkbuster will keep the source release from having any negative impact on the player community.
John Carmack