John Carmack Slashdot Archive

There have been a few things that didn't have prior art that probably could have been gotten past a patent examiner -- constant Z perspective texturing in DOOM, surface caching in Q1, and the overbright gamma table stuff to trade range for precision in Q3, for example. The patent issue came up at Id a few times until a made it perfectly clear that if the company pursued any patents, I would leave.

Hey, I didn't say "virtual reality"... I tend to agree with your assessment. VR is a term loaded with high-enthusiasm / low-results connotations. We have worked with a few VR companies in the past, and I have always found them to not have finishing ability. So much of the VR world (and much other academic style research) is high concept, but sketchy on the details. Most VR experiences are heavy on the "You are in a virtual world!!!!", but don't spend too much time on exactly what you are supposed to be doing there. Can you poke and prod to find interesting things? What happens when someone pushes you? Can you dodge something effectively? Are the controls linear, or integrated over time? etc. I think that one of my strengths is a blend of idealism and pragmatism that has resulted in good results over the years. In any case, of the half dozen things I listed, I am clearly not going to be able to do all of them, so it may be a moot point...

I am typing this on a loaded SGI 320.

When it debuted, it was a very good all around performar, and it had the highest fill rate of any intel based system.

Now, an Nvidia GeForce is just plain superior in almost every aspect. Higher fill rate, even in high res, 32 bit, trilinear modes. Faster, more capable geometry acceleration.

Any remaining areas of SGI superiority are probably due to driver optimization rather than hardware architecture. Nvidia hasn't had much call to optimize stippled lines, for instance.

The super-memory-system wasn't all it was touted to be. It worked well for sharing the load between the graphics and the cpu, but the cpu didn't actually see any better bandwidth than on a standard intel chipset. The cpu write bandwidth was actually about 10% LOWER than a consumer machine.

I have used a lot of intergraph and sgi machines, and the bottom line is that the consumer hardware has just outpaced the workstation hardware because they were on different growth curves. The workstations are better than they have ever been, but the consumer systems are just orders of magnitude better than they used to be.

I think SGI shot too low with the VW's graphics, somewhat out of fear of canibalizing their other workstations, and somewhat out of underestimating the consumer competition. Being quite a bit late didn't help, either.

For back end rendering, they have a room full of MP sparc boxes. To my "SPARC? Why use the slowest of risc processors?" question, they replied that it isn't the speed of the individual processors that was important to them, but the speed PER CUBIC FOOT OF SPACE. Sun made quad pizza boxes, so it was computationally dense.

For modeling and development, they use a lot of SGI octanes. They also use linux + mesa for some internal tools.

This has been discussed before, and has been going on with the previous tests.

The message of the day server was intended as a half-assed auto update feature that could be cross platform.

We send a normal message most of the time, but if the version is out of date, we can send a message with telling you where to get the update.

I didn't want to deal with binary auto-updates on three platforms, and I worry a bit about security issues with that in any case.

You can disable it by setting "cl_motd 0" when the game starts up if you really don't want to send anything or see our message.

We added the result of glGetString( GL_RENDER ) to get some much needed information about the distribution of video cards and drivers.

We can see how many people aren't following directions and running glsetup. This is a big support issue.

We can see how many people are running minidrivers, which are going to make our lives a mess in the future.

We can see how many mac (steady 5%) and linux (5%at initial release, tailed off to 2%, probably due to dual booting) people are playing.

Getting this information has been usefull. We can compare the numbers of people playing with a given card with the amount of support emails we field, so we know which vendors (3DFX) we need to give more crap about their driver quality.

When the article first showed up, I thought "It IS documented in the release!". I went and looked, and unfortunately, that documentation from the previous release didn't make it into the latest release. Sigh. Our fuckup.

Apropriate quote: "Never attribute to malice what can be explained by incompetence".

I remain unconvinced that we have done something morally offensive.

Yes, we could have (should have, meant to) included a notice that it was going on in the EULA, but honestly, how many people carefully read and consider every line of all the EULA's they click through? How much of a difference would that have made to people?

I dislike lengthy legal verbiage, but it is reactions exactly like these that cause them to grow. Every time someone says "Sue 'em!" over something, a lawyer proposes another paragraph in a license document.

The most upstanding thing to do would be to have explicit UI that asks on installation if you don't mind sending your data when you play multiplayer games. I would consider that justified if we were sending a detailed system spec. That is something we may want to do in the future. Data like that is helpfull in making good development decisions.

But this is just a driver string riding along with your game version. It just seems silly, like requiring you to acknowledge before leaving your house that someone might see you. I would rather have fixed a bug somewhere.

I can see that it is a slipperly slope to be on, and I can easily project it to a scenario that I would be offended by, but I just can't convince myself that knowing the reletive distribution of different OpenGL implementations is violating people's rights.

The system was set up to allow us to notify people with a one-line message when their versions are out of date. I imagine some people are offended even by that, but I consider that a positive service to the community.

Including the renderer string was an afterthought to get some good unbiased data to help make future decisions on. Every once in a while we tally up the numbers, then dump all the logs. That's it.

Producing a mac version of glquake or glquakeworld should be pretty easy with the existing code now that Apple has real OpenGL support.

