From quake-dev-owner@gamers.org Fri Aug 2 15:35 MET 1996 Received: from gamers.org (majordomo@thegate.gamers.org [128.205.37.150]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id PAA08543 for ; Fri, 2 Aug 1996 15:35:02 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id JAA00580 for quake-dev-outgoing; Fri, 2 Aug 1996 09:30:20 -0400 Received: from marvin.nero.uni-bonn.de (bernd@marvin.nero.uni-bonn.de [131.220.7.30]) by gamers.org (thegate/gamers) with ESMTP id JAA00575 for ; Fri, 2 Aug 1996 09:29:59 -0400 Received: (from bernd@localhost) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) id PAA08533; Fri, 2 Aug 1996 15:29:57 +0200 (MET DST) Date: Fri, 2 Aug 1996 15:29:57 +0200 (MET DST) From: Bernd Kreimeier Message-Id: <199608021329.PAA08533@marvin.nero.uni-bonn.de> To: quake-dev@gamers.org, bernd@marvin.nero.uni-bonn.de Subject: John Carmack's QuakeWorld plan X-Sun-Charset: US-ASCII Sender: owner-quake-dev@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 10584 X-Lines: 198 Status: RO You will probably have seen this one already. See http://www.cs.virginia.edu/~rg3h/networkVR/paper.html for an intro on dead reckoning and example source. ------------------------------------------------------------------------------ [idsoftware.com] Login name: johnc (messages off) In real life: John Carmack Plan: Here is The New Plan: I copied off the quake codebase and set about doing some major improvements. The old v1.01 codebase will still be updated to fix bugs with the current version, but I didn't want to hold back from fixing things properly even if it involves some major changes. I am focusing on the internet play aspect of the game. While I can lay out a grand clean-sheet-of-paper design, I have chosen to pursue something of a limited enough scope that I can expect to start testing it around the end of the month (august). I still have my grand plans for the future, but I want to get some stuff going NOW. QuakeWorld. The code I am developing right now is EXCLUSIVELY for internet play. It will be rolled back into the single player game sometime along the road to Quake 2 (or whatever it turns out to be called), but the experimental QuakeWorld release will consist of seperate programs for the client and the server. They will use the same data as the current registered quake, so the only thing that will be distributed is new executables (they will peacefully coexist with current quake). There will be a single master server running here at id. Whenever anyone starts up a server, it will register itself with the master server, and whenever a client wants to start a game, it will inquire with the master to find out which servers are available. Users will have a persistant account, and all frags on the entire internet will be logged. I want us to be able to give a global ranking order of everyone playing the game. You should be able to say, "I am one of the ten best QuakeWorld players in existance", and have the record to back it up. There are all sorts of other cool stats that we could mine out of the data: greatest frags/minute, longest uninterrupted quake game, cruelest to newbies, etc, etc. For the time being, this is just my pet research project. The new exes will only work with registered Quake, so I can justify it as a registration incentive (don't pirate!). If it looks feasable, I would like to see internet focused gaming become a justifiable biz direction for us. Its definately cool, but it is uncertain if people can actually make money at it. My halfway thought out proposal for a biz plan is that we let anyone play the game as an anonymous newbie to see if they like it, but to get their name registered and get on the ranking list, they need to pay $10 or so. Newbies would be automatically kicked from servers if a paying customer wants to get on. Sound reasonable? Technical improvements. The game physics is being reworked to make it faster and more uniform. Currently, a p90 dedicated server is about 50% loaded with eight players. The new network code causes a higher cpu load, so I am trying to at least overbalance that, and maybe make a little headway. A single p6-200 system should be able to run around ten simultanious eight player servers. Multiple servers running on a single machine will work a lot better with the master server automatically dealing with different port adresses behind the client's back. A couple subtle features are actually going away. The automatic view tilting on slopes and stairs is buggy in v1.01, and over a couple hundred millisecond latancy connection, it doesn't usually start tilting until you are allready on a different surface, so I just ripped it out entirely. A few other non-crucial game behaviors are also being cut in the interest of making the physics easier to match on the client side. I'm going to do a good chat mode. Servers will have good access control lists. If somebody manages to piss off the entire community, we could even ban them at the master server. The big difference is in the net code. While I can remember and justify all of my decisions about networking from DOOM through Quake, the bottom line is that I was working with the wrong basic assumptions for doing a good internet game. My original design was targeted at <200ms connection latencies. People that have a digital connection to the internet through a good provider get a pretty good game experience. Unfortunately, 99% of the world gets on with a slip or ppp connection over a modem, often through a crappy overcrowded ISP. This gives 300+ ms latencies, minimum. Client. User's modem. ISP's modem. Server. ISP's modem. User's modem. Client. God, that sucks. Ok, I made a bad call. I have a T1 to my house, so I just wasn't familliar with PPP life. I'm adressing it now. The first move was to scrap the current net code. It was based on a reliable stream as its original primitive (way back in qtest), then was retrofited to have an unreliable sideband to make internet play feasable. It was a big mess, so I took it out and shot it. The new code has the unreliable packet as its basic primitive, and all the complexities that entails is now visible to the main code instead of hidden under the net api. This is A Good Thing. Goodbye phantom unconnected players, messages not getting through, etc. The next move was a straightforward attack on latency. The communications channel is not the only thing that contributes to a latent response, and there was some good ground to improve on. In a perfect environment, the instant you provided any input (pressed a key, moved a mouse, etc) you would have feedback on the screen (or speaker) from the action. In the real world, even single player games have latency. A typical game loop goes something like: Read user input. Simulate the world. Render a new graphics scene. Repeat. If the game is running 15 frames a second, that is 66 ms each frame. The user input will arive at a random point in the frame, so it will be an average of 33 ms before the input is even looked at. The input is then read, and 66 more ms pass before the result is actually displayed to the user, for a total of nearly 100 ms of latency, right on your desktop. (you can even count another 8 ms or so for raster refresh if you want to get picky). The best way to adress that latency is to just make the game run faster if possible. If the screen was sized down so that the game ran 25 fps, the latency would be down to 60ms. There are a few other things that can be done to shave a bit more off, like short circuiting some late braeking information (like view angles) directly into the refresh stage, bypassing the simulation stage. The bearing that this all has on net play, aside from setting an upper limit on performance, is that the current Quake servers have a similar frame cycle. They had to, to provide -listen server support. Even when you run a dedicated server, the model is still: fetch all input, process the world, send updates out to all clients. The default server framerate is 20 fps (50 ms). You can change this by adjusting the sys_ticrate cvar, but there are problems either way. If you ask for more fps from the server, you may get less latency, but you would almost certainly overcommit the bandwidth of a dialup link, resulting in all sorts of unwanted buffering in the routers and huge multi thousand ms latency times as things unclog (if they ever do). The proper way to address this is by changing the server model from a game style loop to a fileserver/database style loop. Instead of expecting everyone's messages to be dealt with at once, I now deal with each packet as it comes in. That player alone is moved forward in time, and a custom response is sent out in very short order. The rest of the objects in the world are spread out between the incoming packets. There are a lot of issues that that brings up. Time is no longer advancing uniformly for all objects in the world, which can cause a lot of problems. It works, though! The average time from a packet ariving at the system to the time a response is sent back is down to under 4ms, as opposed to over 50 with the old dedicated servers. Another side benefit is that the server never blindly sends packets out into the void, they must be specifically asked for (note that this is NOT a strict request/reply, because the client is streaming request without waiting for the replies). I am going to be adding bandwidth estimation to help out modem links. If quake knows that a link is clogged up, it can choose not to send anything else, which is far, far better than letting the network buffer everything up or randomly drop packets. A dialup line can just say "never send more than 2000 bytes a second in datagrams", and while the update rate may drop in an overcommited situation, the latency will never pile up like it can with the current version of quake. The biggest difference is the addition of client side movement simulation. I am now allowing the client to guess at the results of the users movement until the authoritative response from the server comes through. This is a biiiig architectural change. The client now needs to know about solidity of objects, friction, gravity, etc. I am sad to see the elegent client-as-terminal setup go away, but I am practical above idealistic. The server is still the final word, so the client is allways repredicting it's movement based off of the last known good message from the server. There are still a lot of things I need to work out, but the basic results are as hoped for: even playing over a 200+ ms latency link, the player movement feels exactly like you are playing a single player game (under the right circumstances -- you can also get it to act rather weird at the moment). The latency isn't gone, though. The client doesn't simulate other objects in the world, so you apear to run a lot closer to doors before they open, and most noticably, projectiles from your weapons seem to come out from where you were, instead of where you are, if you are strafing sideways while you shoot. An interesting issue to watch when this gets out is that you won't be able to tell how long the latency to the server is based on your movement, but you will need to lead your opponents differently when shooting at them. In a clean sheet of paper redesign, I would try to correct more of the discrepencies, but I think I am going to have a big enough improvement coming out of my current work to make a lot of people very happy. John Carmack From quake-dev-owner@gamers.org Fri Aug 2 15:45 MET 1996 Received: from gamers.org (majordomo@thegate.gamers.org [128.205.37.150]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id PAA08555 for ; Fri, 2 Aug 1996 15:45:03 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id JAA00739 for quake-dev-outgoing; Fri, 2 Aug 1996 09:44:25 -0400 Received: from marvin.nero.uni-bonn.de (bernd@marvin.nero.uni-bonn.de [131.220.7.30]) by gamers.org (thegate/gamers) with ESMTP id JAA00731 for ; Fri, 2 Aug 1996 09:44:09 -0400 Received: (from bernd@localhost) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) id PAA08551 for quake-dev@gamers.org; Fri, 2 Aug 1996 15:44:08 +0200 (MET DST) Date: Fri, 2 Aug 1996 15:44:08 +0200 (MET DST) From: Bernd Kreimeier Message-Id: <199608021344.PAA08551@marvin.nero.uni-bonn.de> To: quake-dev@gamers.org Subject: Re: John Carmack's QuakeWorld plan X-Sun-Charset: US-ASCII Sender: owner-quake-dev@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 6351 X-Lines: 147 Status: RO My apologies to those who might consider this off topic for quake-dev - I hope to get this resolved soon. Feel free to forward this to quake-servers. I am not on that list anymore and will not post to a list I have not subscribed to - and it might even be off topic. ----- Begin Included Message ----- >From johnc@idnewt.idsoftware.com Fri Aug 2 14:57 MET 1996 From: John Carmack Date: Fri, 2 Aug 96 07:55:44 -0500 To: Bernd Kreimeier Subject: Re: q&a/QuakeWorld > a) state updates that affect subsequent state updates (movement, > decreasing health) > b) state updates that only affect visual > appearance and view (change skin texture, view tilting, MDL frames) > > Does this make sense? Yes. > More generally, for each category of update packet, one could > assign a priority/relevance value. Updates are sent to the clients > based on relevance - important (a) changes ASAP, less important (b) > ones during low traffic/idle times, later on. See below. It has been my experience that you need to optimize for worst case behavior, where all of the updates are important. Being clever in non-worst case situations leads to larger swings in quality of service. We followed this belief in the graphics engine, where we sacrificed peak performance for level performance at every oportunity. > Increased sampling of inputs, but updates depending on the > amount/significance of changes? This means bandwidth requirements > increases only during times with lots of important events. That basically happens allready to a factor of four or so. If you turn on cl_shownet, when you are running around by yourself you will see numbers like 40-50 or so. When you get into a big firefight, it will top 200. The light case could indeed be optimized further, but it wouldn't help the game. > > >The proper way to address this is by changing the server model > >from a game style loop to a fileserver/database style loop. > > I.e. asynchronous updates on first-come first-served? And the > server calculates the physics, too, to ensure consistency. Is > consistency the real issue here? Yes. I fundamentally believe in authoritative servers. I do not go for the distributed simulation aproach. The programs are complicated enough as it is, and going to a full distributed aproach will lead to a massive amount of additional development work and lots of hard to track bugs. Sometimes even though aproaches are possible and offer theoretical benefits, the practical aspects of using them overbalance the positives. > I have been surprised that you did not stick to a DOOM-style > approach (each clients does the same calculations, occasionally > checked). Client-side dead reckoning and override updates from the > server seemed to be a natural choice. Is done by DIS, IIRC? We have a far more robust architecture with dumber clients. Prog changes just on the server, no consistancy failures, etc. > >The server is still the final word, so the client is allways > >repredicting it's movement based off of the last known good > >message from the server. > > If I got it right: the QuakeWorld client runs (part of) the physics > locally now, based on last confirmed/known good (authorized) update > from QW server, doing a dead reckoning. User inputs are transmitted > ASAP (or by frame?) from QW client to QW server. Waiting for the > ACK/ authorized update, the QW client does *not* use the user > input. The movement prediction calculated by the client is replaced > the moment the autorized update (processed by the QW server) > arrives at the client. Not quite. Every frame the client gathers the user input and sends it off to the server with a sequence number. Each message from the server includes the sequence number of the inputs that it has simulated up to the time of the message. The client then knows that all inputs it has sent out past the one marked in the server message need to be simulated, because they are still "in flight" to or from the server. This will be a single input on a LAN game, but it could be up to eight or ten frames worth on a fast system connected to a latent connection. > >The client doesn't simulate other objects in the world, > > Aiming for NGT instead of QuakeWorld - how to get this scalable? > > Do Proxy Servers fit into the QuakeWorld concept? How else head for > "huge scalable worlds" with client/server? When we finally leave the level based game play behind, there will be a transition to transparently distributed servers. There are still a lot of gameplay issues there, aside from the technical ones. > There is another problem that Quake seems to be approaching with a > not too generic approach: attachment or locking of objects (I use > "attachment", because it generalizes naturally to composite objects > with kinematic chains and dynamics. Same for > collecting/carrying/dropping items or close combat/stick-to/hugging > attacks). I'm not sure that that has high enough order benefits to really address soon. I have other things with higher priorities. > If collision detection/weapon targeting is done on the QW client's > ... > Same for a monster that is seen by nobody else close up. > ... > Every connected process is authorized "server" for one or more > ... > Display Proxies, Potentially Influenced Set > > Any process that has entities within the PIS it could not lock has > ... > This will not work w/o spatial coherency, which should come quite > ... Definately more work on the client than I want to take on. Honestly, I hope that the kludging I am doing is a temporary thing. As latencies improve over the internet, I hope that I can go back to a totally dumb terminal at some future date when everyone has 50 ms ping times. It is a cleaner, more robust model with a lot more flexibility. > Another issue: what do you think about dedicated Resource Servers? > I.e. a client that tries to log on to a server, gets a list of > required resources (map, MDL). The client submits a request to a > Resource Server, and downloads all resources that are not locally > available without slowing down the Game Server machine. Something along those lines would be a good idea, but I don't expect it for the initial testing of QuakeWorld. John Carmack ----- End Included Message ----- From quake-dev-owner@gamers.org Wed Aug 7 22:02 MET 1996 From: "Per S. Hammer" Subject: Client/Server protocol in Quake To: quake developer-list Date: Wed, 7 Aug 1996 20:57:04 +0100 (BST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-quake-dev@gamers.org Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org X-Lines: 31 Status: RO Content-Type: text/plain; charset="us-ascii" Content-Length: 656 Folks, Likewise, has any of you done some reverse-engineering and can shed some light on the matter ? I guess it would be best if you mailed me personally, and I will then post a summary - this to avoid excessive spammage of this list. If I hear nothing I will assume noone knows, and then start to mess around with tcpdump's and UDP packet-headers myself ... ;) I'll still try to post a summary if you folk are interested, though. Happy Quaking, -Per -- Per S. Hammer per@mindbend.demon.co.uk phammer@uk.ibm.com Don't ask me, I just admin here. Certified IBM OS/2 Engineer From quake-dev-owner@gamers.org Thu Aug 8 11:18 MET 1996 Received: from gamers.org (majordomo@thegate.gamers.org [128.205.37.150]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id LAA29614 for ; Thu, 8 Aug 1996 11:18:01 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id FAA12828 for quake-dev-outgoing; Thu, 8 Aug 1996 05:11:39 -0400 Received: from xr3.atlas.fr (xr3.atlas.fr [194.51.9.5]) by gamers.org (thegate/gamers) with ESMTP id FAA12823 for ; Thu, 8 Aug 1996 05:11:33 -0400 Thu, 8 Aug 1996 11:14:46 +0200 Thu, 8 Aug 1996 11:14:46 +0200 Thu, 8 Aug 1996 11:12:09 +0200 X400-Received: by /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; Thu, 8 Aug 1996 11:14:46 +0200 X400-Received: by mta xr3.atlas.fr in /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; Thu, 8 Aug 1996 11:14:46 +0200 X400-Received: by /ADMD=ATLAS/C=FR/; Relayed; Thu, 8 Aug 1996 11:14:39 +0200 X400-Received: by /PRMD=cnet/ADMD=atlas/C=fr/; Relayed; Thu, 8 Aug 1996 11:12:09 +0200 Date: Thu, 8 Aug 1996 11:12:09 +0200 X400-Originator: montanuy@lsun80.lannion.cnet.fr X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=cnet/ADMD=atlas/C=fr/;839495529@x400.lannion.cnet.fr] X400-Content-Type: P2-1984 (2) Content-Identifier: RE: Client/Serve Alternate-Recipient: Allowed From: Olivier Montanuy Message-ID: <9608080912.020604@lat1192.lannion.cnet.fr> To: quake-dev@gamers.org Subject: RE: Client/Server protocol in Quake X-Mailer: E-Mail 1.6 Sender: owner-quake-dev@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 614 X-Lines: 17 Status: RO >Likewise, has any of you done some reverse-engineering and can > shed some light on the matter ? The best source of info is the DEM specs by Uwe Gilrish. The DEM files contain ordinary SERVER to CLIENT commands. For CLIENT to SERVER (needed for bots) hacking is required. That's how I did my camera. But though the staitc version worked, the rocket mounted one still producess a lot of mess :-( > then start to mess around with tcpdump's and UDP packet-headers TCP? what for? UDP only. >I'll still try to post a summary if you folk are interested, though. Please do. It's REAL needed now. Olivier From quake-dev-owner@gamers.org Thu Aug 8 11:57 MET 1996 Received: from gamers.org (majordomo@thegate.gamers.org [128.205.37.150]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id LAA29704 for ; Thu, 8 Aug 1996 11:52:51 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id FAA13057 for quake-dev-outgoing; Thu, 8 Aug 1996 05:48:36 -0400 Received: from marvin.nero.uni-bonn.de (root@marvin.nero.uni-bonn.de [131.220.7.30]) by gamers.org (thegate/gamers) with ESMTP id FAA13052 for ; Thu, 8 Aug 1996 05:48:31 -0400 Received: (from bernd@localhost) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) id KAA29484 for quake-dev@gamers.org; Thu, 8 Aug 1996 10:49:10 +0200 (MET DST) Date: Thu, 8 Aug 1996 10:49:10 +0200 (MET DST) From: Bernd Kreimeier Message-Id: <199608080849.KAA29484@marvin.nero.uni-bonn.de> To: quake-dev@gamers.org Subject: Re: Client/Server protocol in Quake X-Sun-Charset: US-ASCII Sender: owner-quake-dev@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 1038 X-Lines: 26 Status: RO >Does anyone know if id has released any specs on the IP (UDP) protocol >used in communication between Quake servers and Quake clients ? There has been a bit of info on the quake-servers list, perhaps you will find it in the archive at ftp://ftp.premier.net/pub/lists/quake-servers/ I have tried to put together those postings from John Cash, but I am currently drowning in other obligations. There is a very recommendable description of the DEM recording format at Uwe Girlich's page. The DEM format is nearly, perhaps completely identical to the network protocol. See http://www.physik.uni-leipzig.de/~girlich/games/ which is in the still upcoming (sorry about the delay) update of the QDP. Btw., he uses a modified Linuxdoc-SGML which I'd like to recommend for Specs. regards, b. From quake-dev-owner@gamers.org Thu Aug 8 20:00 MET 1996 Received: from gamers.org (majordomo@thegate.gamers.org [128.205.37.150]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id UAA01958 for ; Thu, 8 Aug 1996 20:00:25 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id NAA15466 for quake-dev-outgoing; Thu, 8 Aug 1996 13:52:24 -0400 Received: from lafvax (lafvax.lafayette.edu [139.147.8.2]) by gamers.org (thegate/gamers) with ESMTP id NAA15459 for ; Thu, 8 Aug 1996 13:52:19 -0400 Received: from lafvax.lafayette.edu by lafvax.lafayette.edu (PMDF V5.0-4 #6834) id <01I81AFMAJGG000GCV@lafvax.lafayette.edu> for quake-dev@gamers.org; Thu, 08 Aug 1996 13:55:45 -0500 (EST) Date: Thu, 08 Aug 1996 13:55:45 -0500 (EST) From: Mike Ruete Subject: RE: Client/Server protocol in Quake In-reply-to: <9608080912.020604@lat1192.lannion.cnet.fr> To: quake-dev@gamers.org Message-id: MIME-version: 1.0 Content-transfer-encoding: 7BIT Sender: owner-quake-dev@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org X-Lines: 13 Status: RO Content-Type: TEXT/PLAIN; charset="US-ASCII" Content-Length: 386 On Thu, 8 Aug 1996, Olivier Montanuy wrote: > >I'll still try to post a summary if you folk are interested, though. > Please do. It's REAL needed now. Is it really, though? Carmack is planning on having the re-written client/server code doen by the end of the month. Seems like it'd be kind of a waste to rip apart the current version. Just my opinion. -Mike Ruete / Gripp From quake-dev-owner@gamers.org Fri Aug 9 09:19 MET 1996 Received: from gamers.org (majordomo@thegate.gamers.org [128.205.37.150]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id JAA02939 for ; Fri, 9 Aug 1996 09:19:24 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id DAA16998 for quake-dev-outgoing; Fri, 9 Aug 1996 03:17:07 -0400 Received: from MAINE.maine.edu (SMTP2@maine.maine.edu [130.111.39.100]) by gamers.org (thegate/gamers) with SMTP id DAA16994 for ; Fri, 9 Aug 1996 03:17:02 -0400 Received: from frodo1 by MAINE.maine.edu (IBM VM SMTP V2R3) with TCP; Thu, 08 Aug 96 15:23:57 EDT Message-Id: <1.5.4.32.19960808192356.006b9524@maine.maine.edu> X-Sender: dslope51@maine.maine.edu X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Date: Thu, 08 Aug 1996 15:23:56 -0400 To: quake-c@seal-industries.com From: Derrick Subject: Carmark on Stack Size and impulses Cc: quake-dev@gamers.org Sender: owner-quake-dev@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org X-Lines: 44 Status: RO Content-Type: text/plain; charset="us-ascii" Content-Length: 1653 I wrote to John Carmack about Stack size and impulses, heres his reply: Return-Path: X-Nextstep-Mailer: Mail 3.3 (Enhance 1.0) From: John Carmack Date: Thu, 8 Aug 96 12:14:26 -0500 To: Derrick Subject: Re: Quake-C Stack Size References: <1.5.4.32.19960808170601.006a0ab8@maine.maine.edu> You wrote: > Hi, I know you're a busy man, but I've looked everywhere for info > on this, but to no avail. I'm having some trouble with stack > overflows, Could you tell me how big the stack is, and if there is > a function, or is there any way to implement one in quake-c that > would return the size of the stack so that a function could be > aborted if the stack got too large. > Also, (I realize that I don't know all the implications of what I > am asking) could I humbly sugest making the stack bigger in a > future ver. release. There is space reserved for 8k of variables, but the design of qc (which wasn't originally recursive!) makes it waste a lot of that on saving unneeded temporaries. I may be able to increase it a bit, but we are very tight on memory on 8 meg systems right now. > Also, we quake-c people are running out of > impulses, I'd love to see the number of available impules incresed > to 65535 rather that the present 256. Are you serious? I'm a bit shocked.... I will see if I can increase it, hough. John Carmack Derrick! mailto:dslope51@maine.maine.edu The Quake-C Reference Page: http://136.165.243.183/~frodo/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= God may be subtle, but He isn't plain mean. Albert Einstein From quake-dev-owner@gamers.org Fri Aug 9 15:29 MET 1996 Received: from gamers.org (thegate.gamers.org [128.205.37.150]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id PAA05201 for ; Fri, 9 Aug 1996 15:10:23 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id JAA00719 for quake-dev-outgoing; Fri, 9 Aug 1996 09:01:43 -0400 Received: from marvin.nero.uni-bonn.de (bernd@marvin.nero.uni-bonn.de [131.220.7.30]) by gamers.org (thegate/gamers) with ESMTP id JAA00712 for ; Fri, 9 Aug 1996 09:01:34 -0400 Received: (from bernd@localhost) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) id PAA05183; Fri, 9 Aug 1996 15:01:23 +0200 (MET DST) Date: Fri, 9 Aug 1996 15:01:23 +0200 (MET DST) From: Bernd Kreimeier Message-Id: <199608091301.PAA05183@marvin.nero.uni-bonn.de> To: quake-dev@gamers.org, bernd@marvin.nero.uni-bonn.de Subject: Info from John Carmack (QuakeWorld 2) X-Sun-Charset: US-ASCII Sender: owner-quake-dev@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 7336 X-Lines: 170 Status: RO Another mail on QuakeWorld details (published on http://acs.tamu.edu/~stm9233/qworld.txt), and one message from Michael Abrash distributed by Mike Wilson - there is an unsupported Win32 dedicated server release now, at ftp://ftp.idsoftware.com/idstuff/unsup/qwded103.exe. b. --------------------------------------------------------------------------- From: John Carmack To: jep@sclsis.navy.mil Subject: Quake World Date: Wednesday, August 07, 1996 11:03 AM Qspy is cool. Want to be the official front end for the QuakeWorld project? I think the initial research releases of QuakeWorld are going to be native win32 apps only, and they will listen on a control socket, so an external windows app can very nicely send them from server to server. If you are interested, I can go over the new features we are considering that would be pertinent, and solicit some opinions from you. John Carmack -------------------------------------------------------------------------- From: John Carmack To: "Joe E. Powell" Subject: Re: Quake World Date: Wednesday, August 07, 1996 01:36 PM Ok, the basic structure looks like this: A single master server running at a well known address at idsoftware.com. Freely available client and server win-32 executables. The servers do not require well known port numbers, because they register with the master, so you can just start up ten servers on a pp200, one after the other. When a server is started up, it configures all of its options, then sends a heartbeat out to the master to let it know it is alive. Heartbeats are sent once a minute, and contain all server information, a list of all connected clients, and all of the frags that have taken place in the last minute. They are udp packets fired into the void, so I'm not guaranteeing 100% accurate logging, but it should do just fine for all my purposes. External programs can request information directly from a server, but because they won't know the port number, they will generally be forced to ask the master for at least an address. (they MUST go through the master to connect to a server, they can't just go there directly) Any program can request current server information from the master. I'm still unsure exactly how I want to handle this. I want to have a rough idea of how to scale this setup to around 1000 active servers and 5000 active users, which impacts options a bit. In addition to the current quake info (level, current users, max users), the master will also have a set of key/value pairs from the server that can be used for arbitrary information, like which skill ranks are allowed. I am currently torn between having some form of a query sent to the master to pare down the number of returned servers vs just dumping some form of the entire list to let the client search it. I am leaning toward the dump-the-list aproach, because I know I can change it if it looks like it is going to get overloaded, and it gives max flexibility. Comments? The master will also be able to return the public information for any userid, so you can print out proper named rosters for each server. It will be cool to be able to find out if any of your friends are playing on servers anywhere in the world. User accounts consist of a user id, a password, and two sets of arbitrary key/value pairs. The user modifiable set will be for name, color, clan, etc. The protected (master-modifiable only) will be for rankings and other read only rights that can only be changed by the master server. I don't know all the things we are going to want to try, so I think the unstructured pair lists will give the best flexebility. When a user requests a connection to a server, the master sends their account information and ip address in a message to the server they requested. Servers ignore connect messages from any address but the master. The individual servers are the final authorities for admission of a user. They can accept a user connect command from the master, and simply refuse to honor it for whatever reason (wrong rank, on the banned list, etc). There is an internal ping command in the servers, which should be used over a regular internet ping for quality testing, because the turnaround time for it will also be somewhat influenced by the current server load. There is a "logon" protocol message to the master that returns the current userdata and masterdata for an account if the proper password is given. It isn't really establishing any connection, because you must present user id and password for the connect The first real game extension that I want to add is a centrally administered ranking scheme. Start everyone at private, and let them advance. This gives everyone something to achieve, and will also be used to limit servers to various skill levels. There are millions of other things I want to try, especially with teams, but I want to take this in small managable steps. I am presenting this as research-in-progress, so I'm not going to feel any guilt for downing the master at various times or doing frequent updates to the client/server exes. I would like to move user account creation and logon out of Quake proper, into the GUI app. My vague vision of the gui front end looks like: Launch Quake and get the port number that it running at, which will be needed for connect messages. An initial choice to either logon with an existing userid / password, or create a new account. If logon, fetch the current information from the master and display it. The user data should only change when the user directs it, but the master data will be updated sparadically. The user should be able to see that he advanced in rank before searching for servers. If newuser, prompt for a name, color, and password then fire off a message to the master that will respond with a new userid. Perform a logon to see if any masterdata was generated for the new account. Once the app has a valid userid/password, fetch the server list from the master, and do all the qspy like performance sorting and filtering. When one is selected, send a message to Quake to try to actually log in. These messages will be heeded at any time, so a user can just drop out of full screen Quake mode and click on another server if they like. I am totally open to comments and suggestions. John Carmack --------------------------------------------------------------------------- >From mikew@idsoftware.com Thu Aug 8 23:22 MET 1996 ---------- From: Michael Abrash[SMTP:mikeab] Sent: Thursday, August 08, 1996 4:14 PM Subject: Win32 dedicated Quake server I have placed a native Win32 dedicated Quake server, on the ftp site in idstuff/unsup/qwded103.exe. Please let people know about this. This is an unsupported release, but we have tested it quite a bit over the last few days, and it seems to be the best Internet Quake server available at the moment--and of course it support NT, so it should make a lot of people happy. One note: you have to have the registered Quake levels to run this dedicated server. --Michael --------------------------------------------------------------------------- From quake-dev-owner@gamers.org Wed Aug 7 19:44 MET 1996 From: "Brian K. Martin" Subject: meddle To: quake-dev@gamers.org Date: Wed, 7 Aug 1996 13:39:45 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-quake-dev@gamers.org Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org X-Lines: 22 Status: RO Content-Type: text/plain; charset="us-ascii" Content-Length: 115 I have put a newer version of meddle on cdrom.com and on my homepage www.phyast.pitt.edu/~brian/meddle brian From quake-dev-owner@gamers.org Sun Aug 11 02:55 MET 1996 Received: from olymp.informatik.uni-bonn.de (root@olymp.informatik.uni-bonn.de [131.220.4.1]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id CAA07105 for ; Sun, 11 Aug 1996 02:55:37 +0200 (MET DST) Received: from gamers.org (majordomo@thegate.gamers.org [128.205.37.150]) by olymp.informatik.uni-bonn.de (8.7.1/8.6.12) with ESMTP id CAA04707 for ; Sun, 11 Aug 1996 02:55:51 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id UAA02323 for quake-dev-outgoing; Sat, 10 Aug 1996 20:35:40 -0400 Received: from minerva.phyast.pitt.edu (minerva.phyast.pitt.edu [136.142.111.2]) by gamers.org (thegate/gamers) with SMTP id UAA02318 for ; Sat, 10 Aug 1996 20:35:36 -0400 Received: (brian@localhost) by minerva.phyast.pitt.edu (8.6.10/8.6.5) id UAA13724 for quake-dev@gamers.org; Sat, 10 Aug 1996 20:35:09 -0400 From: "Brian K. Martin" Message-Id: <199608110035.UAA13724@minerva.phyast.pitt.edu> Subject: Re: Rendered output ? To: quake-dev@gamers.org Date: Sat, 10 Aug 1996 20:35:08 -0400 (EDT) In-Reply-To: <1.5.4.32.19960810154108.0070416c@mail.winternet.com> from "Jim Lowell" at Aug 10, 96 10:41:08 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-quake-dev@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org X-Lines: 20 Status: RO Content-Type: text/plain; charset="US-ASCII" Content-Length: 832 > > At 10:09 PM 8/10/96 +0800, Chris Cason wrote: > > > >Has anyone who is working on an editor considered providing export of a world > >(or part thereof) to the input file format of a ray-tracer ? I know some of > >you are building in a ray-tracer, but I'm talking export here. MedDLe (which is not a map editor) will now save model frames in asc, raw, POV, map, dxf, wrl, and (~3ds). So if anyone wants to stick a model in a map and render it with pov, it's done. If someone were to hold a gun to my head I would write a map to POV converter, but I'm sure someone else will do it. BTW, that version of MedDLe will be out next week if things go smooth with the importing section... Question.. Does anyone have an easy to use GIF decoder/encoder source in c/c+++? I've looked at plab source, but it looks a mess... brian From quake-dev-owner@gamers.org Sat Aug 10 14:16 MET 1996 Received: from gamers.org (majordomo@thegate.gamers.org [128.205.37.150]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id OAA06656 for ; Sat, 10 Aug 1996 14:16:06 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id IAA10067 for quake-dev-outgoing; Sat, 10 Aug 1996 08:13:10 -0400 Received: from tulpi.interconnect.com.au (root@tulpi.interconnect.com.au [192.189.54.18]) by gamers.org (thegate/gamers) with ESMTP id IAA10063 for ; Sat, 10 Aug 1996 08:13:05 -0400 Received: from hallam.oaks.com.au (dialup-m3-19.Melbourne.netspace.net.au [203.17.99.147]) by tulpi.interconnect.com.au with SMTP id WAA08920 (8.7.4/IDA-1.6 for ); Sat, 10 Aug 1996 22:12:50 +1000 (EST) Message-ID: <199608101212.WAA08920@tulpi.interconnect.com.au> Comments: Authenticated sender is From: "Chris Cason" Organization: Hallam Oaks Pty. Ltd. To: quake-dev@gamers.org Date: Sat, 10 Aug 1996 22:09:57 +0800 Subject: Rendered output ? Priority: normal X-mailer: Pegasus Mail for Win32 (v2.42) Sender: owner-quake-dev@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 693 X-Lines: 19 Status: RO Excuse if this has already been discussed ... Has anyone who is working on an editor considered providing export of a world (or part thereof) to the input file format of a ray-tracer ? I know some of you are building in a ray-tracer, but I'm talking export here. [Mind you, I'md not saying that such export would be actually _useful_, from an editing/creation sense, but it could be interesting ...] If any of you are interested, email me or followup here (I think it's close enough to being on-topic ? Correct me if not.) I'd also be interested in a talking about a utility that can read the quake data files and create such output. -- Chris PS I'm one of the developers of POV-Ray. From quake-dev-owner@gamers.org Sat Aug 10 17:49 MET 1996 Received: from gamers.org (majordomo@thegate.gamers.org [128.205.37.150]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id RAA06765 for ; Sat, 10 Aug 1996 17:49:47 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id LAA11639 for quake-dev-outgoing; Sat, 10 Aug 1996 11:46:37 -0400 Received: from taz.intouchavl.com ([206.121.78.200]) by gamers.org (thegate/gamers) with ESMTP id LAA11635 for ; Sat, 10 Aug 1996 11:46:33 -0400 Received: from jlowell.intouchavl.com ([206.121.78.5]) by taz.intouchavl.com (post.office MTA v1.9.3b evaluation license) with SMTP id AAA391 for ; Sat, 10 Aug 1996 10:49:11 -0500 Message-Id: <1.5.4.32.19960810154108.0070416c@mail.winternet.com> X-Sender: jlowell@mail.winternet.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Date: Sat, 10 Aug 1996 10:41:08 -0500 To: quake-dev@gamers.org From: Jim Lowell Subject: Re: Rendered output ? Sender: owner-quake-dev@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org X-Lines: 22 Status: RO Content-Type: text/plain; charset="us-ascii" Content-Length: 978 At 10:09 PM 8/10/96 +0800, Chris Cason wrote: >Excuse if this has already been discussed ... > >Has anyone who is working on an editor considered providing export of a world >(or part thereof) to the input file format of a ray-tracer ? I know some of >you are building in a ray-tracer, but I'm talking export here. > >[Mind you, I'md not saying that such export would be actually _useful_, from >an editing/creation sense, but it could be interesting ...] > >If any of you are interested, email me or followup here (I think it's close >enough to being on-topic ? Correct me if not.) I'd also be interested in a >talking about a utility that can read the quake data files and create such >output. This is something that I have been interested in doing for a while now. You will be able to export Thred maps to a simple format which I believe could easily be converted to PovRay. I don't know if this export working right now or not, but I'll check and see. -= Jim Lowell =- From quake-dev-owner@gamers.org Tue Aug 13 15:57 MET 1996 Received: from olymp.informatik.uni-bonn.de (root@olymp.informatik.uni-bonn.de [131.220.4.1]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id PAA02309 for ; Tue, 13 Aug 1996 15:57:03 +0200 (MET DST) Received: from gamers.org (majordomo@thegate.gamers.org [128.205.37.150]) by olymp.informatik.uni-bonn.de (8.7.1/8.6.12) with ESMTP id PAA20556 for ; Tue, 13 Aug 1996 15:56:58 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id JAA18607 for quake-dev-outgoing; Tue, 13 Aug 1996 09:44:26 -0400 Received: from marvin.nero.uni-bonn.de (bernd@marvin.nero.uni-bonn.de [131.220.7.30]) by gamers.org (thegate/gamers) with ESMTP id JAA18601 for ; Tue, 13 Aug 1996 09:44:19 -0400 Received: (from bernd@localhost) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) id PAA02207 for quake-dev@gamers.org; Tue, 13 Aug 1996 15:40:11 +0200 (MET DST) Date: Tue, 13 Aug 1996 15:40:11 +0200 (MET DST) From: Bernd Kreimeier Message-Id: <199608131340.PAA02207@marvin.nero.uni-bonn.de> To: quake-dev@gamers.org Subject: Re: Rendered output ? X-Sun-Charset: US-ASCII Sender: owner-quake-dev@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 599 X-Lines: 17 Status: RO >Does anyone have an easy to use GIF decoder/encoder source >in c/c+++? Michael used a C++ wrapper to Gershon Elber's giflib (with the Difference Engine r95 renderer's screendumps). A recent version of that giflib should be available at http://www.ccil.org/~esr/esr-freeware.html namely http://www.ccil.org/~esr/giflib-2.3.tar.gz. C source, with Linux support. I do not know whether GIF89a support (transparent backgrounds) is already in there. regards, b. From quake-dev-owner@gamers.org Mon Aug 19 17:59 MET 1996 Received: from olymp.informatik.uni-bonn.de (root@olymp.informatik.uni-bonn.de [131.220.4.1]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id RAA08833 for ; Mon, 19 Aug 1996 17:59:07 +0200 (MET DST) Received: from gamers.org (thegate.gamers.org [128.205.37.150]) by olymp.informatik.uni-bonn.de (8.7.1/8.6.12) with ESMTP id RAA27011 for ; Mon, 19 Aug 1996 17:58:33 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id LAA00457 for quake-dev-outgoing; Mon, 19 Aug 1996 11:49:40 -0400 Received: from marvin.nero.uni-bonn.de (marvin.nero.uni-bonn.de [131.220.7.30]) by gamers.org (thegate/gamers) with ESMTP id LAA00452 for ; Mon, 19 Aug 1996 11:49:33 -0400 Received: (from bernd@localhost) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) id PAA08273 for quake-dev@gamers.org; Mon, 19 Aug 1996 15:18:25 +0200 (MET DST) Date: Mon, 19 Aug 1996 15:18:25 +0200 (MET DST) From: Bernd Kreimeier Message-Id: <199608191318.PAA08273@marvin.nero.uni-bonn.de> To: quake-dev@gamers.org Subject: Re: Quake Network specifications X-Sun-Charset: US-ASCII Sender: owner-quake-dev@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 539 X-Lines: 19 Status: RO Olivier wrote: >Dunno if someone released such info. I came across the Quake Network Protocol Specs v1.01b at http://www.upd.edu.ph/~oliber/quake/qnp.html. I already mailed the author - I still suggest you, A. Oliver De Guzman (oliber@aiko.upd.edu) and Uwe Girlich should write a single DEM/Network Specs document to avoid overlap. >intercept, fake client, shielding bots etc. Great! regards, b. From quake-dev-owner@gamers.org Thu Aug 22 09:28 MET 1996 Received: from gamers.org (majordomo@thegate.gamers.org [128.205.37.150]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id JAA20439 for ; Thu, 22 Aug 1996 09:27:25 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id DAA15193 for quake-dev-outgoing; Thu, 22 Aug 1996 03:23:40 -0400 Received: from marvin.nero.uni-bonn.de (bernd@marvin.nero.uni-bonn.de [131.220.7.30]) by gamers.org (thegate/gamers) with ESMTP id DAA15170 for ; Thu, 22 Aug 1996 03:21:57 -0400 Received: (from bernd@localhost) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) id JAA20428; Thu, 22 Aug 1996 09:21:50 +0200 (MET DST) Date: Thu, 22 Aug 1996 09:21:50 +0200 (MET DST) From: Bernd Kreimeier Message-Id: <199608220721.JAA20428@marvin.nero.uni-bonn.de> To: quake-dev@gamers.org, bernd@marvin.nero.uni-bonn.de Subject: Info from John Carmack (final) X-Sun-Charset: US-ASCII Sender: owner-quake-dev@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 3869 X-Lines: 92 Status: RO To give proper credit - the original Dark Sucker Theory nonsense that inspired my suggestion has been posted by Mike Hammond on rec.arts.sf.science in june 1996. I will be in the USA from August 27th till October 25th. The QuakeDev pages will be mothballed from next weekend on (one overdue update to happen then). Thus this is the final q&a posting for some time. b. ----- Begin Included Message ----- >From johnc@idcanon1.idsoftware.com Thu Aug 8 14:55 MET 1996 You wrote: > A bit of design speculations on Current Generation Technology.... > > Q: on backface culling with dynamic lighting - I agree, the current > approximation is indeed a far more convincing solution. A neat > feature even: textures resembling a colored but opaque glass on > thin walls will let moving light sources shine through. Yes, it is pretty cool to see people fighting on the floor beneath you. Totally unrealistic, but neat. > Q: could the Quake engine be used to render to 24bit fb, using the > same indexed color mipmaps and palette? Would it make sense using a > few additional palettes then (e.g. maxbright for light sources > etc.)? We had a 16 and 24 bit backend for a while, but it wasn't worth the effort to maintain the code. 16 bit looked worse, and 24 bit only looked marginally better. If you make a bad 256 color design, direct color will help a lot, but a good 256 color design tries to minimize the palette fitting required. The next engine will be all direct color, and we will be designing for it from the beginning, to good benefit. > Q: Is there any use for a translucency lookup, e.g. byte > LUT[256][256], to map fb_col == LUT[src_col][dest_col]. Taking > advantage of sorted spans and z-buffer, one might put translucent > spans on a stack during front-to-back, and render them afterwards > back-to-front. For mipmapped sprites/billboards, semitransparent > water, colored glass. This is ugly (compared to RGBA) and probably > dead slow even if used with care - not worth the trouble? For a little while I had translucent alias models in the game. We didn't have a great use for them, so I took the hack out, but it may come back in Quake 2. Integrating translucency with the edge sorting for the main world rendering would be a lot more painfull. Another thing to think about is how it will work with hardware accelerators. If you don't stick to a straight blend operation, the hardware can't do the same thing as the arbitrary table. > Q: any way to customize particles - i.e., choose a sprite instead > of a single color for each particle? Is there an entity for each > particle? Not currently. There are up to 2048 particles, so no, there isn't an entity for each one. They have very tight hard coded actions: spread out, fall slowly, fall fast, fade as a rocket trail, fly as an explosion, etc. > A few months ago you mentioned talking to the Rendition people, in > favor of some disclosure of technical info, with XFree86/GLX/Mesa > support in mind. Did you ever get around to this? Yes, I did. The techie type I talk to didn't have any objections at all to it, but the are an under-the-gun startup company, so I don't think they are going to have spare time for a while. > If your handling of dynamic light source brightness uses > a signed magnitude value, it should be possible to implement > a "Dark Sucker" entity. This is not meant as a useful > approximation of illumination in any sense (perhaps > decreasing the ambient would be better anyway). From (your) > game design POV - would such an effect fit to a Quake-like > concept, or would it spoil the immersion? Probably a good idea. We'll check it out. John Carmack ----- End Included Message ----- From quake-dev-owner@gamers.org Thu Aug 22 09:46 MET 1996 Received: from gamers.org (majordomo@thegate.gamers.org [128.205.37.150]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id JAA20870 for ; Thu, 22 Aug 1996 09:45:43 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id DAA15432 for quake-dev-outgoing; Thu, 22 Aug 1996 03:44:46 -0400 Received: from marvin.nero.uni-bonn.de (bernd@marvin.nero.uni-bonn.de [131.220.7.30]) by gamers.org (thegate/gamers) with ESMTP id DAA15428 for ; Thu, 22 Aug 1996 03:44:36 -0400 Received: (from bernd@localhost) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) id JAA20866 for quake-dev@gamers.org; Thu, 22 Aug 1996 09:44:10 +0200 (MET DST) Date: Thu, 22 Aug 1996 09:44:10 +0200 (MET DST) From: Bernd Kreimeier Message-Id: <199608220744.JAA20866@marvin.nero.uni-bonn.de> To: quake-dev@gamers.org Subject: Re: Info from John Carmack (final) X-Sun-Charset: US-ASCII Sender: owner-quake-dev@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 3457 X-Lines: 97 Status: RO I did not get across the first time my question on a 24bpp renderer design. b. ----- Begin Included Message ----- >From bernd Fri Aug 9 17:44 MET 1996 Date: Fri, 9 Aug 1996 17:43:54 +0200 (MET DST) From: Bernd Kreimeier To: johnc@idsoftware.com Sorry about this, I haven't made myself clear. You wrote: >> Q: could the Quake engine be used to render to 24bit fb >We had a 16 and 24 bit backend for a while, but it wasn't worth the >effort to maintain the code. 16 bit looked worse, and 24 bit only >> Q: Is there any use for a translucency lookup, e.g. byte >> LUT[256][256], to map fb_col == LUT[src_col][dest_col]. >Another thing to think about is how it will work with hardware >accelerators. If you don't stick to a straight blend operation, >the hardware can't do the same thing as the arbitrary table. I actually meant the questions to be related. Basically, I am thinking about different ways to combine index color palettes and mipmaps with 24bit back end and hardware support. My crude reasoning was like (a) a well designed translucency (straight blend) might work well with hardware if a 24bit back end is used (b) using palettes and index color mipmaps, conversion to RGB could be done in the mipmap+lightmap processing (surface cache). (c) once using hardware, this could be extended (different palettes for mipmaps, skins, RGBA billboards and water) I understood from earlier explanations that there is no advantage in 24bpp (and no value at all in 16bpp) with the current design. However, I am still wondering how well the lightmap approach will work with hardware support. Depending on your modifications (or replacements) for the main memory surface cache, isn't a 24bit backend a better choice - even allowing for additional features? Related: could the Verite programmable RISC be tweaked to do the mipmap+lightmap processing on board? Does it make sense to try to use blending with the current lightmaps? [...] regards b. ----- End Included Message ----- ----- Begin Included Message ----- >From johnc@idcanon1.idsoftware.com Thu Aug 22 08:41 MET 1996 From: John Carmack Date: Thu, 22 Aug 96 01:40:40 -0500 To: Bernd Kreimeier > on a hybrid renderer (indexed color mipmaps > and RGB surface cache, RGBA billboards with RGBA frame buffer and > RGBA hardware blends)? Or are you too busy with QuakeWorld? It was one of those questions that a well worded response didn't leap from my fingers for, and the mail got buried. I am often getting 50+ emails a fay (ugh), so if it doesn't get answered fast, it rarely does at all. Yes, multiple palettes for textures would be a reasonable way of expanding the dynamic range of a 3d game, because it would still allow you to do the lighting with lookups, which is not practical for full 16 bit textures. I think if I were to do a software only 16 bit game (not planned), I would just bite the bullet and spend a longer time in the surface cache generation and do it right with full 16 bit source data. Matter of taste, not a huge technical issue. John Carmack ----- End Included Message ----- From quake-dev-owner@gamers.org Sun Aug 25 21:41 MET 1996 Received: from gamers.org (majordomo@thegate.gamers.org [128.205.37.150]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id VAA01525 for ; Sun, 25 Aug 1996 21:41:02 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id PAA12593 for quake-dev-outgoing; Sun, 25 Aug 1996 15:30:50 -0400 Received: from genesis.nred.ma.us (genesis.tiac.net [204.180.76.1]) by gamers.org (thegate/gamers) with ESMTP id PAA12578 for ; Sun, 25 Aug 1996 15:30:38 -0400 Received: by genesis.nred.ma.us (8.6.9/genesis0.0) id PAA05692; Sun, 25 Aug 1996 15:31:17 -0400 Message-Id: <199608251931.PAA05692@genesis.nred.ma.us> From: "Mark Mathews" To: "quake-dev@gamers.org" Date: Sun, 25 Aug 96 15:33:20 -0400 Priority: Normal X-Mailer: PMMail 1.52 For OS/2 UNREGISTERED SHAREWARE MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: formats Sender: owner-quake-dev@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org X-Lines: 8 Status: RO Content-Type: text/plain; charset="us-ascii" Content-Length: 182 Does anybody have formats to .MDL, .BSP, and .LMP? I need to know how to read and write these files. Thanks, Mark Mathews mmathews@genesis.nred.ma.us TEAM OS/2, TEAM WOTE From quake-dev-owner@gamers.org Sun Aug 25 22:07 MET 1996 Received: from gamers.org (majordomo@thegate.gamers.org [128.205.37.150]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id WAA01535 for ; Sun, 25 Aug 1996 22:07:47 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id QAA13297 for quake-dev-outgoing; Sun, 25 Aug 1996 16:00:03 -0400 Received: from parsifal.nando.net (root@parsifal.nando.net [152.52.2.7]) by gamers.org (thegate/gamers) with ESMTP id PAA13293 for ; Sun, 25 Aug 1996 15:59:58 -0400 Received: from mistix (grail1312.nando.net [152.52.29.12]) by parsifal.nando.net (8.7/8.6.9) with ESMTP id QAA10707 for ; Sun, 25 Aug 1996 16:02:56 -0400 (EDT) Message-Id: <199608252002.QAA10707@parsifal.nando.net> From: "Phrog`gee" To: "quake-dev" Subject: v_idlescale Date: Sun, 25 Aug 1996 16:01:41 -0400 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1132 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-quake-dev@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org X-Lines: 7 Status: RO Content-Type: text/plain; charset="Default" Content-Length: 213 Has anyone yet discussed the possibilities of using v_idlescale yet? - "The greatest sin is underestimating the enemy" Phrog`gee _Phroge_ Diplomat Clan Napalm Death http://www.onetinc.com/~hans/napalm.html From quake-dev-owner@gamers.org Sun Aug 25 22:13 MET 1996 Received: from gamers.org (majordomo@thegate.gamers.org [128.205.37.150]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id WAA01544 for ; Sun, 25 Aug 1996 22:13:09 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id QAA13416 for quake-dev-outgoing; Sun, 25 Aug 1996 16:04:51 -0400 Received: from rendsburg.netsurf.de (root@rendsburg.netsurf.de [194.64.167.161]) by gamers.org (thegate/gamers) with SMTP id QAA13403 for ; Sun, 25 Aug 1996 16:04:41 -0400 Received: from ppp5.rendsburg.netsurf.de (ppp5.rendsburg.netsurf.de [194.64.167.166]) by rendsburg.netsurf.de (8.6.9/8.6.9) with SMTP id WAA28086 for ; Sun, 25 Aug 1996 22:05:55 +0200 Date: Sun, 25 Aug 1996 22:05:55 +0200 Message-Id: <199608252005.WAA28086@rendsburg.netsurf.de> X-Sender: d.moeller@rendsburg.netsurf.de X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 To: quake-dev@gamers.org From: Denis Subject: Re: formats Sender: owner-quake-dev@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org X-Lines: 14 Status: RO Content-Type: text/plain; charset="us-ascii" Content-Length: 359 Hi! At 15:33 25.08.1996 -0400, you wrote: >Does anybody have formats to .MDL, .BSP, and .LMP? >I need to know how to read and write these files. Doesn't Raphael's QEU stuff handle these? cya Denis --- Denis Moeller, author of NWTpro, quip and TiC's WAD Reviews. e-mail: d.moeller@rendsburg.netsurf.de, #irc: panza http://www.geocities.com/Hollywood/2299/ From quake-dev-owner@gamers.org Sun Aug 25 22:49 MET 1996 Received: from gamers.org (majordomo@thegate.gamers.org [128.205.37.150]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id WAA01558 for ; Sun, 25 Aug 1996 22:49:01 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id QAA14261 for quake-dev-outgoing; Sun, 25 Aug 1996 16:35:16 -0400 Received: from glacier.wise.edt.ericsson.se (glacier-ext.wise.edt.ericsson.se [193.180.251.38]) by gamers.org (thegate/gamers) with ESMTP id QAA14244 for ; Sun, 25 Aug 1996 16:34:59 -0400 Received: from chapelle.eed.ericsson.se (chapelle.eed.ericsson.se [164.48.132.130]) by glacier.wise.edt.ericsson.se (8.7.5/8.7.3/glacier-0.9) with ESMTP id WAA19788 for ; Sun, 25 Aug 1996 22:41:58 +0200 (MET DST) Received: (from eedraq@localhost) by chapelle.eed.ericsson.se (8.7.1/8.7.1) id WAA18851 for quake-dev@gamers.org; Sun, 25 Aug 1996 22:41:57 +0200 (MET DST) Date: Sun, 25 Aug 1996 22:41:56 +0200 (MET DST) Message-Id: <199608252041.WAA18851@chapelle.eed.ericsson.se> To: quake-dev@gamers.org Subject: Re: formats From: Raphael.Quinet@eed.ericsson.se Sender: owner-quake-dev@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 1657 X-Lines: 32 Status: RO On Sun, 25 Aug 1996, Denis wrote: > At 15:33 25.08.1996 -0400, you wrote: > >Does anybody have formats to .MDL, .BSP, and .LMP? > >I need to know how to read and write these files. > Doesn't Raphael's QEU stuff handle these? Well, I sent a personal reply to Mark, but I think I should have posted it to the list instead... I haven't done much for QEU recently. I distributed a beta version of QEU 0.4 to a few people, but there is not much that has changed from 0.3 regarding Quake's files. I have added a lot of stuff for various graphics file formats and the code is now split in two parts: GAEL (GAme Editing Library) which contains a set of functions for working with various file formats, and QEU which contains the utilities compiled with that library. I want GAEL to be as portable and easy to use as possible, so that other people can use it to develop small (or big) utilities without having to re-invent the wheel. GAEL will of course be freely available, and distributed with full source code. Unfortunately, the only Quake file formats that are currently well supported by GAEL (and thus QEU) are the PAK and WAD2 files. I still have to update the code for the other file formats such as MDL and BSP, but I want to finish something else first: the Floyd-Steinberg dithering that can be used for converting various textures and graphics to the Quake palette. I broke that part of the code while trying to optimize it, and I cannot get it to work again (the colors are incorrect). Alas, I haven't had the time to touch the code since last month. I hope I will be able to get back to it soon. -Raphael From quake-dev-owner@gamers.org Mon Aug 26 10:30 MET 1996 Received: from gamers.org (majordomo@thegate.gamers.org [128.205.37.150]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id KAA02214 for ; Mon, 26 Aug 1996 10:30:43 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id EAA24797 for quake-dev-outgoing; Mon, 26 Aug 1996 04:23:52 -0400 Received: from xr3.atlas.fr (xr3.atlas.fr [194.51.9.5]) by gamers.org (thegate/gamers) with ESMTP id EAA24793 for ; Mon, 26 Aug 1996 04:23:49 -0400 Mon, 26 Aug 1996 10:22:04 +0200 Mon, 26 Aug 1996 10:22:04 +0200 Mon, 26 Aug 1996 10:21:54 +0200 X400-Received: by /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; Mon, 26 Aug 1996 10:22:04 +0200 X400-Received: by mta xr3.atlas.fr in /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; Mon, 26 Aug 1996 10:22:04 +0200 X400-Received: by /ADMD=ATLAS/C=FR/; Relayed; Mon, 26 Aug 1996 10:22:00 +0200 X400-Received: by /PRMD=cnet/ADMD=atlas/C=fr/; Relayed; Mon, 26 Aug 1996 10:21:54 +0200 Date: Mon, 26 Aug 1996 10:21:54 +0200 X400-Originator: montanuy@lsun80.lannion.cnet.fr X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=cnet/ADMD=atlas/C=fr/;841047714@x400.lannion.cnet.fr] X400-Content-Type: P2-1984 (2) Content-Identifier: RE: formats Alternate-Recipient: Allowed From: Olivier Montanuy Message-ID: <9608260811.340498@lat1192.lannion.cnet.fr> To: quake-dev@gamers.org Subject: RE: formats X-Mailer: E-Mail 1.6 Sender: owner-quake-dev@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 525 X-Lines: 16 Status: RO >Does anybody have formats to .MDL, .BSP, and .LMP? >I need to know how to read and write these files. I thought that's the kind of stuff we had documented in the UQS. last version is 3.3, and it IS up to date, to my best knowledge. WinTex 4.4 can read those formats. You can get the source if you want, but I had rather release it as part of my new Quake Bot, once made really portable. (My bot compiled under Unix/Win95/Win3.1, but the .BSP and .MDL are not included yet, which make it pretty blind). Olivier From quake-dev-owner@gamers.org Mon Aug 26 11:01 MET 1996 Received: from gamers.org (majordomo@thegate.gamers.org [128.205.37.150]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id LAA02421 for ; Mon, 26 Aug 1996 11:01:13 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id EAA25184 for quake-dev-outgoing; Mon, 26 Aug 1996 04:55:58 -0400 Received: from marvin.nero.uni-bonn.de (bernd@marvin.nero.uni-bonn.de [131.220.7.30]) by gamers.org (thegate/gamers) with ESMTP id EAA25180 for ; Mon, 26 Aug 1996 04:55:52 -0400 Received: (from bernd@localhost) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) id KAA02359; Mon, 26 Aug 1996 10:54:56 +0200 (MET DST) Date: Mon, 26 Aug 1996 10:54:56 +0200 (MET DST) From: Bernd Kreimeier Message-Id: <199608260854.KAA02359@marvin.nero.uni-bonn.de> To: quake-dev@gamers.org, bernd@marvin.nero.uni-bonn.de Subject: ADMIN: offline X-Sun-Charset: US-ASCII Sender: owner-quake-dev@gamers.org Precedence: bulk Reply-To: quake-dev@gamers.org X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 1279 X-Lines: 34 Status: RO I will be in the USA from tomorrow on, till end of october. Steve Benner will kindly take over maintenance of Quake Developer's during those two months. I am currently uploading a final update of the Quake Documentation Project at http://www.gamers.org/dEngine/quake/#QDP. Please submit updates and additional documents to Raphael Quinet. I strongly recommend maintaining a QDP-like collection of all technical documents on the web. One remark about the list: since february, Quake Developer's has been a rather low traffic but hopefully worthwhile list. Here is a good place to post announcements, references and pointers to updates, new tutorials, new source releases, and whatever info is released by id or the community. Nobody who is actually developing something has the time to browse all those web pages out there. see ya around halloween, b. P.S.: this message will be the last in the manually updated Hypermail archive. Please use the DoomGate archives at http://www.gamers.org/forums/hypermail/ in the meantime.