From owner-quake-dev-digest@gamers.org Fri Aug 2 15:31 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 PAA08539 for ; Fri, 2 Aug 1996 15:31:37 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id JAA00590 for quake-dev-digest-outgoing; Fri, 2 Aug 1996 09:30:26 -0400 From: owner-quake-dev-digest@gamers.org Date: Fri, 2 Aug 1996 09:30:26 -0400 Message-Id: <199608021330.JAA00590@gamers.org> To: quake-dev-digest@gamers.org Subject: quake-dev-digest V1 #28 Reply-To: quake-dev@gamers.org Errors-To: owner-quake-dev-digest@gamers.org Precedence: bulk X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 35499 X-Lines: 858 Status: RO quake-dev-digest Friday, 2 August 1996 Volume 01 : Number 028 ---------------------------------------------------------------------- From: Matt Croydon Date: Tue, 30 Jul 1996 11:31:53 -0400 (EDT) Subject: QUTILS Has anyone successfully compiled the qutils (texmake, modelgen, etc) for dos? I've tried but failed :-( - --Matt/Netminder "Our audiance is like people who like licorice. Not everyone likes licorice, but the people who like licorice _really_ like licorice." --Jerry Garcia Matt Croydon ------------------------------ From: pinkdogg@cgsd.com (Alan Blaine) Date: Tue, 30 Jul 1996 12:00:55 -0700 Subject: Re: QUTILS >Has anyone successfully compiled the qutils (texmake, modelgen, etc) for >dos? I've tried but failed :-( I massaged them into a Win95 Console version that loads .3ds or .tri. It was a hard task, and I only worked w/ texmake and modelgen. They are avail at Stomped, and are at .2 Beta. Having some memory allocation related crashes. As soon as fixed and tested I'll bring to 1.0. Alan Blaine pinkdogg@cgsd.com ------------------------------ From: "S. Patrick Gallaty" Date: Tue, 30 Jul 1996 12:54:06 +08:0 Subject: An intro, poll for ideas - Hello, I wanted to put my ideas out and let people chew on them. My idea is to make a persisting server that will maintain character stats, medals, rank etc. Provide ongoing randomly generated missions in a consistent theme backdrop. The scenario is a mix of starship troopers, seal team, and quake. Features I want : Persisting characters with stats. strength health dexterity courage intel Character skills weapon skills (assists in reload times, unjam, aim) martial arts (reduce damage in hth combat, etc.) aim medical technical repair demolitions (setting/using/disarming detpacks) awareness stealth leadership character advancement limited perception (You may not see and hear everything) stealth, hiding crouching, crawling ballistic weapons ground cover, foliage ambient sounds randomly generated missions with pri and sec. objectives search and destroy patrol recon in force search and rescue recovery demolitions dropships artillery (called in by squadleader players) I imagine a 'mothership' like the sulaco from aliens where players hang around between missions - and there may be streches of time where the game is between mission sites. I imagine making several different types of player .mdl's for this. (Gi's in T-shirts :) The idea about the missions is that there would be a dropship, and on some missions an ammo dump or supply depot. The players get dropped into a zone, and have to accomplish their missions from this point. Like most tactical strikes, they have a limited amount of time to accomplish their objectives and get out before the enemy has time to mount an organized defense. They also have to be able to recognize when they have met organized defenses and know when to abort the mission. The enemy will vary from nonexistant to numerous, from heavy and fortified to hidden and snipers. Players will do all sorts of things from having to defend a dropship which is awaiting pickup for dustoff to reinforcing a previous team's drop to going into an underground bughive to kill the queen, in a pitch black nightmare of a giant anthill. The concept behind the game is that I have tools to generate random missions within a map. I make/generate a map, then use that map for some period of time while generating the next map that will be the mission set for the next drop zone. Drop zones will vary tremendously from one to the next. From deserts to jungles, blasted city scapes to underground bug nests. Interesting, ne? My background is being an archwiz on a MUD system. I can envision and in some cases have done these sorts of things within MUDs - I have the ability to code these sorts of things in LPC. The only limitation would be the restrictions placed on me by the quake server. I'd like to hear any contributions that people have regarding this. - -- S. Patrick Gallaty, Systems Administrator "Kein Vergnuegen ohne Gefahr!" patrick@diva.com ------------------------------ From: "Donovan C. Young" Date: Tue, 30 Jul 1996 15:36:27 -0600 Subject: QuakeBBS Proposal (WARNING: Lengthy Post) Below are my current plans for QuakeBBS. I appologize for the length of this post and will not post it a second time for that reason. If anyone would like another copy, please email me at donovan@mindspring.com. Comments and/or suggestions are always welcome, however flames will be ignored with extreme indiference. :-) - ----- QuakeBBS Proposed Feature List QuakeBBS will be a front-end system for Quake Servers. The main focus of this project is to provide user access control to the Quake Server. In addition, further functionality will help provide a user-friendly environment for the Server, including meeting areas (chat) and bulletin boards (messages). Terminology: QS = Quake Server - Quake running in server mode (-dedicated preferably) QBS = QuakeBBS Server - The Server side of QuakeBBS QBC = QuakeBBS Client - The Client, or terminal side of QuakeBBS - --- SERVER END (QBS) The Server end of QuakeBBS will basically run as a front-end to the actual Quake Server. It will need to accept 'calls' (telnet or other) and have the ability to then pass that 'call' to the Quake Server at the configured port. Features should include (but not limited to): * User Database for authentication * Guest Account [optional] * Message Of The Day (MOTD) * Automated custom files transfer [optional] (for .bsp, .mdl, .qc, etc). * Meeting / Waiting area(s) (with FIFO server queing on full servers) [admin override optional] * File area * Bulletin area Explanation of features: * User Database for authentication This is the meat of the application. Maintains a list of valid and authorized clients. Allows QBS administrator to accept or deny logins to his/her server. Will also provide means to ban known ip / email address from logging in (even as guest). * Guest Account [optional] Allows unvalidated users to log into the BBS (will be configurable to restrict access to individual functions [ie: connecting to the Quake Server, etc]). Can be disabled by QBS administrator (ie: for a closed system) * Message Of The Day (MOTD) Prints a message of the day upon login. Actually, there will be several user configured files that can be displayed (before login, after login, failed login, etc). * Automated custom files transfer [optional] (for .bsp, .mdl, .qc, etc). If the QS is running any custom files that are required for play, QBS can be configured to offer those files to the QBC for download. Possible further configuration will allow specific QS information to be communicated to the QBS and deny server connect if the client doesn't have the nessesary files (big MAYBE here). * Meeting / Waiting area (with FIFO server queueing on full servers) [admin override optional] This will be the area where users first go when the log in to the QBS. It will work much like IRC where you can have several 'Meeting Rooms' for different discussions (ie: for Team Meetings, etc). The default room will be the 'Common' room. All rooms will have access control with the exception of the 'common' room. There will also be a 'waiting list' for currently full servers. This will be a First In First Out (FIFO) list with administrator override to rearrange the order of the list. Once a slot opens on the server, the next user on the list will be offered the opportunity to connect. If they refuse, the offer goes to the next on the list, etc. If the user is busy (ie, transfering a file or something), the next user will be offered the connect but the first user will remain at the top of the list. All QBS user command will be executed from here, including file and bulletin commands. * File area Multiple file libraries to allow the QBS administrator to offer files to the user. I invision libraries such as Levels, MDLs, and so on. These will be fully configurable, complete with access control. * Bulletin area As the name implies, it provides a means for administrators and users to send messages to each other without the recipients needing to be logged in at the time. Email messages will also be possible (ala Private Bulletin). - --- CLIENT END (QBC) Basically, the client end will be nothing more than a "terminal" package that knows how to communicate with the QBS. It should be able to simplify logging in as well as launching the Quake client upon receipt of a 'STARTQUAKE' command signaling the Server is ready to accept the client. Features should include (but again, not limited to): * User-Friendly interface * Automated login [optional] * Maintain active server list (ala stomped finger, etc) * File transfer abilities (probably ZModem, maybe FTP) Explanation of features: * User-Friendly interface The QBC will provide a GUI interface to make interacting with QBS user-friendly. * Automated login [optional] Possibly can be configurable so that the userid and password are maintained within QBC for each server, so a simple click on the server name (or connect button) would automatically log the user in with the proper userid and password. For security reasons, this will be user configurable. * Maintain active server list (ala stomped finger, etc) Should have functionality to maintain an active server list (much like what is available currently). * File transfer abilities (probably ZModem, maybe FTP) Will allow file transfers between QBS and QBC using either ZModem and/or FTP (not sure which or both yet -- maybe even others as well). This is primarily for QBS file library functionality but would also be used with the optional Custom File Transfer facility (as mentioned in the QBS specs above). - --- OTHER INFORMATION I currently plan on writing the QBS first then simply releasing the QBC specs (in detail) to the general public to create QBC (or to incorporate in their current front ends). I'll probably write a (very) simple QBC for use until more robust versions are available. Current plans include writing the QBS under Linux in ANSI-C for portability. Since the QBS doesn't need any GUI interface (that's what QBC is for), it should be fairly easy to port to any platform that can run a QS. At this point I am planning on releasing QuakeBBS (QBS & QBC) under the GNU licence (However, I reserve the right to change this at any time, without prior notice). Lastly, this document is by no means complete. This is purely a first draft, off the top of my head, proposal. I'm *SURE* it will change to some degree as development continues. If you have any questions, or would like to help in some way, you can contact me at: donovan@mindspring.com or visit my Homepage at: http://www.mindspring.com/~donovan (Unfortunatly as of this writing, there isn't any QuakeBBS information there, but will be soon!) Donovan Young July 30, 1996 ------------------------------ From: Darxus Date: Tue, 30 Jul 1996 23:30:02 -0400 (EDT) Subject: Re: An intro, poll for ideas - On Tue, 30 Jul 1996, S. Patrick Gallaty wrote: > Interesting, ne? Yup. > My background is being an archwiz on a MUD system. I can envision > and in some cases have done these sorts of things within MUDs - I have the > ability to code these sorts of things in LPC. The only limitation > would be the restrictions placed on me by the quake server. I was wondering where your background was from... I was trying to pick out different textbook RPGs, but the MUD thing makes more sense for you :) I value the um, what did you call it ? -- charachteristics being built up and continuing to exist from game to game -- all the RPGish stuff will add *much* to the game. Hehe, it seems that this is exactly what makes MUDs addictive, and Quake is addictive, well, cuz it's Quake, now add the 2 together.... :) ________________________________________________________________________ ***PGP fingerprint = D5 EB F8 E7 64 55 CF 91 C2 4F E0 4D 18 B6 7C 27*** darxus@netaxs.com / http://www.netaxs.com/~darxus Sanity is for the weak. ------------------------------ From: Bernd Kreimeier Date: Wed, 31 Jul 1996 11:16:35 +0200 (MET DST) Subject: Sky Texturing? A question to those working on editing previews including texturing - has anybody done a sky already? The textured sky has to be done based on three angles of view, but independend of current position. If I understood correctly, sky rendering in Quake is done by span subdivision as well (every 8/16 pixels?), but texture coordinates are calculated from the angles. I haven't looked to closely, but IIRC the sky texture has two parts (scrolling with different speeds), in longitude/latitude representation? Has anybody done a simple "all sky" map? Are there any artifacts near the poles? Where are the poles actually? Or am I mistaken that the sky is done using spherical texture mapping? b. ------------------------------ From: Richard Matthias Date: Wed, 31 Jul 1996 14:07:28 +0000 Subject: Re: Sky Texturing? > The textured sky has to be done based on three angles > of view, but independend of current position. If I > understood correctly, sky rendering in Quake is done > by span subdivision as well (every 8/16 pixels?), > but texture coordinates are calculated from the angles. > I haven't looked to closely, but IIRC the sky texture > has two parts (scrolling with different speeds), in > longitude/latitude representation? > Has anybody done a simple "all sky" map? Are there > any artifacts near the poles? Where are the poles > actually? Or am I mistaken that the sky is done using > spherical texture mapping? The sky texturing appears to be a lot simpler than that. Try and find an area where you can see a large area of sky. Look up at it and note:- a) The bitmap that represents the sky is always "facing you". That is, there is no scaling in any axis. b) The bitmap is tiled in both directions and you move around it in a purely orthogonal manner dependent on your heading (x axis of bimap) and elevation (y axis). c) When you strafe hard left and right while looking at the sky the bitmap is rotated slightly in sympathy with your roll. In addition to this the simply bitmap I refer to is infact 2 bitmaps, one with transparency, that scroll at different speeds to each other independant of your motion. Richard ------------------------------ From: Derek Nickel Date: Wed, 31 Jul 1996 07:09:10 -0700 Subject: RE: Sky Texturing? - ------ =_NextPart_000_01BB7EAF.5B14FFA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >>> Are there any artifacts near the poles? <<< Just looking at the existing levels, it looks to me that there aren't = any artifacts at the poles, but there are at the equator. This is were = the sky and the "anti-sky" meet and sort of swirl together. Derek Nickel dnickel@ccnet.com - ------ =_NextPart_000_01BB7EAF.5B14FFA0 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+Ih0OAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAENgAQAAgAAAAIAAgABBJAG ACABAAABAAAADAAAAAMAADADAAAACwAPDgAAAAACAf8PAQAAAEcAAAAAAAAAgSsfpL6jEBmdbgDd AQ9UAgAAAABxdWFrZS1kZXZAZ2FtZXJzLm9yZwBTTVRQAHF1YWtlLWRldkBnYW1lcnMub3JnAAAe AAIwAQAAAAUAAABTTVRQAAAAAB4AAzABAAAAFQAAAHF1YWtlLWRldkBnYW1lcnMub3JnAAAAAAMA FQwBAAAAAwD+DwYAAAAeAAEwAQAAABcAAAAncXVha2UtZGV2QGdhbWVycy5vcmcnAAACAQswAQAA ABoAAABTTVRQOlFVQUtFLURFVkBHQU1FUlMuT1JHAAAAAwAAOQAAAAALAEA6AQAAAAIB9g8BAAAA BAAAAAAAAANhNAEIgAcAGAAAAElQTS5NaWNyb3NvZnQgTWFpbC5Ob3RlADEIAQSAAQATAAAAUkU6 IFNreSBUZXh0dXJpbmc/AFEGAQWAAwAOAAAAzAcHAB8ABwAJAAoAAwAWAQEggAMADgAAAMwHBwAf AAcABQAOAAMAFgEBCYABACEAAABFQzg3QzkxRjlERUFDRjExQjMyNTQ0NDU1MzU0MDAwMAAWBwED kAYA3AIAABIAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAEAAOQAgBYLY6X67AR4A cAABAAAAEwAAAFJFOiBTa3kgVGV4dHVyaW5nPwAAAgFxAAEAAAAWAAAAAbt+6dh4H8mH7eqdEc+z JURFU1QAAAAAHgAeDAEAAAAFAAAAU01UUAAAAAAeAB8MAQAAABIAAABkbmlja2VsQGNjbmV0LmNv bQAAAAMABhBOBER9AwAHEN8AAAAeAAgQAQAAAGUAAABBUkVUSEVSRUFOWUFSVElGQUNUU05FQVJU SEVQT0xFUz88PDxKVVNUTE9PS0lOR0FUVEhFRVhJU1RJTkdMRVZFTFMsSVRMT09LU1RPTUVUSEFU VEhFUkVBUkVOVEFOWUFSVElGAAAAAAIBCRABAAAAaAEAAGQBAAArAgAATFpGdb7vKXz/AAoBDwIV AqgF6wKDAFAC8gkCAGNoCsBzZXQyNwYABsMCgzIDxQIAcHJCcRHic3RlbQKDM/cC5AcTAoB9CoAI zwnZAoAHCoENsQtgbmcxMDPPFFALChRRC/EgPhlgFLFwZSB0aASQGcAAcHkvGjAAIAaQANB0BCBu ZTMKwRnhIHAG8AeQPyBOPBwgCoUKhUp1E8Ag6RWgb2sLgGcaMAVAG3I8ZXgEABqgHdEb0HZlYGxz LCBpHWQEIHR8byAHgBnRHgQaEhYQbj4nBUAaTB4FG7MfYGJ1MyCpHfdxdR4ABbAuILggVGgEAB9w BCB3GgJJG3JzaxphbmQbYyLrAHAaoC0mUSIgMRHAJoNicxWxIG9mJkAD8HLbAyAgEGcRwBnxLhxc DIIUIEQaAWsHsGljaxsfMCo6ZAMAK3JAY2PpGyB0LgWgbRh8CqADYC8T0BrgHLYVMQAvoAMAEBAD AAAAAwAREAAAAABAAAcwwJjMS+l+uwFAAAgwwJjMS+l+uwEeAD0AAQAAAAUAAABSRTogAAAAAPq0 - ------ =_NextPart_000_01BB7EAF.5B14FFA0-- ------------------------------ From: Michael Hartle Date: Wed, 31 Jul 1996 18:35:44 +0200 Subject: Re: An intro, poll for ideas - Patrick Gallaty wrote: > The concept behind the game is that I have tools to generate random > missions within a map. I make/generate a map, then use that map for > some period of time while generating the next map that will be the > mission set for the next drop zone. To increase the atmosphere and setting of the game, why not keep some remarkable spots of missions on the server if they were good ? It would allow to create a world that can be remembered and where you can come back - citys for example, or geographical specialities that should stay - - its like painting a map. If the action continues where something has happened some days or years ago, the map could be reused and old rememberings would come up. > I'd like to hear any contributions that people have regarding this. Why not create a persisting list of those ideas that could be used ? After collecting ideas for a while, they could be evaluated by means of difficulty and benefit, so such development could be coordinated. This would contribute to keep this idea and everything around up and running. BTW, could you send me some more information about LPC directly to my email account ? Bernd (Admin of this list) does not like mails not exactly belonging to the topic of this mailing list...:] Regards, Michael Hartle - ------------------------------------------------------------------------ "Neinnein. Auf gar keinen Fall. Glaubst Du, ich verteile Konzessionen ?" Tod an den Ratten- und Flohtod, "Alles Sense", Terry Pratchett - ------------------------------------------------------------------------ ------------------------------ From: "Ben Mazur" Date: Wed, 31 Jul 1996 13:52:49 -0400 Subject: Custom Player Textures A lot of talk has been going around about how to implement custom player textures over the internet. It seems to me that this should be best accomplished using a) no modifications to the server code, and b) minimal custimization of the client code, so that those without custom textures or a custom client could play normally. I propose the following idea: Custom textures would be kept in a database, in HTML format, availabble on the world wide web. They could be sorted in compressed .gif or .jpeg (?) format, and the database and all textures within could be loaded with a normal web browser. The textures would be indexed by player handle only, as unless quake trasmits more specific player identification during normal net play, any further identification/verification procedure would simply bog things down. Textures would then be stored in the web browser's cache, and still readily accessible through the internet. When a player dies, and before he repops, he could then hit a button (instead of space to repop) which would then: 1) Grab the handles of those currently playing (ie "QuakeGuy") and match them with those in the database (taken either out of the browser's cache or reloaded off the internet.) 2) If a custom texture is found for the player in the database, it would then load the image (again, either from cache or live off the web,) and process the image (ie "quakeguy.jpg") into a custom model for the player ("quakeguy.mdl") 3) At this point it could probably delete the custom .mdls for all those not playing, to save space. so that 4) when the player repops he will now see all those in the database as their custom texture. This has the advantages that: -Players who choose not to participate in this method could still play normally against those who do. -No modifications to the server code seem to be needed. Those running Quake servers have to do no work to comply with this method. -Images are not distributed by the server to save server bandwidth. -All data can be cached, using readibly available web browsing software, for minimal in-play d/l times. -When not playing quake you could look through the database of custom textures and admire the pretty artwork without having it shooting at you. A few hitches I noticed: -The web server that has the database and images stored on it would get extremely heavy traffic. Possibly images could be distributed across several servers, as they are not physically included in the database, only linked to. -After a while the player database would get very big. A few solutions come to mind but all have their own disadvantages. -Without any sort of authentication method, player impersonation could become a problem. This seems unlikely to me, but only time will tell. Anyways, that's just a pretty rough draft with no real technical details worked out. If you like this idea, spread it around, if you'd like to discuss more details with me, I can be reached via Email at bmazur@sylvania.sev.org All comments are welcome. I typically play on midwest (chicago, michigan, ohio) servers using the handle \/\/ombat. Ben Mazur ------------------------------ From: Darxus Date: Wed, 31 Jul 1996 23:32:04 -0400 (EDT) Subject: Different skins. IT WORKS!!!! (fwd) - ---------- Forwarded message ---------- Date: Wed, 31 Jul 1996 18:20:48 +0200 (MET DST) From: "L.J.Noordsij" To: quake-c@seal-industries.com Subject: Different skins. IT WORKS!!!! Hi I'm happy to tell you the problems is solved! Every player can now choose his own skin, he will respawn in that skin, and each player can have his own individual skin! I've just finished the readme, so I don't want to write all that stuff down here again, but right now I'm updating my page http://web.inter.NL.net/users/L.J.Noordsij/qc.htm where you can find the stuff. I'll also upload it to CDROM.COM. Good points: a player doesn't *require* the MultiSkin, so when he does not have the extra textures he'll just see the normal ones!!! SERVER ADMINS, GET MULTISKIN!!!!! Dennis ------------------------------ From: Ron Crisco Date: Thu, 01 Aug 1996 00:14:44 -0500 Subject: Re: Custom Player Textures Ben Mazur wrote: > > A lot of talk has been going around about how to implement custom player > textures over the internet. It seems to me that this should be best > accomplished using a) no modifications to the server code, and b) minimal > custimization of the client code, so that those without custom textures or > a custom client could play normally. > Dennis Noordsij has implemented a very workable solution and has info posted at http://web.inter.NL.net/users/L.J.Noordsij/qc.htm I highly recommend his approach. Ron crisco@stomped.com ------------------------------ From: Bernd Kreimeier Date: Fri, 2 Aug 1996 15:29:57 +0200 (MET DST) Subject: John Carmack's QuakeWorld plan 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 ------------------------------ End of quake-dev-digest V1 #28 ****************************** From owner-quake-dev-digest@gamers.org Sun Aug 11 02:37 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 CAA07095 for ; Sun, 11 Aug 1996 02:37:36 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id UAA02336 for quake-dev-digest-outgoing; Sat, 10 Aug 1996 20:35:47 -0400 From: owner-quake-dev-digest@gamers.org Date: Sat, 10 Aug 1996 20:35:47 -0400 Message-Id: <199608110035.UAA02336@gamers.org> To: quake-dev-digest@gamers.org Subject: quake-dev-digest V1 #29 Reply-To: quake-dev@gamers.org Errors-To: owner-quake-dev-digest@gamers.org Precedence: bulk X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 26318 X-Lines: 713 Status: RO quake-dev-digest Saturday, 10 August 1996 Volume 01 : Number 029 ---------------------------------------------------------------------- From: Bernd Kreimeier Date: Fri, 2 Aug 1996 15:44:08 +0200 (MET DST) Subject: Re: John Carmack's QuakeWorld plan 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: Tom Wheeley Date: Sun, 04 Aug 96 22:48:45 GMT Subject: qbsp_29.tar.qz uploaded at ftp.idsoftware.com In article <199607251612.MAA28237@genesis.nred.ma.us> you write: > On Thu, 25 Jul 1996 16:27:51 +0200 (MET DST), Bernd Kreimeier wrote: > > > > >----- Begin Included Message ----- > > > >>From johnc@idnewt.idsoftware.com Thu Jul 25 16:24 MET 1996 > >From: John Carmack > >Date: Thu, 25 Jul 96 09:24:15 -0500 > >To: jschuur@onlinemagic.co.uk > >Subject: qbsp_29.tar.qz > > > >The new bsp source is now up. > > > >John Carmack > > > > Could you use pkzip instead of tar? Not everyone is using unix or Next Step. > tar and gzip are freely available for Dos, Windows etc from your local Simtelnet mirror. Or use WinZip, which other people have suggested. .splitbung - -- * TQ 1.0 * The 'Just So Quotes'. "A distributed system is one in which I cannot get something done because a machine I've never heard of is down" --Leslie Lamport ------------------------------ From: "Brian K. Martin" Date: Wed, 7 Aug 1996 13:39:45 -0400 (EDT) Subject: meddle I have put a newer version of meddle on cdrom.com and on my homepage www.phyast.pitt.edu/~brian/meddle Maybe you can see if it's good enough for stomped. I think it's the best, but i'm biased. Only some minor improvements, but they were needed. brian ------------------------------ From: "Per S. Hammer" Date: Wed, 7 Aug 1996 20:57:04 +0100 (BST) Subject: Client/Server protocol in Quake Folks, Does anyone know if id has released any specs on the IP (UDP) protocol used in communication between Quake servers and Quake clients ? 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: "Brian K. Martin" Date: Wed, 7 Aug 1996 18:37:39 -0400 (EDT) Subject: Sorry > > > I have put a newer version of meddle on cdrom.com and on my homepage > oops.... I'm a dork. I swear I mailed that to stomped.... So sorry.... brian ------------------------------ From: Ron Crisco Date: Wed, 07 Aug 1996 23:18:52 -0500 Subject: Re: meddle Brian K. Martin wrote: > > I have put a newer version of meddle on cdrom.com and on my homepage > > www.phyast.pitt.edu/~brian/meddle > > Maybe you can see if it's good enough for stomped. > I think it's the best, but i'm biased. Only some > minor improvements, but they were needed. > > brian > I'll definitely put it up on Stomped, although I'm a little behind due to massive overload at my real job :) That's a great page, BTW, lots of good descriptions. Ron ------------------------------ From: Mark York Date: Thu, 8 Aug 1996 03:19:59 -0500 Subject: That Romero guy Ok... you all already know this, but I wanted to email to make sure. finger johnr@idsoftware.com and you'll see .... Romero quit id. We DON'T need to have the "Romero IS id" vs the "Quake sux 'cause of Romero" arguments here. And .b won't allow them, thankyouverymuch (at least I think, dunno how much steam ppl have bult up over this) We're pro's here. We have a great engine to tweek. & the heart of id isn't really Romero, it's Carmack. If you need to flame, flame me. Not the list. Thanx Mark/Mad_Dog ps. .b, Hmmm... your tight with Carmack. Can you ask him to up the limit on impulses to 65535? The Quake C guys are coming close to running out with 256. ------------------------------ From: Olivier Montanuy Date: Thu, 8 Aug 1996 11:12:09 +0200 Subject: RE: Client/Server protocol in Quake >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: Bernd Kreimeier Date: Thu, 8 Aug 1996 10:49:10 +0200 (MET DST) Subject: Re: Client/Server protocol in Quake >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: Derrick Date: Thu, 08 Aug 1996 09:57:18 -0400 Subject: Re: That Romero guy At 03:19 AM 8/8/96 -0500, you wrote: >.b, Hmmm... your tight with Carmack. Can you ask him to up the limit >on impulses to 65535? The Quake C guys are coming close to running >out with 256. > While you're at it, how 'bout a bigger stack. 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: Mike Ruete Date: Thu, 08 Aug 1996 13:55:45 -0500 (EST) Subject: RE: Client/Server protocol in Quake 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: Derrick Date: Thu, 08 Aug 1996 15:23:56 -0400 Subject: Carmark on Stack Size and impulses 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: Bernd Kreimeier Date: Fri, 9 Aug 1996 15:01:23 +0200 (MET DST) Subject: Info from John Carmack (QuakeWorld 2) 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: "Chris Cason" Date: Sat, 10 Aug 1996 22:09:57 +0800 Subject: Rendered output ? 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: Jim Lowell Date: Sat, 10 Aug 1996 10:41:08 -0500 Subject: Re: Rendered output ? 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: "Brian K. Martin" Date: Sat, 10 Aug 1996 20:35:08 -0400 (EDT) Subject: Re: Rendered output ? > > 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 ------------------------------ End of quake-dev-digest V1 #29 ****************************** From owner-quake-dev-digest@gamers.org Mon Aug 26 11: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 KAA02374 for ; Mon, 26 Aug 1996 10:59:30 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id EAA25201 for quake-dev-digest-outgoing; Mon, 26 Aug 1996 04:56:05 -0400 From: owner-quake-dev-digest@gamers.org Date: Mon, 26 Aug 1996 04:56:05 -0400 Message-Id: <199608260856.EAA25201@gamers.org> To: quake-dev-digest@gamers.org Subject: quake-dev-digest V1 #30 Reply-To: quake-dev@gamers.org Errors-To: owner-quake-dev-digest@gamers.org Precedence: bulk X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 24608 X-Lines: 702 Status: RO quake-dev-digest Monday, 26 August 1996 Volume 01 : Number 030 ---------------------------------------------------------------------- From: "Uffe Friis Lichtenberg" Date: Mon, 12 Aug 1996 10:32:40 +0200 Subject: info ------------------------------ From: Olivier Montanuy Date: Mon, 12 Aug 1996 12:24:07 +0200 Subject: Quake-C network protocol since no-one published any net specs, I have hacked part of the current net protocol of Quake, using the infamous 'snoop' utility for sun o/s. message structure is: short message_type; short message_length; char codes[...]; I saw only 5 messages types: - 0x800 control message - 0x1 send message part (store, do not process) - 0x9 send last part of message (process now) - 0x2 acknowledge a message part (send the next!) - 0x10 update (process immediatly) Didn't go very far, and the DEM specs gave all the server->client codes anyway. For the client->server codes, I didn't see many of them. they are to be interpreted differently from the server->client (dammit, why couldn't they take the same codes? ain't so many of them) 0x1: nop (or I suppose so) 0x4: execute command on server console (name, begin ...) 0x3: client movement for(i=0; i<3;i++) angle[i] = ReadAngle() for(i=0; i<3; i++) acceleration[i] = ReadByte() unknown1 = ReadLong() unknown2 = ReadByte() last two must indicate key pressed, and buttons. It's decently simple, but could be largely optimised (maybe there ain't enough processor time anyway). The status bar update message suck too many bytes. This info might be outdated for Quake Worlds, but I doubt they rewrite the protocol codes entirely. Meanwhile, we can have fun making bots. Olivier ------------------------------ From: "Jeff B Epler Lincoln, NE " Date: Mon, 12 Aug 1996 10:08:47 -0500 (CDT) Subject: Re: Rendered output ? > 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... I started working on a .map to pov converter. It seemed to get the brushes right, but putting the textures on correctly was too much of a headache, so I gave up. (Any brush can be expressed in pov as an intersection of several planes, which is a no-brainer) Jeff > 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... >From a unix background here, the smartest thing to do is make your program decode pnm (portable anymap) format and then have a snippet like this: struct image *readImage(char *filename) { FILE *f=fopen(filename, "rb"); struct image *retval; if(ispnm(f)) return { retval=readPnm(f); fclose(f); return retval; else { char *command=malloc(10+strlen(filename)); /* "anytopnm" plus space and \0 */ struct image if(c==NULL) return NULL; fclose(f); sprintf(command,"anytopnm %s\n",filename); f=popen(command,"rb"); retval=readPnm(f); pclose(f); } } (that code is untested, but I wrote a similar snippet for a Linux image-viewer and it works well) The program 'anytopnm' determines file type from magic numbers or file extension and then uses the various conversion utilities in netpbm to convert them to one of three formats (for bi-level images, grayscale images, and truecolor images. A very simple extension to pgm would make it usable for paletted images, but nobody seems to care) Of course, I don't know if dos/win C libraries have popen/pclose yet and besides, users can hardly be bothered to install something so useful as netpbm. (Hm, anytopnm is a shell script anyway, so they'd still be out of luck) If you're still interested -- netpbm has a gif viewer whose code may be reasonably readable -- try ftp://wuarchive.wustl.edu/graphics/graphics/packages/NetPBM/ > > brian Jeff - -- Jeff Epler (just a student -- ignore my opinion, please) ------------------------------ From: Bernd Kreimeier Date: Tue, 13 Aug 1996 15:40:11 +0200 (MET DST) Subject: Re: Rendered output ? >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: Darxus Date: Fri, 16 Aug 1996 01:49:28 -0400 Subject: Most Wanted Suggestions page... (fwd) - ---------- Forwarded message ---------- Date: Thu, 15 Aug 1996 14:29:26 -0500 From: Shawn Crain Reply-To: quake@samurai.com To: quake@samurai.com Subject: Most Wanted Suggestions page... Just whipped up a Quake's Most Wanted Features page. Very raw, so be kind. Please be so kind as to pass the word and even more importantly, participate! Once I get some more responses I'll post a weekly Top Ten list or something simialar. All depends on the input from you guys. Enjoy. +---------------------+-----------------------------------------------+ | Shawn | --===Make Your Opinions Heard!===-- | | "Mood Dawg" | Tell me what you think needs added/changed | | Crain | in Quake for compilation into the Most Wanted | | | Quake Changes List. Reply to address on left | | shawnc@accessus.net | or visit http://www.accessus.net/~shawnc/ | +---------------------+-----------------------------------------------+ ------------------------------ From: Darxus Date: Fri, 16 Aug 1996 01:49:28 -0400 (EDT) Subject: Most Wanted Suggestions page... (fwd) - ---------- Forwarded message ---------- Date: Thu, 15 Aug 1996 14:29:26 -0500 From: Shawn Crain Reply-To: quake@samurai.com To: quake@samurai.com Subject: Most Wanted Suggestions page... Just whipped up a Quake's Most Wanted Features page. Very raw, so be kind. Please be so kind as to pass the word and even more importantly, participate! Once I get some more responses I'll post a weekly Top Ten list or something simialar. All depends on the input from you guys. Enjoy. +---------------------+-----------------------------------------------+ | Shawn | --===Make Your Opinions Heard!===-- | | "Mood Dawg" | Tell me what you think needs added/changed | | Crain | in Quake for compilation into the Most Wanted | | | Quake Changes List. Reply to address on left | | shawnc@accessus.net | or visit http://www.accessus.net/~shawnc/ | +---------------------+-----------------------------------------------+ ------------------------------ From: Daniel Dorau Date: Fri, 16 Aug 1996 21:46:10 +0200 (MET DST) Subject: Texture alignment / Sounds Is there a way around the limitation that the texture offset has to be a multiple of 16? NAT is nice in some ways but that limitation hurts when designing levels very much. Maybe this limitation could be removed in future quake updates? Id: HINT HINT! Some other question: I havn't been successful to build triggers which don't do any sound and water that doesn't make any sound (after vis). The water ambience is not bad in general but I can't help myself: a wash-basin making the sound of an ocean is inapropriate. Daniel Dorau woodst@cs.tu-berlin.de - ---------------------------------------------------------------------------- "Wer nachts schlaeft, braucht sich nicht zu wundern, wenn er tagsueber arbeiten muss." - ---------------------------------------------------------------------------- ------------------------------ From: Olivier Montanuy Date: Mon, 19 Aug 1996 10:19:45 +0200 Subject: Quake Network specifications (Dunno if someone released such info. If so, sorry). I hacked down the Quake network packets. I think I have somewhat complete specs by now. T'was rather easy because of the DEM specs, the only trouble being to make an UDP client that works :-) I will release those specs in the UQS 3.3. I also have a Quake message interceptor (fake client/fake server) that could be turned into a shielding bot. And of course, I have a complete working bot (though very stupid). Trouble is: it's all coded in Python, and Python is MUCH too slow for the task. the bot lags some 15 seconds back in time, and it's a miracle Quake doesn't even crash :-) Looking for volunteers to implement this in C. Coding in C is too much of a bore for me, now. Too many bugs. With regards, Olivier Montanuy (Olivier.Montanuy@wanadoo.fr) ------------------------------ From: Bernd Kreimeier Date: Mon, 19 Aug 1996 15:18:25 +0200 (MET DST) Subject: Re: Quake Network specifications 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: Craig Mills Date: Tue, 20 Aug 1996 08:12:42 +1000 (GMT+1000) Subject: Re: Quake Network specifications On Mon, 19 Aug 1996, Olivier Montanuy wrote: > (Dunno if someone released such info. If so, sorry). > > I hacked down the Quake network packets. I think I have > somewhat complete specs by now. T'was rather easy because > of the DEM specs, the only trouble being to make an UDP > client that works :-) > > I will release those specs in the UQS 3.3. > > I also have a Quake message interceptor (fake client/fake > server) that could be turned into a shielding bot. > And of course, I have a complete working bot (though very > stupid). > > Trouble is: it's all coded in Python, and Python is MUCH > too slow for the task. the bot lags some 15 seconds back > in time, and it's a miracle Quake doesn't even crash :-) > > Looking for volunteers to implement this in C. Coding > in C is too much of a bore for me, now. Too many bugs. Well... I'll have a look at it if you like. I don't know much about Python however. I know a couple of guys that would probably help out as well, so if the Python source is easy enough to read we could probably whip something up. Craig ------------------------------------------------------------------------ Oh, God! If you want something done properly, | Craig Mills kill Baldrick before you start! | s304989@ -- Edmund BlackAdder, Black Adder III | student.uq.edu.au ------------------------------ From: Bernd Kreimeier Date: Thu, 22 Aug 1996 09:21:50 +0200 (MET DST) Subject: Info from John Carmack (final) 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: Bernd Kreimeier Date: Thu, 22 Aug 1996 09:44:10 +0200 (MET DST) Subject: Re: Info from John Carmack (final) 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: "Mark Mathews" Date: Sun, 25 Aug 96 15:33:20 -0400 Subject: formats 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: "Phrog`gee" Date: Sun, 25 Aug 1996 16:01:41 -0400 Subject: v_idlescale 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: Denis Date: Sun, 25 Aug 1996 22:05:55 +0200 Subject: Re: formats 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: Raphael.Quinet@eed.ericsson.se Date: Sun, 25 Aug 1996 22:41:56 +0200 (MET DST) Subject: Re: formats 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: Olivier Montanuy Date: Mon, 26 Aug 1996 10:21:54 +0200 Subject: RE: formats >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: Bernd Kreimeier Date: Mon, 26 Aug 1996 10:54:56 +0200 (MET DST) Subject: ADMIN: offline 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. ------------------------------ End of quake-dev-digest V1 #30 ******************************