Producing a version of the software renderer with decent performance would be VERY HARD. A huge amount of effort went into the assembly optimization for the PPC, and it still didn't quite measure up to the x86 code.

Heh. You don't know how much trouble it is to convince biz oriented people that this isn't just plain stupid.

While thinking in terms of money and profit are probably good ways of understanding the way most things work in the world, don't let yourself become so jaded or cynical to think that it is the ONLY way things work.

I do think The World Would Be A Better Place if all software companies released older code so users still interested could work with it or learn from it. (I'm not holding my breath, though)

Nope. We are the copyright holder of all works, and we can release any part of it under any license we choose.

Completely aside from that, I think it is still unclear exactly where the GPL wants the separation of code and content.

Few would argue that every document read by a GPL word processor would be covered by the GPL, and most would place maps entered by quake into that catagory, but things can quickly get murky.

Quake game mods are written in QC, but turned into data to be processed by the main code. I think the spirit of the GPL would want that code to be released, but it is only a small step from there to saying that every program loaded by a GPL operating system must be GPL, which is clearly not the case.

How about this:

Make a closed source program that acts as an exe loader / verifier / proxy for the open source main game.

First, the Quake architecture of (reletively) dumb clients conencted to an authoritative server prevents the egregious cheating possible in some games ("I say you are dead now!", "I say I have infinite ammo!").

For the most part, a cheating client can't make their character do anything that couldn't happen as a result of normal game interaction.

The cheating clients/proxies focus on two main areas -- giving the player more information than they should have, and performing actions more skillfully.

The "more information" part can take a number of forms. A reletively harmless one is adding timers for items and powerups. Good players will track a lot of that in their heads, but a simple program can "remind" players of it.

Media cheating provides more information. Changing all the other player skins to bright white and removing all the shadows from a level give players an advantage not within the spirit of the game. Some would say cranking your screen brightness and gamma way up is one step on that path.

More advanced clients can make available information that is not normally visible at all. The server sends over all of the entities in the potentially visible set, because the client can move around a fair amount between updates. This means that the client is often aware of the locations of players that are around corners. A proxy can display this information in a "scanner window". The server could be changed to only send over clients actually visible, but that would result in lots of players blinking in and out as you move around or turn rapidly.

The worst cheats are the aim bots. In addition to providing more information, they override the player's commands to aim and fire with very high accuracy. The player usually "drives" around the level, and the program aims and shoots for them. This is usually extremely devestating and does ruin the game for most people.

There are many possible countermeasures.

There are server-side countermeasures that look for sequences of moves that are likely to be bot-generated and not human-generated, but that is an arms race that will end with skilled human players eventually getting identified as subtle bots.

Media cheats can be protected by various checksums, as we do in Q3 with the sv_pure option. This is only effective if the network protocol is not compromised, because otherwise a proxy can tell the client that it's hacked media are actually ok.

If the network protocol is not known, then the extra-information cheats generally can't happen unless you can hack the client source.

Q3 performs various bits of encryption on the network protocol, but that is only relying on security through obscurity, and a sufficiently patient person with a disassembler can eventually backtrack what is happening. If only they would find something more usefull to spend their time on...

With an open source client, the network communication protocol is right there in the open, so any encryption would be futile.

Any attempt at having the client verify itself isn't going to work out, because a cheating client can just always tell you what you want to hear. People have mentioned nettreck several times, but I don't see how a completelty open source program can keep someone from just reporting what it is supposed to for a while (perhapse using a "real" copy to generate whatever digests are asked for), then switching to new methods. Anyone care to elaborate?

I think a reasonable plan is to modify QW so that to play in "competition mode", it would have to be launched by a separate closed-source program that does all sorts of encryption and verification of the environment. If it just verifies the client, it would prevent the trivial modified client scanners and aim bots. It could verify the media data to prevent media information cheating. To prevent proxy information cheating and aim bots, it would have to encrypt the entire data stream, not just the connection process. That might have negative consequences on latency unless the encrypter is somehow able to be in the same address space as the verified client or scheduling can be tweaked enough to force task switches right after sends.

In the end, it is just a matter of making it more difficult for the cheaters. If all it takes is editing and recompiling a file, lots of people will cheat. This is indeed a disadvantage of open source games. If they have to grovel over huge network dumps and disassemblies to hack a protocol, a smaller number of cheats will be available.

Even if the programs were completely guaranteed secure (I havem't been convinced that is possible even in theory), an aim bot could be implemented at the device driver level.

It would be a lot more work, but a program could be implemented that intercepts the video driver, the mouse driver, and the keyboard driver, and does bot calculations completely from that.

Kind of sucks, doesn't it?

Thank you.

Lots of people were just waving their hands saying "Netreck solved this years ago" without being specific.

As you say, it isn't really a solution. If there were a couple million people playing netrek, there would be cheat proxies for it just like there are for Quake.

I think everyone can agree that it just isn't possible to solve the problem completely, you can only make it more difficult, which is exactly what the netrek solution is -- release binaries without the exact source and make it difficult to decypher.

An Nvidia GeForce/quadro kicks the crap out of a $100k+ SGI reality engine on just about any test you could devise.

The reality engine is quite a few years old, and its follow on, the infinite reality and IR2 still have some honest advantages. You can scale them with enough raster boards so that they have more fill rate, and they do have some other important features like configurable multisample anti-aliasing and 48 bit color.

Even now, lots of applications can be compiled on both platforms and just run much better on WinNT+nvidia than on the best sgi platform available. Having a 700mhz+ main processor helps, irrespective of the graphics card.

Some people still have a knee-jerk reaction that claims that "real applications" still run better on the high end hardware, and there are indeed some examples, but the argument bears a whole lot of resemblence to the ones put forth by the last defenders of ECL vector supercomputers.

Most people's applications don't show advantages on high end SGI hardware.

The big issue is the pace of progress -- SGI aimed for a new graphics family every three years with a speed bump in between. The PC vendors aim for a new generation every year with a speed bump at six months.

There are valid, legal ways to provide a level of protection equal to closed source binaries (which is really only a level of obfuscation).

I realize that they (proxies / loaders / obfuscated modules) may be more of a hassle, but he doesn't get to choose to break the license to avoid a hassle. I traded several emails with Slade over the past month, and I still have a degree of sympathy for his position, but I can't just let him walk around the code license.

All the conspiracy theories about me wanting to destroy the Quake community are silly. I loved what happened with the DOOM source release, and I hoped that the Quake release would have similar effects.

I had talked with Zoid about it a few times over the years, and I think he is making a pretty good decision.

It wasn't always clear from the outside, but Zoid was a remote contractor, not an employee. It was a low key relationship that worked out well for all of us. He stayed in canada and basically worked on whatever he liked, because I thought he had pretty good judgement. He had responsibility for the linux ports and the CTF code, but much of his time was his to allocate as he wanted.

With Loki now picking up the maintenance of the linux port (as well as my steadily increasing involvement with linux), and a new game design starting at Id, his choice was basically to either go develop a brand new Q3 mod by himself, or go work for one of the many gaming companies that had been trying to hire him.

We weren't interested in bringin on another core programmer at id, especially another one with immigration hassles (we have had enough issues with that for a small company). We would have been happy to continue the current arrangement indefinately, but he wanted to get out of the holding pattern.

Another thing he mentioned that I am sympathetic to is the desire to get a bit out of the community limelight. Being a public figure of some note isn't always all it is cracked up to be.

We are parting on the best of terms (leaving right AFTER a project completes is the considerate way to go). He is going to finish up the Quake2 linux updates (better X/GLX support), even if he has to complete the work from his new job.

Static web serving is not problem (once you debug the code).

Nothing is a problem once you debug the code.

I have been following both Cray and Tera for many years now. I have been saddened watching the last of the supercomputer companies wither and die. Supercomputers were always so COOL, but for most things, they just aren't so "super" any more.

I have benchmarked several of my back end utilities on cray systems, and one of them on the early tera machine (the early compiler exploded on the others). None of the single processor runs were as fast as a pentium III, and this was quite some time ago.

Understand that this was often branchy and recursive code running with only 3D sized vectors, so it isn't the sweet spot for traditional supercomputers. If I was doing nothing but multiplying 1k by 1k matricies of doubles, even a five year old cray would kick the crap out of the latest athalon. Unfortunately, none of my code looks like that.

I even spent some time thinking how I could restructure calculations into a vectorizable form, which might make a cray J90 competative. I wanted to buy a Cray! Of course, this was silly. It took less effort to make the code SMP friendly, and the payoff was much larger.

We wound up with a 16 processor SGI origin-2000 system, which has been easy to develop for and predictable in performance. We just recently bought an 8 processor Xeon, which is actually faster than our old 16 processor SGI, but at exactly one tenth the price (the downside is that it is maxed out, while the SGI still has tons of growth potential).

I program all heavy workloads in a parallel fashion now as a matter of habit, but it is easy to overstate the benefits of parallel systems.

The common lunux advocate position of "beowulf makes supercomputers obsolete" isn't quite right. Even with code that is already written in a parallel manner, there is a large difference between developing for a shared memory system and a distributed cluster. Developing a compute (and especially data) intensive program for a cluster rather sucks.

If there was a single processor system that was really four times as fast as "consumer" machines, even if it cost fifty times as much, we would buy it. Unfortunately, there isn't. When the product release cycles are favorable, Alpha systems may be twice as good as x86 systems, but not much beyond that unless you are doing the 1k by 1k matrix type stuff.

It is often forgotten that the original Cray-1 was largely a success because it was the fastest SCALAR processor of the time. The vectorization was just a bonus. Now, vectorization is the only thing that gives them a reason for existance.

The tera architecture is very interesting, but for scalar code, it is VERY, VERY slow. I'm not sure if it will be competative with large processor count SGI origin-2000 systems even after it matures. It gains ease of programming from the lack of caches, but it gives away a lot of problem domains where it is going to look stupidly slow.

If a supercomputer company could make a scalar processor that ran many times faster than existing processors and had similar SMP capabilities, it would probably be a success. Even if it cost a million dollars, filled a room, and burned hundreds of kwatts.

The problem isn't really that supercomputers are bad, its just that we are so spoiled by how AMAZINGLY GOOD our cheap consumer hardware is.

I do still worry about the stiffling of innovation that comes from having so few architectural directions for systems, but in the end, wall clock performance is what really matters.

I actually dug up all my old jaguar development hardware to give to these guys a year or two ago.

Unfortunately, it turned out that I had lost the C compiler that I had retargeted to the jaguar RISC engines, so DOOM was no longer buildable.

There is something noble about developing on a dead platform -- it is so completely for the joy of the development, without any commercial motivation.

The quick recap on the jaguar:

The memory, bus, blitter and video processor were 64 bits wide, but the processors (68k and two custom risc processors) were 32 bit.

The blitter could do basic texture mapping of horizontal and vertical spans, but because there wasn't any caching involved, every pixel caused two ram page misses and only used 1/4 of the 64 bit bus. Two 64 bit buffers would have easily trippled texture mapping performance. Unfortunate.

It could make better use of the 64 bit bus with Z buffered, shaded triangles, but that didn't make for compelling games.

It offered a usefull color space option that allowed you to do lighting effects based on a single channel, isntead of RGB.

The video compositing engine was the most innovative part of the console. All of the characters in Wolf3D were done with just the back end scalar instead of blitting. Still, the experience with the limitations and hard failure cases of that gave me good amunition to rail against microsoft's (thankfully aborted) talisman project.

The little risc engined were decent processors. I was surprised that they didn't use off the shelf designs, but they basically worked ok. They had some design hazards (write after write) that didn't get fixed, but the only thing truly wrong with them was that they had scratchpad memory instead of caches, and couldn't execute code from main memory. I had to chunk the DOOM renderer into nine sequentially loaded overlays to get it working (with hindsight, I would have done it differently in about three...).

The 68k was slow. This was the primary problem of the system. You options were either taking it easy, running everything on the 68k, and going slow, or sweating over lots of overlayed parallel asm chunks to make something go fast on the risc processors.

That is why playstation kicked so much ass for development -- it was programmed like a single serial processor with a single fast accelerator.

If the jaguar had dumped the 68k and offered a dynamic cache on the risc processors and had a tiny bit of buffering on the blitter, it could have put up a reasonable fight against sony.

Now the LYNX, on the other hand, was very much The Right Thing from a programming standpoint. A fast little processor (for its niche), a good color bitmapped display, and a general purpose blitter.

Price and form factor weighed too heavily against it.

Actually, I believe you're referring to Carl Forhan of Songbird Productions

Heh, sorry... I just assumed all jaguar development was coming from a single crazy group. :-)

Even if the memory controller hadn't been broken, performance would still have sucked really bad without a cache.

The jaguar was definately significantly hampered by its technical flaws, which kept me from ever being too big of a jaguar booster. I was proud of my work on Wolf and DOOM (more so than just about any of the other console work Id has been involved in until just recently), but in the end, the better consoles won the war.

I was only into the Apple II/IIGS during the Amiga's strong times, so I never really got to give it a fair evaluation. My impression of the Amiga is mostly colored by later years of fanatics hounding me about supporting the "inherently superior amiga" when it was obviously well past its competative prime.

I mean that I never actually worked with low level register programming specs for the amiga, so I can't comment authoritatively. The reason is that when I was young and the Amiga looked interesting, I couldn't afford one. When I had the means, I no longer had the desire.

I certainly don't mean to imply that all Amiga users are fanatics, just that the advocates that made it to my mailbox were less well mannered than those for many other platforms. You are right, it did color my response.

So, to give you a somewhat better answer:

The Amiga's success was in demonstrating the large benefits of specialized graphics coprocessors for personal computers, and providing close to a workstation like environment while the PC was still struggling with segment registers in dos.

It wouldn't have been obvious at the time, but the Amiga was basically fated to go the way of a console generation, rather than evolve as the PC or mac did.

The reliance on low level hardware knowledge and programming provided the obvious visual superiority, but also locked it in to a very ungracefull evolution.

I have been working on the utah-glx project for about nine months now. I am proud of what we have accomplished, and I think it has been a good example of a working open source project. Matrox and ATI have been pleasantly surprised at how well things have worked out.

However, there are only a half dozen coders working part time on utah-glx, and we are split among three active chipset trees. Nvidia has more people than that working full time exclusively for their chips. We are pretty good. So are they. We can work from specs. They can go interrogate the designer of the hardware. It's a pretty simple equation - I expect their driver to be better than our drivers.

Nvidia is working to maintain a common source base between their windows drivers and their linux drivers. Bugs tracked down by the order of magnitude more windows users will be fixed automatically in the linux version.

DRI does not have all of its problems solved, and there are valid reasons for them to not use it. They might change their mind later.

It should be remembered that some people want to do 3D graphics on linux and don't care about open source principles. Most of the people coming from a technical workstation background just want a vendor to deliver a tool to help them get their work done. I also suspect that most game players will choose a faster driver, even if it is closed source.

The choice isn't between making their driver open source or closed source. They CAN'T open source it because of legal encumbrances on the code. The choice is between doing a closed source driver with their existing code, and doing a completely new driver. Not too many people get excited at the prospect of rewriting perfectly good code.

If you care about getting open source drivers, support Matrox, 3dfx, or ATI. They have released specs to the community, and put out cash for PI to develop and support DRI drivers.

If you just want good 3D, I think nvidia will satisfy you. As for not being done yet, it hasn't been that long since Xfree 4.0 shipped.

A GeForce should be able to run Q3 at 200 fps at 400x300 (r_mode 1) or possibly even 512x384 resolution if the cpu was fast enough. A dual willamette at the end of this year will probably do it.

We currently see 100+ fps timedemos at 640x480 with either a 1ghz processor or dual 800's, and that isn't completely fill rate limited. DDR GeForce cards are really, really fast.

Yes, it is almost completely pointless.

The only reasonable argument for super high framerates is to do multi frame composited motion blur, but it turns out that it isn't all that impressive.

I did a set of offline renderings of running Q3 at 1000 fps and blending down to 60 fps for display. Looked at individually, the screenshots were AWESOME, with characters blurring through their animations and gibs streaking off the screen, but when they were played at 60hz, nobody could tell the difference even side by side.

Motion blur is more important at 24hz movie speeds, but at higher monitor retrace rates it really doesn't matter much.

There are some poster-child cases for it, like a spinning wagon wheel, but for most aspects of a FPS, realistic motion blur isn't noticable.

Exagerated motion blur (light sabers, etc) is a separate issue, and doesn't require ultra-high framerates.

There are still plenty of things we can usefully burn faster cpu's on...

I was elated when Apple announced the original Open Source Darwin initiative. I never would have guessed they would go for it, and I think it is a Very Good Thing.

Getting everything together for a public release is a very non-trivial task. I know the hassles we go through, and darwin is 100x the size of our codebase.

After all that work, including pressing CD's, it was met with a fairly resounding silence.

The darwin mailing lists were dead. It sometimes seemed like there were a grand total of a dozen people with darwin installed.

It was looking like this might go down as a large example of how going to the trouble of Open Source doesn't get you anything but hassle.

It didn't help that darwin was basically unusable by itself, because all you got was a single very slow text console with messed up key bindings. Not exactly a happy development environment.

(most of the active development work is done in the usable environment of OS-X server)

The general response that interested people gave as to why they weren't doing any development with darwin was that "everything is going to change in the next release" (the driver architecture was massively reworked).

Well, the new release is here now. There is still the problematic issue that you can't run ANY current gui on darwin 1.0. OS-X server and the developer seeds of OS-X client are both out of sync with the darwin codebase. All the excuses won't really go away until the next OS-X client release.

A couple months ago, I took on the porting of X windows to Darwin, so it could actually be considered halfway usable by itself.

I released the patches to get X windows running under MacOS-X server, which was basically the same core as the earlier darwin release.

I was then given the same excuse as other people -- why bother porting to the native darwin video and input drivers if everything is going to change soon?

As of now, I am actively feeling guilty about not finishing it. Everything is there for me now, I just need to find the time.

I had been spending my weekends on either GLX or darwin X server work after Q3 shipped, but my R&D "research" has shifted to "development" faster than I expected, and the past few weekends have been monopolized by new engine work. I'll get to it within the next month, but if someone wants to pick up first, feel free...

It may turn out that many of ESR's arguments just don't pan out for Apple, as far as having outsiders improve the core codebase. Even so, releasing the source will benefit Apple by giving application developers the "ultimate docs" on the OS.

I think Apple deserves a lot of credit for the step.

You can't just choose to rotate a drive platter 100 times faster. It may be remotely possible to make a 50,000 rpm drive in the near term, but 100x faster (and larger diameter) is WAY beyond the limits of known materials. It could also double as a dandy KE tank killer or space launch system if it could actually be built...

The limitation isn't the ability to read the data off the platter, it is the ability of the platter to not break into shrapnel.

Apogee distributed the shareware trilogy of Wolf3D.

Id wrote the game.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.)

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.

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.

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.

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.

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.

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.

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.

