[John Carmack] [American McGee] [John Cash]
[Christian Antkow] [Brian Hook] [Paul Steed]
[Paul Jaquays] [Todd Hollenshead] [Barrett Alexander]
I am not a lawyer. This is not legal-advice.
If somebody can prove that this technique was used more than a year before the patent application was submitted, then the patent is either partially, or wholly invalid.
It seems to me that if a vidgame with different shapes or colors for multi-players was out before that time, (when was Gauntlet first out?) then the patent is really weak. The example I read was the surfboard with a sail on it. Some company found a home movie showing that some kid had built one, and sailed it, more than the 'year before', making the invention part of the public domain.
Remember, it's not from when the patent was granted, but from when it was applied for.
I once did some research into patents on the chance I would apply for one. It's an expensive and dicey proposition.
There's a patent that could shake the game industry to its core.
On August 7, 1997, Apogee Software, Ltd. received a certified letter from Mr. Ernest Kettelson of Kettelson Law Offices, Ltd. Kettelson claims to be the attorney representing the owner of U.S. Patent No. 4,662,635, which, if the patent it true and valid, will negatively affect nearly every developer and publisher in the games industry.
In short, the patent covers the use of "real actors or players, making actual plays of the game in question, which have been recorded on video tape, or video disks, or other recording medium." In lay terms, the patent is designed to cover any playback of previously recorded living things, be they people or animals. The patent claim document continues, stating that it covers video games specifically, "...in which previously recorded plays by real living beings are used and displayed on a television screen or other cathode ray tube in accordance with selections made by each player of the video game."
This patent was issued to its owner May 5, 1987.
The letter from Kettelson states that, "An examination of your animated video games such as Duke Nukem 3D indicates that they infringe our client's patent...immediately cease and desist from further manufacture, sale and use of such animated video games."
My question is: How many games does this patent *not* cover!? Any game with filmed full-motion-video sequences, such as Wing Commander 3 & 4, and countless others, are apparently in violation of this absurd patent.
Anyone interested in receiving via fax a full copy of this patent (8 pages) please let me know. Apogee is currently consulting our attorneys on what to do, but it's obvious that we and the game industry must fight to have this patent overturned.
I understand that CTF will be included in Quake 2 and I would like to suggest that an indicator of your current team color appear somewhere on the screen. I know that lots of people float around from game to game and it's tough to hit the TAB key, look for the color attached to your name, and then determine whether or not to waste ammunition on the guy lined up in your crosshairs. Perhaps the background to the face displayed in Quake (assuming Quake2's display follows Quake).
[BloodFire] Dis; do any of the monsters jump in quake2, like over stuff and stuff
[Disruptor] not really bloodfire
[BloodFire] Dis is it possible to describe how cool quake2 is right now
[Disruptor] BloodFire: it gives me a raging erection every day
Just to answer the supposition you mentioned on your news page, here's my (semi-informed) take on it.
SGI is releasing an OpenGL implementation for Win95. This does not mean that if you have a 3d card you can just copy this into your WINDOWS\SYSTEM directory and voila, instant OpenGL support for your particular card. (To simplify) Each card manufacturer will have to put in 'hooks' that will redirect certain calls to the card instead of doing them (slowly) in software.
So, in short what John is saying is that he hopes that every card that has an architecture suitable for OpenGL will do just this and release OpenGL for their card.
One particular thing to note is that this is not going to cure the problem that most cards available today suck for GLQuake/Quake2.
I know you used a specialized driver written by 3dfx for the GLQuake stuff. Now that SGI has come out with a general GL library/DDK for Windows 95, will you be using its implementation, or will you still work only with specialized GL drivers from 3D card manufacturers?
We hope that every card that is able to support a full opengl driver will do so.
I just have one question I've been meaning to ask you for the potential Quake 2 level editors out there. In both DOOM and Quake, reactions to actions always ocurred in the same level as the action (a trigger in Quake only affects something in the same level as the trigger, a tagged linedef in DOOM only affects sectors in that level with the same tag number). I've heard over and over about going back and forth through levels to do things like deactivate power grids, etc. Will there actually be a way to set a trigger that causes an effect in ANOTHER level besides the one currently being played? If so, how?
Yes, we have cross-level triggers in quake 2.
>When Quake 2 comes out, will a Quake2 editor be included in the package?
We're planning on releasing QE4 to the public with full source code at some point.
I went to siggraph last monday to give a talk about realtime graphics for entertainment.
The only real reason I agreed to the talk (I have turned down all other offers in the past) was because Shigeru Miyamoto was supposed to be on the panel representing console software. Id software was really conceived when me, Tom, and Romero made a Super Mario 3 clone after I figured out how to do smooth scrolling EGA games. We actually sent it to nintendo to see if they wanted to publish a PC game, but the interest wasn't there. We wound up doing the Commander Keen games for Apogee instead, and the rest is history.
I was looking forward to meeting Mr. Miyamoto, but he wound up canceling at the last minute. :(
Oh well. I hope everyone that went enjoyed my talk. All the other speakers had powerpoint presentations and detailed discussion plans, but I just rambled for an hour...
I notced that there was a report about my discussion of model level of detail that was in error. I have an experimental harness, an algorithm, and a data structure for doing progressive mesh style LOD rendereing in the quake engine, but I suspect it won't make it into the production Quake 2. Other things are higher priority for us. I may assist some of the quake licensees if they want to pursue it later.
A couple data / feature changes going into the latest (and I hope final) revision of the Quake bsp file format:
Back in my update a month ago where I discussed losing automatic frame animation in models to clean up the format and logic, I mentioned that I still supported automatic texture animation.
Not anymore. There were several obnoxious internal details to dealing with it, especially now with textures outside the bsp file, so I changed the aproach.
When a texture is grabbed, you can now specify another texture name as the next animation in a chain. Much better than the implicit-by-name specification form Quake1.
No animation is automatic now. A bmodel's frame number determines how far along the animation chain to go to find the frame. Textures without animation chains just stay in the original frame.
There is a slight cost in network traffic required to update frame numbers on otherwise unmoving objects, but due to the QuakeWorld style delta compression it is still less thatn a Quake 1 scene with no motion at all.
The benefit, aside from internal code cleanliness, is that a game can precisely control any sequence of animation on a surface. You could have cycles that go forward and backwards through a sequence, you could make slide projectors that only change on specific inputs, etc.
You could not independantly animate two sides of a bmodel that were not syncronized with the same number of frames, but you could allways split it into multiple models if your really needed to.
Everything is simple when its done, but I actually agonized over animation specification for HOURS yesterday...
The last significant thing that I am working on in the map format is leaf clustering for vis operations. You can specify some map brushes as "detail" brushes, and others as "structural" brushes. The BSP and portal list is built for just the structural brushes, then the detail brushes are filtered in later.
This saves a bit of space, but is primarily for allowing complex levels to vis in a reasonable amount of time. The vis operation is very sensitive to complexity in open areas, and usually has an exponentially bad falloff time. Most of the complexity is in the form of small brushes that never really occlude anything. A box room with ten torch holders on the walls would consist of several dozen mostly open leafs. If the torch holders were made detail brushes, the room would just be a single leaf.
A detail / structural seperation is also, I believe, key to making a portal renderer workable. I had a version of Quake that used portals at the convex volume level, and the performance characteristics had considerably worse-than-linear falloff with complexity. By reducing the leaf count considerably, it probably becomes very workable. I will certainly be reevaluating it for trinity.
>If it's true that the monster models are all made up of integrated pieces (arms,
>legs, heads) that are seperate, how come we can't have a player model with
>weapons as seperate pieces and just attached at run time as needed? It seems
>like you wouldn't have to have a full fledged player model for each weapon.
>Just snap on a weapon model as appropriate. Or am I missing the point?
Keep in mind that just because they are in seperate pieces, it doesn't change the fact they're just considered a collection of vertices. We are investigating ways to reflect weapon changes in the game, but everything's still up in the air.
>Can I ask you a question about in-game cinematics? Is there actually
>going to be areas where you are playing through the level, in the
>middle of the game, and it suddenly halts for a cinematic, then after
>playing it returns to your control, or are cinematics only going to
>occur at the beginning and end of the game, and inbetween levels?
>Also, if in-level cinematics are possible, how do addon level authors
>make their own cinematics in the middle of their levels? And do the
>cinematics actually affect anything (like opening a sealed doorway to
>reveal a monster ambush, after which time the control returns to you
>and you deal with aforementioned monsters)?
Repeat after me: "The game will never stop for cinematics." The flics will only play at the beginning, the end and POSSIBLY between one or two levels (not too likely, though). Scripted actions by characters in the game will be implemented in some fashion if we can make them cool and useful. This is an action game and all those other companies that make you watch some expensive FMV or time-consuming animations need to remember the name of the genre. Our animations will in no way take away from the game experience, but will in every way enhance it.
August 9, 1997 (early AM)
Jesus this is a huge .plan update, even for me...
Things are ever so slowly coming together on the graphics side of things.
SciTech Software, the people who do MGL, are on the verge of getting us a code dump, hopefully within the next day or two. By going with MGL we're freeing ourselves from a lot of mundania -- they've solved the problem of dealing with graphics under Win32 cleanly, and we'd rather not reinvent the wheel if at all possible.
An unfortunate side effect of using someone else's library is that we can get stuck for days or weeks when a bug shows up in the library and you have to wait several days (or weeks) to see it fixed. Assuming you're on good enough terms with the library provider that they'll give you a timely fix.
Now, I don't mean to get off on a rant here, but....
A lot of researchers and academics have been pushing "component software" or "software ICs" on the realm of computer science like it's some magic panacea for all the world's problems.
Computer programs are written by computer programmers. I'm a pretty competent computer programmer, and I still fuck up all the time. Assume that I represent the tip of the typical Gaussian distribution of talent -- this means that the BEST case is that most of the programmers out there fuck up as badly and as frequently as me.
This, to put it mildly, gives me the heebie jeebies. It's bad enough that other programmers have to write the compiler, programming tools, operating system, and device drivers that I use -- but to use another programmer's canned libraries?
I've heard it put this way -- if you wrote the code for an airplane's navigation and flight control systems, would you be willing to fly on it?
No sir, I don't think so.
That's why I write computer games -- buggy games may be annoying as hell, but they don't kill people.
Now given this scenario, a company can ask itself -- "we're on a tight schedule and need to ship good software. We can outsource this key technology from someone else who probably isn't better at programming as we are, but should we?"
Every time you decide to outsource some key technology you're putting yourself at considerable risk, especially if you're on a tight timeline. When you use someone else's library, be it sound, graphics, input, GUI, whatever, you open yourself up to all kinds of evil potential problems. And these problems are NOT theoretical. For example:
- getting support for a currently unsupported device
- bugs in the library prevent you from shipping
- bugs in the library cause support hassles
- you need to port to another platform that the library doesn't support
- the library provider goes out of business and you don't have source
These are all things I've seen or even been a part of.
Hell, using someone else's _compiler_ can be a royal pain in the ass at times, especially when "someone else" is more concerned about ActiveX, OLE, and integrated HTML browsing than stable floating point optimizations. This is one of the reasons that I've been so reluctant to start using MFC -- it's poorly evolved library written in C++ for the Win32 platform.
If that ain't a barrel of shit waiting to leak, I don't know what is.
Point being: outsourcing technology can make sense, but you should really really think about it before committing to it. In our case the SciTech MGL libraries just barely justify themselves to us -- they are very competently done, and the crew there are magnificently talented and dedicated, but not having complete control over our entire source base is a huge thing to give up.
The MGL libraries offer a VERY valuable service to us and other programmers attempting to write a graphics program that needs to run across a wide range of Win32 systems. Contrary to popular belief, Win32 didn't solve all the world's device dependency problems, it only shifted the blame.
So what is the MGL? The MGL (at the least the portion interesting to us) provides an abstraction layer between DirectDraw, WinDirect (i.e. VESA BIOS modes under Windows), and good ol' GDI's CreateDIBSection. Under NT, for example, we can get access to DirectDraw and CreateDIBSection. Under 95, we can get access to all three, usually, but in some cases WinDirect is the best access method (e.g. flaky DDraw drivers are installed on the user's system).
And MGL neatly wraps all of this into a dumb framebuffer abstraction that works quite well for what we need.
Another thing that MGL provides, which I'm a bit more leery of, is an OpenGL driver abstraction layer. Currently we sort of have a hacked system that lets us pop between different OpenGL implementations by using LoadLibrary/GetProcAddress. This has its holes, e.g. when it comes to calling wglChoosePixelFormat vs. ChoosePixelFormat, dealing with program deactivation, dealing with fullscreen, etc. but so far it's been livable.
The MGL defines a set of driver hookout mechanisms that a driver writer can implement. This then gives someone who uses the MGL the ability to swap between drivers on the fly, enumerate existing drivers, query for available video modes, and other nice things that our current hacked implementation doesn't have.
BUT, we give up control by going that route. We're exploring this option because it has some nice features, but it is NOT vital that we use the OpenGL facilities of MGL. We're doing it mostly because SciTech has invested the time and effort to switch over our code base to MGL, and thus we don't have to deal with it until it's working.
But even then, we've already felt a minor side effect of this -- the MGL OpenGL driver hookout stuff does not currently work with 3Dfx's mini-GL driver (!). This, in the immortal words of Butthead, sucks. This is being taken care of as we speak, but once again, it's one of those convenience issues.
So the MGL is a good outsourcing of technology for us, but we have, at times, felt the pinch of not having complete control over our source base. We'd be pretty inconvenienced for our DEC Alpha port if the MGL didn't come in a DEC Alpha version (which, lucky for us, it does).
(Note: if you want to see more about MGL, go to http://www.scitechsoft.com)
Now before you start bitching about how we're suffering from "NIH" (Not Invented Here) syndrome, let me state that we do not have a philosophical problem with using software written by others. We have a very PRACTICAL problem with it.
True NIH stems from arrogance and pride. While I certainly suffer from both those afflictions, we, as a company, don't suffer from traditional NIH -- our NIH stems from pragmatism more than anything else.
To sum: using someone else's code is full of pros and cons. Just think real hard about the REAL benefits and the REAL problems associated with using someone else's code instead of developing your own. Software is very rarely a "black box" that you drop in and that "just works". That's what the future of componentware SHOULD be, but we aren't there yet, and that's been promised to us for something like 10 years now.
On a related note, I've tried using OpenStep for NT, and I've reached the conclusion that the folks at NeXT have no comprehension how to deal with selling a real, honest-to-God commercial product. OpenStep's Interface Builder is riddled with bugs, the documentation is poor, there is no appreciable on-line help, and I couldn't find a support contact at their Web site. Oh, and they don't have patches or service paks at their Web page.
$ set rant=off
Okay, so what have I been up to in the Quake2 world lately? Primarily I've been trying to get things optimized in the Alias renderer. There are some more optimizations that I need to be doing in the future, but those will have to wait until after the software is a little less raw.
The optimizations I've been doing have concentrated on FPU pipelining stuff on the Pentium. We're assuming that non-MMX Pentiums are still going to be the majority of systems that people will be running Quake2 on this Christmas.
For the Alias transformation code I'm seeing about a 33% increase in performance from hand optimization. I could go crazy and spend days working on it and crank it up to 50-75%, but I'm not sure that is time well spent.
I'm still pretty convinced that as time goes on that hand optimization is going to become less and less relevant. Wannabe industry futurists (people like me, but who are wrong :-) ) like to keep saying "but every new CPU introduction has people saying that assembly is going to go away!".
And that's true. But if you look at the percentage of code that is written in asm in your average program today versus your average program 5 years ago versus 10 years ago, I think (this is purely speculation on my part) that you'll find that the relative amount of asm code to some high level language has shrunk considerably.
Even today, optimizing is a bitch. I have to make conscious decisions as to what's more important -- faster on Pentium, PentiumMMX, or PPro/P2? Each of these processors has different trade offs that I can take advantage of, possibly at the expense of performance on one of the other processor families.
Not only that, but the speed gains I'm getting on Pentium far outstrip the speed gains I get from the Pentium Pro/P2. Hell, if I was targeting the Pentium Pro or above processors, it's entirely possible I wouldn't even bother with ANY assembly language routines. Optimizing for the PPro is extremely non-deterministic because of the branch predictor, state of the reorder buffer, speculative execution, non-blocking cache loads, etc.
So unless you're optimizing a VERY frequently called loop, it's pretty hard to get a feel for what is "good" PPro optimization.
When the MGL integration is back here, I'll spend a day reintegrating that code base, and we'll be back in Happy Software Rendering Land.
Question conventional wisdom.
Also, stay tuned to 3DNet #quake and #qspy tonight around 11:00pm CST for some pretty cool happenings ;)
Welcome to HexenWorld.
Hello, I'm Phoebus (of Raven Software's and Cult of Phoebus web sites). Together with Dweomer and Basty (from PlanetQuake), and the rest of the HW staff, I would like to announce our ambitious new project named HexenWorld.
After quite a lengthy process, our vision of a MEGA Hexen II web site has come to fruition. HexenWorld delivers not only the latest Hexen II game news but also contains essential features and hosts all the good sites available that offer something unique to the Hexen II community. Featured pages include Serpent's Realm, Militant's Information section, Bakshra's Dictionary, the Official FAQ, the Hexen 2 Ring, among others. Hosted sites so far include the Hexen 2 Guild Keep, and the Vampire TC, with more sites to be hosted soon.
We've teamed up with PlanetQuake and we now both share one another's vast resources. PlanetQuake continues to be the all purpose website, while HexenWorld is the definitive site dedicated to the Hexen II phenomenon.
Note: HexenWorld is not sanctioned by either Raven Software or Activision, the companies responsible for this great game. Those are the only official Hexen II sites.
Visit HexenWorld, a veritable WORLD of Hexen II information, features, and resources for and by the Hexen II community. We look forward to hearing what you think!