You can subscribe to this list here.
1999 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(535) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2000 |
Jan
(1127) |
Feb
(362) |
Mar
(529) |
Apr
(752) |
May
(487) |
Jun
(329) |
Jul
(190) |
Aug
(115) |
Sep
(53) |
Oct
(52) |
Nov
(345) |
Dec
(203) |
2001 |
Jan
(240) |
Feb
(317) |
Mar
(212) |
Apr
(57) |
May
(151) |
Jun
(70) |
Jul
(82) |
Aug
(23) |
Sep
(56) |
Oct
(35) |
Nov
(22) |
Dec
(60) |
2002 |
Jan
(33) |
Feb
(21) |
Mar
(16) |
Apr
(14) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2003 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Tim K. <tke...@sh...> - 2001-12-24 07:19:17
|
On Sun, 23 Dec 2001, Bill Currie wrote: > this should be fixed in current cvs (I cleaned up the the line endings) Yep, compiles and works as well as the released binaries from ID. > Bill Thanks. Tim -- If you want to speak to someone knowledgeable about computers and who knows what's going on in "the local computer store", then you are forced to talk to yourself... (;-)) |
From: Dwayne C. L. <dl...@dl...> - 2001-12-24 05:39:12
|
Can qw-client-* take commands from a fifo? Should I make a wishlist instead of posting every wish I encounter to the list? :-) --=20 Dwayne C. Litzenberger <dl...@dl...> |
From: Dwayne C. L. <dl...@dl...> - 2001-12-24 05:13:07
|
Does it exist yet? --=20 Dwayne C. Litzenberger <dl...@dl...> |
From: Bill C. <bi...@ta...> - 2001-12-24 02:31:38
|
On Sat, Dec 22, 2001 at 01:01:26PM -0700, Tim Keating wrote: > > $ make -C linux all > make: Entering directory `/home/tkeating/build/quake2/linux' > mkdir: cannot create directory `debugi386': File exists Harmless but fixed in current cvs. > ../../quake2/client/../qcommon/../game/q_shared.h:190: parse error before > `->' hmm, haven't had anthing linke that. > ../../quake2/client/../qcommon/../game/q_shared.h:190: stray '\' in > program this should be fixed in current cvs (I cleaned up the the line endings) > ../../quake2/client/../qcommon/../game/q_shared.h:191: stray '\' in > program Bill -- Leave others their otherness. -- Aratak |
From: <qf...@pa...> - 2001-12-23 08:29:06
|
Builds, works in dedicated mode, has a weird error that keeps it from working as a game client: http://web.nilpotent.org/tmp/q2-freebsd-diff1.txt (diffs against files in client/*, game/*) http://web.nilpotent.org/tmp/q2-freebsd-diff2.txt (creates quake2/freebsd/, and populates it) It's essentially a copy of some of quake2/linux source files. The weird error is that FreeBSD doesn't have an mremap() call; I've tried faking it (see quake2/freebsd/q_shfreebsd.c) using the version in FreeBSD's Linux emulation code, but apparently I got something or other wrong. I haven't tested sound support yet. The cdrom code compiles but doesn't do anything useful. Faried. ps: anyone have a good bot that comes with its sources? i've tried acebot, but it's way too "smart"; if i show up *anywhere* where it can possibly see me, it *will* find me. even if it's fighting two other bots on the ground and i show up somewhere above it. |
From: Tim K. <tke...@sh...> - 2001-12-22 20:02:03
|
$ make -C linux all make: Entering directory `/home/tkeating/build/quake2/linux' mkdir: cannot create directory `debugi386': File exists mkdir: cannot create directory `debugi386/client': File exists mkdir: cannot create directory `debugi386/ref_soft': File exists mkdir: cannot create directory `debugi386/ref_gl': File exists mkdir: cannot create directory `debugi386/game': File exists mkdir: cannot create directory `debugi386/ctf': File exists mkdir: cannot create directory `debugi386/xatrix': File exists make: [build_debug] Error 1 (ignored) make targets BUILDDIR=debugi386 CFLAGS="-Dstricmp=strcasecmp -g" make[1]: Entering directory `/home/tkeating/build/quake2/linux' gcc -Dstricmp=strcasecmp -g -o debugi386/client/cl_cin.o -c ../../quake2/client/cl_cin.c In file included from ../../quake2/client/../qcommon/qcommon.h:23, from ../../quake2/client/ref.h:21, from ../../quake2/client/client.h:30, from ../../quake2/client/cl_cin.c:20: ../../quake2/client/../qcommon/../game/q_shared.h:190: parse error before `->' ../../quake2/client/../qcommon/../game/q_shared.h:190: stray '\' in program ../../quake2/client/../qcommon/../game/q_shared.h:191: stray '\' in program ../../quake2/client/../qcommon/../game/q_shared.h:192: stray '\' in program ../../quake2/client/../qcommon/../game/q_shared.h:193: stray '\' in program ../../quake2/client/../qcommon/../game/q_shared.h:194: stray '\' in program ../../quake2/client/../qcommon/../game/q_shared.h:195: stray '\' in program ../../quake2/client/../qcommon/../game/q_shared.h:196: stray '\' in program ../../quake2/client/../qcommon/../game/q_shared.h:197: stray '\' in program ../../quake2/client/../qcommon/../game/q_shared.h:198: stray '\' in program ../../quake2/client/../qcommon/../game/q_shared.h:199: stray '\' in program ../../quake2/client/../qcommon/../game/q_shared.h:200: stray '\' in program ../../quake2/client/../qcommon/../game/q_shared.h:201: stray '\' in program ../../quake2/client/../qcommon/../game/q_shared.h:202: stray '\' in program make[1]: *** [debugi386/client/cl_cin.o] Error 1 make[1]: Leaving directory `/home/tkeating/build/quake2/linux' make: *** [build_debug] Error 2 make: Leaving directory `/home/tkeating/build/quake2/linux' Cleaning out all the above mentioned '\' in game/q_shared.h leaves me with ... make[1]: Entering directory `/home/tkeating/build/quake2/linux' gcc -Dstricmp=strcasecmp -g -o debugi386/client/cl_cin.o -c ../../quake2/client/cl_cin.c In file included from ../../quake2/client/../qcommon/qcommon.h:23, from ../../quake2/client/ref.h:21, from ../../quake2/client/client.h:30, from ../../quake2/client/cl_cin.c:20: ../../quake2/client/../qcommon/../game/q_shared.h:190: parse error before `->' make[1]: *** [debugi386/client/cl_cin.o] Error 1 make[1]: Leaving directory `/home/tkeating/build/quake2/linux' make: *** [build_debug] Error 2 This is on a modified Slack 8.0 $ sh /usr/src/linux/scripts/ver_linux If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux darkspace 2.4.17-rc2 #1 Wed Dec 19 21:09:59 MST 2001 i586 unknown Gnu C 2.95.4 Gnu make 3.79.1 util-linux 2.11m mount 2.11m modutils 2.4.12 e2fsprogs 1.25 reiserfsprogs 3.x.0j Linux C Library 2.2.4 Dynamic linker (ldd) 2.2.4 Procps 2.0.7 Net-tools 1.60 Kbd 1.06 Sh-utils 2.0 $ as --version GNU assembler 2.11.92.0.12.3 20011121 Copyright 2001 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. This assembler was configured for a target of `i586-pc-linux-gnu'. I know this version of binutils was creating some build problems with the kernel. Looking forward to seeing what you folk do with this code! Tim -- If you want to speak to someone knowledgeable about computers and who knows what's going on in "the local computer store", then you are forced to talk to yourself... (;-)) |
From: Jeff T. <de...@d2...> - 2001-12-22 12:47:35
|
lo...@ou... wrote: > I have downloaded the quakeforge 0.3.0 and have just tried to run it but > it seems to be needing a file called gfx.wad. Does someone know where I > can get this file? It's in pak0.pak, which comes with Quake. If you already have Quake, it means that QuakeForge can't find your pakfiles. It could be because it's all uppercase, or because you don't have the fs_sharepath variable set to the location of the directory your id1 directory is in. in /etc/quakeforge.conf: set fs_sharepath /path/to/quake/dir -- | Jeff Teunissen -=- Pres., Dusk To Dawn Computing -=- deek @ d2dc.net | GPG: 1024D/9840105A 7102 808A 7733 C2F3 097B 161B 9222 DAB8 9840 105A | Core developer, The QuakeForge Project http://www.quakeforge.net/ | Specializing in Debian GNU/Linux http://www.d2dc.net/~deek/ |
From: Ulrich G. <uga...@li...> - 2001-12-22 04:35:26
|
On Fri, 21 Dec 2001, Kirk Alexander wrote: > Hi, > > I am working with Zachary Kuhn from the tuxboxgames project (sourceforge) and > we're trying to work out how to adapt Quake to run with split-screen support > appropriate for a console. Obviously Id did this for Quake on the Nintendo 64, > but asking them should be a last resort. I was hoping you guys might be able to > give us some pointers on how to go about this. The following are the three > possibilities I have come up with so far. There may be better solutions. Please > flame away if they show incredible naivety :) > > Thanks very much, and keep up the great work on QF! > Cheers, > Kirk Alexander > > 1) Messy. Easy. > > Unmodified server. > 4 slightly modified clients - mainly new menu code appropriate to split-screen > > play. > 1 new control program containing Quake menu code, starts up server and clients > > when needed and aligns them on screen, so it looks like full screen. Depends > on > graphics system how hard this would be to get right. > > 2) Relatively straight-forward. Invasive. Lots of grunt work? > > Unmodified server. > 1 client program modified to support multiple clients in one process, and adapt > > menu code as appropriate. > > 3) Complex. Lots of work. Possible? > > Unmodified server. > 4 clients "qf-client-vas" : new target (vas == vassal) > 1 control program "qf-lord-x11" etc. : new program class > > The vassal programs would be generic (independent of graphics system) and would > feed commands to the control program which would do the actual rendering. This > option may not be possible, since my knowledge of the rendering stuff is > limited. It would be simple enough to make it work for menus, status bar etc. > > > > > -- > QuakeForge Development [ qua...@li... ] > https://lists.sourceforge.net/lists/listinfo/quake-devel > I think it's important to note that id software didn't do the port to N64 themselves. Just so you're not suprised when you get a big "wha...?" from teh quaek pappies. Maybe not so big a deal. (notice i didn't actually look up who did it) *<><><><><><><><><><><><><><><><><><><>* // ZANCRUS: Ulrich Galbraith \\ \\ E-Mail: uga...@kr... // // \\ \\ ICQ: 3093981 // *<><><><><><><><><><><><><><><><><><><>* |
From: Adam O. <rh...@d2...> - 2001-12-21 04:18:23
|
On Fri, Dec 21, 2001 at 11:11:48AM +1300, Kirk Alexander wrote: > Hi, > > I am working with Zachary Kuhn from the tuxboxgames project (sourceforge) and > we're trying to work out how to adapt Quake to run with split-screen support > appropriate for a console. Obviously Id did this for Quake on the Nintendo 64, > but asking them should be a last resort. I was hoping you guys might be able to > give us some pointers on how to go about this. The following are the three > possibilities I have come up with so far. There may be better solutions. Please > flame away if they show incredible naivety :) > > Thanks very much, and keep up the great work on QF! > Cheers, > Kirk Alexander > > 1) Messy. Easy. > > Unmodified server. > 4 slightly modified clients - mainly new menu code appropriate to split-screen > > play. > 1 new control program containing Quake menu code, starts up server and clients > > when needed and aligns them on screen, so it looks like full screen. Depends > on > graphics system how hard this would be to get right. > > 2) Relatively straight-forward. Invasive. Lots of grunt work? > > Unmodified server. > 1 client program modified to support multiple clients in one process, and adapt > > menu code as appropriate. > > 3) Complex. Lots of work. Possible? > > Unmodified server. > 4 clients "qf-client-vas" : new target (vas == vassal) > 1 control program "qf-lord-x11" etc. : new program class > > The vassal programs would be generic (independent of graphics system) and would > feed commands to the control program which would do the actual rendering. This > option may not be possible, since my knowledge of the rendering stuff is > limited. It would be simple enough to make it work for menus, status bar etc. I think a combination approach may be best. Do everything in one process, but modularize all the systems so it works naturally. -- Adam Olsen, aka Rhamphoryncus |
From: Dwayne C. L. <dl...@dl...> - 2001-12-20 23:28:14
|
Basically, fraglogs are nice, but they don't work very well for games like = CTF or TF, since winning or losing these games is not based on kills. A cvar that causes scores to be dumped to a file when games end (and maybe = on server exit) would also be useful. Something like this would work: \playername\team\pants-colour\shirt-colour\score\ --+ \playername\team\pants-colour\shirt-colour\score\ | \playername\team\pants-colour\shirt-colour\score\ +-- Game 1 \playername\team\pants-colour\shirt-colour\score\ | \playername\team\pants-colour\shirt-colour\score\ --+ \\\\\\ \playername\team\pants-colour\shirt-colour\score\ --+ \playername\team\pants-colour\shirt-colour\score\ | \playername\team\pants-colour\shirt-colour\score\ +-- Game 2 \playername\team\pants-colour\shirt-colour\score\ | \playername\team\pants-colour\shirt-colour\score\ --+ \\\\\\ =2E . . This is a feature request. It would be great if it could be done in less t= han a week (LAN party :), but obviously I can't expect people to do it unless t= hey want to. (I might do it myself, if it's simple enough and if I have time.) Does anyone see any potential problems with this? --=20 Dwayne C. Litzenberger <dl...@dl...> |
From: Seth G. <sga...@li...> - 2001-12-20 23:10:07
|
On Fri, 21 Dec 2001, Kirk Alexander wrote: > 1) Messy. Easy. > > Unmodified server. > > 4 slightly modified clients - mainly new menu code appropriate to > split-screen play. > > 1 new control program containing Quake menu code, starts up server and > clients when needed and aligns them on screen, so it looks like full > screen. Maybe this "new control program" can be a regular client with several new options that could be launched by the menu, console commands or other events: * start a server (launches the server executable) * add a new player (resizes the window and launches the client executable in a new window with different parameters like which controller to use.) You might use environment variables or something to communicate basic details like how many clients and servers are currently running. (With a little Quake-C scripting you might even be able to let players travel to different maps by starting a new server when they hit a level exit and stopping the server once all the players have gone to another server. I've been planning something similar for a sort of "web" of interconnected servers running different parts of the same world.) Of course modifying the client to allow multiple players per client executable also has potential advantages. Certain mods like Hack and Slash might even be able to use multiple players in a single view. (Obviously with a bit of wasted network traffic, but there you are.) __ __ _ _ __ __ _/ \__/ \__/ Seth Galbraith "The Serpent Lord" \__/ \__/ \_ \__/ \__/ \_ sga...@kr... #2244199 on ICQ _/ \__/ \__/ _/ \__/ \__/ http://www.planetquake.com/gg \__/ \__/ \_ |
From: <ki...@ya...> - 2001-12-20 22:11:48
|
Hi, I am working with Zachary Kuhn from the tuxboxgames project (sourceforge) and we're trying to work out how to adapt Quake to run with split-screen support appropriate for a console. Obviously Id did this for Quake on the Nintendo 64, but asking them should be a last resort. I was hoping you guys might be able to give us some pointers on how to go about this. The following are the three possibilities I have come up with so far. There may be better solutions. Please flame away if they show incredible naivety :) Thanks very much, and keep up the great work on QF! Cheers, Kirk Alexander 1) Messy. Easy. Unmodified server. 4 slightly modified clients - mainly new menu code appropriate to split-screen play. 1 new control program containing Quake menu code, starts up server and clients when needed and aligns them on screen, so it looks like full screen. Depends on graphics system how hard this would be to get right. 2) Relatively straight-forward. Invasive. Lots of grunt work? Unmodified server. 1 client program modified to support multiple clients in one process, and adapt menu code as appropriate. 3) Complex. Lots of work. Possible? Unmodified server. 4 clients "qf-client-vas" : new target (vas == vassal) 1 control program "qf-lord-x11" etc. : new program class The vassal programs would be generic (independent of graphics system) and would feed commands to the control program which would do the actual rendering. This option may not be possible, since my knowledge of the rendering stuff is limited. It would be simple enough to make it work for menus, status bar etc. |
From: Dwayne C. L. <dl...@dl...> - 2001-12-16 21:00:11
|
Are other people having these (related) problems with the GL renderer? 1. When entering or leaving water, the sky becomes visible for some reason 2. Shadows cast onto water look like the sky 3. Edges of the world (including ammo boxes) will show the sky, depending on the viewing angle. Here are some screenshots (turn the brightness up on your display to see them): http://www.dlitz.net/temp/qf/ --=20 Dwayne C. Litzenberger <dl...@dl...> |
From: Adam O. <rh...@d2...> - 2001-12-15 18:20:15
|
On Fri, Dec 14, 2001 at 09:26:57PM -0600, Dwayne C. Litzenberger wrote: > The name spam kicking causes a segfault on the server. > > Client [Dw0n1s] ([127.0.0.1]:27001) connected > [Dw0n1s] entered the game > [Dw0n1s] changed name to a > a changed name to b > b changed name to c > c changed name to d > d changed name to e > e changed name to f > f changed name to g > g was kicked for name spam > h left the game with 0 frags > Client g removed > > > ] > Program received signal SIGSEGV, Segmentation fault. > 0x4007fc5c in Info_ValueForKey (info=0xbffffa6c, key=0x4001536c "") > at info.c:78 > 78 info_key_t *k = Hash_Find (info->tab, key); > (gdb) bt > #0 0x4007fc5c in Info_ValueForKey (info=0xbffffa6c, key=0x4001536c "") > at info.c:78 > #1 0x088cbf88 in ?? () > > Also, can somebody tell my why gdb won't backtrace? I'm using gdb 5.1. Probably because there's nothing left to trace :) Invalid pointers can easily thrash the stack, ruining any backtrace. The crash is probably caused by calling Info_* after SV_DropClient is called. The fix is to make SV_ExtractFromUserinfo not call SV_DropClient at all, instead flagging them to be dropped at the end of the frame. (both for invalid names and name spamming) Somebody wanna do this? My tree is on a different branch. -- Adam Olsen, aka Rhamphoryncus |
From: Adam O. <rh...@d2...> - 2001-12-15 18:11:09
|
On Fri, Dec 14, 2001 at 08:52:27PM -0600, Dwayne C. Litzenberger wrote: > The logfile isn't being fflush()ed on each write. This can cause problems > with bots that actively monitor the console to perform certain tasks. (I hope > that made sense. :) Flushing it on each call is just a work around (and bad for performance). The proper fix is to call "setvbuf (sv_logfile->file, 0, _IOLBF, BUFSIZE);" when it's opened. The struct used for sv_logfile isn't exported from quakeio.c though, so it needs to be done in there. Anybody have a suggestion where exactly? A flag to Qopen, or a Qsetvbuf maybe? -- Adam Olsen, aka Rhamphoryncus |
From: Dwayne C. L. <dl...@dl...> - 2001-12-15 06:40:22
|
I'm not familiar with automake, so I never made a Makefile.am for this program, but it depends on libs/util/sys.c (specifically, sys_char_map), FYI. Could this be added to the tools/ dir? -- Dwayne C. Litzenberger <dl...@dl...> |
From: Dwayne C. L. <dl...@dl...> - 2001-12-15 03:26:59
|
The name spam kicking causes a segfault on the server. Client [Dw0n1s] ([127.0.0.1]:27001) connected [Dw0n1s] entered the game [Dw0n1s] changed name to a a changed name to b b changed name to c c changed name to d d changed name to e e changed name to f f changed name to g g was kicked for name spam h left the game with 0 frags Client g removed ] Program received signal SIGSEGV, Segmentation fault. 0x4007fc5c in Info_ValueForKey (info=3D0xbffffa6c, key=3D0x4001536c "") at info.c:78 78 info_key_t *k =3D Hash_Find (info->tab, key); (gdb) bt #0 0x4007fc5c in Info_ValueForKey (info=3D0xbffffa6c, key=3D0x4001536c "") at info.c:78 #1 0x088cbf88 in ?? () Also, can somebody tell my why gdb won't backtrace? I'm using gdb 5.1. --=20 Dwayne C. Litzenberger <dl...@dl...> |
From: <42...@in...> - 2001-12-15 03:22:06
|
/* Theorically Array support: */ float val1,val2,val3,val4; array("val",3,num); // will be evalutate to this "val3=num;" /* My function that (will) do that */ // Tei array void PF_array (void) { int l,i,val, lenkey, val2; char *p, *d; char tmp[200]; d = pr_string_temp; memset(d, 0, 127); p = G_STRING(OFS_PARM0); val = G_FLOAT(OFS_PARM1); lenkey = strlen(p); Q_strncpy(d, p, lenkey); val2 = floor(val); sscanf(tmp,"%d", val2); //Bug here? Q_strncpy((d + lenkey), tmp, strlen(tmp));//Bug here? //Unfinised work //ED_FindGlobal (new) G_INT(OFS_RETURN) = pr_string_temp - pr_strings; } // Tei array /* The test case */ With this qc func: void () TestArray = { local float res; res = array("cosa",12); bprint( ":",res,":\n"); }; /* The output */ I get :cosa<crap><crap>...<crap>: /* What i expect */ :cosa12: I need help or suggestions.. 1 saludo Tei --------------------------------------------- This message was sent using Endymion MailMan. http://www.endymion.com/products/mailman/ |
From: Dwayne C. L. <dl...@dl...> - 2001-12-15 02:52:32
|
The logfile isn't being fflush()ed on each write. This can cause problems with bots that actively monitor the console to perform certain tasks. (I hope that made sense. :) I've attached a fix. -- Dwayne C. Litzenberger <dl...@dl...> |
From: Seth G. <sga...@li...> - 2001-12-14 21:44:10
|
Kenny wrote: > The TuxBoxProject, an open source gaming console similar to the XBox, > is becoming more active, but it needs help. It's powered by Linux, > and since there is already a Linux version of QuakeForge w/OpenGL it > should be very easy to port QuakeForge to the TuxBox. > Anyone care to help out? I understand that TuxBox games are supposed to run on a fixed hardware and software platform (although you can include libraries on the game disk or with a downloaded game.) Have you got any details about what it will specifically take to make a game compatible with the TuxBox? BFGalbraith wrote: > Us Galbraith Games guys are totally exited about the tux box. I wish > we could spare a programmer right now (but we can't.) I sincerly hope > some someone else will help you. You'll need content (like graphics, sound and music) as well as software to make a TuxBox game with QuakeForge. Quake's content is not free, although you *might* be able to create a downloadable TuxBox freeware game that downloads and installs the data from Quake Shareware, which is a nice free game in itself. Open Quartz - http://openquartz.sf.net - has free content you could distribute freely with a TuxBox game. It has replacements for all of Quake's multiplayer graphics and most of the sounds. Open Quartz also has some levels and single player content. Hack and Slash - http://www.planetquake.com/gg - this is a free game I'm working on using the QuakeForge engine. This 3rd person hand-to-hand combat oriented game is intended to be a generic foundation for action/adventure/role-playing games such as River City Ransom, Diablo, or any of the Legend of Zelda games. Although it is playable, this game is still very much a work in progress, but I'm working on it constantly and hope to have it basically finished soon. qbism - http://qbism.telefragged.com - is a game with free content that uses it's own customized Quake engine. __ __ _ _ __ __ _/ \__/ \__/ Seth Galbraith "The Serpent Lord" \__/ \__/ \_ \__/ \__/ \_ sga...@kr... #2244199 on ICQ _/ \__/ \__/ _/ \__/ \__/ http://www.planetquake.com/gg \__/ \__/ \_ |
From: BFGalbraith <bga...@kr...> - 2001-12-14 04:45:44
|
>The TuxBoxProject, an open source gaming console similar to the XBox, is becoming more active, but it needs help. It's powered by Linux, and since there is already a Linux version of QuakeForge w/OpenGL it should be very easy to port QuakeForge to >the TuxBox. Anyone care to help out? >Kenny Us Galbraith Games guys are totally exited about the tux box. I wish we could spare a programmer right now (but we can't.) I sincerly hope some someone else will help you. -BFGalbraith Hack and Slash Project Manager bga...@kr... Here's what's up: www.planetquake.com/gg |
From: <BL...@ao...> - 2001-12-13 19:40:59
|
The TuxBoxProject, an open source gaming console similar to the XBox, is becoming more active, but it needs help. It's powered by Linux, and since there is already a Linux version of QuakeForge w/OpenGL it should be very easy to port QuakeForge to the TuxBox. Anyone care to help out? Kenny |
From: Mike M. <sho...@gr...> - 2001-12-12 01:39:32
|
I originally intended to develop this later as a plugin, but here goes. I Expanding particles with no limits (EPs) A What are they EPs are particles that repel each other with at an acceleration which is inversely proportional to distance. B How they work At each physics cycle, a set of forces is calculated for each particle. Each force represents that particle's motion as caused by one other particle. The total number of forces should be one less than the total number of particles. The final motion of the particle is determined by the sum of the forces calculated. Particles should bounce off model and BSP surfaces, exerting a push on models if appropriate. C What are they good for? Gases are always pushing to expand. This provides a way to describe the motion of lightweight particles (such as smoke or clouds of smoke) in fixed environments. This allows things like switchable and controllable wind environments, realistic airfists (I.e. you can literally flush everyone out of a room by firing at the doorway.). II Expanding particles with limits (EPLs) A What are they? There are two typs of EPLs. One kind behaves like EPs, but ceases to impart an acceleration after a certain distance. The other behaves like EPs, but a particle is deleted once it is beyond a certain distance of all other particles. B How they work One type adds a condition check while generating each force, to make sure that force isn't coming from an irrelevant particle. The other type checks that there is at least one other particle within a certain distance before allowing the particle in question to survive. C What are they good for? Type 1 EPLs are excellent if you want a pool of particles to collect in a high place (smoke) or a low place (water or fog). Type 2 EPLs are excellent if you only want a temporary cloud that shouldn't be worried about once it's dissapated. (Like mustard gas or other concentration-sensitive gas weapons.) III Chained duo-particles (CDPs) A What are they? A CDP is essentially a magnet, with a north pole and a south pole, and a fixed distance between them. Calculations are done much the same as with EPs. B How do they work? A CDP is really two particles, a north pole and a south pole. For each particle, a set of forces is calculated exactly the same way as an EP is calculated, except that acceleration is toward the particle if the relevant particle is of the opposite pole, and the acceleration is away from the particle if the other particle is of the same pole. C What are they good for? CDPs are useful for whenever you want a viscous or "bouncy" fluid. Meaning you can make a superball which is sensitive to explosions. :) Imagine Quake-based volleyball with range-limited rocket launchers and walls for boundaries. IV Particle nets A What are they? Particle nets are difficult to explain...imagine a coarse heightmap, and imagine each point as a particle, with invisible lines limiting the distance between each particle and its neighbors. B How do they work? Each particle in a particle net has neighbors. A force on one particle in the net is bounced on through the net. Picture a fishing net. Lift up on one node of the net, and the rest of the net nearby is drawn towards where that node, though still subject to gravity. C What are they good for? Nets to throw on players. Modeling fire (with EPs underneath the net to keep things moving). Modeling a water surface you can walk across. Modeling walking across a big rubber sheet, or across a big net. |
From: Seth G. <sga...@li...> - 2001-12-10 18:45:05
|
On Thu, 6 Dec 2001, Bill Currie wrote: > Just what does this mean for the sw renderer? I'm not certain, but I > think it relies on the 8 bit vertex data. It's certainly not a problem > for the gl renderer: all coords get converted to floats anyway. In SW the points have to be converted to floats also - but it's done at rendering time. I believe it's done in several places in sw_ralias.c - apparently by implicit casting - usually something like this: ... DotProduct (pverts->v, aliastransform[0]) ... (aliastransform is an array of arrays of floats) So to add extra precision you would just add the extra precision bytes and pverts->v together and use that in the DotProduct when rendering an extra precise model: VectorScale (extra_pverts->v, 1.0 / 256, temp->v); VectorAdd (pverts->v, temp->v, precise_pverts->v); ... DotProduct (precise_pverts->v, aliastransform[0]) ... __ __ _ _ __ __ _/ \__/ \__/ Seth Galbraith "The Serpent Lord" \__/ \__/ \_ \__/ \__/ \_ sga...@kr... #2244199 on ICQ _/ \__/ \__/ _/ \__/ \__/ http://www.planetquake.com/gg \__/ \__/ \_ |
From: Dwayne C. L. <dl...@dl...> - 2001-12-09 05:14:31
|
I recently started toying with QuakeForge again, and one of the features I noticed was missing was that nifty rocket fireball effect (gl_fires). So I had a look at the CVS logs, and apparently taniwha killed it last Nov becau= se "it's semi-broken, generally nasty (code wise) and kinda tacky". The gl_fires cvar still exists, but is never used. The feature it was fair= ly popular at our last LAN party, and since there's another one coming up shortly, I'd like to see if I can get it added again somehow. I've looked at the gl_dyn_fires.c code from newtree, and I think it's simple enough that it could probably be my first pet project for the next week or two (I'm a complete OpenGL newbie). So, what was wrong with gl_fires, that warranted its removal? (i.e. what should I watch for if I want to re-implement it?) --=20 Dwayne C. Litzenberger <dl...@dl...> |