The article lays out all the things Bill should have done:

He should have compromised what he really thought.He should have "played the PR game".He should have coddled bureaucrats.He should have paid attention to "political sensibilities".

From the perspective of Fortune or Business Week, that all sounds right and proper.

But from a hacker perspective?

I'm not saying Gates is a hacker (although he is indeed really damn smart), but if you align yourself with those ideals, is it really correct to deride someone for being forthright and stubborn in the defense of their position?

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. :-)

My point was that with texturing tied directly to the patch orientation, you can't do exactly the thing that you describe.

I'm not a big booster of hardware curves in any form, but I only rail against hardware schemes that use aligned textures.

The hardware curved surfaces in upcoming hardware is basically ok, because you can have all the attributes independent of each other at each control point. My major point was that the 3DO/Saturn/NV1 botched it badly by explicitly tying the texture to the patch orientation, which prevents them from being able to do triangle like things at ALL.

I was ranting specifically about square patches that have implicit texture alignment, not curves in general. I am on record as saying that curved surfaces aren't as wonderful as the first seem, though.

It was my experience that subdivision surfaces are much more convenient for modeling free form organic surfaces, but polynomial patches can be more convenient for architectural work.

Unfortunately, the giant projector screens are not color calibrated the same way at all.

The colors did get rather washed out on the big screen.

