The article hints that the NV1's quadratic surfaces might have actually been a good thing, and it was held back by Microsoft's push to conformity with triangles.
Er, no.
For several years now, Nvidia has been kicking ass like no other graphics company, but lets not romanticize the early days. The NV1 sucked bad, and it would have been damaging to the development of 3D accelerators if it had gotten more widespread success. Microsoft did a good thing by standing firm against Nvidia's pressure to add quadratic surfaces to the initial version of D3D.
There is an intuitive notion that curved surfaces are "better" than triangles, because it takes lots of triangles to aproximate a curved surface.
In their most general form, they can be degenerated to perform the same functions as triangles, just at a huge waste in specification traffic.
Unfortunately, there have been a long string of products that miss the "most general form" part, and implement some form of patch surface that requires textures to be aligned with the patch isoparms. This seems to stem from a background in 2D graphics, where the natural progression from sliding sprites around goes to scaling them, then rotating them, then projecting them, then curving them.
3DO did it. Saturn did it. NV1 did it. Some people are probably working on displacement mapping schemes right now that are making the same mistake.
Without the ability to separate the texturing from the geometry, you can't clip any geometry in a general way (not even mentioning the fact that clipping a curve along anything but an isoparm will raise it's order), and you either live with texel density varying wildly and degenerating to points, or you have texture seams between every change in density. No ability to rotate a texture on a surface, project a texture across multiple surfaces, etc. You can't replace the generality if a triangle with primitives like that.
Even aside from the theoretical issues, NV1 didn't have any form of hidden surface removal, and the curve subdivision didn't stitch, frustum clip or do perspective. It was a gimmick, not a tool.
All water under the bridge now, of course. NV20 rocks.:-)
The only downside of the next product is that initially it will probably only work at full feature level with the Nvidia OpenGL driver, but after the first test gets out (still a very long time in the future), I will jump back in to the driver development to try and bring the other open source drivers up to par.
We are going to continue to support linux in future products, but unfortunately it doesn't look like a strong business case can be made for it. The mac version outsold the linux version by quite a bit, and even that didn't hit 5% of the windows sales. Mac versions are still valid business cases, because the support is way easier than on either windows or linux platforms, and the sales numbers amount to something noticeable.
There is no way that a linux box will hit the shelf at the same time and have the same price as a windows box, assuming the publisher is making a maximum effort for the windows box. If this is truly a gating factor, linux boxed games just won't succeed.
Loki wants to get away from making games "convertable" between platforms, to force linux players to buy the linux boxes. I have issues with this. Not making executable binaries available online sucks. I hate binary patches, and requiring either patches from different versions, or the installation of all previous patches. Just releasing a new executable is so much easier.
Our options from here are to move towards a hybrid CD and pay Loki for official support (which makes linux support look like an expense, rather than a benefit), make a hybrid CD but leave the linux version in an "unsupported" directory, or just make unsupported linux executables available online like we used to.
It is going to be quite some time before DOOM ships, so we can't say anything definitive at this point.
I will probably do the initial development work for DOOM on linux, but I'm not interested in tracking every change that goes on in the linux world. The initial work will probably be with the Nvidia driver, which already has all the features I need, then I will work with the Open Source mesa drivers to bring them up to par.
I have been meaning to write an article about my involvement with, and impressions of the space community over the past year. Slashdot's space coverage started getting me interested in the field last year, and I wound up putting $34k into funding two of the CATS prize entries (JPA and SORAC). If one of them had won, they would have returned the funding money, but it was basically done as philanthropy.
From the outside, or with cursory knowledge, it seems so damn simple, and all the problems sound like they could have been prevented with a little thought. It's harder than it sounds. Feel free to help.
A lot of efforts came together in the last couple months, and none of them have been successful. After the fact, it's easy to toss off what should have been done.
Ky Michaelson's space shot got off better than most. It launched well, and went through it's full burn before losing a fin at mach 4+. If it had held together, it might have made it into space. Hindsight says he should have welded the fins.
The Wickman AN space booster static test CATO'd. Hindsight says he should have hydrotested the casing.
The HARC launch reached the full altitude for balloon launch (an achievement by itself), and the electronics all seemed to work, but the launch failed due to interference with the launch rail. Hindsight says they should have done a test launch from the ground with the launcher hung from scaffolding.
The SORAC team ran into some political and personal issues with the Bureau of Land Management, resulting in them being banned from black rock for a while, scrubbing their planned CATS launch. Being honest, it would have been a rush job if they had launched in the scheduled slot, but they still would have had a chance. Hindsight says they should have started cultivating the BLM bureaucrats at the start of the year.
JP Aerospace got fucked by the FAA. They have had licenses to try for 100km a couple times in the past, and they always turn everything in more than six months in advance and check up on the process constantly. Four days before they were heading to black rock, the FAA informed them that there were problems with their application. Hindsight doesn't say anything. There was still a pretty good chance JPA would have had problems with their new launch structure because they missed their last AWAY test run schedule, but they probably had the best shot.
Interorbital has a sea launch slot next week, but pushing for the last week of the prize sounds like things probably aren't quite ready to go.
The SORAC and JPA CATS rockets will still be launched when the proper permits are all in line again (the government agencies have turned around), so there is a decent chance that there will be an amateur rocket getting into space come spring, but unfortunately there won't be a payoff for them now that the prize is expiring.
>Q. After reading the voodooextreme interview, it sounds like you are pursuing an allmost completely different rendering pass/phases with Doom 3. Can you give us any more details?:-)
It adds up to lots and lots of passes. I am expecting the total overdraw to average around 30x when you have all features enabled.
>Q. Could you give us your thoughts on T&L? Why does 3Dfx say it's not important?
Contrary to some comments here, 3dfx didn't just "decide not to put in T&L", the didn't have that option. Product development cycles can take years, and you can't just change your mind at the end.
They don't have it, so naturally they downplay the importance of it.
>Reguardless, I won't buy either. Why? Because
>they both claim OpenGL support. Now, I don't
>know about you folks, but seeing as I work in
>AutoCAD frequently, that means hardware support.
>Neither of them have it. ATI doesn't. #9 didn't.
>Why? Most of them view software as the future.
All of the modern cards have full rasterization support for OpenGL, but I guess you are refering to geometry acceleration.
The situation has changed since you last looked at it.
The Nvidia GeForce cards have an extremely capable geometry accelerator, and they have the ability to fetch display lists either over AGP with a large bandwidth savings due to vertex reuse, or store the display lists completely in local memory to remove all vertex traffic from the bus.
The issue with professional OpenGL support has mostly been the focus of the driver writers, not the hardware. I think that Nvidia's partnering with ELSA to work on professional app certification with the Nvidia hardware was an extremely good move.
There are a few edges that the expensive professional boards still have over the nvidia consumer cards, but not many:
You can get more total memory, like a 32mb framebuffer and 64mb texture memory configuration. We will probably see workstation graphics systems with up to a gig of memory within a year. Consumer cards will offer 128mb next year, but the workstation cards can easily maintain an advantage there.
This has a cost, though: large, expandable memory subsystems can't be clocked as high as the single-option, short trace layouts that nvidia does. Even dual pipe workstation boards can't match the memory bandwidth of a GeForce2.
You generally get better high end DACs and shielding on workstation boards. The upper end of the consumer boards will do the high numbers, but it just isn't as clean of a signal.
Dual monitor has been supported much better on the workstation boards. This is starting to become a feature on consumer boards, which is welcome.
The consumer cards are still skimping on itterator precision bits. Under demanding conditions, like very large magnitude texcoord values stretched a small increment across a large number of pixels, you can see many consumer cards start getting fuzzy texel edges while the workstation cards still look rock solid.
Probably the most noticable case is in edge rasterization, where some workstation cards are so good that you don't usually notice T-Junction cracks in your data, while the consumer cards have them stand out all over the place.
Next years consumer cards should fix that.
When the consumer cards first started posting fill rate numbers higher than the professional boards, it was mostly a lie. They got impressive numbers at 640x480 in 16 bit color, without blending, depth buffering, and filtering, but if you turned on 32 bit, depth, blend, trilinear, and ran at high res, they could fall to 1/4 or less of the quoted value.
Today, there isn't a single combination of rendering attributes that will let a wildcat out-rasterize a GeForce2.
Wildcat was supposed to offer huge 8 and 16 way scalability that would offset that, but it doesn't look like it is coming any time soon.
The workstation vendors do stupid driver tricks to make CDRS go faster, while consumer vendors do stupid driver tricks to make Q3 go faster.
We bought three generations of intergraph/intense3D products, but the last generation (initial wildcat) was a mistake. We use nvidia boards for both professional work and gaming now. I still think the professional boards are a bit more stable, but they fell behind in other features, especially fill rate. Being an order of magnitude cheaper doesn't directly factor into our decisions, but it would for most people.
Actually, even the original Verite V1000 could do 32 bit color rendering.
At a whopping 6 mpix or so...
Rendition did a lot of things right, even on their very first card. They had all the blend modes and texture environments from the very beginning. The only thing they didn't have was per-pixel mip-mapping.
If they had delivered the V2xx series on time, they could have had a strong foothold before voodoo2. The V3xx seried would have been a solid TNT competitor, but again, it wasn't ready on time. They wound up ditching that entire generation.
PVS was The Right Thing when level geometry counts were much lower. With tens of thousands of polygons in a scene, creating a cluster tree directly from that becomes completely unrealistic from a space and time perspective.
The options are to either do PVS with a simplified version of the world, or ignore the geometry and just work with portal topology.
Unreal used a scan-line visibility algorithm, which crippled it's ability to have high poly counts or high framerates with hardware accelerators.
Tim Sweeny knows full well that the architecture is very wrong for modern systems, but many of the original decisions were based on earlier software technologies. Unreal was supposed to be a "killer app" for the Pentium-200 MMX processor.
I have a lot of respect for Tim and Unreal, but the visibility algorithm in Unreal turned out to be a bad call. He is changing it for future work.
John Carmack
Developers all want a royalty. NOT.
on
Salon on the XBox
·
· Score: 5
I don't.
The argument for royalties is that it allows the console price to be lower, allowing more units to be sold, and theoretically allowing you to sell enough more units to offset the royalty.
The downside is that if a large chunk of the console revenue must be derived from software royalties, it must be made impossible to bypass the console company in the production of a title.
This forces them to resort to various copy protection and registered developer schemes, which open the door to all the back room scheming between publishers and the hardware vendor about shipping sequencing, and content aproval.
I would rather have a console that was six months less powerfull, but 100% completely open, and that anyone could press games for.
You have confused two different forms of compression.
S3TC is a modified form of block truncation coding (BTC), which involves selecting two colors and generating two other colors by interpolation. This is done with 4x4 blocks, giving very nearly 4 bits per pixel. This is nice because it doesn't require any additional tables.
Vector quantization is a general process where you try to take a large set of number strings and pick some subset that can be used to aproximate all of them reasonably. In the dreamcast's case, you specify 256 2x2 blocks, so each pixel is represented by 2 bits, but you also have 2k of codebook overhead. This works out pretty well for smaller textures, but large textures often come out badly because there just aren't enough codebook entries to reasonably aproximate it.
All signs are pointing towards a future without page flipping, so adding the messy infrastructure for it now would be a mistake. Don't let benchmarking furor encourage a messy code architecture.
Points:
The benefit of page flipping is decreasing as more and more computation is done per pixel to the back buffer.
In the old days of 2D scrollers, you might barely cover the screen with one pass of writes, so page flipping could double your speed over blitting.
On a typical modern 3D game that becomes fill limited, under 25% of the performance is in the blit, and often under 10% in scenes with significant overdraw.
In upcoming games that composite 20+ layers of textures, the cost of a blit is down in the noise.
Blits add flexibility. Anti-aliasing is better done through a blit operation than with a deep front buffer. Other operations, like converting from a 64 bit work pixel to a 32 bit display pixel, or performing convolutions, are also better done with blits.
Back buffers are more optimally arranged in tiled patterns, while front buffers prefer linear scans.
Basically, our back buffers are starting to look less like raster
Page flipping doesn't apply to windowed rendering unless you butcher the X server to render all 2D to multiple buffers and clip all 3D operations. I consider that a bad thing. Making the full screen rendering more distant from windowed rendering is also a bad thing.
Every implementation of page flipping brings in a class of bugs, and obfuscates several code paths. It's not worth it.
Make no mistake -- the PS2 is definately more powerful than the dreamcast.
For some types of things, it is easier to get a dreamcast game to look better due to a better back end filter, autoamtically working mip-mapping, and larger addressable texture space, but the second generation PS2 games should really start showing off the increased power.
Dreamcast should be able to undercut the price, but I don't know how significant that will be.
There are few things that I would really call "revolutionary", but that doesn't mean that Sony didn't build a good machine. It just happens to be built with a set of tradeoffs that I don't completely agree with.
John Carmack
Yes, the linux sales figures were low. Low enough that they are certainly not going to provide an incentive for other developers to do simultaneous linux releases, which was a good chunk of my goal. The sales would cover the costs of porting, but they wouldn't make a bean-counter blink.
I think Loki did a fantastic job - they went above and beyond what was required, pestering us (a good thing in this case) about the linux deliverables, taking pre-orders, doing the tin box run, shipping CDs first, then boxes when available, etc.
There are a number of possible reasons why you might not have bought the linux specific version:
You couldn't find the game in stores near you. This is going to remain a problem for quite some time.
The game is available earlier for windows. Even with a simultaneous release, this is going to continue. Big publishers making large lot runs get priority, and that is just life.
The game costs more for linux. This is probably also not going to change. The wholesale prices are probably the same, but big stores severely discount popular titles and advertise them to bring customers in. This won't happen with linux versions.
Configuring 3D on linux is a significant chore. I expect this will largely be gone by the time we ship another game. As the DRI drivers mature and XF4.0 becomes standard in distributions, people should start having out-of-box 3D support.
The game runs slower in linux than under windows. While we did have a couple benchmark victories on some cards, the general rule will still stand: a high performance card on windows will probably have more significant effort expended on optimization than it will get from an open source driver. Nvidia's drivers may be the exception, because all of their windows optimization work immediately applies to the linux version, but it is valid for most of the mesa based drivers.
Trying to change this would probably have negative long-term consequences. There are certainly coders in the open source community that are every bit as good of optimizers as the driver writers at the card companies, but I have always tried to restrain them from going gung-ho at winning benchmarks against windows. Mesa is going to be with us five years from now, and dodgy optimizations are going to make future work a lot more difficult.
Loki's position is that the free availability of linux executables for download to convert windows versions into linux versions was the primary factor. They have been recommending that we stop making full executables available, and only do binary patches.
I hate binary patches, and I think that going down that road would be making life more difficult for the people playing our games.
That becomes the crucial question: How much inconvenience is it worth to help nurture a new market? We tried a small bit of it with Q3 by not making the linux executables available for a while. Is it worth even more? The upside is that a visibly healthy independent market would bring more titles to it.
The fallback position is to just have hybrid CD's. I'm pretty sure we can force our publishers to have a linux executable in an "unsupported" directory. You would lose technical support, you wouldn't get an install program, and you wouldn't have anyone that is really dedicated to the issues of the product, but it would be there on day 1.
John Carmack
Re:That wasn't the carmack we know..
on
New Doom Details
·
· Score: 5
Alright. This is wierd. However, it's a natural progression. If we have ingame editing, most likely we won't be using BSP trees anymore, or perhaps we will turn culling off when we walk around. I think such a thing could be handled as a mod in the game. It just makes more sense than some win32 app that has completely different requirements than the game itself
"In game editor" is probably being confused here somewhat. I am NOT talking about running around in the game, moving brushes around as you play. The editor is still a completely different user interface, with multi-view outlined drawing in addition to a 3D view. It just happens to live in the same executable as the game, and shares lots of code with it.
John Carmack
Re:That wasn't the carmack we know..
on
New Doom Details
·
· Score: 5
> what happened to that? apart from it: can you imagine ID coding something in c++
First of all, the fact that none of our deployed games used OOP does not mean that I don't think there are benefits to it. In the early days, there were portability, performance, and bloat problems with it, so we never chose to deploy with it. However, all of the tools for DOOM and Quake were developed in Obejctive-C on NEXTSTEP. Q3 also came fairly close to have a JVM instead of the QVM interpreter, but it didn't quite fit my needs.
I'm still not a huge C++ fan, but anyone that will flat out deny the benefits of OOP for some specific classes of problems like UI programming and some game logic is bordering on being a luddite. I still don't think it is beneficial everywhere, but, if anything, I think we are behind the curve on making the transition.
> Carmack basically said, that single-player games suck from a money/replayability point of view
This was a balancing act in company morale and politics. My first choice for future projects would be to pursue the snowcrash-like extensible virtual worlds, but most of the company wants to work on a game with a story. We have three new hires coming on soon, so we are growing somewhat to support it.
> In the same interview he said, that he doesn't like integrated editors, and will never do so.
That was a significant change in my stance over the last year. Did I actually say "never"?
You can just take the short answer of "I was wrong", but here is the longer argument (I went over this some in the talk):
Historically, we could make better games by using exotic and expensive development hardware or software that differed significantly from our deployment platform.
While early games with integrated editors were hurting their 640k memory footprint and forcing developers to work with a 320 or 640 res screen for tool development, we were using NeXT workstations with megapixel displays for our tools.
Given the option of a good rendering technology that required a lot of preprocessing, we bought first a quad alpha, then a 16 way SGI to do the processing.
Even when we moved the editor to WinNT, it used intergraph workstation graphics, while our deployment platform was mostly still software rendered or possibly Voodoo based.
The key thing that changed (after that earlier speech) was that the optimal development platform is now the same thing as the optimal deployment platform: x86 + nvidia.
That is important. The tools/editor/game HAD to be separate before. Now, the question has to be looked at with a fresh view.
There was a lot of code that was present in nearly identical form in the utils, editor, and game. Misc functions, image loading, model loading, pk3 filesystem support, etc. It was one of my big goals to make all that common.
The obvious step would be to make libraries out of them, but I have something of a personal dislike for managing code that way.
Rather than just endlessly debating the issues, I just took a day and combined the utility code into the main project. It went well, and I was happy with the many thousands of lines of code that got removed, and the increased functionality that resulted. Later, Robert did the same thing with the editor.
I do fret about code bloat issues, but I feel quite good about all of the common and not-quite-orthogonal code that has been removed, and in the scope of the entire project, it really isn't that much space -- it adds maybe a megabyte to the executable, but it will never be paged in if you are just playing the game.
I do think there are real benefits to the user community from having the tools with the game -- my earlier objection were always based not wanting to give up any possible advantages that we could have as developers.
The advantages are going to be especially strong for the linux and mac platforms: the entire tool chain will be available from day one on every platform the game runs on.
Geez, I don't think this really rates a news story...
I put off an interviewer with questions about the X-Box by saying that I was on the X-Box Advisory Board, and probably shouldn't discuss specifics, instead of just my usual "sorry, too busy" reply.
Here is the longer answer:
At last years CGDC, Tim Sweeny and I had a meeting with Bill Gates about the X-Box. It was not handled well.
For weeks ahead of time, I had been pressing for technical information so I could have something useful to comment on at the meeting. A couple days before the meeting, I finally got an email directing me to "look at this EETimes article, they are pretty close". Yeah. Ok.
So, we just wound up just talking about generalities.
A while later, I was contacted about being on the formal advisory board, with a promise that it wouldn't be like that "trophy meeting" at CGDC, but would be making critiques of real documents.
I am on a lot of advisory boards, and they vary quite a bit in level of participation.
3DFX's advisory board meets every quarter, and we go over detailed technical things. Unfortunately, the very first advisory board of over two years ago discussed a part that still hasn't shipped, so it is hard to say what the impact is.
Apple's gaming advisory board has met three times, and was moderately productive.
Nvidia listed me as a member of their technical advisory board in their IPO filing, but there has never been a group meeting. I meet with them a couple times a year privately, but I haven't had a whole lot to complain about or suggest to them since they got past the RIVA 128 (until the recent push for 64 bit color)-- they have been doing a great job.
All of the other companies just informally stop by everey once in a while to discuss things.
I had made some suggestions to microsoft about DirectSound and DirectInput in past years that were always at the wrong time to ever get acted upon, so I don't know what to expect from this board.
So far, microsoft seems to be sticking to the plan -- I got a big fat binder of stuff in today to look over before our meeting next week.
I'm all for the X-Box as a console platform. The graphics hardware is a lot cooler than PS2, and there are a lot of other things going for it. I am still uneasy about all the market protection issues that go with consoles, but I tend to think that microsoft is a more open company than many of the traditional console companies.
I want microsoft to make good products. Heck, I want everyone to make good products. Even at the height of the D3D vs OpenGL antagonism, I had always given them source drops of what I was working on, and freedom to use it for demonstrating new features.
I had hoped that they would use it as a real-world testbed for new features, rather than just dreaming them up and making the industry follow their plan without ever really testing things out.
In any case, talking with MS has no bearing on my development decisions. I'm still using OpenGL, and we are still planning simultanious releases for linux and MacOS-X. If things work out well with X-Box, that may be added to the list.
All forces acting on a body can be summed to a vector through the CG and a rotation around it.
The thrust coming out at the nose or tail doesn't matter, it will still act through the CG.
--- R ! ! ! ! CG !
With a rocket exhausting down from R, there will be both an upwards acceleration and a clockwise rotation. That obviously won't fly straight.
----- R ! R ! ! ! CG !
With two rockets (or any symetric number), the rotational forces cancel out, leaving just a forward acceleration acting through CG. Again, no matter where the forces are applied to a rigid body, they act through CG.
This rocket will fly straight in an airless vaccuum, or in a perfect world with non-moving air and EXACTLY balanced engine thrust.
When a body has a center of pressure that isn't exactly at the center of gravity (almost everything but symetric and uniform blocks of material), a sideways gust of wind will cause a slight rotation of the rocket around around CG.
----- R ! R ! !W ! CG !
If a wind force acts to the left at W, it will cause an acceleration to the left through the CG and a counter-clockwise torque around CG. The existance of other forces on the same body have no effect whatsoever on this. The rockets don't thrust "down" (which WOULD cause a corrective force), they thrust "along the rocket".
A "stable" rocket will have the CP behind the CG, which causes the much larger forward aerodynamic forces to swing the rocket back towards it's direction of travel. That's why there is a minimum stable launch speed for unguided rockets -- the forward aerodynamic forces have to be larger than the sideways winds.
An "unstable" rocket with CP ahead of CG will fly straight as long as there are no winds and it is pointed exactly in it's direction of travel. As soon as there is a slight rotation, the forward aerodynamic forces push it in the same direction as the existing disturbance, reinforcing it into a rapid spin.
Direction of travel determines the orientation of CG and CP. This rocket will be stable when falling down, just not when flying up.
Again, the pendulum is different because it is not a single rigid body. If you didn't hook a bendulum to anything, it would fall without any rotation in an airless space, and would fly with it's CG (the ball) ahead of it's CP if thrown.
A pendulum has a pivot point, so when gravity tries to pull the center of gravity towards the earth, the linear acceleration is converted to a rotation torque around the pivot point, swinging the pendulum back down..
A rocket isn't held by anything, so the force of gravity will only pull it downwards, not cause any rotation. Gravity can't cause a rotation (ignoring very large scale gravity gradient issues), only aerodynamic forces.
Any wind will cause a rotation based on the CG/CP relationship, which will not be corrected by forward aerodynamic forces in this case because CP is forward of CG.
The truth is that I used to think along the same lines as this theory, but I built a couple models to test it, and they were complete failures.
After thinking about it for a while, I realized the difference between hanging from a pivot and having a force along the body.
At first I thought it was just bad reporting, with "Most of the weight will be behind, and gravity will keep the rocket pointed upward", but seeing the picture on his site backs that up.
Putting a big, fin-looking cockpit ahead of the fuel tank mass is going to make every breeze cause a heading change.
His site goes on with:
"What about guidance systems? The thrust will come out at the top of the rocket. An early American pioneer Robert Goddard did the same thing with his early test rockets. The rocket should "hang down" from the thrust like a pendulum"
That DOESN'T WORK.
It doesn't matter if a rocket is being pulled or pushed, all that matters is the relationship of the center of gravity to the center of pressure.
The reason why the intuitive "hangs like a pendulum" doesn't work out is that gravity acts on a deflected pendulum in a direction out of line with the pendulum string, while a rocket thrust will always be in line with the body.
Last I heard, Nvidia was going to be providing OpenGL for the X-Box. If they do, we will probably do some simultanious development for X-Box. If not, it would have to wait until after the game ships to be ported.
The X-Box specs put it as a larger leap over PSX2 than PSX2 is over Dreamcast, but anyone with sense can see that by the time it ships, the hardcore gaming PC will already be a generation ahead of it in raw power.
The X-Box should be able to keep up for a while, because you can usually expect to get about twice the performance out of a fixed platform as you would when shooting for the broad PC space, just because you can code much more specifically.
I don't have much of a personal stake in it, but I am pulling for the X-Box. If you need to pick a feudal lord in the console market, I would take microsoft over sony/sega/nintendo any day.
It is interesting watching the way the tides of public opinion flow around some technical issues.
Over the last year or two, it was amazing the amount of panic among hardware companies that Sony caused with the PlayStation 2. Engineers that really should have known better were walking around with a paniced look, thinking "my god, they are going to crush us, we need to rethink everything!". It was disturbing to see PR effect technical people that much.
PS2 is unquestionably the most powerfull console, but it is a straightforward evolutionary step in power, not the "unprecedented leap forward" that it was billed (and perceived) as. People generally realize that now.
Microsoft seems to have captured much of the same sense of technical inevitability with DX8.
DX8 is good. Microsoft has a long history of shipping an initially crappy product (DX3), then aggressively improving it until it is competative or superior to everything else. Many people underestimate the quality of microsoft's products by only forming opinions on early versions, and never revising them.
The crucial advances of DX8 are the vertex and pixel shaders. I think that the basic concepts are strong, and they will give real benefits.
I expect that that functionality will be exposed through OpenGL extensions by the time I need it.
For one thing, DX8 is modeled pretty closely on Nvidia's hardware, and Nvidia's hardware is already fully exposed through their register combiner extension, even somewhat moreso than under DX.
The issue will be finding consensus between the other hardware vendors.
The upside is that not all hardware designs are exactly in line with DX8, and some usefull and interesting features exist that DX8 doesn't expose. It is looking like several hardware vendors are making moves to expose ALL of their functionality through OpenGL extensions to be available when the product ships, rather than at the next DX cycle.
The other issue is still portability. I am 100% committed to delivering our next title on linux and MacOSX (NOT MaxOS-9), in an effectively simultanious timeframe. That would be more troublesome if I was gung-ho for DX8.
I'm happy that microsoft is doing a better job, but I don't feel that I will be in a disadvantaged position continuing to work with OpenGL.
John Carmack
Re:About Quake3's serial numbers....
on
Copyrant
·
· Score: 5
The "key generators" are all fakes. Some of them look like they work for a while because servers you have visited with a valid key keep a cache to let you in again.
As far as we know, there are no real key generators. If there were, we would have much more significant support issues.
We certainly will drop the CD-in-the-drive-for-single-player check in a future patch, that is our standard procedure after a game's primary sales are over.
The real answer is just inertia from NeXT, but there are some true technical advantages to the mach base.
The mach interfaces for virtual memory and task communication have more scope than the standard unix ones. I was rather surprised when I found out that linux memory management is still basically based on sbrk (although you can fake up virtual memory objects with mapped files yourself).
There definately is some weirdness when you can have so many different types of threads: mach threads/tasks, unix tasks (threads also?), AppKit threads, and possibly some form of Carbon threads. They all come down to mach primitives, but they aren't interchangable.
I specifically asked Steve Jobs about this last time I talked with him (several months ago), and he said that terminal won't be hidden away.
Not that he isn't allowed to change his mind about things...
I was pushing for including at least the command line compile/link tools with every install, but NeXT had an established history of having the development tools all on a separate CD, so it doesn't look like that is going to happen.
Slashdot Mirror
The article hints that the NV1's quadratic surfaces might have actually been a good thing, and it was held back by Microsoft's push to conformity with triangles.
:-)
Er, no.
For several years now, Nvidia has been kicking ass like no other graphics company, but lets not romanticize the early days. The NV1 sucked bad, and it would have been damaging to the development of 3D accelerators if it had gotten more widespread success. Microsoft did a good thing by standing firm against Nvidia's pressure to add quadratic surfaces to the initial version of D3D.
There is an intuitive notion that curved surfaces are "better" than triangles, because it takes lots of triangles to aproximate a curved surface.
In their most general form, they can be degenerated to perform the same functions as triangles, just at a huge waste in specification traffic.
Unfortunately, there have been a long string of products that miss the "most general form" part, and implement some form of patch surface that requires textures to be aligned with the patch isoparms. This seems to stem from a background in 2D graphics, where the natural progression from sliding sprites around goes to scaling them, then rotating them, then projecting them, then curving them.
3DO did it. Saturn did it. NV1 did it. Some people are probably working on displacement mapping schemes right now that are making the same mistake.
Without the ability to separate the texturing from the geometry, you can't clip any geometry in a general way (not even mentioning the fact that clipping a curve along anything but an isoparm will raise it's order), and you either live with texel density varying wildly and degenerating to points, or you have texture seams between every change in density. No ability to rotate a texture on a surface, project a texture across multiple surfaces, etc. You can't replace the generality if a triangle with primitives like that.
Even aside from the theoretical issues, NV1 didn't have any form of hidden surface removal, and the curve subdivision didn't stitch, frustum clip or do perspective. It was a gimmick, not a tool.
All water under the bridge now, of course. NV20 rocks.
John Carmack
We are still supporting linux.
The only downside of the next product is that initially it will probably only work at full feature level with the Nvidia OpenGL driver, but after the first test gets out (still a very long time in the future), I will jump back in to the driver development to try and bring the other open source drivers up to par.
John Carmack
We are going to continue to support linux in future products, but unfortunately it doesn't look like a strong business case can be made for it. The mac version outsold the linux version by quite a bit, and even that didn't hit 5% of the windows sales. Mac versions are still valid business cases, because the support is way easier than on either windows or linux platforms, and the sales numbers amount to something noticeable.
There is no way that a linux box will hit the shelf at the same time and have the same price as a windows box, assuming the publisher is making a maximum effort for the windows box. If this is truly a gating factor, linux boxed games just won't succeed.
Loki wants to get away from making games "convertable" between platforms, to force linux players to buy the linux boxes. I have issues with this. Not making executable binaries available online sucks. I hate binary patches, and requiring either patches from different versions, or the installation of all previous patches. Just releasing a new executable is so much easier.
Our options from here are to move towards a hybrid CD and pay Loki for official support (which makes linux support look like an expense, rather than a benefit), make a hybrid CD but leave the linux version in an "unsupported" directory, or just make unsupported linux executables available online like we used to.
It is going to be quite some time before DOOM ships, so we can't say anything definitive at this point.
I will probably do the initial development work for DOOM on linux, but I'm not interested in tracking every change that goes on in the linux world. The initial work will probably be with the Nvidia driver, which already has all the features I need, then I will work with the Open Source mesa drivers to bring them up to par.
John Carmack
I have been meaning to write an article about my involvement with, and impressions of the space community over the past year. Slashdot's space coverage started getting me interested in the field last year, and I wound up putting $34k into funding two of the CATS prize entries (JPA and SORAC). If one of them had won, they would have returned the funding money, but it was basically done as philanthropy.
From the outside, or with cursory knowledge, it seems so damn simple, and all the problems sound like they could have been prevented with a little thought. It's harder than it sounds. Feel free to help.
A lot of efforts came together in the last couple months, and none of them have been successful. After the fact, it's easy to toss off what should have been done.
Ky Michaelson's space shot got off better than most. It launched well, and went through it's full burn before losing a fin at mach 4+. If it had held together, it might have made it into space. Hindsight says he should have welded the fins.
The Wickman AN space booster static test CATO'd. Hindsight says he should have hydrotested the casing.
The HARC launch reached the full altitude for balloon launch (an achievement by itself), and the electronics all seemed to work, but the launch failed due to interference with the launch rail. Hindsight says they should have done a test launch from the ground with the launcher hung from scaffolding.
The SORAC team ran into some political and personal issues with the Bureau of Land Management, resulting in them being banned from black rock for a while, scrubbing their planned CATS launch. Being honest, it would have been a rush job if they had launched in the scheduled slot, but they still would have had a chance. Hindsight says they should have started cultivating the BLM bureaucrats at the start of the year.
JP Aerospace got fucked by the FAA. They have had licenses to try for 100km a couple times in the past, and they always turn everything in more than six months in advance and check up on the process constantly. Four days before they were heading to black rock, the FAA informed them that there were problems with their application. Hindsight doesn't say anything. There was still a pretty good chance JPA would have had problems with their new launch structure because they missed their last AWAY test run schedule, but they probably had the best shot.
Interorbital has a sea launch slot next week, but pushing for the last week of the prize sounds like things probably aren't quite ready to go.
The SORAC and JPA CATS rockets will still be launched when the proper permits are all in line again (the government agencies have turned around), so there is a decent chance that there will be an amateur rocket getting into space come spring, but unfortunately there won't be a payoff for them now that the prize is expiring.
John Carmack
>Q. After reading the voodooextreme interview, it sounds like you are pursuing an allmost completely different rendering pass/phases with Doom 3. Can you give us any more details? :-)
It adds up to lots and lots of passes. I am expecting the total overdraw to average around 30x when you have all features enabled.
>Q. Could you give us your thoughts on T&L? Why does 3Dfx say it's not important?
Contrary to some comments here, 3dfx didn't just "decide not to put in T&L", the didn't have that option. Product development cycles can take years, and you can't just change your mind at the end.
They don't have it, so naturally they downplay the importance of it.
John Carmack
>Reguardless, I won't buy either. Why? Because
>they both claim OpenGL support. Now, I don't
>know about you folks, but seeing as I work in
>AutoCAD frequently, that means hardware support.
>Neither of them have it. ATI doesn't. #9 didn't.
>Why? Most of them view software as the future.
All of the modern cards have full rasterization support for OpenGL, but I guess you are refering to geometry acceleration.
The situation has changed since you last looked at it.
The Nvidia GeForce cards have an extremely capable geometry accelerator, and they have the ability to fetch display lists either over AGP with a large bandwidth savings due to vertex reuse, or store the display lists completely in local memory to remove all vertex traffic from the bus.
The issue with professional OpenGL support has mostly been the focus of the driver writers, not the hardware. I think that Nvidia's partnering with ELSA to work on professional app certification with the Nvidia hardware was an extremely good move.
There are a few edges that the expensive professional boards still have over the nvidia consumer cards, but not many:
You can get more total memory, like a 32mb framebuffer and 64mb texture memory configuration. We will probably see workstation graphics systems with up to a gig of memory within a year. Consumer cards will offer 128mb next year, but the workstation cards can easily maintain an advantage there.
This has a cost, though: large, expandable memory subsystems can't be clocked as high as the single-option, short trace layouts that nvidia does. Even dual pipe workstation boards can't match the memory bandwidth of a GeForce2.
You generally get better high end DACs and shielding on workstation boards. The upper end of the consumer boards will do the high numbers, but it just isn't as clean of a signal.
Dual monitor has been supported much better on the workstation boards. This is starting to become a feature on consumer boards, which is welcome.
The consumer cards are still skimping on itterator precision bits. Under demanding conditions, like very large magnitude texcoord values stretched a small increment across a large number of pixels, you can see many consumer cards start getting fuzzy texel edges while the workstation cards still look rock solid.
Probably the most noticable case is in edge rasterization, where some workstation cards are so good that you don't usually notice T-Junction cracks in your data, while the consumer cards have them stand out all over the place.
Next years consumer cards should fix that.
When the consumer cards first started posting fill rate numbers higher than the professional boards, it was mostly a lie. They got impressive numbers at 640x480 in 16 bit color, without blending, depth buffering, and filtering, but if you turned on 32 bit, depth, blend, trilinear, and ran at high res, they could fall to 1/4 or less of the quoted value.
Today, there isn't a single combination of rendering attributes that will let a wildcat out-rasterize a GeForce2.
Wildcat was supposed to offer huge 8 and 16 way scalability that would offset that, but it doesn't look like it is coming any time soon.
The workstation vendors do stupid driver tricks to make CDRS go faster, while consumer vendors do stupid driver tricks to make Q3 go faster.
We bought three generations of intergraph/intense3D products, but the last generation (initial wildcat) was a mistake. We use nvidia boards for both professional work and gaming now. I still think the professional boards are a bit more stable, but they fell behind in other features, especially fill rate. Being an order of magnitude cheaper doesn't directly factor into our decisions, but it would for most people.
John Carmack
Actually, even the original Verite V1000 could do 32 bit color rendering.
At a whopping 6 mpix or so...
Rendition did a lot of things right, even on their very first card. They had all the blend modes and texture environments from the very beginning. The only thing they didn't have was per-pixel mip-mapping.
If they had delivered the V2xx series on time, they could have had a strong foothold before voodoo2. The V3xx seried would have been a solid TNT competitor, but again, it wasn't ready on time. They wound up ditching that entire generation.
John Carmack
PVS was The Right Thing when level geometry counts were much lower. With tens of thousands of polygons in a scene, creating a cluster tree directly from that becomes completely unrealistic from a space and time perspective.
The options are to either do PVS with a simplified version of the world, or ignore the geometry and just work with portal topology.
Unreal used a scan-line visibility algorithm, which crippled it's ability to have high poly counts or high framerates with hardware accelerators.
Tim Sweeny knows full well that the architecture is very wrong for modern systems, but many of the original decisions were based on earlier software technologies. Unreal was supposed to be a "killer app" for the Pentium-200 MMX processor.
I have a lot of respect for Tim and Unreal, but the visibility algorithm in Unreal turned out to be a bad call. He is changing it for future work.
John Carmack
I don't.
The argument for royalties is that it allows the console price to be lower, allowing more units to be sold, and theoretically allowing you to sell enough more units to offset the royalty.
The downside is that if a large chunk of the console revenue must be derived from software royalties, it must be made impossible to bypass the console company in the production of a title.
This forces them to resort to various copy protection and registered developer schemes, which open the door to all the back room scheming between publishers and the hardware vendor about shipping sequencing, and content aproval.
I would rather have a console that was six months less powerfull, but 100% completely open, and that anyone could press games for.
(Indrema has not disclosed me on their hardware.)
John Carmack
You have confused two different forms of compression.
S3TC is a modified form of block truncation coding (BTC), which involves selecting two colors and generating two other colors by interpolation. This is done with 4x4 blocks, giving very nearly 4 bits per pixel. This is nice because it doesn't require any additional tables.
Vector quantization is a general process where you try to take a large set of number strings and pick some subset that can be used to aproximate all of them reasonably. In the dreamcast's case, you specify 256 2x2 blocks, so each pixel is represented by 2 bits, but you also have 2k of codebook overhead. This works out pretty well for smaller textures, but large textures often come out badly because there just aren't enough codebook entries to reasonably aproximate it.
John Carmack
All signs are pointing towards a future without page flipping, so adding the messy infrastructure for it now would be a mistake. Don't let benchmarking furor encourage a messy code architecture.
Points:
The benefit of page flipping is decreasing as more and more computation is done per pixel to the back buffer.
In the old days of 2D scrollers, you might barely cover the screen with one pass of writes, so page flipping could double your speed over blitting.
On a typical modern 3D game that becomes fill limited, under 25% of the performance is in the blit, and often under 10% in scenes with significant overdraw.
In upcoming games that composite 20+ layers of textures, the cost of a blit is down in the noise.
Blits add flexibility. Anti-aliasing is better done through a blit operation than with a deep front buffer. Other operations, like converting from a 64 bit work pixel to a 32 bit display pixel, or performing convolutions, are also better done with blits.
Back buffers are more optimally arranged in tiled patterns, while front buffers prefer linear scans.
Basically, our back buffers are starting to look less like raster
Page flipping doesn't apply to windowed rendering unless you butcher the X server to render all 2D to multiple buffers and clip all 3D operations. I consider that a bad thing. Making the full screen rendering more distant from windowed rendering is also a bad thing.
Every implementation of page flipping brings in a class of bugs, and obfuscates several code paths. It's not worth it.
John Carmack
Make no mistake -- the PS2 is definately more powerful than the dreamcast. For some types of things, it is easier to get a dreamcast game to look better due to a better back end filter, autoamtically working mip-mapping, and larger addressable texture space, but the second generation PS2 games should really start showing off the increased power. Dreamcast should be able to undercut the price, but I don't know how significant that will be. There are few things that I would really call "revolutionary", but that doesn't mean that Sony didn't build a good machine. It just happens to be built with a set of tradeoffs that I don't completely agree with. John Carmack
Yes, the linux sales figures were low. Low enough that they are certainly not going to provide an incentive for other developers to do simultaneous linux releases, which was a good chunk of my goal. The sales would cover the costs of porting, but they wouldn't make a bean-counter blink.
I think Loki did a fantastic job - they went above and beyond what was required, pestering us (a good thing in this case) about the linux deliverables, taking pre-orders, doing the tin box run, shipping CDs first, then boxes when available, etc.
There are a number of possible reasons why you might not have bought the linux specific version:
You couldn't find the game in stores near you. This is going to remain a problem for quite some time.
The game is available earlier for windows. Even with a simultaneous release, this is going to continue. Big publishers making large lot runs get priority, and that is just life.
The game costs more for linux. This is probably also not going to change. The wholesale prices are probably the same, but big stores severely discount popular titles and advertise them to bring customers in. This won't happen with linux versions.
Configuring 3D on linux is a significant chore. I expect this will largely be gone by the time we ship another game. As the DRI drivers mature and XF4.0 becomes standard in distributions, people should start having out-of-box 3D support.
The game runs slower in linux than under windows. While we did have a couple benchmark victories on some cards, the general rule will still stand: a high performance card on windows will probably have more significant effort expended on optimization than it will get from an open source driver. Nvidia's drivers may be the exception, because all of their windows optimization work immediately applies to the linux version, but it is valid for most of the mesa based drivers.
Trying to change this would probably have negative long-term consequences. There are certainly coders in the open source community that are every bit as good of optimizers as the driver writers at the card companies, but I have always tried to restrain them from going gung-ho at winning benchmarks against windows. Mesa is going to be with us five years from now, and dodgy optimizations are going to make future work a lot more difficult.
Loki's position is that the free availability of linux executables for download to convert windows versions into linux versions was the primary factor. They have been recommending that we stop making full executables available, and only do binary patches.
I hate binary patches, and I think that going down that road would be making life more difficult for the people playing our games.
That becomes the crucial question: How much inconvenience is it worth to help nurture a new market? We tried a small bit of it with Q3 by not making the linux executables available for a while. Is it worth even more? The upside is that a visibly healthy independent market would bring more titles to it.
The fallback position is to just have hybrid CD's. I'm pretty sure we can force our publishers to have a linux executable in an "unsupported" directory. You would lose technical support, you wouldn't get an install program, and you wouldn't have anyone that is really dedicated to the issues of the product, but it would be there on day 1.
John Carmack
"In game editor" is probably being confused here somewhat. I am NOT talking about running around in the game, moving brushes around as you play. The editor is still a completely different user interface, with multi-view outlined drawing in addition to a 3D view. It just happens to live in the same executable as the game, and shares lots of code with it.
John Carmack
> what happened to that? apart from it: can you imagine ID coding something in c++
First of all, the fact that none of our deployed games used OOP does not mean that I don't think there are benefits to it. In the early days, there were portability, performance, and bloat problems with it, so we never chose to deploy with it. However, all of the tools for DOOM and Quake were developed in Obejctive-C on NEXTSTEP. Q3 also came fairly close to have a JVM instead of the QVM interpreter, but it didn't quite fit my needs.
I'm still not a huge C++ fan, but anyone that will flat out deny the benefits of OOP for some specific classes of problems like UI programming and some game logic is bordering on being a luddite. I still don't think it is beneficial everywhere, but, if anything, I think we are behind the curve on making the transition.
> Carmack basically said, that single-player games suck from a money/replayability point of view
This was a balancing act in company morale and politics. My first choice for future projects would be to pursue the snowcrash-like extensible virtual worlds, but most of the company wants to work on a game with a story. We have three new hires coming on soon, so we are growing somewhat to support it.
> In the same interview he said, that he doesn't like integrated editors, and will never do so.
That was a significant change in my stance over the last year. Did I actually say "never"?
You can just take the short answer of "I was wrong", but here is the longer argument (I went over this some in the talk):
Historically, we could make better games by using exotic and expensive development hardware or software that differed significantly from our deployment platform.
While early games with integrated editors were hurting their 640k memory footprint and forcing developers to work with a 320 or 640 res screen for tool development, we were using NeXT workstations with megapixel displays for our tools.
Given the option of a good rendering technology that required a lot of preprocessing, we bought first a quad alpha, then a 16 way SGI to do the processing.
Even when we moved the editor to WinNT, it used intergraph workstation graphics, while our deployment platform was mostly still software rendered or possibly Voodoo based.
The key thing that changed (after that earlier speech) was that the optimal development platform is now the same thing as the optimal deployment platform: x86 + nvidia.
That is important. The tools/editor/game HAD to be separate before. Now, the question has to be looked at with a fresh view.
There was a lot of code that was present in nearly identical form in the utils, editor, and game. Misc functions, image loading, model loading, pk3 filesystem support, etc. It was one of my big goals to make all that common.
The obvious step would be to make libraries out of them, but I have something of a personal dislike for managing code that way.
Rather than just endlessly debating the issues, I just took a day and combined the utility code into the main project. It went well, and I was happy with the many thousands of lines of code that got removed, and the increased functionality that resulted. Later, Robert did the same thing with the editor.
I do fret about code bloat issues, but I feel quite good about all of the common and not-quite-orthogonal code that has been removed, and in the scope of the entire project, it really isn't that much space -- it adds maybe a megabyte to the executable, but it will never be paged in if you are just playing the game.
I do think there are real benefits to the user community from having the tools with the game -- my earlier objection were always based not wanting to give up any possible advantages that we could have as developers.
The advantages are going to be especially strong for the linux and mac platforms: the entire tool chain will be available from day one on every platform the game runs on.
John Carmack
Geez, I don't think this really rates a news story...
I put off an interviewer with questions about the X-Box by saying that I was on the X-Box Advisory Board, and probably shouldn't discuss specifics, instead of just my usual "sorry, too busy" reply.
Here is the longer answer:
At last years CGDC, Tim Sweeny and I had a meeting with Bill Gates about the X-Box. It was not handled well.
For weeks ahead of time, I had been pressing for technical information so I could have something useful to comment on at the meeting. A couple days before the meeting, I finally got an email directing me to "look at this EETimes article, they are pretty close". Yeah. Ok.
So, we just wound up just talking about generalities.
A while later, I was contacted about being on the formal advisory board, with a promise that it wouldn't be like that "trophy meeting" at CGDC, but would be making critiques of real documents.
I am on a lot of advisory boards, and they vary quite a bit in level of participation.
3DFX's advisory board meets every quarter, and we go over detailed technical things. Unfortunately, the very first advisory board of over two years ago discussed a part that still hasn't shipped, so it is hard to say what the impact is.
Apple's gaming advisory board has met three times, and was moderately productive.
Nvidia listed me as a member of their technical advisory board in their IPO filing, but there has never been a group meeting. I meet with them a couple times a year privately, but I haven't had a whole lot to complain about or suggest to them since they got past the RIVA 128 (until the recent push for 64 bit color)-- they have been doing a great job.
All of the other companies just informally stop by everey once in a while to discuss things.
I had made some suggestions to microsoft about DirectSound and DirectInput in past years that were always at the wrong time to ever get acted upon, so I don't know what to expect from this board.
So far, microsoft seems to be sticking to the plan -- I got a big fat binder of stuff in today to look over before our meeting next week.
I'm all for the X-Box as a console platform. The graphics hardware is a lot cooler than PS2, and there are a lot of other things going for it. I am still uneasy about all the market protection issues that go with consoles, but I tend to think that microsoft is a more open company than many of the traditional console companies.
I want microsoft to make good products. Heck, I want everyone to make good products. Even at the height of the D3D vs OpenGL antagonism, I had always given them source drops of what I was working on, and freedom to use it for demonstrating new features.
I had hoped that they would use it as a real-world testbed for new features, rather than just dreaming them up and making the industry follow their plan without ever really testing things out.
In any case, talking with MS has no bearing on my development decisions. I'm still using OpenGL, and we are still planning simultanious releases for linux and MacOS-X. If things work out well with X-Box, that may be added to the list.
John Carmack
All forces acting on a body can be summed to a vector through the CG and a rotation around it.
The thrust coming out at the nose or tail doesn't matter, it will still act through the CG.
---
R !
!
!
!
CG
!
With a rocket exhausting down from R, there will be both an upwards acceleration and a clockwise rotation. That obviously won't fly straight.
-----
R ! R
!
!
!
CG
!
With two rockets (or any symetric number), the rotational forces cancel out, leaving just a forward acceleration acting through CG. Again, no matter where the forces are applied to a rigid body, they act through CG.
This rocket will fly straight in an airless vaccuum, or in a perfect world with non-moving air and EXACTLY balanced engine thrust.
When a body has a center of pressure that isn't exactly at the center of gravity (almost everything but symetric and uniform blocks of material), a sideways gust of wind will cause a slight rotation of the rocket around around CG.
-----
R ! R
!
!W
!
CG
!
If a wind force acts to the left at W, it will cause an acceleration to the left through the CG and a counter-clockwise torque around CG. The existance of other forces on the same body have no effect whatsoever on this. The rockets don't thrust "down" (which WOULD cause a corrective force), they thrust "along the rocket".
A "stable" rocket will have the CP behind the CG, which causes the much larger forward aerodynamic forces to swing the rocket back towards it's direction of travel. That's why there is a minimum stable launch speed for unguided rockets -- the forward aerodynamic forces have to be larger than the sideways winds.
An "unstable" rocket with CP ahead of CG will fly straight as long as there are no winds and it is pointed exactly in it's direction of travel. As soon as there is a slight rotation, the forward aerodynamic forces push it in the same direction as the existing disturbance, reinforcing it into a rapid spin.
Direction of travel determines the orientation of CG and CP. This rocket will be stable when falling down, just not when flying up.
Again, the pendulum is different because it is not a single rigid body. If you didn't hook a bendulum to anything, it would fall without any rotation in an airless space, and would fly with it's CG (the ball) ahead of it's CP if thrown.
John Carmack
A pendulum has a pivot point, so when gravity tries to pull the center of gravity towards the earth, the linear acceleration is converted to a rotation torque around the pivot point, swinging the pendulum back down..
A rocket isn't held by anything, so the force of gravity will only pull it downwards, not cause any rotation. Gravity can't cause a rotation (ignoring very large scale gravity gradient issues), only aerodynamic forces.
Any wind will cause a rotation based on the CG/CP relationship, which will not be corrected by forward aerodynamic forces in this case because CP is forward of CG.
The truth is that I used to think along the same lines as this theory, but I built a couple models to test it, and they were complete failures.
After thinking about it for a while, I realized the difference between hanging from a pivot and having a force along the body.
John Carmack
At first I thought it was just bad reporting, with "Most of the weight will be behind, and gravity will keep the rocket pointed upward", but seeing the picture on his site backs that up.
Putting a big, fin-looking cockpit ahead of the fuel tank mass is going to make every breeze cause a heading change.
His site goes on with:
"What about guidance systems? The thrust will come out at the top of the rocket. An early American pioneer Robert Goddard did the same thing with his early test rockets. The rocket should "hang down" from the thrust like a pendulum"
That DOESN'T WORK.
It doesn't matter if a rocket is being pulled or pushed, all that matters is the relationship of the center of gravity to the center of pressure.
The reason why the intuitive "hangs like a pendulum" doesn't work out is that gravity acts on a deflected pendulum in a direction out of line with the pendulum string, while a rocket thrust will always be in line with the body.
John Carmack
Last I heard, Nvidia was going to be providing OpenGL for the X-Box. If they do, we will probably do some simultanious development for X-Box. If not, it would have to wait until after the game ships to be ported.
The X-Box specs put it as a larger leap over PSX2 than PSX2 is over Dreamcast, but anyone with sense can see that by the time it ships, the hardcore gaming PC will already be a generation ahead of it in raw power.
The X-Box should be able to keep up for a while, because you can usually expect to get about twice the performance out of a fixed platform as you would when shooting for the broad PC space, just because you can code much more specifically.
I don't have much of a personal stake in it, but I am pulling for the X-Box. If you need to pick a feudal lord in the console market, I would take microsoft over sony/sega/nintendo any day.
John Carmack
It is interesting watching the way the tides of public opinion flow around some technical issues.
Over the last year or two, it was amazing the amount of panic among hardware companies that Sony caused with the PlayStation 2. Engineers that really should have known better were walking around with a paniced look, thinking "my god, they are going to crush us, we need to rethink everything!". It was disturbing to see PR effect technical people that much.
PS2 is unquestionably the most powerfull console, but it is a straightforward evolutionary step in power, not the "unprecedented leap forward" that it was billed (and perceived) as. People generally realize that now.
Microsoft seems to have captured much of the same sense of technical inevitability with DX8.
DX8 is good. Microsoft has a long history of shipping an initially crappy product (DX3), then aggressively improving it until it is competative or superior to everything else. Many people underestimate the quality of microsoft's products by only forming opinions on early versions, and never revising them.
The crucial advances of DX8 are the vertex and pixel shaders. I think that the basic concepts are strong, and they will give real benefits.
I expect that that functionality will be exposed through OpenGL extensions by the time I need it.
For one thing, DX8 is modeled pretty closely on Nvidia's hardware, and Nvidia's hardware is already fully exposed through their register combiner extension, even somewhat moreso than under DX.
The issue will be finding consensus between the other hardware vendors.
The upside is that not all hardware designs are exactly in line with DX8, and some usefull and interesting features exist that DX8 doesn't expose. It is looking like several hardware vendors are making moves to expose ALL of their functionality through OpenGL extensions to be available when the product ships, rather than at the next DX cycle.
The other issue is still portability. I am 100% committed to delivering our next title on linux and MacOSX (NOT MaxOS-9), in an effectively simultanious timeframe. That would be more troublesome if I was gung-ho for DX8.
I'm happy that microsoft is doing a better job, but I don't feel that I will be in a disadvantaged position continuing to work with OpenGL.
John Carmack
The "key generators" are all fakes. Some of them look like they work for a while because servers you have visited with a valid key keep a cache to let you in again.
As far as we know, there are no real key generators. If there were, we would have much more significant support issues.
We certainly will drop the CD-in-the-drive-for-single-player check in a future patch, that is our standard procedure after a game's primary sales are over.
John Carmack
The real answer is just inertia from NeXT, but there are some true technical advantages to the mach base.
The mach interfaces for virtual memory and task communication have more scope than the standard unix ones. I was rather surprised when I found out that linux memory management is still basically based on sbrk (although you can fake up virtual memory objects with mapped files yourself).
There definately is some weirdness when you can have so many different types of threads: mach threads/tasks, unix tasks (threads also?), AppKit threads, and possibly some form of Carbon threads. They all come down to mach primitives, but they aren't interchangable.
John Carmack
I specifically asked Steve Jobs about this last time I talked with him (several months ago), and he said that terminal won't be hidden away.
Not that he isn't allowed to change his mind about things...
I was pushing for including at least the command line compile/link tools with every install, but NeXT had an established history of having the development tools all on a separate CD, so it doesn't look like that is going to happen.
John Carmack
Apogee distributed the shareware trilogy of Wolf3D.
Id wrote the game.
John Carmack