We did a ton of testing the last two weeks while we were putting the demo together.

The 733 G4 was not as fast as my 1 ghz PIII in any of the trouble areas.

Apple is doing a lot of good work, but the CPU's just aren't as fast as the x86 ones.

AltiVec can compensate in some cases, because it is way, way easier to program for than SSE, but it takes a very simple batched, computation intensive task for it to pay off in any noticable way. Amdahls law and all that.

We did a couple functions with AltiVec, but they didn't make much difference.

Video encoding and large image processing are two areas that it can pay off, because you may be spending 90%+ of your time in one page of code.

Even then, it takes a special balance to let a G4 come out ahead, because it has less memory bandwidthd than a high end x86 system.

We moved to C++ for the current game (which does not have an official full name yet).

I will probably do a .plan update about it, because it has definately had its pros and cons.

Jim Dose had inadvertantly used a few MS specific idioms that we had to weed out over the past couple weeks of the bring up on OS-X.

Half Life made net profits of just over $200,000

Uh, no. Half Life made FAR more than that.

The top titles still bring in lots of money, but if you don't get a hit, you probably won't recoup your development money.

We don't have any technology specifically directed towards character features. The animation was done pretty conventionally in Maya.

Our new animator comes from a film background, and we are finding that the skills are directly relevent in the new engine.

It used to be that NASA had to have a string of ground stations and ships around the world to get continuous data from space vehicles. This is still an issue for countries like China, and the logistics have impacted their space program. NASA does now use a lot of custom relay satellites, but the communications hardware is still $100k+ one-offs for each application. Using $5k of commercial equipment that is probably better developed is indeed a good thing. The articles also lumped together with the LEO sat communication aspect the increasing use of GPS to augment and eventually replace dedicated radar for positioning.

My even-more-modest efforts are also ongoing:

www.armadilloaerospace.com

We hope to be making a properly controlled test flight within the next two weeks now that our gyros are working properly.

Coming back as a glider implies wings and landing gear, which wind up massing more than vertical landing propellant.

Trying to do without wings on X-33 forced a sub-optimal tankage solution, which turned out to not work.

A VTVL isn't expected to "fly" to a landing. It plummets at terminal velocity (not as fast as you might expect, because it is mostly empty), only firing the engines a reletive few seconds before landing. The fuel required is then only a few seconds of several G thrust for the EMPTY mass of the vehicle.

A somewhat more valid argument against vertical landing is that doing it efficiently requires computer control, and it is unlikely that a human pilot would be able to do it manually without a lot more slop fuel.

I don't have an orbital timeframe. There are too many things I need to learn before I can make a credible estimate.

The timeframe I do have is:

Year 1: work out all the kinks in the VTVL demonstrator.

Year 2: manned rocket ships and ballistic flight, but still rather low altitudes.

Year 3: space (100km) shots, both unmanned and manned

The throttle is manual, but attitude control is computer managed. The joystick input gives a target angle, and the computer deals with rates and pulses to try and get it there. Manual control of a differentially throttled vehicle is extremely difficult (the simulator allows you to try).

CG/CP is irrelevent for this vehicle, because it isn't designed to go fast enough that aerodynamics are a factor.

Four fixed position engines can give full 3 axis control if you are tricky about it. Opposite pairs of engines are canted a few degrees so that one pair of engines gives a slight positive roll, and the other pair of engines gives a slight negative roll. This does mean that there is a cross couple for every pitch or yaw adjustment, but with an order of magnitude difference between them, it is easy to correct out.

The difficulty of guidance and control is overrated.

I should ammend myself, and say that the difficulty AT LOW SPEEDS is not that bad. Removing aerodynamic factors simplifies things a lot.

Doing something like hypersonic kinetic kill missile guidance still sounds, uh, non-trivial.

I should mention that really, all of this work can be traced back to slashdot.

Until a year and a half ago, I hadn't thought about space and (real) rockets since I was a kid.

I started reading slashdot for the open source coverage, but the occasional space story and the comments on them led me to the CATS prize and the other things going on in the space community.

I spent a year learning the engineering aspects and funding a few things that I considered interesting (JP Aerospace, SORAC, Space Frontier Foundation, and XCOR), and the last six months actually doing something myself.

I was sort of planning on submitting an article about the whole process at some point, but it looks like I got preempted (and our site is slashdotted)...

Heh. That sort of takes some of the wind out of the FSF financial conspiracy theory.

Yes, that was my blackjack winnings.

I wind up doing my own internal PPC vs X86 benchmarks almost every year.

I'll set up whatever current game I am working on to run with the graphics stubbed out so it is strictly a CPU load. We just did this recently while putting the DOOM demo together for MacWorld Tokyo.

I'll port long-run time off line utilities.

I'll sometimes write some synthetic benchmarks.

Now understand that I LIKE Apple hardware from a systems standpoint (every time I have to open up a stupid PC case, I think about the Apple G3/G4 cases) , and I generally support Apple, but every test I have ever done has had x86 hardware outperforming PPC hardware.

Not necessarily by huge margins, but pretty conclusively.

Yes, I have used the Mr. C compiler and tried all the optimization options.

Altivec is nice and easy to program for, but in most cases it is going to be held up because the memory subsystems on PPC systems aren't as good as on the PC.

Some operations in Premier or Photoshop are definitely a lot faster on macs, and I would be very curious to see the respective implementations on PPC and X86. They damn sure won't just be the same C code compiled on both platforms, and it may just be a case of lots of hand optimized code competing against poorer implementations. I would like to see a Michael Abrash or Terje Mathison take the x86 SSE implementation head to head with the AltiVec implementation. That would make a great magazine article.

I'll be right there trumpeting it when I get a Mac that runs my tests faster than any x86 hardware, but it hasn't happened yet. This is about measurements, not tribal identity, but some people always wind up being deeply offended by it...

The FAA regs (FAR 101) used for model/high power rocketry specifically refer to "unmanned rockets", not "unpiloted rockets", so it isn't at all clear how something like this is regulated.

I have sent a query to the FAA about getting waivers for the manned rockets my team is working on, but it got booted up to Washington a couple weeks ago, and I haven't heard back yet.

I won't get into gameplay arguments about it, but from an engine standpoint:

Pathways into Darkness was Bungie's take on Wolfenstein.

The original Marathon was Bungie's take on DOOM.

I don't put a lot of stock in pinning down "firsts", even though people in general, and the media in particular, love to harp on it.

Everything is built on past work.

A lot of people like to think of creativity and innovation as something that springs from the void, but the truth is that everything is traceable to its origins.

I consider myself fortunate that I am consciously aware of the process. I can dissect all of my good ideas into their original parts, and even when there is an interesting synthesis, the transformation can usually be posed as an analogy to some previous work.

Given that fact, you will rarely find me touting anything as a "first", because I could always say it is "sort of like this thing over here, but with the principle demonstrated by this over there added to allow it to give the feature we wanted back then" and so on.

There are the occasional "eureka!" moments, but they tend to be in twitchy little technical things, not the larger ideas like "3D environment" or "multiplayer gaming".

I'm not all that concerned with our place in history. The process has been interesting enough in its own right, and lots of people have enjoyed the work as we produced it.

We will have a manned rocket vehicle flying by the end of the year, but it will be a modest little thing. The performance will only be about what you got out of the old Bell rocket pack, but it is fully fly-by-wire (and can be tested remotely) with active stabilization, and all the subsystems are directly scaleable to much larger vehicles.

I will probably enter as an X-Prize competitor at that point.

Armadillo Aerospace [armadilloaerospace.com]

He is sort of correct.

It is easier to get a high thrust to weight ratio out of solids, even though they have a lower Isp and generally a lower total dV per stage.

To get more thrust out of a solid, you basically just need a bigger nozzle, while to get more out of a conventional liquid engine, you need a bigger nozzle, and bigger turbopumps, plumbing, and combustion chamber.

Not that I think solids on a manned vehicle are very sensible...

Yes, this is very similar to what I am working on.

www.armadilloaerospace.com

Their current vehicle is a good deal larger than ours, has an aeroshell, and significantly, uses liquid hydrogen / liquid oxygen, a much more potent and difficult propellant than the hydrogen peroxide we use.

On the other hand, my project has been a lot faster and cheaper. I have spent about $50k and we have been working on it for nine months, versus their $400k and four years.

Our first up scale vehicle is going to be ready in a few months. It won't go very high or fast, but we can carry a person on it...

Next year, at the very least, we will have a supersonic manned rocket ship.

Run the numbers.

With a 400 Isp engine, one percent of the vehicle landing mass can kill 40m/s of velocity. That is over 80 mph, which an efficient VTVL vehicle could expect to have as its terminal velocity.

A parachute masses more than 1% of its load.

There are lots of other factors that can push the decision either way, but it is certainly within the realm of feasible engineering decision.

Then we get NASA and the US Government refusing to allow private launches so that people have to go off-shore to launch to try to claim the X Prize!!!

Actually, it's worse than that.

The US government (NASA doesn't have anything to do with it) claims authority over all actions of its citizens, even when they aren't inside national boundaries.

If you launched an X-Prize vehicle from another country or from international waters without getting FAA/AST clearance, you are still in trouble (and wouldn't be eligable for the prize).

The standard lighting model in DOOM, with all features enabled, but no custom shaders, takes five passes on a GF1/2 or Radeon, either two or three passes on a GF3, and should be possible in a clear + single pass on ATI's new part.

It is still unclear how the total performance picture will look.

Lots of pixels are still rendered with no textures at all (stencil shadows), or only a single texture (blended effects), so the pass advantage will only show up on some subset of all the drawing.

If ATI doesn't do as good of a job with the memory interface, or doesn't get the clock rate up as high as NVidia, they will still lose.

The pixel operations are a step more flexible than Nvidia's current options, but it is still clearly not where things are going to be going soon in terms of generality.

Developers are just going to need to sweat out the diversity or go for a least common denominator for the next couple years.

I fully expect the next generation engine after the current DOOM engine will be targeted at the properly general purpose graphics processors that I have been pushing towards over the last several years.

Hardware vendors are sort of reticent to give up being able to "out feature" the opposition, but the arguments for the final flexibility steps are too strong to ignore.

Taking things one step at a time is critical for success.

We have a pretty clear plan of attack to take us to X-Prize level vehicles. There will be several intermediate vehicles to learn from along the way, but I am pretty confident that we can do it, and that I can pay for it. The regulatory approval is still uncertain. Things get much more questionable after that.

The next step would be using the X-Prize vehicle as a booster for a upper stage(s) that launch a microsat into orbit. That requires many times for dV, and the regulatory environment, telemetry, and logistics become a lot more challenging. This would get fairly expensive, because making a reusable upper stage(s) is a whole new level of problem, and you just can't test a lot of the systems without going all the way. Even on a shoestring, it could easily get to $100k for each attempt, after you factor everything in. Realistically, it will take a lot of attempts to learn everything you need to know. A lot of people will talk about how straightforward it is, but I have a healthy respect for the challenges. Smart money probably wouldn't bet on any "garage shop" getting to orbit, but it certainly isn't impossible.

After that, you could either work towards reusable upper stages, or scale everything up to the point you could try to orbit a passenger or a semi-useful LEO satellite.

Sure, if all that works out, I would love to make a moon shot, but that qualifies as day-dreaming, not planning. The idea that Dennis Wingo has floated recently about M class asteroids rich in platinum group metals possibly being able to have survived impact on the moon without vaporizing under some conditions is Very Very Interesting.

The extent of my "business planning" for the rockets is along the lines of "If you actually make something really, really cool, you will wind up making money on it somehow". Hopelessly naive? Possibly. We'll see. I hate being involved in business, so we would probably just partner with some of the existing companies interested in suborbital rides or sounding rocket business.

In the short term, watch for us getting a man off the ground in the upscaled lander frame within a couple months.

On topic: I think pretty highly of the DaVinci project, and I would say they are definitely one of the leading contenders. Brian Feeney talks about some technical issues on open mailing lists, which is a good sign. My biggest concern for them would be that, from my experience with JP Aerospace, getting two successful rockoon launches off within the 14 days required by the X-Prize is going to involve a good sized helping of luck.

It (DOOM) was designed by talented people with good skills and academic degrees in computer science.

None of us had degrees in computer science. Romero, Adrian, and I don't have any degrees at all, and Kevin's is in political science.

It even had a simple but multithreaded "operating system" of its own to handle asynchronous updates of graphics and playing sound while performing the game simulation.

No. We made the startup sequence busy and techie in a sort of imitation of the NeXT workstations we were using at the time, but there was no multithreading going on. The sound was done with interrupt driven processing, which doesn't qualify.

With the source code open for years, this should have been easy to check.

a resolution of only 320x240

320x200

I would take issue with some of the other vague statements made later on, but they aren't pointed enough to debate.

We were surprised at Wolf3D mods, but we knew it was going to happen with DOOM. I worked with some of the Wolf3D map editor guys before DOOM was even released, but they didn't wind up making the popular level editors.

The editor and utility source code was released quite early, but it was all for NeXT workstations in Objective-C, so it had to wait for someone to rewrite it for more conventional systems.

I'm still developing everything with OpenGL, and I'm still targeting mac and linux as well as windows, but I want to rationally address some points in the API debate:

D3D is clunky, etc

Not really true anymore. MS made large strides with each release, and DX8 can't be called a lousy API anymore. One can argue various points, but they are minor points. Anti-Microsoft forces have a bad habit of focusing on early problems, and not tracking the improvements that have been made in current versions. My rant of five years ago doesn't apply to the world of today.

I do think that the world would be a slightly better place if Microsoft had pulled an embrace-and-extend on OpenGL instead of developing a brand new API that had to be rewritten a half dozen times, but its water under the bridge now.

Open for more sales, etc

It has been pretty clearly demonstrated that the mac market is barely viable and the linux market is not viable for game developers to pursue. Linux ports will be done out of good will, not profit motives. From an economic standpoint, a developer is not making a bad call if they ignore the existence of all platforms but windows.

DX8 Gives more features

Some people have an odd view that an API gives you features. Assuming you don't care about software emulation, hardware gives you features, and an API exposes them. If you try to use vertex programs or bump env map on a TNT, DX8 doesn't magically make it work. DX8's hardware independence is also looking a bit silly now as they make point releases to support ATI's new hardware. They might as well say D3D-GF3 or D3D-R200 instead of DX8 and DX8.1.

All of Nvidia's new features have showed up as OpenGL extensions before they show up as new D3D features.

Divergent extensions haven't been a problem up until very recently. All of the vendors tended to support all the extensions they could, and if they had unique functionality, like register combiners, they made their own extension. The current status of vertex programs does piss me off, though. I really wish ATI would have just adopted Nvidia's extension, even if it meant not exposing every last bit of their hardware.

Abstraction in a high performance environment can be dangerous. If you insist that all hardware behave the same, you prevent vendors from making significant improvements. If the spec for behavior comes from people that aren't hardware oriented, it can be a huge burden. D3D still suffers somewhat due to this, with some semantics and odd features that make hardware guys wince.

The Good News

We are rapidly approaching a real golden age for graphics programming. Currently, cards and API's are a complex mess of hundreds of states and function calls, but the next two years will see the addition of the final primitive functionality needed to all