From auerswal at unix-ag.uni-kl.de Sun Apr 2 10:53:52 2006 From: auerswal at unix-ag.uni-kl.de (Erik Auerswald) Date: Sun, 2 Apr 2006 16:53:52 +0200 Subject: [PATCH] SDL joystick code additions Message-ID: <20060402145352.GA22041@sushi.unix-ag.uni-kl.de> Hi, the attached patch adds a way to select the joystick to use (instead of the first one) and support for joystick "hats" to the SDL joystick code. This takes care of two "FIXME"s. The joystick is selected by setting the new CVar "in_joystickNo" to the appropriate number. Erik -------------- next part -------------- Index: code/unix/sdl_glimp.c =================================================================== --- code/unix/sdl_glimp.c (revision 692) +++ code/unix/sdl_glimp.c (working copy) @@ -1361,17 +1361,32 @@ K_JOY26, K_JOY27 }; +// translate hat events into keypresses +// the 4 highest buttons are used for the first hat ... +static int hat_keys[16] = { + K_JOY29, K_JOY30, + K_JOY31, K_JOY32, + K_JOY25, K_JOY26, + K_JOY27, K_JOY28, + K_JOY21, K_JOY22, + K_JOY23, K_JOY24, + K_JOY17, K_JOY18, + K_JOY19, K_JOY20 +}; + // bk001130 - from linux_glimp.c extern cvar_t * in_joystick; extern cvar_t * in_joystickDebug; extern cvar_t * joy_threshold; +cvar_t *in_joystickNo; #define ARRAYLEN(x) (sizeof (x) / sizeof (x[0])) struct { qboolean buttons[16]; // !!! FIXME: these might be too many. unsigned int oldaxes; + unsigned int oldhats; } stick_state; @@ -1411,36 +1426,35 @@ for (i = 0; i < total; i++) Com_Printf("[%d] %s\n", i, SDL_JoystickName(i)); - // !!! FIXME: someone should add a way to select a specific stick. - for( i = 0; i < total; i++ ) { - stick = SDL_JoystickOpen(i); - if (stick == NULL) - continue; + in_joystickNo = Cvar_Get( "in_joystickNo", "0", CVAR_ARCHIVE ); + if( in_joystickNo->integer < 0 || in_joystickNo->integer >= total ) + Cvar_Set( "in_joystickNo", "0" ); - Com_Printf( "Joystick %d opened\n", i ); - Com_Printf( "Name: %s\n", SDL_JoystickName(i) ); - Com_Printf( "Axes: %d\n", SDL_JoystickNumAxes(stick) ); - Com_Printf( "Hats: %d\n", SDL_JoystickNumHats(stick) ); - Com_Printf( "Buttons: %d\n", SDL_JoystickNumButtons(stick) ); - Com_Printf( "Balls: %d\n", SDL_JoystickNumBalls(stick) ); + stick = SDL_JoystickOpen( in_joystickNo->integer ); - SDL_JoystickEventState(SDL_QUERY); - - /* Our work here is done. */ + if (stick == NULL) { + Com_Printf( "No joystick opened.\n" ); return; } - /* No soup for you. */ - if( stick == NULL ) { - Com_Printf( "No joystick opened.\n" ); - return; - } + Com_Printf( "Joystick %d opened\n", in_joystickNo->integer ); + Com_Printf( "Name: %s\n", SDL_JoystickName(in_joystickNo->integer) ); + Com_Printf( "Axes: %d\n", SDL_JoystickNumAxes(stick) ); + Com_Printf( "Hats: %d\n", SDL_JoystickNumHats(stick) ); + Com_Printf( "Buttons: %d\n", SDL_JoystickNumButtons(stick) ); + Com_Printf( "Balls: %d\n", SDL_JoystickNumBalls(stick) ); + + SDL_JoystickEventState(SDL_QUERY); + + /* Our work here is done. */ + return; } void IN_JoyMove( void ) { qboolean joy_pressed[ARRAYLEN(joy_keys)]; unsigned int axes = 0; + unsigned int hats = 0; int total = 0; int i = 0; @@ -1494,8 +1508,95 @@ } } - // !!! FIXME: look at the hats... + // look at the hats... + total = SDL_JoystickNumHats(stick); + if (total > 0) + { + if (total > 4) total = 4; + for (i = 0; i < total; i++) + { + ((Uint8 *)&hats)[i] = SDL_JoystickGetHat(stick, i); + } + } + // update hat state + if (hats != stick_state.oldhats) + { + for( i = 0; i < 4; i++ ) { + if( ((Uint8 *)&hats)[i] != ((Uint8 *)&stick_state.oldhats)[i] ) { + // release event + switch( ((Uint8 *)&stick_state.oldhats)[i] ) { + case SDL_HAT_UP: + Sys_QueEvent( 0, SE_KEY, hat_keys[4*i + 0], qfalse, 0, NULL ); + break; + case SDL_HAT_RIGHT: + Sys_QueEvent( 0, SE_KEY, hat_keys[4*i + 1], qfalse, 0, NULL ); + break; + case SDL_HAT_DOWN: + Sys_QueEvent( 0, SE_KEY, hat_keys[4*i + 2], qfalse, 0, NULL ); + break; + case SDL_HAT_LEFT: + Sys_QueEvent( 0, SE_KEY, hat_keys[4*i + 3], qfalse, 0, NULL ); + break; + case SDL_HAT_RIGHTUP: + Sys_QueEvent( 0, SE_KEY, hat_keys[4*i + 0], qfalse, 0, NULL ); + Sys_QueEvent( 0, SE_KEY, hat_keys[4*i + 1], qfalse, 0, NULL ); + break; + case SDL_HAT_RIGHTDOWN: + Sys_QueEvent( 0, SE_KEY, hat_keys[4*i + 2], qfalse, 0, NULL ); + Sys_QueEvent( 0, SE_KEY, hat_keys[4*i + 1], qfalse, 0, NULL ); + break; + case SDL_HAT_LEFTUP: + Sys_QueEvent( 0, SE_KEY, hat_keys[4*i + 0], qfalse, 0, NULL ); + Sys_QueEvent( 0, SE_KEY, hat_keys[4*i + 3], qfalse, 0, NULL ); + break; + case SDL_HAT_LEFTDOWN: + Sys_QueEvent( 0, SE_KEY, hat_keys[4*i + 2], qfalse, 0, NULL ); + Sys_QueEvent( 0, SE_KEY, hat_keys[4*i + 3], qfalse, 0, NULL ); + break; + default: + break; + } + // press event + switch( ((Uint8 *)&hats)[i] ) { + case SDL_HAT_UP: + Sys_QueEvent( 0, SE_KEY, hat_keys[4*i + 0], qtrue, 0, NULL ); + break; + case SDL_HAT_RIGHT: + Sys_QueEvent( 0, SE_KEY, hat_keys[4*i + 1], qtrue, 0, NULL ); + break; + case SDL_HAT_DOWN: + Sys_QueEvent( 0, SE_KEY, hat_keys[4*i + 2], qtrue, 0, NULL ); + break; + case SDL_HAT_LEFT: + Sys_QueEvent( 0, SE_KEY, hat_keys[4*i + 3], qtrue, 0, NULL ); + break; + case SDL_HAT_RIGHTUP: + Sys_QueEvent( 0, SE_KEY, hat_keys[4*i + 0], qtrue, 0, NULL ); + Sys_QueEvent( 0, SE_KEY, hat_keys[4*i + 1], qtrue, 0, NULL ); + break; + case SDL_HAT_RIGHTDOWN: + Sys_QueEvent( 0, SE_KEY, hat_keys[4*i + 2], qtrue, 0, NULL ); + Sys_QueEvent( 0, SE_KEY, hat_keys[4*i + 1], qtrue, 0, NULL ); + break; + case SDL_HAT_LEFTUP: + Sys_QueEvent( 0, SE_KEY, hat_keys[4*i + 0], qtrue, 0, NULL ); + Sys_QueEvent( 0, SE_KEY, hat_keys[4*i + 3], qtrue, 0, NULL ); + break; + case SDL_HAT_LEFTDOWN: + Sys_QueEvent( 0, SE_KEY, hat_keys[4*i + 2], qtrue, 0, NULL ); + Sys_QueEvent( 0, SE_KEY, hat_keys[4*i + 3], qtrue, 0, NULL ); + break; + default: + break; + } + } + } + } + + // save hat state + stick_state.oldhats = hats; + // finally, look at the axes... total = SDL_JoystickNumAxes(stick); if (total > 0) Index: README =================================================================== --- README (revision 692) +++ README (working copy) @@ -120,6 +120,7 @@ in_shiftedKeys - non-SDL Linux only. Enables binding to shifted keys cl_consoleHistory - read only, stores the console history cl_platformSensitivity - read only, indicates the mouse input scaling + in_joystickNo - select joystick to use New commands video [filename] - start video capture (use with demo command) From tim at ngus.net Mon Apr 3 03:50:19 2006 From: tim at ngus.net (Tim Angus) Date: Mon, 03 Apr 2006 08:50:19 +0100 Subject: Tremulous 1.10 based on icculus.org/quake3 out! In-Reply-To: <442D9090.1030900@timedoctor.org> References: <442D9090.1030900@timedoctor.org> Message-ID: <4430D3BB.3000906@ngus.net> Zachary J. Slater wrote: > Tim "Timbo" Angus has just released his stand-alone Tremulous Q3 TC over > at http://www.tremulous.net/ based on this very engine :) Strictly speaking it's 1.1.0 not 1.10. From marc.leeman at gmail.com Mon Apr 3 04:08:58 2006 From: marc.leeman at gmail.com (Marc Leeman) Date: Mon, 3 Apr 2006 10:08:58 +0200 Subject: [quake3] Re: Tremulous 1.10 based on icculus.org/quake3 out! In-Reply-To: <4430D3BB.3000906@ngus.net> References: <442D9090.1030900@timedoctor.org> <4430D3BB.3000906@ngus.net> Message-ID: <20060403080858.GF5413@scorpius.homelinux.org> > >Tim "Timbo" Angus has just released his stand-alone Tremulous Q3 TC over > >at http://www.tremulous.net/ based on this very engine :) > > Strictly speaking it's 1.1.0 not 1.10. Reading through the site; both the code and the artwork (skins, models) are GPL? In that case, it would be a nice ioQ3 based game to upload to the debian archives (without the classical data package fetched by a install package). -- greetz, marc I'm only judging on my experience with you, but I've never seen such a deficient species. Pilot - Crackers Don't Matter scorpius.homelinux.org 2.6.16 #6 PREEMPT Sat Apr 1 21:22:39 CEST 2006 GNU/Linux -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: Digital signature URL: From zakk at timedoctor.org Mon Apr 3 04:11:45 2006 From: zakk at timedoctor.org (Zachary J. Slater) Date: Mon, 03 Apr 2006 01:11:45 -0700 Subject: [quake3] Re: Tremulous 1.10 based on icculus.org/quake3 out! In-Reply-To: <20060403080858.GF5413@scorpius.homelinux.org> References: <442D9090.1030900@timedoctor.org> <4430D3BB.3000906@ngus.net> <20060403080858.GF5413@scorpius.homelinux.org> Message-ID: <4430D8C1.7080305@timedoctor.org> Marc Leeman wrote: >>> Tim "Timbo" Angus has just released his stand-alone Tremulous Q3 TC over >>> at http://www.tremulous.net/ based on this very engine :) >> Strictly speaking it's 1.1.0 not 1.10. > > Reading through the site; both the code and the artwork (skins, models) > are GPL? > > In that case, it would be a nice ioQ3 based game to upload to the debian > archives (without the classical data package fetched by a install > package). The artwork is Creative Commons with some special rider thing, I think. The code is still GPL of course. -- - Zachary J. Slater zakk at timedoctor.org zacharyslater at gmail.com From insidepoolhenry at yahoo.com Mon Apr 3 18:36:47 2006 From: insidepoolhenry at yahoo.com (Henry Garcia) Date: Mon, 3 Apr 2006 15:36:47 -0700 (PDT) Subject: OpenAL on Linux Message-ID: <20060403223647.88776.qmail@web52311.mail.yahoo.com> Graphics and performance are better on the newer executables. But still having the sound cut out on me in Linux. Doesn't happen when SDL and OPENAL are disabled in the compiled executables. Is there a particular version of OpenAL that my machine should have installed. I notice that the program console says that it using version 0.0.7 of OPENAL. Also, just installed Visual Studio 2003 .NET on the Windows Machine. Notice that I'm now receiving an error message in the mingw compile saying it can't find the files\MSVS on the last few lines. All the dll's compile fine along with the executables. But the compiler must want to do something else with Visual Studio? Hank --------------------------------- Yahoo! Messenger with Voice. PC-to-Phone calls for ridiculously low rates. -------------- next part -------------- An HTML attachment was scrubbed... URL: From zakk at timedoctor.org Mon Apr 3 18:42:21 2006 From: zakk at timedoctor.org (Zachary J. Slater) Date: Mon, 03 Apr 2006 15:42:21 -0700 Subject: [quake3] OpenAL on Linux In-Reply-To: <20060403223647.88776.qmail@web52311.mail.yahoo.com> References: <20060403223647.88776.qmail@web52311.mail.yahoo.com> Message-ID: <4431A4CD.9080109@timedoctor.org> Henry Garcia wrote: > Graphics and performance are better on the newer executables. > > But still having the sound cut out on me in Linux. Doesn't happen when > SDL and OPENAL are disabled in the compiled executables. > > Is there a particular version of OpenAL that my machine should have > installed. I notice that the program console says that it using version > 0.0.7 of OPENAL. > > Also, just installed Visual Studio 2003 .NET on the Windows Machine. > Notice that I'm now receiving an error message in the mingw compile > saying it can't find the files\MSVS on the last few lines. All the dll's > compile fine along with the executables. But the compiler must want to > do something else with Visual Studio? > > Hank > > ------------------------------------------------------------------------ > Yahoo! Messenger with Voice. > > PC-to-Phone calls for ridiculously low rates. Please do not send html mail to this list. -- - Zachary J. Slater zakk at timedoctor.org zacharyslater at gmail.com From arny at ats.s.bawue.de Sun Apr 9 18:55:10 2006 From: arny at ats.s.bawue.de (Thilo Schulz) Date: Mon, 10 Apr 2006 00:55:10 +0200 Subject: ioquake3 for eliteforce beta release Message-ID: <200604100055.13479.arny@ats.s.bawue.de> Hullo list, Just a quick announcement FYI: I have fixed the last quirks that I deemed fixable and Eliteforce should run without bigger problems now. Patches: patch -p0 < xxx.diff in ioquake3's source dir Just take the most recent one (at the time of this writing: quake3-efbeta1-iorev697.diff) available here: http://thilo.kickchat.com/efport-progress/patches/ And do "make eliteforce" afterwards. Requirements: additionally to the usual ioquake3 requirements a working installation of libmad library + header files is necessary. Builds (Linux and Windows): http://thilo.kickchat.com/efport-progress/bin/ Here's the readme: http://thilo.kickchat.com/efport-progress/README-EF.txt Have fun! -- Thilo Schulz -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tjw at webteam.net Mon Apr 10 14:24:09 2006 From: tjw at webteam.net (Tony J. White) Date: Mon, 10 Apr 2006 13:24:09 -0500 Subject: [PATCH] Mac OSX support Message-ID: <20060410182409.GX2900@morbo.webteam.net> I've been working on getting Tremulous working on Mac OSX. It still needs work, but you will find the patch here that is required to get the mac build to stop crashing when it queries network interfaces: http://www.tjw.org/tremulous/macosx/ (note that there are two seperate patches, one for tremulous SVN and another for ioquake3 SVN) In addition you will need to remove the libSDL-1.2.0.dylib file from SVN ad replace it with the libSDL.a file from there. That libSDL was compiled using this patch: http://www.algonet.se/~afb/libsdl/SDL-1.2.9-loadso.patch So probably that should be included as well. I'm pretty sure that the use of .bundles which (is required for OSX 10.3 and up) will break compatability with OSX 10.2 and older. I don't know much about making backwards compatible versions, but I think most people use 10.3 or 10.4 anyway. For example Wolf:ET was released for OSX over a year ago and only supports 10.3 and up because of it's use of library ".bundle"s. -Tony From only_mortal at mac.com Mon Apr 10 14:31:31 2006 From: only_mortal at mac.com (Mike Davis) Date: Mon, 10 Apr 2006 20:31:31 +0200 Subject: [quake3] [PATCH] Mac OSX support In-Reply-To: <20060410182409.GX2900@morbo.webteam.net> References: <20060410182409.GX2900@morbo.webteam.net> Message-ID: <16B41F51-3BC2-4766-A1DA-ECA498232CA1@mac.com> I'm not sure what you're referring to but bundles go back to, at least, NeXTSTEP 3.0. 10.3 and up can use dynamic libraries, just like you have always been able to do so... On 10 Apr 2006, at 20:24, Tony J. White wrote: > > I've been working on getting Tremulous working on Mac OSX. > > It still needs work, but you will find the patch here that is required > to get the mac build to stop crashing when it queries network > interfaces: > > http://www.tjw.org/tremulous/macosx/ > > (note that there are two seperate patches, one for tremulous SVN > and another > for ioquake3 SVN) > > In addition you will need to remove the libSDL-1.2.0.dylib file > from SVN ad > replace it with the libSDL.a file from there. > > That libSDL was compiled using this patch: > http://www.algonet.se/~afb/libsdl/SDL-1.2.9-loadso.patch > So probably that should be included as well. > > I'm pretty sure that the use of .bundles which (is required for OSX > 10.3 and up) > will break compatability with OSX 10.2 and older. I don't know > much about > making backwards compatible versions, but I think most people use > 10.3 or 10.4 > anyway. For example Wolf:ET was released for OSX over a year ago > and only > supports 10.3 and up because of it's use of library ".bundle"s. > > -Tony From tjw at webteam.net Mon Apr 10 14:39:07 2006 From: tjw at webteam.net (Tony J. White) Date: Mon, 10 Apr 2006 13:39:07 -0500 Subject: [quake3] [PATCH] Mac OSX support In-Reply-To: <16B41F51-3BC2-4766-A1DA-ECA498232CA1@mac.com> References: <20060410182409.GX2900@morbo.webteam.net> <16B41F51-3BC2-4766-A1DA-ECA498232CA1@mac.com> Message-ID: <20060410183907.GZ2900@morbo.webteam.net> On Mon, Apr 10, 2006 at 08:31:31PM +0200, Mike Davis wrote: > I'm not sure what you're referring to but bundles go back to, at least, > NeXTSTEP 3.0. 10.3 and up can use dynamic libraries, just like you have always > been able to do so... Oh, sorry. I guess I was just a bit confused by the comments in Anders' SDL patch which seemed to indicate that dlopen() should be used pre-10.3. And also by the fact that ioq3 did not use .bundle previously. -Tony > On 10 Apr 2006, at 20:24, Tony J. White wrote: > > > > >I've been working on getting Tremulous working on Mac OSX. > > > >It still needs work, but you will find the patch here that is required > >to get the mac build to stop crashing when it queries network interfaces: > > > >http://www.tjw.org/tremulous/macosx/ > > > >(note that there are two seperate patches, one for tremulous SVN and another > >for ioquake3 SVN) > > > >In addition you will need to remove the libSDL-1.2.0.dylib file from SVN ad > >replace it with the libSDL.a file from there. > > > >That libSDL was compiled using this patch: > >http://www.algonet.se/~afb/libsdl/SDL-1.2.9-loadso.patch > >So probably that should be included as well. > > > >I'm pretty sure that the use of .bundles which (is required for OSX 10.3 and > >up) > >will break compatability with OSX 10.2 and older. I don't know much about > >making backwards compatible versions, but I think most people use 10.3 or 10.4 > >anyway. For example Wolf:ET was released for OSX over a year ago and only > >supports 10.3 and up because of it's use of library ".bundle"s. > > > >-Tony > -- From icculus at icculus.org Mon Apr 10 14:47:25 2006 From: icculus at icculus.org (Ryan C. Gordon) Date: Mon, 10 Apr 2006 14:47:25 -0400 Subject: [quake3] [PATCH] Mac OSX support In-Reply-To: <20060410183907.GZ2900@morbo.webteam.net> References: <20060410182409.GX2900@morbo.webteam.net> <16B41F51-3BC2-4766-A1DA-ECA498232CA1@mac.com> <20060410183907.GZ2900@morbo.webteam.net> Message-ID: <443AA83D.9080109@icculus.org> > Oh, sorry. I guess I was just a bit confused by the comments in Anders' SDL > patch which seemed to indicate that dlopen() should be used pre-10.3. And > also by the fact that ioq3 did not use .bundle previously. There's no dlopen() function in Mac OS X before 10.3. SDL reimplements dlopen() internally using lower level Carbon calls to retain 10.2 compatibility. Dynamic libraries, unlike bundles, can't be unloaded on Mac OS X, which might be why ET has that requirement. --ryan. From tjw at webteam.net Mon Apr 10 15:31:02 2006 From: tjw at webteam.net (Tony J. White) Date: Mon, 10 Apr 2006 14:31:02 -0500 Subject: [quake3] [PATCH] Mac OSX support In-Reply-To: <443AA83D.9080109@icculus.org> References: <20060410182409.GX2900@morbo.webteam.net> <16B41F51-3BC2-4766-A1DA-ECA498232CA1@mac.com> <20060410183907.GZ2900@morbo.webteam.net> <443AA83D.9080109@icculus.org> Message-ID: <20060410193102.GA2900@morbo.webteam.net> On Mon, Apr 10, 2006 at 02:47:25PM -0400, Ryan C. Gordon wrote: > > >Oh, sorry. I guess I was just a bit confused by the comments in Anders' SDL > >patch which seemed to indicate that dlopen() should be used pre-10.3. And > >also by the fact that ioq3 did not use .bundle previously. > > There's no dlopen() function in Mac OS X before 10.3. SDL reimplements dlopen() > internally using lower level Carbon calls to retain 10.2 compatibility. Yes, it appears I read Anders's comment backwards: +/* + With Mac OS X v10.3 and above, using dlopen is recommended. + See http://developer.apple.com/technotes/tn2002/tn2071.html +*/ So apperantly my patch will not break compatability with older OSX versions afterall. It would be nice to get someone with older versions of OSX to test building (or even running) my 10.4 build: http://trem.tjw.org/Tremulous-20060409.dmg I have a feeling the framework dependencies may tie the build to 10.4. On the other hand, I obviously don't know what I'm talking about :) > Dynamic libraries, unlike bundles, can't be unloaded on Mac OS X, which might > be why ET has that requirement. All the more reason to use .bundles then. I guess I'm still a bit confused as to why ioq3 even tries to load the .dylib files instead of using bundles in the first place. -Tony From only_mortal at mac.com Mon Apr 10 16:20:27 2006 From: only_mortal at mac.com (Mike Davis) Date: Mon, 10 Apr 2006 22:20:27 +0200 Subject: [quake3] [PATCH] Mac OSX support In-Reply-To: <443AA83D.9080109@icculus.org> References: <20060410182409.GX2900@morbo.webteam.net> <16B41F51-3BC2-4766-A1DA-ECA498232CA1@mac.com> <20060410183907.GZ2900@morbo.webteam.net> <443AA83D.9080109@icculus.org> Message-ID: <72D77E4E-BBAB-40E1-AD51-537AF9D93028@mac.com> On 10 Apr 2006, at 20:47, Ryan C. Gordon wrote: > >> Oh, sorry. I guess I was just a bit confused by the comments in >> Anders' SDL >> patch which seemed to indicate that dlopen() should be used >> pre-10.3. And >> also by the fact that ioq3 did not use .bundle previously. > > There's no dlopen() function in Mac OS X before 10.3. SDL > reimplements dlopen() internally using lower level Carbon calls to > retain 10.2 compatibility. I used to use some code that did what dlopen() does using the mach loader apis (in ViaVoice OSX and SafeCast specifically). I seem to remember some code in an older Darwin that did dlopen(). Either that or someone wrote some stub code for dlopen(). > > Dynamic libraries, unlike bundles, can't be unloaded on Mac OS X, > which might be why ET has that requirement. > > --ryan. > From icculus at icculus.org Mon Apr 10 16:53:10 2006 From: icculus at icculus.org (Ryan C. Gordon) Date: Mon, 10 Apr 2006 16:53:10 -0400 Subject: [quake3] [PATCH] Mac OSX support In-Reply-To: <72D77E4E-BBAB-40E1-AD51-537AF9D93028@mac.com> References: <20060410182409.GX2900@morbo.webteam.net> <16B41F51-3BC2-4766-A1DA-ECA498232CA1@mac.com> <20060410183907.GZ2900@morbo.webteam.net> <443AA83D.9080109@icculus.org> <72D77E4E-BBAB-40E1-AD51-537AF9D93028@mac.com> Message-ID: <443AC5B6.7030401@icculus.org> > I seem to > remember some code in an older Darwin that did dlopen(). Either that > or someone wrote some stub code for dlopen(). Probably dlcompat, which is what SDL uses internally. http://www.opendarwin.org/projects/dlcompat/ --ryan. From tjw at webteam.net Mon Apr 10 17:07:00 2006 From: tjw at webteam.net (Tony J. White) Date: Mon, 10 Apr 2006 16:07:00 -0500 Subject: [PATCH] cl_guid Message-ID: <20060410210700.GC2900@morbo.webteam.net> What is cl_guid? It is a CVAR_USERINFO cvar that is used by Even Balance's Punkbuster software in quake3 and deriviatives. It's a unique identifier that may or may not be tied to a CD-Key. In games without a CD Key like Wolf:ET, it is randomly generated and can be reset at any time by removing the file full of binary garbage at etmain/etkey. What use is it? I use it in my Wolf:ET mod (etpub) to grant authentication for administrators, store a player's gamestate information while that player is not connected, and to store player statistics. There is also an option to append the cl_guid to game log records since some log analyzers for Wolf:ET also use it for more accurate player statistics (as opposed to netname). I'm in the process of adapting the administration system to work with Tremulous and it will obviously not work without a cl_guid. Why add it to ioq3? As the name applies, cl_guid belongs in the client engine, not cgame. It is meant to be consistent no matter which client mod is loaded. There is also the fact that cl_guid was in Id's quake3 binaries, ioq3 should be more compatabile with any mods that made use of it. How does it work? On startup, the client engine looks for a file called qkey. If it does not exist, 2KiB worth of random binary data is inserted into the qkey file. A MD5 digest is then made of the qkey file and it is inserted into the cl_guid cvar. This is essentially the same way it works on ET except that pb uses some other secret voodoo to hide how it comes up with the MD5 digest. How about authentication and duplicates? Punkbuster authenticates each guid and keeps track of when they are created and squashes generation of duplicates. It is obviously out of the scope of ioq3 to do this so duplicates are possible, but very unlikely. -Tony -------------- next part -------------- Index: code/qcommon/md5.c =================================================================== --- code/qcommon/md5.c (revision 0) +++ code/qcommon/md5.c (revision 0) @@ -0,0 +1,299 @@ +/* + * This code implements the MD5 message-digest algorithm. + * The algorithm is due to Ron Rivest. This code was + * written by Colin Plumb in 1993, no copyright is claimed. + * This code is in the public domain; do with it what you wish. + * + * Equivalent code is available from RSA Data Security, Inc. + * This code has been tested against that, and is equivalent, + * except that you don't need to include two pages of legalese + * with every copy. + * + * To compute the message digest of a chunk of bytes, declare an + * MD5Context structure, pass it to MD5Init, call MD5Update as + * needed on buffers full of bytes, and then call MD5Final, which + * will fill a supplied 16-byte array with the digest. + */ +#include "q_shared.h" +#include "qcommon.h" + +typedef struct MD5Context { + unsigned long int buf[4]; + unsigned long int bits[2]; + unsigned char in[64]; +} MD5_CTX; + +#ifndef Q3_BIG_ENDIAN + #define byteReverse(buf, len) /* Nothing */ +#else + static void byteReverse(unsigned char *buf, unsigned longs); + + /* + * Note: this code is harmless on little-endian machines. + */ + static void byteReverse(unsigned char *buf, unsigned longs) + { + unsigned long int t; + do { + t = (unsigned long int) + ((unsigned) buf[3] << 8 | buf[2]) << 16 | + ((unsigned) buf[1] << 8 | buf[0]); + *(unsigned long int *) buf = t; + buf += 4; + } while (--longs); + } +#endif // Q3_BIG_ENDIAN + +/* + * Start MD5 accumulation. Set bit count to 0 and buffer to mysterious + * initialization constants. + */ +static void MD5Init(struct MD5Context *ctx) +{ + ctx->buf[0] = 0x67452301; + ctx->buf[1] = 0xefcdab89; + ctx->buf[2] = 0x98badcfe; + ctx->buf[3] = 0x10325476; + + ctx->bits[0] = 0; + ctx->bits[1] = 0; +} +/* The four core functions - F1 is optimized somewhat */ + +/* #define F1(x, y, z) (x & y | ~x & z) */ +#define F1(x, y, z) (z ^ (x & (y ^ z))) +#define F2(x, y, z) F1(z, x, y) +#define F3(x, y, z) (x ^ y ^ z) +#define F4(x, y, z) (y ^ (x | ~z)) + +/* This is the central step in the MD5 algorithm. */ +#define MD5STEP(f, w, x, y, z, data, s) \ + ( w += f(x, y, z) + data, w = w<>(32-s), w += x ) + +/* + * The core of the MD5 algorithm, this alters an existing MD5 hash to + * reflect the addition of 16 longwords of new data. MD5Update blocks + * the data and converts bytes into longwords for this routine. + */ +static void MD5Transform(unsigned long int buf[4], + unsigned long int const in[16]) +{ + register unsigned long int a, b, c, d; + + a = buf[0]; + b = buf[1]; + c = buf[2]; + d = buf[3]; + + MD5STEP(F1, a, b, c, d, in[0] + 0xd76aa478, 7); + MD5STEP(F1, d, a, b, c, in[1] + 0xe8c7b756, 12); + MD5STEP(F1, c, d, a, b, in[2] + 0x242070db, 17); + MD5STEP(F1, b, c, d, a, in[3] + 0xc1bdceee, 22); + MD5STEP(F1, a, b, c, d, in[4] + 0xf57c0faf, 7); + MD5STEP(F1, d, a, b, c, in[5] + 0x4787c62a, 12); + MD5STEP(F1, c, d, a, b, in[6] + 0xa8304613, 17); + MD5STEP(F1, b, c, d, a, in[7] + 0xfd469501, 22); + MD5STEP(F1, a, b, c, d, in[8] + 0x698098d8, 7); + MD5STEP(F1, d, a, b, c, in[9] + 0x8b44f7af, 12); + MD5STEP(F1, c, d, a, b, in[10] + 0xffff5bb1, 17); + MD5STEP(F1, b, c, d, a, in[11] + 0x895cd7be, 22); + MD5STEP(F1, a, b, c, d, in[12] + 0x6b901122, 7); + MD5STEP(F1, d, a, b, c, in[13] + 0xfd987193, 12); + MD5STEP(F1, c, d, a, b, in[14] + 0xa679438e, 17); + MD5STEP(F1, b, c, d, a, in[15] + 0x49b40821, 22); + + MD5STEP(F2, a, b, c, d, in[1] + 0xf61e2562, 5); + MD5STEP(F2, d, a, b, c, in[6] + 0xc040b340, 9); + MD5STEP(F2, c, d, a, b, in[11] + 0x265e5a51, 14); + MD5STEP(F2, b, c, d, a, in[0] + 0xe9b6c7aa, 20); + MD5STEP(F2, a, b, c, d, in[5] + 0xd62f105d, 5); + MD5STEP(F2, d, a, b, c, in[10] + 0x02441453, 9); + MD5STEP(F2, c, d, a, b, in[15] + 0xd8a1e681, 14); + MD5STEP(F2, b, c, d, a, in[4] + 0xe7d3fbc8, 20); + MD5STEP(F2, a, b, c, d, in[9] + 0x21e1cde6, 5); + MD5STEP(F2, d, a, b, c, in[14] + 0xc33707d6, 9); + MD5STEP(F2, c, d, a, b, in[3] + 0xf4d50d87, 14); + MD5STEP(F2, b, c, d, a, in[8] + 0x455a14ed, 20); + MD5STEP(F2, a, b, c, d, in[13] + 0xa9e3e905, 5); + MD5STEP(F2, d, a, b, c, in[2] + 0xfcefa3f8, 9); + MD5STEP(F2, c, d, a, b, in[7] + 0x676f02d9, 14); + MD5STEP(F2, b, c, d, a, in[12] + 0x8d2a4c8a, 20); + + MD5STEP(F3, a, b, c, d, in[5] + 0xfffa3942, 4); + MD5STEP(F3, d, a, b, c, in[8] + 0x8771f681, 11); + MD5STEP(F3, c, d, a, b, in[11] + 0x6d9d6122, 16); + MD5STEP(F3, b, c, d, a, in[14] + 0xfde5380c, 23); + MD5STEP(F3, a, b, c, d, in[1] + 0xa4beea44, 4); + MD5STEP(F3, d, a, b, c, in[4] + 0x4bdecfa9, 11); + MD5STEP(F3, c, d, a, b, in[7] + 0xf6bb4b60, 16); + MD5STEP(F3, b, c, d, a, in[10] + 0xbebfbc70, 23); + MD5STEP(F3, a, b, c, d, in[13] + 0x289b7ec6, 4); + MD5STEP(F3, d, a, b, c, in[0] + 0xeaa127fa, 11); + MD5STEP(F3, c, d, a, b, in[3] + 0xd4ef3085, 16); + MD5STEP(F3, b, c, d, a, in[6] + 0x04881d05, 23); + MD5STEP(F3, a, b, c, d, in[9] + 0xd9d4d039, 4); + MD5STEP(F3, d, a, b, c, in[12] + 0xe6db99e5, 11); + MD5STEP(F3, c, d, a, b, in[15] + 0x1fa27cf8, 16); + MD5STEP(F3, b, c, d, a, in[2] + 0xc4ac5665, 23); + + MD5STEP(F4, a, b, c, d, in[0] + 0xf4292244, 6); + MD5STEP(F4, d, a, b, c, in[7] + 0x432aff97, 10); + MD5STEP(F4, c, d, a, b, in[14] + 0xab9423a7, 15); + MD5STEP(F4, b, c, d, a, in[5] + 0xfc93a039, 21); + MD5STEP(F4, a, b, c, d, in[12] + 0x655b59c3, 6); + MD5STEP(F4, d, a, b, c, in[3] + 0x8f0ccc92, 10); + MD5STEP(F4, c, d, a, b, in[10] + 0xffeff47d, 15); + MD5STEP(F4, b, c, d, a, in[1] + 0x85845dd1, 21); + MD5STEP(F4, a, b, c, d, in[8] + 0x6fa87e4f, 6); + MD5STEP(F4, d, a, b, c, in[15] + 0xfe2ce6e0, 10); + MD5STEP(F4, c, d, a, b, in[6] + 0xa3014314, 15); + MD5STEP(F4, b, c, d, a, in[13] + 0x4e0811a1, 21); + MD5STEP(F4, a, b, c, d, in[4] + 0xf7537e82, 6); + MD5STEP(F4, d, a, b, c, in[11] + 0xbd3af235, 10); + MD5STEP(F4, c, d, a, b, in[2] + 0x2ad7d2bb, 15); + MD5STEP(F4, b, c, d, a, in[9] + 0xeb86d391, 21); + + buf[0] += a; + buf[1] += b; + buf[2] += c; + buf[3] += d; +} + +/* + * Update context to reflect the concatenation of another buffer full + * of bytes. + */ +static void MD5Update(struct MD5Context *ctx, unsigned char const *buf, + unsigned len) +{ + register unsigned long int t; + + /* Update bitcount */ + + t = ctx->bits[0]; + if ((ctx->bits[0] = t + ((unsigned long int) len << 3)) < t) + ctx->bits[1]++; /* Carry from low to high */ + ctx->bits[1] += len >> 29; + + t = (t >> 3) & 0x3f; /* Bytes already in shsInfo->data */ + + /* Handle any leading odd-sized chunks */ + + if (t) { + unsigned char *p = (unsigned char *) ctx->in + t; + + t = 64 - t; + if (len < t) { + memcpy(p, buf, len); + return; + } + memcpy(p, buf, t); + byteReverse(ctx->in, 16); + MD5Transform(ctx->buf, (unsigned long int *) ctx->in); + buf += t; + len -= t; + } + /* Process data in 64-byte chunks */ + + while (len >= 64) { + memcpy(ctx->in, buf, 64); + byteReverse(ctx->in, 16); + MD5Transform(ctx->buf, (unsigned long int *) ctx->in); + buf += 64; + len -= 64; + } + + /* Handle any remaining bytes of data. */ + + memcpy(ctx->in, buf, len); +} + + +/* + * Final wrapup - pad to 64-byte boundary with the bit pattern + * 1 0* (64-bit count of bits processed, MSB-first) + */ +static void MD5Final(struct MD5Context *ctx, unsigned char *digest) +{ + unsigned long int count; + unsigned char *p; + + /* Compute number of bytes mod 64 */ + count = (ctx->bits[0] >> 3) & 0x3F; + + /* Set the first char of padding to 0x80. This is safe since there is + always at least one byte free */ + p = ctx->in + count; + *p++ = 0x80; + + /* Bytes of padding needed to make 64 bytes */ + count = 64 - 1 - count; + + /* Pad out to 56 mod 64 */ + if (count < 8) { + /* Two lots of padding: Pad the first block to 64 bytes */ + memset(p, 0, count); + byteReverse(ctx->in, 16); + MD5Transform(ctx->buf, (unsigned long int *) ctx->in); + + /* Now fill the next block with 56 bytes */ + memset(ctx->in, 0, 56); + } else { + /* Pad block to 56 bytes */ + memset(p, 0, count - 8); + } + byteReverse(ctx->in, 14); + + /* Append length in bits and transform */ + ((unsigned long int *) ctx->in)[14] = ctx->bits[0]; + ((unsigned long int *) ctx->in)[15] = ctx->bits[1]; + + MD5Transform(ctx->buf, (unsigned long int *) ctx->in); + byteReverse((unsigned char *) ctx->buf, 4); + + if (digest!=NULL) + memcpy(digest, ctx->buf, 16); + //memset(ctx, 0, sizeof(ctx)); /* In case it's sensitive */ +} + + +char *Com_MD5File(const char *fn, int length) +{ + static char final[33] = {"unknown"}; + unsigned char digest[16] = {""}; + fileHandle_t f; + MD5_CTX md5; + char buffer[2048]; + int i; + int filelen = 0; + int r = 0; + int total = 0; + + filelen = FS_FOpenFileRead(fn, &f, qtrue); + if(filelen < 1) { + return final; + } + if(filelen < length || !length) { + length = filelen; + } + + MD5Init(&md5); + for(;;) { + r = FS_Read2(buffer, sizeof(buffer), f); + if(r < 1) + break; + if(r + total > length) + r = length - total; + total += r; + MD5Update(&md5 , (unsigned char *)buffer, r); + if(r < sizeof(buffer) || total >= length) + break; + } + FS_FCloseFile(f); + MD5Final(&md5, digest); + final[0] = '\0'; + for(i = 0; i < 16; i++) { + Q_strcat(final, sizeof(final), va("%02X", digest[i])); + } + return final; +} Index: code/qcommon/qcommon.h =================================================================== --- code/qcommon/qcommon.h (revision 697) +++ code/qcommon/qcommon.h (working copy) @@ -729,6 +729,7 @@ int Com_EventLoop( void ); int Com_Milliseconds( void ); // will be journaled properly unsigned Com_BlockChecksum( const void *buffer, int length ); +char *Com_MD5File(const char *filename, int length); int Com_HashKey(char *string, int maxlen); int Com_Filter(char *filter, char *name, int casesensitive); int Com_FilterPath(char *filter, char *name, int casesensitive); Index: code/client/cl_main.c =================================================================== --- code/client/cl_main.c (revision 697) +++ code/client/cl_main.c (working copy) @@ -2378,6 +2378,28 @@ CL_CloseAVI( ); } +static void CL_GenerateQKey(void) +{ + int len = 0; + unsigned char buff[2048]; + + len = FS_ReadFile(QKEY_FILE, NULL); + if(len >= (int)sizeof(buff)) { + Com_Printf("QKEY found.\n"); + return; + } + else { + int i; + srand(time(0)); + for(i = 0; i < sizeof(buff) - 1; i++) { + buff[i] = (unsigned char)(rand() % 255); + } + buff[i] = 0; + Com_Printf("QKEY generated\n"); + FS_WriteFile(QKEY_FILE, buff, sizeof(buff)); + } +} + /* ==================== CL_Init @@ -2526,6 +2548,9 @@ Cvar_Set( "cl_running", "1" ); + CL_GenerateQKey(); + Cvar_Get("cl_guid", Com_MD5File(QKEY_FILE, 0), CVAR_USERINFO | CVAR_ROM); + Com_Printf( "----- Client Initialization Complete -----\n" ); } Index: code/client/client.h =================================================================== --- code/client/client.h (revision 697) +++ code/client/client.h (working copy) @@ -30,6 +30,9 @@ #include "../cgame/cg_public.h" #include "../game/bg_public.h" +// tjw: file full of random crap that gets used to create cl_guid +#define QKEY_FILE "qkey" + #define RETRANSMIT_TIMEOUT 3000 // time between connection packet retransmits Index: Makefile =================================================================== --- Makefile (revision 697) +++ Makefile (working copy) @@ -779,6 +779,7 @@ $(B)/client/cvar.o \ $(B)/client/files.o \ $(B)/client/md4.o \ + $(B)/client/md5.o \ $(B)/client/msg.o \ $(B)/client/net_chan.o \ $(B)/client/huffman.o \ @@ -1029,6 +1030,7 @@ $(B)/client/cvar.o : $(CMDIR)/cvar.c; $(DO_CC) $(B)/client/files.o : $(CMDIR)/files.c; $(DO_CC) $(B)/client/md4.o : $(CMDIR)/md4.c; $(DO_CC) +$(B)/client/md5.o : $(CMDIR)/md5.c; $(DO_CC) $(B)/client/msg.o : $(CMDIR)/msg.c; $(DO_CC) $(B)/client/net_chan.o : $(CMDIR)/net_chan.c; $(DO_CC) $(B)/client/huffman.o : $(CMDIR)/huffman.c; $(DO_CC) From ludwig.nussel at suse.de Mon Apr 10 19:14:45 2006 From: ludwig.nussel at suse.de (Ludwig Nussel) Date: Tue, 11 Apr 2006 01:14:45 +0200 Subject: [quake3] [PATCH] cl_guid In-Reply-To: <20060410210700.GC2900@morbo.webteam.net> References: <20060410210700.GC2900@morbo.webteam.net> Message-ID: <200604110114.45805.ludwig.nussel@suse.de> Tony J. White wrote: > [...] > On startup, the client engine looks for a file called qkey. If it does > not exist, 2KiB worth of random binary data is inserted into the qkey file. > A MD5 digest is then made of the qkey file and it is inserted into the > cl_guid cvar. This is essentially the same way it works on ET except that > pb uses some other secret voodoo to hide how it comes up with the MD5 digest. What about directly storing the hex representation of 16 random bytes in the cvar instead of hashing 2k using MD5? cu Ludwig -- (o_ Ludwig Nussel //\ SUSE LINUX Products GmbH, Development V_/_ http://www.suse.de/ From tjw at webteam.net Mon Apr 10 20:47:16 2006 From: tjw at webteam.net (Tony J. White) Date: Mon, 10 Apr 2006 19:47:16 -0500 Subject: [quake3] [PATCH] cl_guid In-Reply-To: <200604110114.45805.ludwig.nussel@suse.de> References: <20060410210700.GC2900@morbo.webteam.net> <200604110114.45805.ludwig.nussel@suse.de> Message-ID: <20060411004716.GD2900@morbo.webteam.net> On Tue, Apr 11, 2006 at 01:14:45AM +0200, Ludwig Nussel wrote: > Tony J. White wrote: > > [...] > > On startup, the client engine looks for a file called qkey. If it does > > not exist, 2KiB worth of random binary data is inserted into the qkey file. > > A MD5 digest is then made of the qkey file and it is inserted into the > > cl_guid cvar. This is essentially the same way it works on ET except that > > pb uses some other secret voodoo to hide how it comes up with the MD5 digest. > > What about directly storing the hex representation of 16 random > bytes in the cvar instead of hashing 2k using MD5? There needs to be a way of preventing the user from setting their own MD5 to whatever they want or there will be a bunch of players with the cl_guid of 0000000000000000000000000B00B135. Or a malicious server admin could collect the guids of his players who may have admin rights on other servers to impersonate them. Of course it would be possible to build your own ioq3 client with that cl_guid hardcoded, but this at least prevents casual abuse. To counter this, it would be possible for the client to send the contents of the qkey to the server on request so the hash can be validated (which I believe pb also does). I have not looked into the specifics of this though and such a think could always be added later as an enhancement. -Tony From tjw at webteam.net Tue Apr 11 11:48:17 2006 From: tjw at webteam.net (Tony J. White) Date: Tue, 11 Apr 2006 10:48:17 -0500 Subject: [quake3] [PATCH] Mac OSX support In-Reply-To: <443AC5B6.7030401@icculus.org> References: <20060410182409.GX2900@morbo.webteam.net> <16B41F51-3BC2-4766-A1DA-ECA498232CA1@mac.com> <20060410183907.GZ2900@morbo.webteam.net> <443AA83D.9080109@icculus.org> <72D77E4E-BBAB-40E1-AD51-537AF9D93028@mac.com> <443AC5B6.7030401@icculus.org> Message-ID: <20060411154817.GF2900@morbo.webteam.net> On Mon, Apr 10, 2006 at 04:53:10PM -0400, Ryan C. Gordon wrote: > > > I seem to > >remember some code in an older Darwin that did dlopen(). Either that or > >someone wrote some stub code for dlopen(). > > Probably dlcompat, which is what SDL uses internally. > > http://www.opendarwin.org/projects/dlcompat/ I just now noticed you added dlcompat to the SDL CVS version. Now I understand why ioq3 was trying to load .dylib files directly (instead of through .bundles). Forget about all portions of my patch except the crashing fix to 'code/unix/unix_net.c' for now. I will focus on building against the CVS version of libSDL. The src/libs/macosx/libSDL-1.2.0.dylib file should still be removed since it does not seem to support SDL_LoadObject() anyway. -Tony From auerswal at unix-ag.uni-kl.de Tue Apr 11 18:45:26 2006 From: auerswal at unix-ag.uni-kl.de (Erik Auerswald) Date: Wed, 12 Apr 2006 00:45:26 +0200 Subject: [PATCH] cl_guid In-Reply-To: <20060410210700.GC2900@morbo.webteam.net> References: <20060410210700.GC2900@morbo.webteam.net> Message-ID: <20060411224526.GC22586@sushi.unix-ag.uni-kl.de> Hi, On Mon, Apr 10, 2006 at 04:07:00PM -0500, Tony J. White wrote: > How does it work? > > On startup, the client engine looks for a file called qkey. At first I thought the patch would actually use the CD key required by Quake 3 and saved in the file "q3key"... To state the obvious: this cl_guid will be different from from the cl_guid used by the punkbuster enabled id software version of Quake 3 and not at all related to the CD key. > Index: code/qcommon/md5.c > [...] FWIW the patch works for me (linux/x86). Erik From tjw at webteam.net Wed Apr 12 10:05:56 2006 From: tjw at webteam.net (Tony J. White) Date: Wed, 12 Apr 2006 09:05:56 -0500 Subject: [quake3] Re: [PATCH] cl_guid In-Reply-To: <20060411224526.GC22586@sushi.unix-ag.uni-kl.de> References: <20060410210700.GC2900@morbo.webteam.net> <20060411224526.GC22586@sushi.unix-ag.uni-kl.de> Message-ID: <20060412140556.GH2900@morbo.webteam.net> On Wed, Apr 12, 2006 at 12:45:26AM +0200, Erik Auerswald wrote: > > On startup, the client engine looks for a file called qkey. > > At first I thought the patch would actually use the CD key required by > Quake 3 and saved in the file "q3key"... To state the obvious: this > cl_guid will be different from from the cl_guid used by the punkbuster > enabled id software version of Quake 3 and not at all related to the CD > key. Perhaps calling the random file "qkey" will cause confusion. I don't know what to renamed it to though. > > Index: code/qcommon/md5.c > > [...] > > FWIW the patch works for me (linux/x86). I've also verified it works on win32, and OSX ppc (which is the real test). -Tony From icculus at icculus.org Wed Apr 12 12:38:17 2006 From: icculus at icculus.org (Ryan C. Gordon) Date: Wed, 12 Apr 2006 12:38:17 -0400 Subject: Mac retail disc? Message-ID: <443D2CF9.2000406@icculus.org> Does someone have the retail disc from the Mac version of the game? I need a listing of the directory contents so I can see how the data files were laid out on the disc. Thanks, --ryan. From ben at zygoat.ca Wed Apr 12 13:00:29 2006 From: ben at zygoat.ca (Ben Kennedy) Date: Wed, 12 Apr 2006 13:00:29 -0400 Subject: [quake3] Mac retail disc? In-Reply-To: <443D2CF9.2000406@icculus.org> References: <443D2CF9.2000406@icculus.org> Message-ID: <20060412170029.6005@mail.zygoat.ca> Ryan C. Gordon wrote at 12:38 PM (-0400) on 4/12/06: >Does someone have the retail disc from the Mac version of the game? I >need a listing of the directory contents so I can see how the data files >were laid out on the disc. Sure thing: g5-en0:~ ben$ ls -laR /Volumes/Q3A total 1512 drwxr-xr-x 14 ben staff 476 Dec 22 1999 . drwxrwxrwt 4 root admin 136 Apr 12 12:58 .. -rwxr-xr-x 1 ben staff 49152 Dec 20 1999 AppleShare PDS -rwxr-xr-x 1 ben staff 49152 Dec 22 1999 Desktop DB -rwxr-xr-x 1 ben staff 170978 Dec 22 1999 Desktop DF drwxr-xr-x 2 ben staff 68 Dec 21 1999 Desktop Folder -rwxr-xr-x 1 ben staff 0 Dec 20 1999 DesktopPrinters DB -rwxr-xr-x 1 ben staff 0 Dec 20 1999 Icon? -rwxr-xr-x 1 ben staff 0 Dec 22 1999 OpenFolderListDF? drwxr-xr-x 6 ben staff 204 Nov 17 1999 OpenGL Install -rwxr-xr-x 1 ben staff 7068 Dec 21 1999 Quake 3 Arena Install -rwxr-xr-x 1 ben staff 0 Dec 22 1999 Readme.htm alias drwxr-xr-x 2 ben staff 68 Dec 22 1999 Trash drwxr-xr-x 7 ben staff 238 Dec 22 1999 quake3 /Volumes/Q3A/Desktop Folder: total 0 drwxr-xr-x 2 ben staff 68 Dec 21 1999 . drwxr-xr-x 14 ben staff 476 Dec 22 1999 .. /Volumes/Q3A/OpenGL Install: total 1032 drwxr-xr-x 6 ben staff 204 Nov 17 1999 . drwxr-xr-x 14 ben staff 476 Dec 22 1999 .. -rwxr-xr-x 1 ben staff 0 Nov 2 1999 Install OpenGL -rwxr-xr-x 1 ben staff 0 Aug 15 1997 Installer drwxr-xr-x 3 ben staff 102 Nov 2 1999 OpenGL Parts -rwxr-xr-x 1 ben staff 3709 Oct 29 1999 OpenGL Read Me /Volumes/Q3A/OpenGL Install/OpenGL Parts: total 7800 drwxr-xr-x 3 ben staff 102 Nov 2 1999 . drwxr-xr-x 6 ben staff 204 Nov 17 1999 .. -rwxr-xr-x 1 ben staff 3980163 Nov 2 1999 Tome /Volumes/Q3A/Trash: total 0 drwxr-xr-x 2 ben staff 68 Dec 22 1999 . drwxr-xr-x 14 ben staff 476 Dec 22 1999 .. /Volumes/Q3A/quake3: total 1800 drwxr-xr-x 7 ben staff 238 Dec 22 1999 . drwxr-xr-x 14 ben staff 476 Dec 22 1999 .. -rwxr-xr-x 1 ben staff 9344 Dec 17 1999 EULA drwxr-xr-x 10 ben staff 340 Dec 17 1999 Extras -rwxr-xr-x 1 ben staff 196 Dec 21 1999 Joystick Users ReadME -rwxr-xr-x 1 ben staff 859711 Dec 22 1999 MacQuake3 drwxr-xr-x 3 ben staff 102 Dec 17 1999 baseq3 /Volumes/Q3A/quake3/Extras: total 168 drwxr-xr-x 10 ben staff 340 Dec 17 1999 . drwxr-xr-x 7 ben staff 238 Dec 22 1999 .. -rwxr-xr-x 1 ben staff 0 Dec 15 1999 Announcements & News -rwxr-xr-x 1 ben staff 0 Dec 15 1999 Challenge Ladders & Leagues -rwxr-xr-x 1 ben staff 0 Dec 15 1999 Discussion Forums -rwxr-xr-x 1 ben staff 0 Dec 15 1999 Events & Tournaments drwxr-xr-x 14 ben staff 476 Dec 22 1999 Help -rwxr-xr-x 1 ben staff 0 Dec 15 1999 Mplayer -rwxr-xr-x 1 ben staff 0 Dec 15 1999 Stats -rwxr-xr-x 1 ben staff 0 Dec 15 1999 Team (Clan) Listings /Volumes/Q3A/quake3/Extras/Help: total 528 drwxr-xr-x 14 ben staff 476 Dec 22 1999 . drwxr-xr-x 10 ben staff 340 Dec 17 1999 .. -rwxr-xr-x 1 ben staff 44352 Nov 22 1999 BotCommands.htm -rwxr-xr-x 1 ben staff 26168 Dec 17 1999 Dedicated Server.htm drwxr-xr-x 5 ben staff 170 Dec 17 1999 DocsArt -rwxr-xr-x 1 ben staff 1929 Nov 21 1999 Index.htm drwxr-xr-x 5 ben staff 170 Dec 17 1999 Manual -rwxr-xr-x 1 ben staff 42302 Nov 22 1999 Q3A Comm_expl.rtf -rwxr-xr-x 1 ben staff 28193 Nov 20 1999 Q3A EULA.htm -rwxr-xr-x 1 ben staff 14632 Nov 20 1999 Q3A EULA.txt -rwxr-xr-x 1 ben staff 13477 Nov 22 1999 Q3A License Explanation.rtf -rwxr-xr-x 1 ben staff 9344 Dec 17 1999 Readme.htm drwxr-xr-x 6 ben staff 204 Dec 17 1999 Support -rwxr-xr-x 1 ben staff 204 Dec 22 1999 anet /Volumes/Q3A/quake3/Extras/Help/DocsArt: total 120 drwxr-xr-x 5 ben staff 170 Dec 17 1999 . drwxr-xr-x 14 ben staff 476 Dec 22 1999 .. -rwxr-xr-x 1 ben staff 11762 Nov 20 1999 Header.jpg -rwxr-xr-x 1 ben staff 20102 Nov 21 1999 fast1.jpg -rwxr-xr-x 1 ben staff 21919 Nov 21 1999 fast2.jpg /Volumes/Q3A/quake3/Extras/Help/Manual: total 24 drwxr-xr-x 5 ben staff 170 Dec 17 1999 . drwxr-xr-x 14 ben staff 476 Dec 22 1999 .. drwxr-xr-x 20 ben staff 680 Dec 17 1999 htmlpages -rwxr-xr-x 1 ben staff 506 Nov 21 1999 index.html drwxr-xr-x 39 ben staff 1326 Dec 17 1999 navart /Volumes/Q3A/quake3/Extras/Help/Manual/htmlpages: total 936 drwxr-xr-x 20 ben staff 680 Dec 17 1999 . drwxr-xr-x 5 ben staff 170 Dec 17 1999 .. -rwxr-xr-x 1 ben staff 57992 Nov 21 1999 arena.html -rwxr-xr-x 1 ben staff 11438 Nov 21 1999 arenaa.html -rwxr-xr-x 1 ben staff 30696 Nov 20 1999 arenae.html -rwxr-xr-x 1 ben staff 24240 Nov 20 1999 arenaf.html -rwxr-xr-x 1 ben staff 12204 Nov 21 1999 arenag.html -rwxr-xr-x 1 ben staff 10440 Nov 20 1999 arenah.html -rwxr-xr-x 1 ben staff 13591 Nov 21 1999 arenam.html -rwxr-xr-x 1 ben staff 36656 Nov 20 1999 arenaw.html -rwxr-xr-x 1 ben staff 5920 Nov 21 1999 credits.html -rwxr-xr-x 1 ben staff 7932 Nov 21 1999 customer.html -rwxr-xr-x 1 ben staff 8861 Nov 21 1999 default.html -rwxr-xr-x 1 ben staff 14239 Nov 21 1999 escmenu.html -rwxr-xr-x 1 ben staff 6710 Nov 21 1999 installation.html -rwxr-xr-x 1 ben staff 21540 Nov 21 1999 main.html -rwxr-xr-x 1 ben staff 37893 Nov 21 1999 mainm.html -rwxr-xr-x 1 ben staff 83136 Nov 21 1999 mains.html -rwxr-xr-x 1 ben staff 8885 Nov 20 1999 navigate.html -rwxr-xr-x 1 ben staff 6427 Nov 21 1999 overview.html /Volumes/Q3A/quake3/Extras/Help/Manual/navart: total 936 drwxr-xr-x 39 ben staff 1326 Dec 17 1999 . drwxr-xr-x 5 ben staff 170 Dec 17 1999 .. drwxr-xr-x 34 ben staff 1156 Dec 17 1999 charart -rwxr-xr-x 1 ben staff 7928 Nov 17 1999 cornerlogo.jpg -rwxr-xr-x 1 ben staff 33424 Nov 18 1999 cover.jpg -rwxr-xr-x 1 ben staff 1566 Nov 17 1999 nav_01_dn.gif -rwxr-xr-x 1 ben staff 2585 Nov 17 1999 nav_01_up.gif -rwxr-xr-x 1 ben staff 1551 Nov 17 1999 nav_02_dn.gif -rwxr-xr-x 1 ben staff 2434 Nov 17 1999 nav_02_up.gif -rwxr-xr-x 1 ben staff 1957 Nov 17 1999 nav_03_dn.gif -rwxr-xr-x 1 ben staff 3042 Nov 17 1999 nav_03_up.gif -rwxr-xr-x 1 ben staff 1397 Nov 17 1999 nav_04_dn.gif -rwxr-xr-x 1 ben staff 2195 Nov 17 1999 nav_04_up.gif -rwxr-xr-x 1 ben staff 1236 Nov 17 1999 nav_05_dn.gif -rwxr-xr-x 1 ben staff 1948 Nov 17 1999 nav_05_up.gif -rwxr-xr-x 1 ben staff 1632 Nov 18 1999 nav_06_dn.gif -rwxr-xr-x 1 ben staff 2438 Nov 18 1999 nav_06_up.gif -rwxr-xr-x 1 ben staff 1705 Nov 17 1999 nav_07_dn.gif -rwxr-xr-x 1 ben staff 2747 Nov 17 1999 nav_07_up.gif -rwxr-xr-x 1 ben staff 1079 Nov 17 1999 nav_08_dn.gif -rwxr-xr-x 1 ben staff 1573 Nov 17 1999 nav_08_up.gif drwxr-xr-x 36 ben staff 1224 Dec 17 1999 screens -rwxr-xr-x 1 ben staff 10877 Nov 17 1999 sidebar.jpg -rwxr-xr-x 1 ben staff 6246 Nov 18 1999 sidebarb.jpg -rwxr-xr-x 1 ben staff 6361 Nov 18 1999 sidebarg.jpg -rwxr-xr-x 1 ben staff 4714 Nov 18 1999 space.jpg -rwxr-xr-x 1 ben staff 6453 Nov 17 1999 subcatline.jpg -rwxr-xr-x 1 ben staff 9635 Nov 17 1999 subtfrag.jpg drwxr-xr-x 48 ben staff 1632 Dec 17 1999 subtitles -rwxr-xr-x 1 ben staff 13709 Nov 18 1999 titlearena.jpg -rwxr-xr-x 1 ben staff 10043 Nov 18 1999 titlecred.jpg -rwxr-xr-x 1 ben staff 15186 Nov 18 1999 titlecust.jpg -rwxr-xr-x 1 ben staff 13796 Nov 18 1999 titledef.jpg -rwxr-xr-x 1 ben staff 10423 Nov 18 1999 titleesc.jpg -rwxr-xr-x 1 ben staff 12257 Nov 18 1999 titleinstall.jpg -rwxr-xr-x 1 ben staff 9461 Nov 17 1999 titleline.jpg -rwxr-xr-x 1 ben staff 11739 Nov 18 1999 titlemain.jpg -rwxr-xr-x 1 ben staff 13370 Nov 17 1999 titleover.jpg drwxr-xr-x 50 ben staff 1700 Dec 17 1999 weapons /Volumes/Q3A/quake3/Extras/Help/Manual/navart/charart: total 1008 drwxr-xr-x 34 ben staff 1156 Dec 17 1999 . drwxr-xr-x 39 ben staff 1326 Dec 17 1999 .. -rwxr-xr-x 1 ben staff 11166 Nov 18 1999 Anarki.jpg -rwxr-xr-x 1 ben staff 11186 Nov 18 1999 Angel.jpg -rwxr-xr-x 1 ben staff 12104 Nov 18 1999 Biker.jpg -rwxr-xr-x 1 ben staff 9063 Nov 20 1999 Bitterman.jpg -rwxr-xr-x 1 ben staff 10081 Nov 20 1999 Bones.jpg -rwxr-xr-x 1 ben staff 13371 Nov 18 1999 Cadavre.jpg -rwxr-xr-x 1 ben staff 9759 Nov 20 1999 Crash.jpg -rwxr-xr-x 1 ben staff 10237 Nov 18 1999 Daemia.jpg -rwxr-xr-x 1 ben staff 12705 Nov 18 1999 Doom.jpg -rwxr-xr-x 1 ben staff 12110 Nov 18 1999 Gorre.jpg -rwxr-xr-x 1 ben staff 12160 Nov 18 1999 Grunt.jpg -rwxr-xr-x 1 ben staff 11625 Nov 18 1999 Hossman.jpg -rwxr-xr-x 1 ben staff 9840 Nov 18 1999 Hunter.jpg -rwxr-xr-x 1 ben staff 12963 Nov 18 1999 Keel.jpg -rwxr-xr-x 1 ben staff 11755 Nov 18 1999 Klesk.jpg -rwxr-xr-x 1 ben staff 12129 Nov 18 1999 Lucy.jpg -rwxr-xr-x 1 ben staff 10759 Nov 18 1999 Major.jpg -rwxr-xr-x 1 ben staff 9097 Nov 18 1999 Mynx.jpg -rwxr-xr-x 1 ben staff 11782 Nov 18 1999 Orbb.jpg -rwxr-xr-x 1 ben staff 11038 Nov 18 1999 Patriot.jpg -rwxr-xr-x 1 ben staff 12675 Nov 18 1999 Phobos.jpg -rwxr-xr-x 1 ben staff 12558 Nov 18 1999 Ranger.jpg -rwxr-xr-x 1 ben staff 12155 Nov 18 1999 Razor.jpg -rwxr-xr-x 1 ben staff 11481 Nov 18 1999 Sarge.jpg -rwxr-xr-x 1 ben staff 10745 Nov 18 1999 Slash.jpg -rwxr-xr-x 1 ben staff 14427 Nov 18 1999 Sorlag.jpg -rwxr-xr-x 1 ben staff 13946 Nov 18 1999 Stripe.jpg -rwxr-xr-x 1 ben staff 15821 Nov 18 1999 Tankjr.jpg -rwxr-xr-x 1 ben staff 11999 Nov 18 1999 Uriel.jpg -rwxr-xr-x 1 ben staff 10841 Nov 18 1999 Visor.jpg -rwxr-xr-x 1 ben staff 12496 Nov 18 1999 Wrack.jpg -rwxr-xr-x 1 ben staff 12738 Nov 18 1999 Xaero.jpg /Volumes/Q3A/quake3/Extras/Help/Manual/navart/screens: total 1128 drwxr-xr-x 36 ben staff 1224 Dec 17 1999 . drwxr-xr-x 39 ben staff 1326 Dec 17 1999 .. -rwxr-xr-x 1 ben staff 5786 Nov 18 1999 acceler_l.jpg -rwxr-xr-x 1 ben staff 5369 Nov 18 1999 acceler_r.jpg -rwxr-xr-x 1 ben staff 4664 Nov 18 1999 bounce_l.jpg -rwxr-xr-x 1 ben staff 5053 Nov 18 1999 bounce_r.jpg -rwxr-xr-x 1 ben staff 14203 Nov 20 1999 captureflag.jpg -rwxr-xr-x 1 ben staff 14961 Nov 20 1999 controls.jpg -rwxr-xr-x 1 ben staff 13029 Nov 20 1999 create.jpg -rwxr-xr-x 1 ben staff 5633 Nov 18 1999 doors_l.jpg -rwxr-xr-x 1 ben staff 4226 Nov 18 1999 doors_r.jpg -rwxr-xr-x 1 ben staff 16668 Nov 20 1999 escmenu.jpg -rwxr-xr-x 1 ben staff 3049 Nov 18 1999 fog_l.jpg -rwxr-xr-x 1 ben staff 3591 Nov 18 1999 fog_r.jpg -rwxr-xr-x 1 ben staff 3741 Nov 18 1999 fogdeath.jpg -rwxr-xr-x 1 ben staff 17750 Nov 20 1999 freeforall.jpg -rwxr-xr-x 1 ben staff 13404 Nov 20 1999 gameoptions.jpg -rwxr-xr-x 1 ben staff 4139 Nov 18 1999 gates.jpg -rwxr-xr-x 1 ben staff 15267 Nov 20 1999 graphics.jpg -rwxr-xr-x 1 ben staff 5916 Nov 18 1999 lava_l.jpg -rwxr-xr-x 1 ben staff 5852 Nov 18 1999 lava_r.jpg -rwxr-xr-x 1 ben staff 3519 Nov 18 1999 lift.jpg -rwxr-xr-x 1 ben staff 16354 Nov 20 1999 multiplayer.jpg -rwxr-xr-x 1 ben staff 5074 Nov 18 1999 pendulum.jpg -rwxr-xr-x 1 ben staff 4458 Nov 18 1999 platform.jpg -rwxr-xr-x 1 ben staff 14539 Nov 20 1999 playerset.jpg -rwxr-xr-x 1 ben staff 13133 Nov 20 1999 setup.jpg -rwxr-xr-x 1 ben staff 12180 Nov 20 1999 singleplayer.jpg -rwxr-xr-x 1 ben staff 12578 Nov 20 1999 skirmish.jpg -rwxr-xr-x 1 ben staff 4222 Nov 18 1999 slime.jpg -rwxr-xr-x 1 ben staff 16275 Nov 20 1999 teamdeath.jpg -rwxr-xr-x 1 ben staff 4620 Nov 18 1999 teleport.jpg -rwxr-xr-x 1 ben staff 16933 Nov 20 1999 tourney.jpg -rwxr-xr-x 1 ben staff 5266 Nov 18 1999 trigger.jpg -rwxr-xr-x 1 ben staff 3814 Nov 18 1999 voids.jpg -rwxr-xr-x 1 ben staff 6676 Nov 18 1999 water.jpg /Volumes/Q3A/quake3/Extras/Help/Manual/navart/subtitles: total 1104 drwxr-xr-x 48 ben staff 1632 Dec 17 1999 . drwxr-xr-x 39 ben staff 1326 Dec 17 1999 .. -rwxr-xr-x 1 ben staff 9517 Nov 20 1999 subarena.jpg -rwxr-xr-x 1 ben staff 6937 Nov 18 1999 subarmor.jpg -rwxr-xr-x 1 ben staff 8513 Nov 18 1999 subcarri.jpg -rwxr-xr-x 1 ben staff 8940 Nov 20 1999 subchoose.jpg -rwxr-xr-x 1 ben staff 7903 Nov 18 1999 subcontr.jpg -rwxr-xr-x 1 ben staff 8658 Nov 20 1999 subcontrol.jpg -rwxr-xr-x 1 ben staff 9615 Nov 20 1999 subcopy.jpg -rwxr-xr-x 1 ben staff 6867 Nov 18 1999 subdemo.jpg -rwxr-xr-x 1 ben staff 9168 Nov 18 1999 subenviro.jpg -rwxr-xr-x 1 ben staff 6375 Nov 18 1999 subflags.jpg -rwxr-xr-x 1 ben staff 8848 Nov 18 1999 subgame.jpg -rwxr-xr-x 1 ben staff 8879 Nov 20 1999 subgamg.jpg -rwxr-xr-x 1 ben staff 7958 Nov 18 1999 subglad.jpg -rwxr-xr-x 1 ben staff 9524 Nov 18 1999 subgraph.jpg -rwxr-xr-x 1 ben staff 6704 Nov 18 1999 subheal.jpg -rwxr-xr-x 1 ben staff 8809 Nov 18 1999 subhost.jpg -rwxr-xr-x 1 ben staff 9161 Nov 18 1999 subinaust.jpg -rwxr-xr-x 1 ben staff 9722 Nov 18 1999 subinter.jpg -rwxr-xr-x 1 ben staff 7500 Nov 18 1999 subintheus.jpg -rwxr-xr-x 1 ben staff 6613 Nov 18 1999 subitems.jpg -rwxr-xr-x 1 ben staff 8833 Nov 18 1999 subjoin.jpg -rwxr-xr-x 1 ben staff 8055 Nov 18 1999 subleave.jpg -rwxr-xr-x 1 ben staff 6275 Nov 18 1999 sublook.jpg -rwxr-xr-x 1 ben staff 6559 Nov 18 1999 sublook02.jpg -rwxr-xr-x 1 ben staff 7179 Nov 20 1999 submedal.jpg -rwxr-xr-x 1 ben staff 6300 Nov 18 1999 submisc.jpg -rwxr-xr-x 1 ben staff 6558 Nov 18 1999 submisc02.jpg -rwxr-xr-x 1 ben staff 6323 Nov 18 1999 submove.jpg -rwxr-xr-x 1 ben staff 6580 Nov 18 1999 submove02.jpg -rwxr-xr-x 1 ben staff 8468 Nov 20 1999 submulti.jpg -rwxr-xr-x 1 ben staff 8638 Nov 18 1999 subnews.jpg -rwxr-xr-x 1 ben staff 10510 Nov 18 1999 subplayer.jpg -rwxr-xr-x 1 ben staff 6883 Nov 18 1999 subplayer02.jpg -rwxr-xr-x 1 ben staff 7867 Nov 18 1999 subpower.jpg -rwxr-xr-x 1 ben staff 6624 Nov 18 1999 subquit.jpg -rwxr-xr-x 1 ben staff 6744 Nov 18 1999 subquit02.jpg -rwxr-xr-x 1 ben staff 8994 Nov 18 1999 subreset.jpg -rwxr-xr-x 1 ben staff 7165 Nov 18 1999 subserve.jpg -rwxr-xr-x 1 ben staff 7945 Nov 20 1999 subsetup.jpg -rwxr-xr-x 1 ben staff 6597 Nov 18 1999 subshoot.jpg -rwxr-xr-x 1 ben staff 7042 Nov 18 1999 subshoot02.jpg -rwxr-xr-x 1 ben staff 8767 Nov 18 1999 subsing.jpg -rwxr-xr-x 1 ben staff 7038 Nov 18 1999 subsyst.jpg -rwxr-xr-x 1 ben staff 6498 Nov 18 1999 subteam.jpg -rwxr-xr-x 1 ben staff 8712 Nov 17 1999 subtstruct.jpg -rwxr-xr-x 1 ben staff 7100 Nov 18 1999 subweap.jpg /Volumes/Q3A/quake3/Extras/Help/Manual/navart/weapons: total 1152 drwxr-xr-x 50 ben staff 1700 Dec 17 1999 . drwxr-xr-x 39 ben staff 1326 Dec 17 1999 .. -rwxr-xr-x 1 ben staff 8716 Nov 18 1999 BFG-10K.jpg -rwxr-xr-x 1 ben staff 9869 Nov 18 1999 Railg.jpg -rwxr-xr-x 1 ben staff 10836 Nov 18 1999 armorcombat.jpg -rwxr-xr-x 1 ben staff 9339 Nov 18 1999 armorheavy.jpg -rwxr-xr-x 1 ben staff 7965 Nov 18 1999 armorshard.jpg -rwxr-xr-x 1 ben staff 8736 Nov 18 1999 battles.jpg -rwxr-xr-x 1 ben staff 7582 Nov 18 1999 bfg-10ka.jpg -rwxr-xr-x 1 ben staff 7048 Nov 18 1999 bfg-10kh.jpg -rwxr-xr-x 1 ben staff 6404 Nov 18 1999 blue.jpg -rwxr-xr-x 1 ben staff 8764 Nov 18 1999 flight.jpg -rwxr-xr-x 1 ben staff 8349 Nov 18 1999 gauntlet.jpg -rwxr-xr-x 1 ben staff 7217 Nov 18 1999 grenadea.jpg -rwxr-xr-x 1 ben staff 6424 Nov 18 1999 grenadeh.jpg -rwxr-xr-x 1 ben staff 8523 Nov 18 1999 grenadel.jpg -rwxr-xr-x 1 ben staff 8724 Nov 18 1999 haste.jpg -rwxr-xr-x 1 ben staff 9970 Nov 21 1999 healthgld.jpg -rwxr-xr-x 1 ben staff 10306 Nov 18 1999 healthgrn.jpg -rwxr-xr-x 1 ben staff 10412 Nov 18 1999 healthyelo.jpg -rwxr-xr-x 1 ben staff 6997 Nov 18 1999 invisib.jpg -rwxr-xr-x 1 ben staff 7379 Nov 18 1999 lightinga.jpg -rwxr-xr-x 1 ben staff 8814 Nov 18 1999 lightingg.jpg -rwxr-xr-x 1 ben staff 6823 Nov 18 1999 lightningh.jpg -rwxr-xr-x 1 ben staff 7462 Nov 18 1999 machinea.jpg -rwxr-xr-x 1 ben staff 9096 Nov 18 1999 machineg.jpg -rwxr-xr-x 1 ben staff 7355 Nov 18 1999 machineh.jpg -rwxr-xr-x 1 ben staff 5632 Nov 20 1999 medacc.jpg -rwxr-xr-x 1 ben staff 5882 Nov 20 1999 medexce.jpg -rwxr-xr-x 1 ben staff 5688 Nov 20 1999 medfrag.jpg -rwxr-xr-x 1 ben staff 5836 Nov 20 1999 medgua.jpg -rwxr-xr-x 1 ben staff 5734 Nov 20 1999 medimpr.jpg -rwxr-xr-x 1 ben staff 6982 Nov 18 1999 medkit.jpg -rwxr-xr-x 1 ben staff 5752 Nov 20 1999 medperf.jpg -rwxr-xr-x 1 ben staff 7984 Nov 18 1999 megaheal.jpg -rwxr-xr-x 1 ben staff 7468 Nov 18 1999 plasmaa.jpg -rwxr-xr-x 1 ben staff 10393 Nov 18 1999 plasmag.jpg -rwxr-xr-x 1 ben staff 7075 Nov 18 1999 plasmah.jpg -rwxr-xr-x 1 ben staff 8233 Nov 18 1999 quaddam.jpg -rwxr-xr-x 1 ben staff 7728 Nov 18 1999 raila.jpg -rwxr-xr-x 1 ben staff 7566 Nov 18 1999 railh.jpg -rwxr-xr-x 1 ben staff 6832 Nov 18 1999 red.jpg -rwxr-xr-x 1 ben staff 8524 Nov 18 1999 regen.jpg -rwxr-xr-x 1 ben staff 7229 Nov 18 1999 rocketa.jpg -rwxr-xr-x 1 ben staff 6763 Nov 18 1999 rocketh.jpg -rwxr-xr-x 1 ben staff 8771 Nov 18 1999 rocketl.jpg -rwxr-xr-x 1 ben staff 8232 Nov 18 1999 shotg.jpg -rwxr-xr-x 1 ben staff 7341 Nov 18 1999 shotguna.jpg -rwxr-xr-x 1 ben staff 7194 Nov 18 1999 shotgunh.jpg -rwxr-xr-x 1 ben staff 7327 Nov 18 1999 teleport.jpg /Volumes/Q3A/quake3/Extras/Help/Support: total 48 drwxr-xr-x 6 ben staff 204 Dec 17 1999 . drwxr-xr-x 14 ben staff 476 Dec 22 1999 .. -rwxr-xr-x 1 ben staff 86 Oct 9 1999 Activision Support.url drwxr-xr-x 11 ben staff 374 Dec 17 1999 Customer Support -rwxr-xr-x 1 ben staff 923 Dec 17 1999 Index.htm drwxr-xr-x 10 ben staff 340 Dec 17 1999 Information /Volumes/Q3A/quake3/Extras/Help/Support/Customer Support: total 216 drwxr-xr-x 11 ben staff 374 Dec 17 1999 . drwxr-xr-x 6 ben staff 204 Dec 17 1999 .. -rwxr-xr-x 1 ben staff 851 Nov 21 1999 CS_Australia_and_NZ.htm -rwxr-xr-x 1 ben staff 1312 Nov 21 1999 CS_Latin_America.htm -rwxr-xr-x 1 ben staff 876 Nov 21 1999 CS_North_America.htm -rwxr-xr-x 1 ben staff 3568 Nov 21 1999 CS__UK_and_Europe.htm -rwxr-xr-x 1 ben staff 2315 Dec 17 1999 Customer_Support.htm -rwxr-xr-x 1 ben staff 5937 Nov 21 1999 Customer_Support__France.htm -rwxr-xr-x 1 ben staff 4398 Nov 21 1999 Customer_Support__Italy.htm -rwxr-xr-x 1 ben staff 2520 Nov 21 1999 Customer_Support__Spain.htm -rwxr-xr-x 1 ben staff 3750 Nov 21 1999 Kundendienst_in_Deutschland.htm /Volumes/Q3A/quake3/Extras/Help/Support/Information: total 192 drwxr-xr-x 10 ben staff 340 Dec 17 1999 . drwxr-xr-x 6 ben staff 204 Dec 17 1999 .. -rwxr-xr-x 1 ben staff 532 Dec 17 1999 Audio_Problems.htm -rwxr-xr-x 1 ben staff 3077 Nov 22 1999 DirectX.htm -rwxr-xr-x 1 ben staff 988 Nov 21 1999 Electronic_Registration.htm -rwxr-xr-x 1 ben staff 2312 Nov 21 1999 Improving_Performance.htm -rwxr-xr-x 1 ben staff 1602 Dec 17 1999 Minimum_System_Requirements.htm -rwxr-xr-x 1 ben staff 334 Dec 17 1999 Sound_Card_Conflicts.htm -rwxr-xr-x 1 ben staff 899 Nov 21 1999 Updates_and_or_Patches.htm -rwxr-xr-x 1 ben staff 550 Nov 21 1999 compressedHD.htm /Volumes/Q3A/quake3/baseq3: total 936528 drwxr-xr-x 3 ben staff 102 Dec 17 1999 . drwxr-xr-x 7 ben staff 238 Dec 22 1999 .. -rwxr-xr-x 1 ben staff 479493658 Nov 21 1999 pak0.pk3 g5-en0:~ ben$ -b -- Ben Kennedy, chief magician zygoat creative technical services 613-228-3392 | 1-866-466-4628 http:/www.zygoat.ca From auerswal at unix-ag.uni-kl.de Wed Apr 12 15:09:25 2006 From: auerswal at unix-ag.uni-kl.de (Erik Auerswald) Date: Wed, 12 Apr 2006 21:09:25 +0200 Subject: [quake3] Re: [PATCH] cl_guid In-Reply-To: <20060412140556.GH2900@morbo.webteam.net> References: <20060410210700.GC2900@morbo.webteam.net> <20060411224526.GC22586@sushi.unix-ag.uni-kl.de> <20060412140556.GH2900@morbo.webteam.net> Message-ID: <20060412190925.GA13171@sushi.unix-ag.uni-kl.de> Hi, On Wed, Apr 12, 2006 at 09:05:56AM -0500, Tony J. White wrote: > Perhaps calling the random file "qkey" will cause confusion. I don't know > what to renamed it to though. Perhaps something like "guid_seed". But I don't think the name is that important, it might be helpful to mention in the README that it does not use the CD key. > > FWIW the patch works for me (linux/x86). > > I've also verified it works on win32, and OSX ppc (which is the real test). A test on a supported 64bit platform would be nice IMHO. Erik From icculus at icculus.org Wed Apr 12 17:22:16 2006 From: icculus at icculus.org (Ryan C. Gordon) Date: Wed, 12 Apr 2006 17:22:16 -0400 Subject: [quake3] Mac retail disc? In-Reply-To: <20060412170029.6005@mail.zygoat.ca> References: <443D2CF9.2000406@icculus.org> <20060412170029.6005@mail.zygoat.ca> Message-ID: <443D6F88.3030601@icculus.org> >>Does someone have the retail disc from the Mac version of the game? I >>need a listing of the directory contents so I can see how the data files >>were laid out on the disc. > > Sure thing: Wow, that was fast! Thanks! --ryan. From maximinus at gmail.com Thu Apr 13 14:57:37 2006 From: maximinus at gmail.com (Chris Smith) Date: Thu, 13 Apr 2006 14:57:37 -0400 Subject: Starting a new mod Message-ID: Hi. I'm seriously thinking of making a stand-alone game /mod using icculus/q3 as my base. I say seriously because obviously it's no small undertaking. I was just wondering if anyone has any helpful tips, or could point me to any info on the web (doesn't seem to be a lot out there, especially if you're gonna be using gcc/*nix) I've programmed in C++ for the last 10 or so years so I could just look at all that lovely source code, but I was hoping for any kind of shortcut that I could get to get me up and started as fast as possible (low productivity = low drive etc...) Cheers, Chris -- Science is open source religion -------------- next part -------------- An HTML attachment was scrubbed... URL: From only_mortal at mac.com Thu Apr 13 16:02:13 2006 From: only_mortal at mac.com (Mike Davis) Date: Thu, 13 Apr 2006 22:02:13 +0200 Subject: [quake3] Starting a new mod In-Reply-To: References: Message-ID: Take a look at the forums on www.quake3world.com. On 13 Apr 2006, at 20:57, Chris Smith wrote: > Hi. > > I'm seriously thinking of making a stand-alone game /mod using > icculus/q3 as my base. I say seriously because obviously it's no > small undertaking. I was just wondering if anyone has any helpful > tips, or could point me to any info on the web (doesn't seem to be > a lot out there, especially if you're gonna be using gcc/*nix) > > I've programmed in C++ for the last 10 or so years so I could just > look at all that lovely source code, but I was hoping for any kind > of shortcut that I could get to get me up and started as fast as > possible (low productivity = low drive etc...) > > Cheers, Chris > > -- > Science is open source religion From stowellt at gmail.com Thu Apr 13 16:12:54 2006 From: stowellt at gmail.com (Tim Stowell) Date: Thu, 13 Apr 2006 14:12:54 -0600 Subject: [quake3] Starting a new mod In-Reply-To: References: Message-ID: <994f7fe90604131312h32dac2cdp6c208a48c27cd8a3@mail.gmail.com> I find these forums very helpful for programming questions http://www.quakesrc.org/forums/ On 4/13/06, Mike Davis wrote: > > Take a look at the forums on www.quake3world.com. > > On 13 Apr 2006, at 20:57, Chris Smith wrote: > > > Hi. > > > > I'm seriously thinking of making a stand-alone game /mod using > > icculus/q3 as my base. I say seriously because obviously it's no > > small undertaking. I was just wondering if anyone has any helpful > > tips, or could point me to any info on the web (doesn't seem to be > > a lot out there, especially if you're gonna be using gcc/*nix) > > > > I've programmed in C++ for the last 10 or so years so I could just > > look at all that lovely source code, but I was hoping for any kind > > of shortcut that I could get to get me up and started as fast as > > possible (low productivity = low drive etc...) > > > > Cheers, Chris > > > > -- > > Science is open source religion > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bnoordhuis at gmail.com Thu Apr 13 18:39:29 2006 From: bnoordhuis at gmail.com (Ben Noordhuis) Date: Fri, 14 Apr 2006 00:39:29 +0200 Subject: [quake3] Starting a new mod In-Reply-To: <994f7fe90604131312h32dac2cdp6c208a48c27cd8a3@mail.gmail.com> References: <994f7fe90604131312h32dac2cdp6c208a48c27cd8a3@mail.gmail.com> Message-ID: <54885e060604131539r4df5d84fm6f5edcd6fe80e68c@mail.gmail.com> As pointed out by Mike and Tim, http://www.quakesrc.org/forums/ and http://www.quake3world.com/forum/ are the places to go. The former for programming related questions, the latter for player feedback, etc. From ra at ra.is Fri Apr 14 00:56:16 2006 From: ra at ra.is (Richard Allen) Date: Fri, 14 Apr 2006 04:56:16 +0000 Subject: Standalone RQ3 using Icculus Q3 In-Reply-To: <54885e060604131539r4df5d84fm6f5edcd6fe80e68c@mail.gmail.com> References: <994f7fe90604131312h32dac2cdp6c208a48c27cd8a3@mail.gmail.com> <54885e060604131539r4df5d84fm6f5edcd6fe80e68c@mail.gmail.com> Message-ID: <443F2B70.1050709@ra.is> It's been a dream for us in the RQ3 team to finally create a standalone opensource version of our mod. Today I started working on it (I've got 11 days off this easter) :) I only needed to do very minimal changes to the engine to get it to use Reaction as it's default mod. Apart from some UI problems that are most likely our own fault we are now dealing with the fallout of not using ID's pk3's... Turns out our code, maps and models make remarkably much usage of ID's shaders, wav files and so forth. I'm working on Linux and I have not even tried to compile the Win32 or OS X versions yet, but I have noticed some problems with Audio. Sometimes it goes a bit haywire and sounds very strange. I'm using a FC4 system and KDE in a pretty basic setup. Are there any known problems with audio in todays svn code ? Or is this something we're doing wrong ? Thanks in advance... Richard 'JBravo' Allen :) -- Rikki. -- RHCE, RHCX, HP-UX CSA and CSE. -- Solaris 7 Certified Systems and Network Administrator. Bell Labs Unix -- Reach out and grep someone. Those who do not understand Unix are condemned to reinvent it, poorly. From zakk at timedoctor.org Fri Apr 14 18:38:56 2006 From: zakk at timedoctor.org (Zachary J. Slater) Date: Fri, 14 Apr 2006 15:38:56 -0700 Subject: Mac (ppc) Progress! Message-ID: <44402480.5000803@timedoctor.org> Finally, health spheres are rendered correctly! Unfortunately jump pads and other shaders don't appear to animate. -- - Zachary J. Slater zakk at timedoctor.org zacharyslater at gmail.com From windle.poons at arcor.de Sun Apr 16 16:20:48 2006 From: windle.poons at arcor.de (Michael Sauer) Date: Sun, 16 Apr 2006 22:20:48 +0200 Subject: quake3 media replacement project Message-ID: <1145218848.18094.1.camel@vivane> Hi there, is there already a q3 media replacement project for ioquake3 ? mIc From anders at anders1.org Sun Apr 16 16:26:04 2006 From: anders at anders1.org (Anders Bergh) Date: Sun, 16 Apr 2006 22:26:04 +0200 Subject: [quake3] quake3 media replacement project In-Reply-To: <1145218848.18094.1.camel@vivane> References: <1145218848.18094.1.camel@vivane> Message-ID: <976395530604161326r1945b5b0o33dc514b787ec399@mail.gmail.com> I think there is OpenArena, but they are modifying the ID engine... I think it works in ioq3 though. Not sure. Anders On 4/16/06, Michael Sauer wrote: > Hi there, > > is there already a q3 media replacement project for ioquake3 ? > > mIc > > -- Anders From zakk at timedoctor.org Sun Apr 16 19:39:20 2006 From: zakk at timedoctor.org (Zachary J. Slater) Date: Sun, 16 Apr 2006 16:39:20 -0700 Subject: [quake3] quake3 media replacement project In-Reply-To: <1145218848.18094.1.camel@vivane> References: <1145218848.18094.1.camel@vivane> Message-ID: <4442D5A8.2030006@timedoctor.org> Michael Sauer wrote: > Hi there, > > is there already a q3 media replacement project for ioquake3 ? > > mIc None that I endorse. -- - Zachary J. Slater zakk at timedoctor.org zacharyslater at gmail.com From auerswal at unix-ag.uni-kl.de Mon Apr 17 00:47:19 2006 From: auerswal at unix-ag.uni-kl.de (Erik Auerswald) Date: Mon, 17 Apr 2006 06:47:19 +0200 Subject: Standalone RQ3 using Icculus Q3 In-Reply-To: <443F2B70.1050709@ra.is> References: <994f7fe90604131312h32dac2cdp6c208a48c27cd8a3@mail.gmail.com> <54885e060604131539r4df5d84fm6f5edcd6fe80e68c@mail.gmail.com> <443F2B70.1050709@ra.is> Message-ID: <20060417044719.GC13128@sushi.unix-ag.uni-kl.de> Hi, On Fri, Apr 14, 2006 at 04:56:16AM +0000, Richard Allen wrote: > Turns out our code, maps and models make remarkably much usage of ID's > shaders, wav files and so forth. You might want to check out the "Free Texture / Open Media Archive" at https://cat2.dynu.ca/ftoma/index.html > I'm working on Linux and I have not even tried to compile the Win32 or OS X > versions yet, but I have noticed some problems with Audio. > Sometimes it goes a bit haywire and sounds very strange. > I'm using a FC4 system and KDE in a pretty basic setup. Are there any > known problems with audio in todays svn code ? Or is this something we're > doing wrong ? You could try disabling the KDE sound daemon (artsd). Another thing to try is to set the environment variable SDL_AUDIODRIVER to oss or alsa (sometimes the oss emulation of alsa works better than the direcly using alsa). See the audio part of the Linux Gamers' FAQ at http://icculus.org/lgfaq/#audio Erik From stowellt at gmail.com Mon Apr 17 11:12:51 2006 From: stowellt at gmail.com (Tim Stowell) Date: Mon, 17 Apr 2006 09:12:51 -0600 Subject: [quake3] quake3 media replacement project In-Reply-To: <4442D5A8.2030006@timedoctor.org> References: <1145218848.18094.1.camel@vivane> <4442D5A8.2030006@timedoctor.org> Message-ID: <994f7fe90604170812x4c776664tdb76faaf87800053@mail.gmail.com> I have successfully used pak0.pk3 from OpenArena in ioq3, although at the time there were still media files missing that are in the retail pak0. It did allow me to play the game, though. -Tim On 4/16/06, Zachary J. Slater wrote: > > Michael Sauer wrote: > > Hi there, > > > > is there already a q3 media replacement project for ioquake3 ? > > > > mIc > > None that I endorse. > > -- > - Zachary J. Slater > zakk at timedoctor.org > zacharyslater at gmail.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arny at ats.s.bawue.de Mon Apr 17 17:47:49 2006 From: arny at ats.s.bawue.de (Thilo Schulz) Date: Mon, 17 Apr 2006 23:47:49 +0200 Subject: Flares over lightsources Message-ID: <200604172347.59487.arny@ats.s.bawue.de> Hello, I've been working on flares over the last few days and got them to be rendered. IMHO, they add alot of realism to the scene. A patch is available here: http://thilo.kickchat.com/efport-progress/patches/q3-flarefix.diff Here are a few screenshots of my work: http://thilo.kickchat.com/bilder/screenshots/q3dm19-noflares.png http://thilo.kickchat.com/bilder/screenshots/q3dm19-flares.png This if from my EF project: http://thilo.kickchat.com/efport-progress/screenshots/noflares.png http://thilo.kickchat.com/efport-progress/screenshots/flares.png I am mostly using already existing code there just improving on it. It was originally planned that flares have about the same size proportionally to the screen width with increasing distance, just the intensity changes proportionally to 1/r^2. I have implemented that behaviour so some of the annoying bugs that were in previous q3test releases are history. However, I was not able to get rid of all bugs. All flares are "added" from the RB_RenderDrawSurfList loop. When looking directly at a flare, in most cases the flare is the last thing added from that loop (it is not added yet by RB_EndSurface, it only registers the flare in the list in tr_flare.c). If I use certain weapons or look at the flares from a certain view angle on some maps flares suddenly change their intensity, and it hasn't got anything to do with my intensity computing functions but the order in which RB_EndSurface is called and what kind surfaces are drawn after the flare has been registered. Have a look at these screenshots: http://thilo.kickchat.com/bilder/screenshots/flarebug-normal.png http://thilo.kickchat.com/bilder/screenshots/flarebug-toodark.png These two screenshots show the same flare from the same angle but with a different weapon in the hand. The brightness of the flare suddenly changes. The map is q3tourney2. It may have to do something with the modelView matrix in "backEnd.or" or some left-over values in the tess structure. Changing the modelView matrix or values in tess changed the bug behaviour considerably, so setting these things to the right values would probably fix the bug. In RB_RenderFlares there are these calls: qglPushMatrix(); qglLoadIdentity(); qglMatrixMode( GL_PROJECTION ); qglPushMatrix(); qglLoadIdentity(); qglOrtho( backEnd.viewParms.viewportX, backEnd.viewParms.viewportX + backEnd.viewParms.viewportWidth, backEnd.viewParms.viewportY, backEnd.viewParms.viewportY + backEnd.viewParms.viewportHeight, -99999, 99999 ); Still, the RB_RenderFlare function makes use of the RB_BeginSurface and RB_EndSurface functions. With a different matrix mode, I don't know whether the backEnd.or data previously used for the 3d stuff is appropriate for this one at all. Maybe someone with more insight to OpenGL could help. -- Thilo Schulz -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ntoronto at cs.byu.edu Mon Apr 17 17:52:00 2006 From: ntoronto at cs.byu.edu (Neil Toronto) Date: Mon, 17 Apr 2006 15:52:00 -0600 Subject: [quake3] Flares over lightsources In-Reply-To: <200604172347.59487.arny@ats.s.bawue.de> References: <200604172347.59487.arny@ats.s.bawue.de> Message-ID: <44440E00.1050009@cs.byu.edu> Can you put read permissions on the q3dm19-*.png files? Thilo Schulz wrote: >Hello, > >I've been working on flares over the last few days and got them to be >rendered. IMHO, they add alot of realism to the scene. >A patch is available here: >http://thilo.kickchat.com/efport-progress/patches/q3-flarefix.diff > >Here are a few screenshots of my work: >http://thilo.kickchat.com/bilder/screenshots/q3dm19-noflares.png >http://thilo.kickchat.com/bilder/screenshots/q3dm19-flares.png > >This if from my EF project: >http://thilo.kickchat.com/efport-progress/screenshots/noflares.png >http://thilo.kickchat.com/efport-progress/screenshots/flares.png > >I am mostly using already existing code there just improving on it. >It was originally planned that flares have about the same size proportionally >to the screen width with increasing distance, just the intensity changes >proportionally to 1/r^2. I have implemented that behaviour so some >of the annoying bugs that were in previous q3test releases are history. > >However, I was not able to get rid of all bugs. All flares are "added" from >the RB_RenderDrawSurfList loop. >When looking directly at a flare, in most cases the flare is the last thing >added from that loop (it is not added yet by RB_EndSurface, it only registers >the flare in the list in tr_flare.c). >If I use certain weapons or look at the flares from a certain view angle on >some maps flares suddenly change their intensity, and it hasn't got anything >to do with my intensity computing functions but the order in which >RB_EndSurface is called and what kind surfaces are drawn after the flare has >been registered. > >Have a look at these screenshots: >http://thilo.kickchat.com/bilder/screenshots/flarebug-normal.png >http://thilo.kickchat.com/bilder/screenshots/flarebug-toodark.png > >These two screenshots show the same flare from the same angle but with a >different weapon in the hand. The brightness of the flare suddenly changes. >The map is q3tourney2. > >It may have to do something with the modelView matrix in "backEnd.or" >or some left-over values in the tess structure. >Changing the modelView matrix or values in tess changed the bug behaviour >considerably, so setting these things to the right values would probably fix >the bug. > >In RB_RenderFlares there are these calls: > >qglPushMatrix(); >qglLoadIdentity(); >qglMatrixMode( GL_PROJECTION ); >qglPushMatrix(); >qglLoadIdentity(); >qglOrtho( backEnd.viewParms.viewportX, backEnd.viewParms.viewportX + >backEnd.viewParms.viewportWidth, backEnd.viewParms.viewportY, >backEnd.viewParms.viewportY + backEnd.viewParms.viewportHeight, -99999, >99999 ); > >Still, the RB_RenderFlare function makes use of the RB_BeginSurface and >RB_EndSurface functions. With a different matrix mode, I don't know whether >the backEnd.or data previously used for the 3d stuff is appropriate for this >one at all. Maybe someone with more insight to OpenGL could help. > > > From arny at ats.s.bawue.de Mon Apr 17 17:55:02 2006 From: arny at ats.s.bawue.de (Thilo Schulz) Date: Mon, 17 Apr 2006 23:55:02 +0200 Subject: [quake3] Flares over lightsources In-Reply-To: <44440E00.1050009@cs.byu.edu> References: <200604172347.59487.arny@ats.s.bawue.de> <44440E00.1050009@cs.byu.edu> Message-ID: <200604172355.07047.arny@ats.s.bawue.de> On Monday 17 April 2006 23:52, Neil Toronto wrote: > Can you put read permissions on the q3dm19-*.png files? Did that already, but thanks for telling. -- Thilo Schulz -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From arny at ats.s.bawue.de Mon Apr 17 20:11:24 2006 From: arny at ats.s.bawue.de (Thilo Schulz) Date: Tue, 18 Apr 2006 02:11:24 +0200 Subject: [quake3] Flares over lightsources In-Reply-To: <200604172347.59487.arny@ats.s.bawue.de> References: <200604172347.59487.arny@ats.s.bawue.de> Message-ID: <200604180211.27963.arny@ats.s.bawue.de> I have prepared some more media showing off flares: http://thilo.kickchat.com/videos/q3dm19-flares.avi This is EliteForce: http://thilo.kickchat.com/videos/hm_dm1-flares.avi This video shows the bugs I mentioned in my posts: http://thilo.kickchat.com/videos/q3tourney2_flarebug.avi -- Thilo Schulz -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From zakk at timedoctor.org Tue Apr 18 01:11:37 2006 From: zakk at timedoctor.org (Zachary J. Slater) Date: Mon, 17 Apr 2006 22:11:37 -0700 Subject: [quake3] Flares over lightsources In-Reply-To: <200604180211.27963.arny@ats.s.bawue.de> References: <200604172347.59487.arny@ats.s.bawue.de> <200604180211.27963.arny@ats.s.bawue.de> Message-ID: <44447509.9090307@timedoctor.org> Thilo Schulz wrote: > I have prepared some more media showing off flares: > http://thilo.kickchat.com/videos/q3dm19-flares.avi > > This is EliteForce: > http://thilo.kickchat.com/videos/hm_dm1-flares.avi > > This video shows the bugs I mentioned in my posts: > http://thilo.kickchat.com/videos/q3tourney2_flarebug.avi > This is spinal tap! \m/ Actually, it is really neat. I like it! -- - Zachary J. Slater zakk at timedoctor.org zacharyslater at gmail.com From marc.leeman at gmail.com Tue Apr 18 02:43:49 2006 From: marc.leeman at gmail.com (Marc Leeman) Date: Tue, 18 Apr 2006 08:43:49 +0200 Subject: [quake3] Flares over lightsources In-Reply-To: <200604172347.59487.arny@ats.s.bawue.de> References: <200604172347.59487.arny@ats.s.bawue.de> Message-ID: <20060418064349.GG21269@scorpius.homelinux.org> Hi, Thilo, First of all, I my apologies for just asking instead of trying, but running Q3 over ssh would probably be a stretch to test it :) I have a question about your EF patch: is it possible to run your patch in the main ioQ3 code without breaking Q3A, and running EF multiplayer as a mod? If you don't know, I'll try to remember to try it when I'm at my main development machine. In that case, I think we could include your patch in Debian pkg-games-devel. -- greetz, marc Nebari mental cleansing doesn't get the tough stains out. Crichton - Durka Returns scorpius.homelinux.org 2.6.16 #6 PREEMPT Sat Apr 1 21:22:39 CEST 2006 GNU/Linux -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From arny at ats.s.bawue.de Tue Apr 18 09:32:42 2006 From: arny at ats.s.bawue.de (Thilo Schulz) Date: Tue, 18 Apr 2006 15:32:42 +0200 Subject: [quake3] Flares over lightsources In-Reply-To: <20060418064349.GG21269@scorpius.homelinux.org> References: <200604172347.59487.arny@ats.s.bawue.de> <20060418064349.GG21269@scorpius.homelinux.org> Message-ID: <200604181532.48324.arny@ats.s.bawue.de> On Tuesday 18 April 2006 08:43, Marc Leeman wrote: > First of all, I my apologies for just asking instead of trying, but > running Q3 over ssh would probably be a stretch to test it :) No worries =) > I have a question about your EF patch: is it possible to run your patch > in the main ioQ3 code without breaking Q3A, and running EF multiplayer > as a mod? Not possible. There are many changes in the interface between virtual machine and game APIs. Alot of Flags are different, network protocol is completely different. It would have been a pain in the ass to make the switch between EF/Q3 at runtime. I just used #ifdefs. That means, Q3 should work okay if you don't have ELITEFORCE set as macro, but that's of course not what you meant to do. > In that case, I think we could include your patch in Debian > pkg-games-devel. You'd probably need to do a seperate package. Of course, being a long-time debian user myself, I'd find it cool if that happened. :) -- Thilo Schulz -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From arny at ats.s.bawue.de Tue Apr 18 13:01:29 2006 From: arny at ats.s.bawue.de (Thilo Schulz) Date: Tue, 18 Apr 2006 19:01:29 +0200 Subject: [quake3] Flares over lightsources In-Reply-To: <200604172347.59487.arny@ats.s.bawue.de> References: <200604172347.59487.arny@ats.s.bawue.de> Message-ID: <200604181901.32808.arny@ats.s.bawue.de> On Monday 17 April 2006 23:47, Thilo Schulz wrote: > However, I was not able to get rid of all bugs. The cause of the bug is the fogNum value. Apparently, the fogging doesn't work on flares. I am pretty sure the modelView matrix is responsible that is needed in RB_CalcFogTexCoords in tr_shade_calc.c I have created a second patch that will always set fogNum to zero, so there are no sudden unexpected brightness changes anymore in the flares: http://thilo.kickchat.com/efport-progress/patches/q3-flarefix2.diff That means that fog is not influencing the flare intensity anymore, which should be fixed. Pretty disturbing on q3tourney5 i.e. with all the fog there. -- Thilo Schulz -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From arny at ats.s.bawue.de Wed Apr 19 20:19:39 2006 From: arny at ats.s.bawue.de (Thilo Schulz) Date: Thu, 20 Apr 2006 02:19:39 +0200 Subject: [quake3] Flares over lightsources In-Reply-To: <200604181901.32808.arny@ats.s.bawue.de> References: <200604172347.59487.arny@ats.s.bawue.de> <200604181901.32808.arny@ats.s.bawue.de> Message-ID: <200604200219.42393.arny@ats.s.bawue.de> On Tuesday 18 April 2006 19:01, Thilo Schulz wrote: > The cause of the bug is the fogNum value. Apparently, the fogging doesn't > work on flares. Fogging on flares is working. Now all bugs in flares should be fixed. It was because of RB_[Begin|End]Surface was never really intended for 2d objects like the flares are and thus didn't work with fogging. Fogging is now computed directly in tr_flares.c Here you go: http://thilo.kickchat.com/efport-progress/patches/q3-flarefix3.diff Shall I open a bugtrack item for addition after the release? -- Thilo Schulz -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From arny at ats.s.bawue.de Wed Apr 19 20:32:02 2006 From: arny at ats.s.bawue.de (Thilo Schulz) Date: Thu, 20 Apr 2006 02:32:02 +0200 Subject: [quake3] Flares over lightsources In-Reply-To: <200604200219.42393.arny@ats.s.bawue.de> References: <200604172347.59487.arny@ats.s.bawue.de> <200604181901.32808.arny@ats.s.bawue.de> <200604200219.42393.arny@ats.s.bawue.de> Message-ID: <200604200232.05244.arny@ats.s.bawue.de> Sorry, I forgot some instructions still: You enable flares by setting r_flares to 1 in the console. I introduced a new cvar, namely r_flareCoeff. This cvar will determine how quickly the flare will fade with increasing distance. Default value is 150. -- Thilo Schulz -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From zakk at timedoctor.org Wed Apr 19 20:38:42 2006 From: zakk at timedoctor.org (Zachary J. Slater) Date: Wed, 19 Apr 2006 17:38:42 -0700 Subject: [quake3] Flares over lightsources In-Reply-To: <200604200232.05244.arny@ats.s.bawue.de> References: <200604172347.59487.arny@ats.s.bawue.de> <200604181901.32808.arny@ats.s.bawue.de> <200604200219.42393.arny@ats.s.bawue.de> <200604200232.05244.arny@ats.s.bawue.de> Message-ID: <4446D812.7010309@timedoctor.org> Thilo Schulz wrote: > Sorry, > > I forgot some instructions still: > You enable flares by setting r_flares to 1 in the console. > I introduced a new cvar, namely r_flareCoeff. This cvar will determine how > quickly the flare will fade with increasing distance. Default value is 150. > This defaults to off, right? -- - Zachary J. Slater zakk at timedoctor.org zacharyslater at gmail.com From zakk at timedoctor.org Wed Apr 19 22:05:11 2006 From: zakk at timedoctor.org (Zachary J. Slater) Date: Wed, 19 Apr 2006 19:05:11 -0700 Subject: ppc Message-ID: <4446EC57.9040702@timedoctor.org> I should note that mirrors and portals are working for the most part (I see some hom stuff) -- - Zachary J. Slater zakk at timedoctor.org zacharyslater at gmail.com From floam at sh.nu Wed Apr 19 22:12:43 2006 From: floam at sh.nu (Aaron Gyes) Date: Wed, 19 Apr 2006 19:12:43 -0700 Subject: [quake3] Flares over lightsources In-Reply-To: <4446D812.7010309@timedoctor.org> References: <200604172347.59487.arny@ats.s.bawue.de> <200604181901.32808.arny@ats.s.bawue.de> <200604200219.42393.arny@ats.s.bawue.de> <200604200232.05244.arny@ats.s.bawue.de> <4446D812.7010309@timedoctor.org> Message-ID: <1145499163.29878.2.camel@laika.home.floam.sh.nu> On Wed, 2006-04-19 at 17:38 -0700, Zachary J. Slater wrote: > This defaults to off, right? Quake3 has always had flare support, and from the code in svn they default to 0: /code/renderer/tr_init.c: r_flares = ri.Cvar_Get ("r_flares", "0", CVAR_ARCHIVE ); From arny at ats.s.bawue.de Wed Apr 19 23:05:37 2006 From: arny at ats.s.bawue.de (Thilo Schulz) Date: Thu, 20 Apr 2006 05:05:37 +0200 Subject: [quake3] Flares over lightsources In-Reply-To: <1145499163.29878.2.camel@laika.home.floam.sh.nu> References: <200604172347.59487.arny@ats.s.bawue.de> <4446D812.7010309@timedoctor.org> <1145499163.29878.2.camel@laika.home.floam.sh.nu> Message-ID: <200604200506.13608.arny@ats.s.bawue.de> On Thursday 20 April 2006 04:12, Aaron Gyes wrote: > Quake3 has always had flare support Not quite true. Even though Quake3 has alot of flares distributed over the maps, they obviously disabled them hardcoded. Maybe because of problem, maybe because of performance... > /code/renderer/tr_init.c: > r_flares = ri.Cvar_Get ("r_flares", "0", CVAR_ARCHIVE ); My patch doesn't change that. -- Thilo Schulz -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From zakk at timedoctor.org Wed Apr 19 23:07:41 2006 From: zakk at timedoctor.org (Zachary J. Slater) Date: Wed, 19 Apr 2006 20:07:41 -0700 Subject: [quake3] Flares over lightsources In-Reply-To: <200604200506.13608.arny@ats.s.bawue.de> References: <200604172347.59487.arny@ats.s.bawue.de> <4446D812.7010309@timedoctor.org> <1145499163.29878.2.camel@laika.home.floam.sh.nu> <200604200506.13608.arny@ats.s.bawue.de> Message-ID: <4446FAFD.2090701@timedoctor.org> Thilo Schulz wrote: > On Thursday 20 April 2006 04:12, Aaron Gyes wrote: >> Quake3 has always had flare support > > Not quite true. > Even though Quake3 has alot of flares distributed over the maps, they > obviously disabled them hardcoded. Maybe because of problem, maybe because of > performance... > >> /code/renderer/tr_init.c: >> r_flares = ri.Cvar_Get ("r_flares", "0", CVAR_ARCHIVE ); > > My patch doesn't change that. > Right, that is what I wanted to hear. -- - Zachary J. Slater zakk at timedoctor.org zacharyslater at gmail.com From zakk at timedoctor.org Thu Apr 20 00:38:15 2006 From: zakk at timedoctor.org (Zachary J. Slater) Date: Wed, 19 Apr 2006 21:38:15 -0700 Subject: New maintainer guy Message-ID: <44471037.1090900@timedoctor.org> Thilo "I Know Nothing!" Shultz is the latest coder with commit access, hopefully now everyone will stop e-mailing and instant messaging me asking when we'll get more flare. -- - Zachary J. Slater zakk at timedoctor.org zacharyslater at gmail.com From floam at sh.nu Thu Apr 20 00:54:50 2006 From: floam at sh.nu (Aaron Gyes) Date: Wed, 19 Apr 2006 21:54:50 -0700 Subject: [quake3] Flares over lightsources In-Reply-To: <200604200506.13608.arny@ats.s.bawue.de> References: <200604172347.59487.arny@ats.s.bawue.de> <4446D812.7010309@timedoctor.org> <1145499163.29878.2.camel@laika.home.floam.sh.nu> <200604200506.13608.arny@ats.s.bawue.de> Message-ID: <1145508890.29878.5.camel@laika.home.floam.sh.nu> On Thu, 2006-04-20 at 05:05 +0200, Thilo Schulz wrote: > On Thursday 20 April 2006 04:12, Aaron Gyes wrote: > > Quake3 has always had flare support > > Not quite true. I was just pointing out that the r_flares cvar has always been there and continues to default to off. He was concerned that a new graphical feature would default to enabled, which is something we have said since the beginning won't happen. Aaron Gyes From jaq at spacepants.org Thu Apr 20 01:10:57 2006 From: jaq at spacepants.org (Jamie Wilkinson) Date: Thu, 20 Apr 2006 15:10:57 +1000 Subject: [quake3] New maintainer guy In-Reply-To: <44471037.1090900@timedoctor.org> References: <44471037.1090900@timedoctor.org> Message-ID: <20060420051056.GM14445@spacepants.org> This one time, at band camp, Zachary J. Slater wrote: >Thilo "I Know Nothing!" Shultz is the latest coder with commit access, >hopefully now everyone will stop e-mailing and instant messaging me >asking when we'll get more flare. 15 pieces of flare is the *minimum*. Now, it's up to you whether or not you want to just do the bare minimum. Well, like Brian, for example, has 37 pieces of flare. And a terrific smile! From auerswal at unix-ag.uni-kl.de Fri Apr 21 07:31:23 2006 From: auerswal at unix-ag.uni-kl.de (Erik Auerswald) Date: Fri, 21 Apr 2006 13:31:23 +0200 Subject: botlib.log Message-ID: <20060421113123.GA14573@sushi.unix-ag.uni-kl.de> Hi, my patch to change the location of the file "botlib.log" from the current directory to the quake home directory (~/.q3a/ on linux), which has been commited to svn by Tim Angus (thanks :-)), might have introduced a problem for windows users: I do not know if the "fs_homepath" cvar is empty on windows (comments in the code suggest this might be the case). If it is, the logfile is created on the current disk in the root directory on windows ("\botlib.log"). Someone with windows might want to check this. Another problem with the patch is, that all other logfiles are created in the game base directory in the home dir (~/.q3a/baseq3/ on linux for Quake 3 Arena) except the "botlib.log". The first patch attached to this mail corrects these two problems. The base directory for Quake 3 Arena is hardcoded as this is done in several other places of the code. Obviously there should be no "botlib.log" by default, it should have to be enabled by setting the cvar logfile to 1 (as is done with the other logfiles). The second attached patch implements this. I've reopened bugzilla bug #2634 and attached the patches there as well. Erik -------------- next part -------------- Index: code/botlib/be_interface.c =================================================================== --- code/botlib/be_interface.c (revision 714) +++ code/botlib/be_interface.c (working copy) @@ -137,12 +137,24 @@ { int errnum; char logfilename[MAX_QPATH]; + char *homedir, *gamedir; bot_developer = LibVarGetValue("bot_developer"); memset( &botlibglobals, 0, sizeof(botlibglobals) ); // bk001207 - init //initialize byte swapping (litte endian etc.) // Swap_Init(); - Com_sprintf(logfilename, sizeof(logfilename), "%s%cbotlib.log", LibVarGetString("homedir"), PATH_SEP); + homedir = LibVarGetString("homedir"); + gamedir = LibVarGetString("gamedir"); + if (homedir[0]) { + if (gamedir[0]) { + Com_sprintf(logfilename, sizeof(logfilename), "%s%c%s%cbotlib.log", homedir, PATH_SEP, gamedir, PATH_SEP); + } + else { + Com_sprintf(logfilename, sizeof(logfilename), "%s%cbaseq3%cbotlib.log", homedir, PATH_SEP, PATH_SEP); + } + } else { + Com_sprintf(logfilename, sizeof(logfilename), "botlib.log"); + } Log_Open(logfilename); // botimport.Print(PRT_MESSAGE, "------- BotLib Initialization -------\n"); -------------- next part -------------- Index: code/game/ai_main.c =================================================================== --- code/game/ai_main.c (revision 714) +++ code/game/ai_main.c (working copy) @@ -1593,6 +1593,7 @@ trap_BotLibVarSet("g_gametype", buf); //bot developer mode and log file trap_BotLibVarSet("bot_developer", bot_developer.string); + trap_Cvar_VariableStringBuffer("logfile", buf, sizeof(buf)); trap_BotLibVarSet("log", buf); //no chatting trap_Cvar_VariableStringBuffer("bot_nochat", buf, sizeof(buf)); From arny at ats.s.bawue.de Fri Apr 21 13:13:12 2006 From: arny at ats.s.bawue.de (Thilo Schulz) Date: Fri, 21 Apr 2006 19:13:12 +0200 Subject: [quake3] botlib.log In-Reply-To: <20060421113123.GA14573@sushi.unix-ag.uni-kl.de> References: <20060421113123.GA14573@sushi.unix-ag.uni-kl.de> Message-ID: <200604211913.14180.arny@ats.s.bawue.de> On Friday 21 April 2006 13:31, Erik Auerswald wrote: > I do not know if the "fs_homepath" cvar is > empty on windows (comments in the code suggest this might be the case). If > it is, the logfile is created on the current disk in the root directory > on windows ("\botlib.log"). Someone with windows might want to check this. It's not empty. It seems to point to the directory where the .exe resides > I've reopened bugzilla bug #2634 and attached the patches there as well. I commited your patches, see bugzilla. -- Thilo Schulz -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jamlacey at gmail.com Fri Apr 21 15:46:48 2006 From: jamlacey at gmail.com (James Lacey) Date: Fri, 21 Apr 2006 12:46:48 -0700 Subject: win64 support Message-ID: <000001c6657c$54a2bfe0$6800000a@interactiontech.local> Since I haven't been told that my Win64 patches have been merged into the repository, I am assuming they haven't. If that is the case, what else do the maintainers want to be done before they accept the patch? If the patch is unacceptable for whatever reason, then I am thinking about posting my working Win64 build somewhere with the source patch against the official icculus.org CVS. As a side note, when I run ioq3 with the DLLs instead of the VM, it complains about a recursive error after not being able to find ui/menu.txt (actually it says: ^3ui/menu.txt). If I set vm_ui to 2 and leave vm_cgame and vm_game at 0, I get the error message right as I am about to enter a level. Anyone encounter this before using the DLLs instead of the VM? James -------------- next part -------------- An HTML attachment was scrubbed... URL: From zakk at timedoctor.org Fri Apr 21 15:49:13 2006 From: zakk at timedoctor.org (Zachary J. Slater) Date: Fri, 21 Apr 2006 12:49:13 -0700 Subject: [quake3] win64 support In-Reply-To: <000001c6657c$54a2bfe0$6800000a@interactiontech.local> References: <000001c6657c$54a2bfe0$6800000a@interactiontech.local> Message-ID: <44493739.3050008@timedoctor.org> I'm uninterested in win64 until after os x is working. -- - Zachary J. Slater zakk at timedoctor.org zacharyslater at gmail.com From tim at ngus.net Fri Apr 21 19:10:21 2006 From: tim at ngus.net (Tim Angus) Date: Sat, 22 Apr 2006 00:10:21 +0100 Subject: win64 support In-Reply-To: <000001c6657c$54a2bfe0$6800000a@interactiontech.local> References: <000001c6657c$54a2bfe0$6800000a@interactiontech.local> Message-ID: <20060422001021.24e5fa60.tim@ngus.net> On Fri, 21 Apr 2006 12:46:48 -0700 James wrote: > Since I haven't been told that my Win64 patches have been merged into > the repository, I am assuming they haven't. If that is the case, what > else do the maintainers want to be done before they accept the patch? > If the patch is unacceptable for whatever reason, then I am thinking > about posting my working Win64 build somewhere with the source patch > against the official icculus.org CVS. Stick patches in bugzilla if you want them to be remembered. From auerswal at unix-ag.uni-kl.de Sat Apr 22 02:58:43 2006 From: auerswal at unix-ag.uni-kl.de (Erik Auerswald) Date: Sat, 22 Apr 2006 08:58:43 +0200 Subject: [quake3] win64 support In-Reply-To: <44493739.3050008@timedoctor.org> References: <000001c6657c$54a2bfe0$6800000a@interactiontech.local> <44493739.3050008@timedoctor.org> Message-ID: <20060422065842.GA4771@sushi.unix-ag.uni-kl.de> Hi, On Fri, Apr 21, 2006 at 12:49:13PM -0700, Zachary J. Slater wrote: > I'm uninterested in win64 until after os x is working. This won't create any OS X developers. You could post this policy on the "help" web page so that no one will try to improve on non OS X parts of the project. Erik From auerswal at unix-ag.uni-kl.de Sat Apr 22 03:09:22 2006 From: auerswal at unix-ag.uni-kl.de (Erik Auerswald) Date: Sat, 22 Apr 2006 09:09:22 +0200 Subject: [quake3] botlib.log In-Reply-To: <200604211913.14180.arny@ats.s.bawue.de> References: <20060421113123.GA14573@sushi.unix-ag.uni-kl.de> <200604211913.14180.arny@ats.s.bawue.de> Message-ID: <20060422070922.GB4771@sushi.unix-ag.uni-kl.de> Hi, On Fri, Apr 21, 2006 at 07:13:12PM +0200, Thilo Schulz wrote: > On Friday 21 April 2006 13:31, Erik Auerswald wrote: > > I do not know if the "fs_homepath" cvar is > > empty on windows (comments in the code suggest this might be the case). If > > it is, the logfile is created on the current disk in the root directory > > on windows ("\botlib.log"). Someone with windows might want to check this. > > It's not empty. It seems to point to the directory where the .exe resides Thanks for testing. > > I've reopened bugzilla bug #2634 and attached the patches there as well. > > I commited your patches, see bugzilla. Thanks. Concerning the need to manually activate the fixed code: IMHO the README should mention that the shared libraries need to be used to actually use most of the fixes commited to ioq3. Erik From ludwig.nussel at suse.de Sat Apr 22 08:13:58 2006 From: ludwig.nussel at suse.de (Ludwig Nussel) Date: Sat, 22 Apr 2006 14:13:58 +0200 Subject: [quake3] win64 support In-Reply-To: <000001c6657c$54a2bfe0$6800000a@interactiontech.local> References: <000001c6657c$54a2bfe0$6800000a@interactiontech.local> Message-ID: <200604221413.58810.ludwig.nussel@suse.de> James Lacey wrote: > Since I haven't been told that my Win64 patches have been merged into the > repository, I am assuming they haven't. If that is the case, what else do > the maintainers want to be done before they accept the patch? If the patch Personally I did not apply the patch because a) we have (in theory) code freeze and I cannot verify it doesn't break the Win32 build which must work for the release, b) statements like in the following paragraph suggest that the patch is still incomplete. > As a side note, when I run ioq3 with the DLLs instead of the VM, it > complains about a recursive error after not being able to find ui/menu.txt > (actually it says: ^3ui/menu.txt). If I set vm_ui to 2 and leave vm_cgame > and vm_game at 0, I get the error message right as I am about to enter a > level. Anyone encounter this before using the DLLs instead of the VM? Works fine on Linux. To check whether interpreter and dll loader work you need to start ioq3 like this (need to copy *dll to baseq3/ first of course): ioquake3.exe +set vm_cgame 0 +set vm_game 0 +set vm_ui 0 +set sv_pure 0 +map q3dm17 resp. ioquake3.exe +set vm_cgame 1 +set vm_game 1 +set vm_ui 1 +set sv_pure 0 +map q3dm17 \vminfo in the console should report 'native' in the first case and 'interpreted' in the second. cu Ludwig -- (o_ Ludwig Nussel //\ SUSE LINUX Products GmbH, Development V_/_ http://www.suse.de/ From ludwig.nussel at suse.de Sat Apr 22 08:24:03 2006 From: ludwig.nussel at suse.de (Ludwig Nussel) Date: Sat, 22 Apr 2006 14:24:03 +0200 Subject: mailinglist as default bugzilla component owner? Message-ID: <200604221424.03526.ludwig.nussel@suse.de> Hi, What about setting up a mailinglist/alias (or whatever bugzilla best practice is) like e.g. quake3-maintainers at icculus.org as default assignee of quake3 bugs? This way everyone interested would get notified of new bugs automatically and doesn't need to poll bugzilla. cu Ludwig -- (o_ Ludwig Nussel //\ SUSE LINUX Products GmbH, Development V_/_ http://www.suse.de/ From jamlacey at gmail.com Sat Apr 22 11:36:35 2006 From: jamlacey at gmail.com (James Lacey) Date: Sat, 22 Apr 2006 08:36:35 -0700 Subject: [quake3] win64 support In-Reply-To: <200604221413.58810.ludwig.nussel@suse.de> Message-ID: <000001c66622$8cc28f80$0300a8c0@interactiontech.local> Since you say there is a code freeze, I will post the patch to Bugzilla. You guys can use the patch in the future as a basis for Win64 support or not as you see fit. -----Original Message----- From: Ludwig Nussel [mailto:ludwig.nussel at suse.de] Sent: Saturday, April 22, 2006 5:14 AM To: quake3 at icculus.org Subject: Re: [quake3] win64 support James Lacey wrote: > Since I haven't been told that my Win64 patches have been merged into the > repository, I am assuming they haven't. If that is the case, what else do > the maintainers want to be done before they accept the patch? If the patch Personally I did not apply the patch because a) we have (in theory) code freeze and I cannot verify it doesn't break the Win32 build which must work for the release, b) statements like in the following paragraph suggest that the patch is still incomplete. > As a side note, when I run ioq3 with the DLLs instead of the VM, it > complains about a recursive error after not being able to find ui/menu.txt > (actually it says: ^3ui/menu.txt). If I set vm_ui to 2 and leave vm_cgame > and vm_game at 0, I get the error message right as I am about to enter a > level. Anyone encounter this before using the DLLs instead of the VM? Works fine on Linux. To check whether interpreter and dll loader work you need to start ioq3 like this (need to copy *dll to baseq3/ first of course): ioquake3.exe +set vm_cgame 0 +set vm_game 0 +set vm_ui 0 +set sv_pure 0 +map q3dm17 resp. ioquake3.exe +set vm_cgame 1 +set vm_game 1 +set vm_ui 1 +set sv_pure 0 +map q3dm17 \vminfo in the console should report 'native' in the first case and 'interpreted' in the second. cu Ludwig -- (o_ Ludwig Nussel //\ SUSE LINUX Products GmbH, Development V_/_ http://www.suse.de/ From zakk at timedoctor.org Sat Apr 22 11:38:42 2006 From: zakk at timedoctor.org (Zachary J. Slater) Date: Sat, 22 Apr 2006 08:38:42 -0700 Subject: [quake3] win64 support In-Reply-To: <20060422065842.GA4771@sushi.unix-ag.uni-kl.de> References: <000001c6657c$54a2bfe0$6800000a@interactiontech.local> <44493739.3050008@timedoctor.org> <20060422065842.GA4771@sushi.unix-ag.uni-kl.de> Message-ID: <444A4E02.9080304@timedoctor.org> Erik Auerswald wrote: > Hi, > > On Fri, Apr 21, 2006 at 12:49:13PM -0700, Zachary J. Slater wrote: >> I'm uninterested in win64 until after os x is working. > > This won't create any OS X developers. You could post this policy on the > "help" web page so that no one will try to improve on non OS X parts of > the project. > > Erik No, see, we're trying to do a release. For that release I have some criteria, which interestingly enough, has already been posted to various places. Win64 can be in the next release. -- - Zachary J. Slater zakk at timedoctor.org zacharyslater at gmail.com From jamlacey at gmail.com Sat Apr 22 11:43:17 2006 From: jamlacey at gmail.com (James Lacey) Date: Sat, 22 Apr 2006 08:43:17 -0700 Subject: [quake3] win64 support In-Reply-To: <444A4E02.9080304@timedoctor.org> Message-ID: <000101c66623$7a60a380$0300a8c0@interactiontech.local> Standard release engineering is to create a branch, stabilize and then freeze it for release, while still allowing (possibly disruptive) development work to continue on the trunk. But you are the maintainer so you can do whatever you like :) -----Original Message----- From: Zachary J. Slater [mailto:zakk at timedoctor.org] Sent: Saturday, April 22, 2006 8:39 AM To: quake3 at icculus.org Subject: Re: [quake3] win64 support Erik Auerswald wrote: > Hi, > > On Fri, Apr 21, 2006 at 12:49:13PM -0700, Zachary J. Slater wrote: >> I'm uninterested in win64 until after os x is working. > > This won't create any OS X developers. You could post this policy on the > "help" web page so that no one will try to improve on non OS X parts of > the project. > > Erik No, see, we're trying to do a release. For that release I have some criteria, which interestingly enough, has already been posted to various places. Win64 can be in the next release. -- - Zachary J. Slater zakk at timedoctor.org zacharyslater at gmail.com From zakk at timedoctor.org Sat Apr 22 11:49:13 2006 From: zakk at timedoctor.org (Zachary J. Slater) Date: Sat, 22 Apr 2006 08:49:13 -0700 Subject: [quake3] mailinglist as default bugzilla component owner? In-Reply-To: <200604221424.03526.ludwig.nussel@suse.de> References: <200604221424.03526.ludwig.nussel@suse.de> Message-ID: <444A5079.5070402@timedoctor.org> Ludwig Nussel wrote: > Hi, > > What about setting up a mailinglist/alias (or whatever bugzilla best > practice is) like e.g. quake3-maintainers at icculus.org as default > assignee of quake3 bugs? This way everyone interested would get > notified of new bugs automatically and doesn't need to poll > bugzilla. > > cu > Ludwig > I'd be fine with this, I'll bug ryan about it/he'll see it on this ml. -- - Zachary J. Slater zakk at timedoctor.org zacharyslater at gmail.com From arny at ats.s.bawue.de Sat Apr 22 14:30:57 2006 From: arny at ats.s.bawue.de (Thilo Schulz) Date: Sat, 22 Apr 2006 20:30:57 +0200 Subject: And the winner of the day is... Message-ID: <200604222031.25963.arny@ats.s.bawue.de> ... iDSoftware! Clients should never be able to download pak*.pk3 files released from id. The security check for required files on autodownload in the client works correctly, on the server it does *NOT*. I was able to download pak0.pk3 from an *unmodified* officially released id server (point release 1.32) using a slightly hacked ioq3 client. Probably alot of other commercial games are hit by that bug, too :D I wonder whether Doom3/Q4 suffers from it? I commited a tested fix to SVN. -- Thilo Schulz -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From arny at ats.s.bawue.de Sat Apr 22 16:42:25 2006 From: arny at ats.s.bawue.de (Thilo Schulz) Date: Sat, 22 Apr 2006 22:42:25 +0200 Subject: Crash in x86_64 compiled VM when running WoP mod Message-ID: <200604222242.27880.arny@ats.s.bawue.de> Hi, When running the WoP with recent version of ioq3 the game crashes with a segmentation fault. The crash does not occur, when I add the PROT_WRITEFLAG to the mmap call in vm_x86_64.c in mmapfile(). I guess it's probably because the VM of that mod is doing something that it should not, but I'd like to be clear and give you some kind of feedback on recent changes in the codebase just to be sure. -- Thilo Schulz -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From icculus at icculus.org Sat Apr 22 18:28:59 2006 From: icculus at icculus.org (Ryan C. Gordon) Date: Sat, 22 Apr 2006 18:28:59 -0400 Subject: [quake3] mailinglist as default bugzilla component owner? In-Reply-To: <444A5079.5070402@timedoctor.org> References: <200604221424.03526.ludwig.nussel@suse.de> <444A5079.5070402@timedoctor.org> Message-ID: <444AAE2B.9070207@icculus.org> > I'd be fine with this, I'll bug ryan about it/he'll see it on this ml. Any historical reason for -maintainers? Can I call it quake3-bugs instead? --ryan. From robust at gentoo.se Sat Apr 22 19:11:58 2006 From: robust at gentoo.se (Robert Lundmark) Date: Sun, 23 Apr 2006 01:11:58 +0200 Subject: PNG Support Message-ID: <1145747518.27402.2.camel@robust.homelinux.net> Would people find the feature useful? I like the thought because it's lossless and therefore great if someone else wants to edit or reuse the graphics. It's also smaller than tga. I would also like to know if ogg vorbis is supported. From arny at ats.s.bawue.de Sat Apr 22 19:39:54 2006 From: arny at ats.s.bawue.de (Thilo Schulz) Date: Sun, 23 Apr 2006 01:39:54 +0200 Subject: [quake3] PNG Support In-Reply-To: <1145747518.27402.2.camel@robust.homelinux.net> References: <1145747518.27402.2.camel@robust.homelinux.net> Message-ID: <200604230139.56713.arny@ats.s.bawue.de> On Sunday 23 April 2006 01:11, Robert Lundmark wrote: > Would people find the feature useful? I like the thought because it's > lossless and therefore great if someone else wants to edit or reuse the > graphics. It's also smaller than tga. If you like the thought so much, why don't *you* do it? :D > I would also like to know if ogg vorbis is supported. yes. -- Thilo Schulz -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From zakk at timedoctor.org Sat Apr 22 19:52:29 2006 From: zakk at timedoctor.org (Zachary J. Slater) Date: Sat, 22 Apr 2006 16:52:29 -0700 Subject: [quake3] mailinglist as default bugzilla component owner? In-Reply-To: <444AAE2B.9070207@icculus.org> References: <200604221424.03526.ludwig.nussel@suse.de> <444A5079.5070402@timedoctor.org> <444AAE2B.9070207@icculus.org> Message-ID: <444AC1BD.8070600@timedoctor.org> Ryan C. Gordon wrote: > >> I'd be fine with this, I'll bug ryan about it/he'll see it on this ml. > > Any historical reason for -maintainers? Can I call it quake3-bugs instead? > > --ryan. > I'd prefer that only maintainers are subscribed, so this doesn't get too screwy. -- - Zachary J. Slater zakk at timedoctor.org zacharyslater at gmail.com From robust at gentoo.se Sat Apr 22 21:18:07 2006 From: robust at gentoo.se (Robert Lundmark) Date: Sun, 23 Apr 2006 03:18:07 +0200 Subject: [quake3] PNG Support In-Reply-To: <200604230139.56713.arny@ats.s.bawue.de> References: <1145747518.27402.2.camel@robust.homelinux.net> <200604230139.56713.arny@ats.s.bawue.de> Message-ID: <1145755087.29452.1.camel@robust.homelinux.net> I'm not telling anyone to do anything, and for your information I can't program. The reason that I put this message on the mailinglist is because I would like to hear people's opinions. > On Sunday 23 April 2006 01:11, Robert Lundmark wrote: > > Would people find the feature useful? I like the thought because it's > > lossless and therefore great if someone else wants to edit or reuse the > > graphics. It's also smaller than tga. > > If you like the thought so much, why don't *you* do it? :D > > > I would also like to know if ogg vorbis is supported. > > yes. > From floam at sh.nu Sun Apr 23 01:54:36 2006 From: floam at sh.nu (Aaron Gyes) Date: Sat, 22 Apr 2006 22:54:36 -0700 Subject: [quake3] mailinglist as default bugzilla component owner? In-Reply-To: <444AC1BD.8070600@timedoctor.org> References: <200604221424.03526.ludwig.nussel@suse.de> <444A5079.5070402@timedoctor.org> <444AAE2B.9070207@icculus.org> <444AC1BD.8070600@timedoctor.org> Message-ID: <1145771676.9677.0.camel@laika.home.floam.sh.nu> On Sat, 2006-04-22 at 16:52 -0700, Zachary J. Slater wrote: > I'd prefer that only maintainers are subscribed, so this doesn't get too > screwy. Why? Lots of projects have -bugs lists that anyone can subscribe to to get information of bug changes. I don't see how anything would get more screwy? From zakk at timedoctor.org Sun Apr 23 02:07:53 2006 From: zakk at timedoctor.org (Zachary J. Slater) Date: Sat, 22 Apr 2006 23:07:53 -0700 Subject: [quake3] mailinglist as default bugzilla component owner? In-Reply-To: <1145771676.9677.0.camel@laika.home.floam.sh.nu> References: <200604221424.03526.ludwig.nussel@suse.de> <444A5079.5070402@timedoctor.org> <444AAE2B.9070207@icculus.org> <444AC1BD.8070600@timedoctor.org> <1145771676.9677.0.camel@laika.home.floam.sh.nu> Message-ID: <444B19B9.5030908@timedoctor.org> Aaron Gyes wrote: > On Sat, 2006-04-22 at 16:52 -0700, Zachary J. Slater wrote: >> I'd prefer that only maintainers are subscribed, so this doesn't get too >> screwy. > > Why? Lots of projects have -bugs lists that anyone can subscribe to to > get information of bug changes. I don't see how anything would get more > screwy? > This list would be the "default owner" of all new projects? Unless there is a way to do it without doing that. -- - Zachary J. Slater zakk at timedoctor.org zacharyslater at gmail.com From floam at sh.nu Sun Apr 23 02:38:42 2006 From: floam at sh.nu (Aaron Gyes) Date: Sat, 22 Apr 2006 23:38:42 -0700 Subject: [quake3] mailinglist as default bugzilla component owner? In-Reply-To: <444B19B9.5030908@timedoctor.org> References: <200604221424.03526.ludwig.nussel@suse.de> <444A5079.5070402@timedoctor.org> <444AAE2B.9070207@icculus.org> <444AC1BD.8070600@timedoctor.org> <1145771676.9677.0.camel@laika.home.floam.sh.nu> <444B19B9.5030908@timedoctor.org> Message-ID: <1145774322.11809.4.camel@laika.home.floam.sh.nu> On Sat, 2006-04-22 at 23:07 -0700, Zachary J. Slater wrote: > This list would be the "default owner" of all new projects? Huh? Why would you want that? Wouldn't you want it to be the default asignee, the "QA Contact" email for the product, like other projects do? Aaron From zakk at timedoctor.org Sun Apr 23 03:55:43 2006 From: zakk at timedoctor.org (Zachary J. Slater) Date: Sun, 23 Apr 2006 00:55:43 -0700 Subject: [quake3] mailinglist as default bugzilla component owner? In-Reply-To: <1145774322.11809.4.camel@laika.home.floam.sh.nu> References: <200604221424.03526.ludwig.nussel@suse.de> <444A5079.5070402@timedoctor.org> <444AAE2B.9070207@icculus.org> <444AC1BD.8070600@timedoctor.org> <1145771676.9677.0.camel@laika.home.floam.sh.nu> <444B19B9.5030908@timedoctor.org> <1145774322.11809.4.camel@laika.home.floam.sh.nu> Message-ID: <444B32FF.30706@timedoctor.org> Aaron Gyes wrote: > On Sat, 2006-04-22 at 23:07 -0700, Zachary J. Slater wrote: >> This list would be the "default owner" of all new projects? > Huh? Why would you want that? Wouldn't you want it to be the default > asignee, the "QA Contact" email for the product, like other projects do? > > Aaron > Er, what I meant to say was that the q3-maintainers list would be the default asignee, which is why I'd rather it is only accessible by maintainers, as opposed to joe q interested person who is then going to go close bugs because he is so cool and knows how to press radio buttons. This (quake3 at i.o) list is really the QA+discussion list, unless it becomes too unwieldy in that respect. -- - Zachary J. Slater zakk at timedoctor.org zacharyslater at gmail.com From tim at ngus.net Sun Apr 23 05:06:19 2006 From: tim at ngus.net (Tim Angus) Date: Sun, 23 Apr 2006 10:06:19 +0100 Subject: mailinglist as default bugzilla component owner? In-Reply-To: <200604221424.03526.ludwig.nussel@suse.de> References: <200604221424.03526.ludwig.nussel@suse.de> Message-ID: <20060423100619.3b0227ce.tim@ngus.net> On Sat, 22 Apr 2006 14:24:03 +0200 Ludwig wrote: > What about setting up a mailinglist/alias (or whatever bugzilla best > practice is) like e.g. quake3-maintainers at icculus.org as default > assignee of quake3 bugs? This way everyone interested would get > notified of new bugs automatically and doesn't need to poll > bugzilla. Sort of related: is there any way to get bugzilla to add a header to the mail it sends which indicates which project/component the bug refers to? If you are involved in more than one i.o bugzilla project there is no way to filter the bugs from each into their own mail folders. From Dietrich_Joerg at t-online.de Sun Apr 23 08:26:30 2006 From: Dietrich_Joerg at t-online.de (Joerg Dietrich) Date: Sun, 23 Apr 2006 14:26:30 +0200 Subject: [quake3] PNG Support In-Reply-To: <1145747518.27402.2.camel@robust.homelinux.net> References: <1145747518.27402.2.camel@robust.homelinux.net> Message-ID: <444B7276.1070501@t-online.de> Robert Lundmark wrote: > Would people find the feature useful? I like the thought because it's > lossless and therefore great if someone else wants to edit or reuse the > graphics. It's also smaller than tga. I would also like to know if ogg > vorbis is supported. Ogg Vorbis is supported, you just need to enable it during compilation. Than you can use Vorbis files as easily as Wav files in your new maps. I even made an oggified Demo-Pak0 for testing purposes. For the PNG-support : I support that! But it would be far more easy to "borrow" the SDL_image implementation of R_LoadImage() from the now defunct quakesrc.org Quake 3 port. SDL_image supports a wide range of image formats even PNG. On this way we could get rid of the local copy of jpeg-lib. I don't want to know how many long since fixed errors hide in there. The only problem are the two JPEG-writing functions in tr_image.c, which should be replaced by calls to the system jpeg-lib, which is anyways linked from SDL_image. Joerg From ludwig.nussel at suse.de Sun Apr 23 08:31:47 2006 From: ludwig.nussel at suse.de (Ludwig Nussel) Date: Sun, 23 Apr 2006 14:31:47 +0200 Subject: [quake3] mailinglist as default bugzilla component owner? In-Reply-To: <444AAE2B.9070207@icculus.org> References: <200604221424.03526.ludwig.nussel@suse.de> <444A5079.5070402@timedoctor.org> <444AAE2B.9070207@icculus.org> Message-ID: <200604231431.47321.ludwig.nussel@suse.de> Ryan C. Gordon wrote: > > I'd be fine with this, I'll bug ryan about it/he'll see it on this ml. > > Any historical reason for -maintainers? Can I call it quake3-bugs instead? We have such lists for some projects at SUSE :-). Depending on how the project works bugs either stay assigned to xy-maintainers all the time or someone regularly looks at new bugs and re-assigns them to individuals. Whether or not the list stays CC'd again depends on the project. There is also a bugzilla feature where a list gets copies of *all* bug changes (the qa contact IIRC). If we want to use that I'd indeed name the account quake3-bugs instead of quake3-maintainers. cu Ludwig -- (o_ Ludwig Nussel //\ SUSE LINUX Products GmbH, Development V_/_ http://www.suse.de/ From ludwig.nussel at suse.de Sun Apr 23 08:42:40 2006 From: ludwig.nussel at suse.de (Ludwig Nussel) Date: Sun, 23 Apr 2006 14:42:40 +0200 Subject: [quake3] PNG Support In-Reply-To: <444B7276.1070501@t-online.de> References: <1145747518.27402.2.camel@robust.homelinux.net> <444B7276.1070501@t-online.de> Message-ID: <200604231442.40653.ludwig.nussel@suse.de> Joerg Dietrich wrote: > [...] > On this way we could get rid of the local copy of jpeg-lib. I don't want > to know how many long since fixed errors hide in there. > The only problem are the two JPEG-writing functions in tr_image.c, which > should be replaced by calls to the system jpeg-lib, which is anyways > linked from SDL_image. The problem is the memory management. Libraries need to use quake3's alloc functions in order to not cause memleaks. It's anything but trivial to make libjpeg do that by using api functions. Aside from that I vote against adding support for all kinds of file formats of the day just for the purpose having a long feature list to show on the website. cu Ludwig -- (o_ Ludwig Nussel //\ SUSE LINUX Products GmbH, Development V_/_ http://www.suse.de/ From robust at gentoo.se Sun Apr 23 09:32:43 2006 From: robust at gentoo.se (Robert Lundmark) Date: Sun, 23 Apr 2006 15:32:43 +0200 Subject: Sound issues with DMIX Message-ID: <1145799163.19461.10.camel@robust.homelinux.net> The problem is in tremulous, but I expect that it's not tremulous specific. I had the same kind of problems when I tried the icculus q3 source. I use alsa 1.0.11 that enables dmix by default. If I use sdl output in tremulous the sound is delayed, but switching to openal solves this temporarily. The problems starts again if I try using another program that uses sound (e.g a music player), then the sound get's delayed again. And it's even worse if I disable dmix, then tremulous stalls and the sound goes into infinite loop. From daniellord at mac.com Sun Apr 23 12:52:00 2006 From: daniellord at mac.com (Daniel Lord) Date: Sun, 23 Apr 2006 09:52:00 -0700 Subject: [quake3] What happened to md5.c? In-Reply-To: <1145799163.19461.10.camel@robust.homelinux.net> References: <1145799163.19461.10.camel@robust.homelinux.net> Message-ID: build from svn fails--md5.c missing (did someone delete it from the source?): I am in the right place... [daniello at mercury.local]$ pwd /Users/daniello/Project/ioQuake/quake3 With the svn contents... [daniello at mercury.local]$ ls BUGS Makefile build id-readme.txt COPYING.txt README code ui ChangeLog TODO cross-make-mingw.sh But no md5.c! [daniello at mercury.local]$ ls code/qcommon/md* code/qcommon/md4.c [daniello at mercury.local]$ find . -regex ".*md5.c" [daniello at mercury.local]$ _nothing_ gcc -mdynamic-no-pic -Wall -fno-strict-aliasing -Wimplicit -Wstrict- prototypes -DMACOS_X -fno-common -pipe -gfull -DUSE_OPENAL=1 - DUSE_SDL_VIDEO=1 -DUSE_SDL_SOUND=1 -D_THREAD_SAFE=1 -Icode/SDL12/ include -DNO_VM_COMPILED -DUSE_LOCAL_HEADERS=1 -DNDEBUG -O3 -ffast- math -falign-loops=16 -MMD -o build/release-darwin-i386/client/md4.o - c code/qcommon/md4.c make[1]: *** No rule to make target `code/qcommon/md5.c', needed by `build/release-darwin-i386/client/md5.o'. Stop. make: *** [build_release] Error 2 From mattst88 at gmail.com Sun Apr 23 13:40:40 2006 From: mattst88 at gmail.com (Matt Turner) Date: Sun, 23 Apr 2006 13:40:40 -0400 Subject: [quake3] PNG Support In-Reply-To: <444B7276.1070501@t-online.de> References: <1145747518.27402.2.camel@robust.homelinux.net> <444B7276.1070501@t-online.de> Message-ID: IIRC, SDL_image supports saving JPEGs. A "IMG_LoadJPG_RW" does exist. Matt On 4/23/06, Joerg Dietrich wrote: > > Robert Lundmark wrote: > > Would people find the feature useful? I like the thought because it's > > lossless and therefore great if someone else wants to edit or reuse the > > graphics. It's also smaller than tga. I would also like to know if ogg > > vorbis is supported. > > Ogg Vorbis is supported, you just need to enable it during compilation. > Than you can use Vorbis files as easily as Wav files in your new maps. > I even made an oggified Demo-Pak0 for testing purposes. > For the PNG-support : I support that! But it would be far more easy > to "borrow" the SDL_image implementation of R_LoadImage() from the > now defunct quakesrc.org Quake 3 port. SDL_image supports a wide range > of image formats even PNG. > On this way we could get rid of the local copy of jpeg-lib. I don't want > to know how many long since fixed errors hide in there. > The only problem are the two JPEG-writing functions in tr_image.c, which > should be replaced by calls to the system jpeg-lib, which is anyways > linked from SDL_image. > > Joerg > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim at ngus.net Sun Apr 23 14:05:41 2006 From: tim at ngus.net (Tim Angus) Date: Sun, 23 Apr 2006 19:05:41 +0100 Subject: What happened to md5.c? In-Reply-To: References: Message-ID: <20060423190541.0b29148e.tim@ngus.net> On Sun, 23 Apr 2006 09:52:00 -0700 Daniel wrote: > build from svn fails--md5.c missing (did someone delete it from the > source?): Oops sorry. Just never added it. From daniellord at mac.com Sun Apr 23 14:42:19 2006 From: daniellord at mac.com (Daniel Lord) Date: Sun, 23 Apr 2006 11:42:19 -0700 Subject: [quake3] Re: What happened to md5.c? In-Reply-To: <20060423190541.0b29148e.tim@ngus.net> References: <20060423190541.0b29148e.tim@ngus.net> Message-ID: Thanks. Got it. Now building. ;-) On Apr 23, 2006, at 11:05, Tim Angus wrote: > On Sun, 23 Apr 2006 09:52:00 -0700 Daniel wrote: >> build from svn fails--md5.c missing (did someone delete it from the >> source?): > > Oops sorry. Just never added it. > From vincent at cojot.name Sun Apr 23 16:33:05 2006 From: vincent at cojot.name (vincent at cojot.name) Date: Sun, 23 Apr 2006 22:33:05 +0200 (CEST) Subject: Small diff Message-ID: Please apply: Index: code/tools/asm/Makefile =================================================================== --- code/tools/asm/Makefile (revision 722) +++ code/tools/asm/Makefile (working copy) @@ -6,7 +6,7 @@ BINEXT= endif -ifeq ($(PLATFORM),SunOS) +ifeq ($(PLATFORM),sunos) INSTALL=ginstall else INSTALL=install Thanks, -- ,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-, Vincent S. Cojot, Computer Engineering. STEP project. _.,-*~'`^`'~*-,._.,-*~ Ecole Polytechnique de Montreal, Comite Micro-Informatique. _.,-*~'`^`'~*-,. Linux Xview/OpenLook resources page _.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~' http://step.polymtl.ca/~coyote _.,-*~'`^`'~*-,._ coyote at NOSPAM4cojot.name They cannot scare me with their empty spaces Between stars - on stars where no human race is I have it in me so much nearer home To scare myself with my own desert places. - Robert Frost From vincent at cojot.name Sun Apr 23 16:34:46 2006 From: vincent at cojot.name (vincent at cojot.name) Date: Sun, 23 Apr 2006 22:34:46 +0200 (CEST) Subject: [quake3] Small diff In-Reply-To: References: Message-ID: On Sun, 23 Apr 2006, vincent at cojot.name wrote: Discard this patch, I found another occurence. Please apply the attached patch... Thanks, Vincent -------------- next part -------------- Index: code/tools/asm/Makefile =================================================================== --- code/tools/asm/Makefile (revision 722) +++ code/tools/asm/Makefile (working copy) @@ -6,7 +6,7 @@ BINEXT= endif -ifeq ($(PLATFORM),SunOS) +ifeq ($(PLATFORM),sunos) INSTALL=ginstall else INSTALL=install Index: code/tools/lcc/Makefile =================================================================== --- code/tools/lcc/Makefile (revision 722) +++ code/tools/lcc/Makefile (working copy) @@ -30,7 +30,7 @@ LCC_CFLAGS += -DMACOS_X endif -ifeq ($(PLATFORM),SunOS) +ifeq ($(PLATFORM),sunos) INSTALL=ginstall else INSTALL=install From ludwig.nussel at suse.de Sun Apr 23 17:00:16 2006 From: ludwig.nussel at suse.de (Ludwig Nussel) Date: Sun, 23 Apr 2006 23:00:16 +0200 Subject: [quake3] Small diff In-Reply-To: References: Message-ID: <200604232300.16923.ludwig.nussel@suse.de> vincent at cojot.name wrote: > On Sun, 23 Apr 2006, vincent at cojot.name wrote: > > Discard this patch, I found another occurence. Please apply the attached > patch... applied, thanks. cu Ludwig -- (o_ Ludwig Nussel //\ SUSE LINUX Products GmbH, Development V_/_ http://www.suse.de/ From icculus at icculus.org Sun Apr 23 22:15:29 2006 From: icculus at icculus.org (Ryan C. Gordon) Date: Sun, 23 Apr 2006 22:15:29 -0400 Subject: [quake3] mailinglist as default bugzilla component owner? In-Reply-To: <200604231431.47321.ludwig.nussel@suse.de> References: <200604221424.03526.ludwig.nussel@suse.de> <444A5079.5070402@timedoctor.org> <444AAE2B.9070207@icculus.org> <200604231431.47321.ludwig.nussel@suse.de> Message-ID: <444C34C1.90802@icculus.org> > We have such lists for some projects at SUSE :-). Depending on how I just wanted to make sure there wasn't some deep Unix tradition I was missing out on. :) > the project works bugs either stay assigned to xy-maintainers all > the time or someone regularly looks at new bugs and re-assigns them > to individuals. Whether or not the list stays CC'd again depends on > the project. There is also a bugzilla feature where a list gets > copies of *all* bug changes (the qa contact IIRC). If we want to use > that I'd indeed name the account quake3-bugs instead of > quake3-maintainers. That's more what I was thinking of...a QA contact that gets a copy of all email traffic from bugzilla, so those that want to track everything can do so, but otherwise it works as usual. I'd limit posting to the list to Bugzilla itself, so people can read it if they want, but all public discussion still has to come here, or be attached to the specific bug. --ryan. From ntoronto at cs.byu.edu Mon Apr 24 01:31:47 2006 From: ntoronto at cs.byu.edu (Neil Toronto) Date: Sun, 23 Apr 2006 23:31:47 -0600 Subject: [quake3] PNG Support In-Reply-To: <200604231442.40653.ludwig.nussel@suse.de> References: <1145747518.27402.2.camel@robust.homelinux.net> <444B7276.1070501@t-online.de> <200604231442.40653.ludwig.nussel@suse.de> Message-ID: <444C62C3.1010309@cs.byu.edu> Ludwig Nussel wrote: >Joerg Dietrich wrote: > > >>[...] >>On this way we could get rid of the local copy of jpeg-lib. I don't want >>to know how many long since fixed errors hide in there. >>The only problem are the two JPEG-writing functions in tr_image.c, which >>should be replaced by calls to the system jpeg-lib, which is anyways >>linked from SDL_image. >> >> > >Aside from that I vote against adding support for all kinds of file >formats of the day just for the purpose having a long feature list >to show on the website. > > > Good show, mate. :/ Presumably, PNG support would exist to provide a lossless compression format, which Quake 3 currently lacks. Quake 3 maps usually have 95% compressed JPGs (whatever 95% meant in whatever software they used to compress them), which can create texture seams on repeating textures, or in places where two textures are *supposed* to match up. In places where it matters, you could use a PNG instead for roughly 3x the size, and it gaurantees you no seams whatsoever. I've spent some time mapping for Q3, and I can tell you unequivocally that the mappers would love this feature. >cu >Ludwig > Neil From daniellord at mac.com Mon Apr 24 02:08:29 2006 From: daniellord at mac.com (Daniel Lord) Date: Sun, 23 Apr 2006 23:08:29 -0700 Subject: [quake3] PNG Support In-Reply-To: <444C62C3.1010309@cs.byu.edu> References: <1145747518.27402.2.camel@robust.homelinux.net> <444B7276.1070501@t-online.de> <200604231442.40653.ludwig.nussel@suse.de> <444C62C3.1010309@cs.byu.edu> Message-ID: On Apr 23, 2006, at 22:31, Neil Toronto wrote: >>> [...] >>> On this way we could get rid of the local copy of jpeg-lib. I >>> don't want to know how many long since fixed errors hide in there. >>> The only problem are the two JPEG-writing functions in >>> tr_image.c, which should be replaced by calls to the system jpeg- >>> lib, which is anyways linked from SDL_image. Don't expect libjpeg to be in there in the system build unless you plan on breaking the OS X port. OS X doesn't ship with libjpeg installed. It doesn't come wth libpng either for that matter. I had to install libjpeg to get a FAT port of the Python Imaging Library (PIL) to work so I know. -------------- next part -------------- An HTML attachment was scrubbed... URL: From arny at ats.s.bawue.de Mon Apr 24 02:59:52 2006 From: arny at ats.s.bawue.de (Thilo Schulz) Date: Mon, 24 Apr 2006 08:59:52 +0200 Subject: [quake3] PNG Support In-Reply-To: <444C62C3.1010309@cs.byu.edu> References: <1145747518.27402.2.camel@robust.homelinux.net> <200604231442.40653.ludwig.nussel@suse.de> <444C62C3.1010309@cs.byu.edu> Message-ID: <200604240859.58493.arny@ats.s.bawue.de> On Monday 24 April 2006 07:31, Neil Toronto wrote: > I've spent some time mapping for Q3, and I can tell you unequivocally > that the mappers would love this feature. ... once PNG support has been added to the radiant as well ... -- Thilo Schulz -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bnoordhuis at gmail.com Mon Apr 24 05:40:37 2006 From: bnoordhuis at gmail.com (Ben Noordhuis) Date: Mon, 24 Apr 2006 11:40:37 +0200 Subject: [quake3] Sound issues with DMIX In-Reply-To: <1145799163.19461.10.camel@robust.homelinux.net> References: <1145799163.19461.10.camel@robust.homelinux.net> Message-ID: <54885e060604240240q4277068i4ac0a22fb756bec2@mail.gmail.com> This sounds like the behaviour I got when my setup of ALSA got corrupted. Configure ALSA as described here (esp. part 6): http://alsa.opensrc.org/index.php?page=DmixPlugin Make sure buffer_size is at least 4K and a multiple of two; dmix becomes quite quirky otherwise. From ntoronto at cs.byu.edu Mon Apr 24 11:20:02 2006 From: ntoronto at cs.byu.edu (Neil Toronto) Date: Mon, 24 Apr 2006 09:20:02 -0600 Subject: [quake3] PNG Support In-Reply-To: <200604240859.58493.arny@ats.s.bawue.de> References: <1145747518.27402.2.camel@robust.homelinux.net> <200604231442.40653.ludwig.nussel@suse.de> <444C62C3.1010309@cs.byu.edu> <200604240859.58493.arny@ats.s.bawue.de> Message-ID: <444CECA2.7060705@cs.byu.edu> Thilo Schulz wrote: >On Monday 24 April 2006 07:31, Neil Toronto wrote: > > >>I've spent some time mapping for Q3, and I can tell you unequivocally >>that the mappers would love this feature. >> >> > >... once PNG support has been added to the radiant as well ... > > > Good point. From defsyn at gmail.com Mon Apr 24 17:32:16 2006 From: defsyn at gmail.com (Henry Garcia) Date: Mon, 24 Apr 2006 17:32:16 -0400 Subject: MingW not compiling for the last few subversions: Message-ID: Here's part of the std and stderr output: gcc -Wall -fno-strict-aliasing -Wimplicit -Wstrict-prototypes -DUSE_OPENAL=1 -DUSE_OPENAL_DLOPEN=1 -m32 -DUSE_LOCAL_HEADERS=1 -DNDEBUG -O3 -march=i586 -fomit-frame-pointer -ffast-math -falign-loops=2 -funroll-loops -falign-jumps=2 -falign-functions=2 -fstrength-reduce -MMD -o build/release-mingw32-x86/client/tr_image.o -c code/renderer/tr_image.c -DDONT_TYPEDEF_INT32 code/renderer/tr_image.c: In function `Upload32': code/renderer/tr_image.c:703: error: `GL_TEXTURE_MAX_ANISOTROPY_EXT' undeclared (first use in this function) code/renderer/tr_image.c:703: error: (Each undeclared identifier is reported only once code/renderer/tr_image.c:703: error: for each function it appears in.) make[1]: *** [build/release-mingw32-x86/client/tr_image.o] Error 1 make[1]: Leaving directory `/cygdrive/c/msys/1.0/home/Henry/programs/quake/quake3' make: *** [build_release] Error 2 Been doing this for about the last 6 or so subversions. Hank -------------- next part -------------- An HTML attachment was scrubbed... URL: From mattst88 at gmail.com Tue Apr 25 21:17:04 2006 From: mattst88 at gmail.com (Matt Turner) Date: Tue, 25 Apr 2006 21:17:04 -0400 Subject: [quake3] MingW not compiling for the last few subversions: In-Reply-To: References: Message-ID: I ran into this a few days ago. All that needs to be added is "#include " in renderer/tr_image.c and win32/win_glimp.c. Attached is a diff to fix this. I'm unsure if there's a particular style of patches/code that should be adhered to, so someone review it. Matt On 4/24/06, Henry Garcia wrote: > > Here's part of the std and stderr output: > > gcc -Wall -fno-strict-aliasing -Wimplicit -Wstrict-prototypes > -DUSE_OPENAL=1 -DUSE_OPENAL_DLOPEN=1 -m32 -DUSE_LOCAL_HEADERS=1 -DNDEBUG -O3 > -march=i586 -fomit-frame-pointer -ffast-math -falign-loops=2 -funroll-loops > -falign-jumps=2 -falign-functions=2 -fstrength-reduce -MMD -o > build/release-mingw32-x86/client/tr_image.o -c code/renderer/tr_image.c > -DDONT_TYPEDEF_INT32 > code/renderer/tr_image.c: In function `Upload32': > code/renderer/tr_image.c:703: error: `GL_TEXTURE_MAX_ANISOTROPY_EXT' > undeclared (first use in this function) > code/renderer/tr_image.c:703: error: (Each undeclared identifier is > reported only once > code/renderer/tr_image.c:703: error: for each function it appears in.) > make[1]: *** [build/release-mingw32-x86/client/tr_image.o] Error 1 > make[1]: Leaving directory > `/cygdrive/c/msys/1.0/home/Henry/programs/quake/quake3' > make: *** [build_release] Error 2 > > Been doing this for about the last 6 or so subversions. > > Hank > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: include_glext.h.diff Type: application/octet-stream Size: 768 bytes Desc: not available URL: From auerswal at unix-ag.uni-kl.de Wed Apr 26 08:43:20 2006 From: auerswal at unix-ag.uni-kl.de (Erik Auerswald) Date: Wed, 26 Apr 2006 14:43:20 +0200 Subject: [PATCH] replacing "baseq3" by BASEGAME Message-ID: <20060426124320.GA5471@sushi.unix-ag.uni-kl.de> Hi, Thilo has started to replace the string literal "baseq3" by the macro BASEGAME. By moving the macro definition from qcommon/qcommon.h to qcoomon/q_shared.h the remaining string literals can be eliminated. Erik -------------- next part -------------- Index: code/qcommon/q_shared.h =================================================================== --- code/qcommon/q_shared.h (revision 725) +++ code/qcommon/q_shared.h (working copy) @@ -33,6 +33,8 @@ #define CONSOLE_WINDOW_ICON "ioq3 console" // 1.32 released 7-10-2002 +#define BASEGAME "baseq3" + #define MAX_TEAMNAME 32 #ifdef _MSC_VER Index: code/qcommon/qcommon.h =================================================================== --- code/qcommon/qcommon.h (revision 725) +++ code/qcommon/qcommon.h (working copy) @@ -535,8 +535,6 @@ #define MAX_FILE_HANDLES 64 -#define BASEGAME "baseq3" - qboolean FS_Initialized( void ); void FS_InitFilesystem ( void ); Index: code/game/g_local.h =================================================================== --- code/game/g_local.h (revision 725) +++ code/game/g_local.h (working copy) @@ -29,7 +29,7 @@ //================================================================== // the "gameversion" client command will print this plus compile date -#define GAMEVERSION "baseq3" +#define GAMEVERSION BASEGAME #define BODY_QUEUE_SIZE 8 Index: code/game/bg_public.h =================================================================== --- code/game/bg_public.h (revision 725) +++ code/game/bg_public.h (working copy) @@ -25,7 +25,7 @@ // because games can change separately from the main system version, we need a // second version that must match between game and cgame -#define GAME_VERSION "baseq3-1" +#define GAME_VERSION BASEGAME "-1" #define DEFAULT_GRAVITY 800 #define GIB_HEALTH -40 Index: code/botlib/be_interface.c =================================================================== --- code/botlib/be_interface.c (revision 725) +++ code/botlib/be_interface.c (working copy) @@ -150,7 +150,7 @@ Com_sprintf(logfilename, sizeof(logfilename), "%s%c%s%cbotlib.log", homedir, PATH_SEP, gamedir, PATH_SEP); } else { - Com_sprintf(logfilename, sizeof(logfilename), "%s%cbaseq3%cbotlib.log", homedir, PATH_SEP, PATH_SEP); + Com_sprintf(logfilename, sizeof(logfilename), "%s%c" BASEGAME "%cbotlib.log", homedir, PATH_SEP, PATH_SEP); } } else { Com_sprintf(logfilename, sizeof(logfilename), "botlib.log"); From arny at ats.s.bawue.de Wed Apr 26 09:45:16 2006 From: arny at ats.s.bawue.de (Thilo Schulz) Date: Wed, 26 Apr 2006 15:45:16 +0200 Subject: md5.c is not 64 bit-safe. Message-ID: <200604261545.19760.arny@ats.s.bawue.de> Hello, I have commented: Cvar_Get("cl_guid", Com_MD5File(QKEY_FILE, 0), CVAR_USERINFO | CVAR_ROM); in cl_main.c because the MD5 hash generation functions are *not* 64 bit safe and crashes amd64 builds. The crux seems to be at line 272 in md5.c: /* Append length in bits and transform */ ((unsigned long int *) ctx->in)[14] = ctx->bits[0]; ((unsigned long int *) ctx->in)[15] = ctx->bits[1]; In GCC sizeof(long int) is 8 bytes on 64 bit platforms but only 4 bytes on 32 bit platforms. This means because of unsigned char in[64]; the program writes somewhere it shouldn't. -- Thilo Schulz -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From arny at ats.s.bawue.de Wed Apr 26 09:46:35 2006 From: arny at ats.s.bawue.de (Thilo Schulz) Date: Wed, 26 Apr 2006 15:46:35 +0200 Subject: [quake3] [PATCH] replacing "baseq3" by BASEGAME In-Reply-To: <20060426124320.GA5471@sushi.unix-ag.uni-kl.de> References: <20060426124320.GA5471@sushi.unix-ag.uni-kl.de> Message-ID: <200604261546.38139.arny@ats.s.bawue.de> On Wednesday 26 April 2006 14:43, Erik Auerswald wrote: > Thilo has started to replace the string literal "baseq3" by the macro > BASEGAME. By moving the macro definition from qcommon/qcommon.h to > qcoomon/q_shared.h the remaining string literals can be eliminated. Committed, thanks :) -- Thilo Schulz -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tjw at webteam.net Wed Apr 26 11:11:40 2006 From: tjw at webteam.net (Tony J. White) Date: Wed, 26 Apr 2006 10:11:40 -0500 Subject: [quake3] md5.c is not 64 bit-safe. In-Reply-To: <200604261545.19760.arny@ats.s.bawue.de> References: <200604261545.19760.arny@ats.s.bawue.de> Message-ID: <20060426151140.GB14550@morbo.webteam.net> On Wed, Apr 26, 2006 at 03:45:16PM +0200, Thilo Schulz wrote: > /* Append length in bits and transform */ > ((unsigned long int *) ctx->in)[14] = ctx->bits[0]; > ((unsigned long int *) ctx->in)[15] = ctx->bits[1]; > > In GCC sizeof(long int) is 8 bytes on 64 bit platforms but only 4 bytes on 32 > bit platforms. Sorry. Could someone with a 64-bit platform please test the attached patch for md5.c? I used the same uint32 defines from md4.c so I assume it works for determining that type on all build targets. -Tony -- -------------- next part -------------- Index: code/qcommon/md5.c =================================================================== --- code/qcommon/md5.c (revision 726) +++ code/qcommon/md5.c (working copy) @@ -17,9 +17,17 @@ #include "q_shared.h" #include "qcommon.h" +#ifndef int32 +#define int32 int +#endif + +#ifndef uint32 +#define uint32 unsigned int32 +#endif + typedef struct MD5Context { - unsigned long int buf[4]; - unsigned long int bits[2]; + uint32 buf[4]; + uint32 bits[2]; unsigned char in[64]; } MD5_CTX; @@ -33,12 +41,12 @@ */ static void byteReverse(unsigned char *buf, unsigned longs) { - unsigned long int t; + uint32 t; do { - t = (unsigned long int) + t = (uint32) ((unsigned) buf[3] << 8 | buf[2]) << 16 | ((unsigned) buf[1] << 8 | buf[0]); - *(unsigned long int *) buf = t; + *(uint32 *) buf = t; buf += 4; } while (--longs); } @@ -75,10 +83,10 @@ * reflect the addition of 16 longwords of new data. MD5Update blocks * the data and converts bytes into longwords for this routine. */ -static void MD5Transform(unsigned long int buf[4], - unsigned long int const in[16]) +static void MD5Transform(uint32 buf[4], + uint32 const in[16]) { - register unsigned long int a, b, c, d; + register uint32 a, b, c, d; a = buf[0]; b = buf[1]; @@ -166,12 +174,12 @@ static void MD5Update(struct MD5Context *ctx, unsigned char const *buf, unsigned len) { - register unsigned long int t; + register uint32 t; /* Update bitcount */ t = ctx->bits[0]; - if ((ctx->bits[0] = t + ((unsigned long int) len << 3)) < t) + if ((ctx->bits[0] = t + ((uint32) len << 3)) < t) ctx->bits[1]++; /* Carry from low to high */ ctx->bits[1] += len >> 29; @@ -189,7 +197,7 @@ } memcpy(p, buf, t); byteReverse(ctx->in, 16); - MD5Transform(ctx->buf, (unsigned long int *) ctx->in); + MD5Transform(ctx->buf, (uint32 *) ctx->in); buf += t; len -= t; } @@ -198,7 +206,7 @@ while (len >= 64) { memcpy(ctx->in, buf, 64); byteReverse(ctx->in, 16); - MD5Transform(ctx->buf, (unsigned long int *) ctx->in); + MD5Transform(ctx->buf, (uint32 *) ctx->in); buf += 64; len -= 64; } @@ -215,7 +223,7 @@ */ static void MD5Final(struct MD5Context *ctx, unsigned char *digest) { - unsigned long int count; + uint32 count; unsigned char *p; /* Compute number of bytes mod 64 */ @@ -234,7 +242,7 @@ /* Two lots of padding: Pad the first block to 64 bytes */ memset(p, 0, count); byteReverse(ctx->in, 16); - MD5Transform(ctx->buf, (unsigned long int *) ctx->in); + MD5Transform(ctx->buf, (uint32 *) ctx->in); /* Now fill the next block with 56 bytes */ memset(ctx->in, 0, 56); @@ -245,10 +253,10 @@ byteReverse(ctx->in, 14); /* Append length in bits and transform */ - ((unsigned long int *) ctx->in)[14] = ctx->bits[0]; - ((unsigned long int *) ctx->in)[15] = ctx->bits[1]; + ((uint32 *) ctx->in)[14] = ctx->bits[0]; + ((uint32 *) ctx->in)[15] = ctx->bits[1]; - MD5Transform(ctx->buf, (unsigned long int *) ctx->in); + MD5Transform(ctx->buf, (uint32 *) ctx->in); byteReverse((unsigned char *) ctx->buf, 4); if (digest!=NULL) Index: code/client/cl_main.c =================================================================== --- code/client/cl_main.c (revision 726) +++ code/client/cl_main.c (working copy) @@ -2549,8 +2549,7 @@ Cvar_Set( "cl_running", "1" ); CL_GenerateQKey(); -// Uncomment this once md5.c has been made 64 bit-safe. -// Cvar_Get("cl_guid", Com_MD5File(QKEY_FILE, 0), CVAR_USERINFO | CVAR_ROM); + Cvar_Get("cl_guid", Com_MD5File(QKEY_FILE, 0), CVAR_USERINFO | CVAR_ROM); Com_Printf( "----- Client Initialization Complete -----\n" ); } From auerswal at unix-ag.uni-kl.de Wed Apr 26 11:35:52 2006 From: auerswal at unix-ag.uni-kl.de (Erik Auerswald) Date: Wed, 26 Apr 2006 17:35:52 +0200 Subject: [quake3] md5.c is not 64 bit-safe. In-Reply-To: <20060426151140.GB14550@morbo.webteam.net> References: <200604261545.19760.arny@ats.s.bawue.de> <20060426151140.GB14550@morbo.webteam.net> Message-ID: <20060426153551.GA24795@sushi.unix-ag.uni-kl.de> Hi, On Wed, Apr 26, 2006 at 10:11:40AM -0500, Tony J. White wrote: > On Wed, Apr 26, 2006 at 03:45:16PM +0200, Thilo Schulz wrote: > > In GCC sizeof(long int) is 8 bytes on 64 bit platforms but only 4 bytes > > on 32 bit platforms. > > Sorry. > > Could someone with a 64-bit platform please test the attached patch for md5.c? > > I used the same uint32 defines from md4.c so I assume it works for determining > that type on all build targets. In the file server/sv_rankings.c uint32_t is used, so maybe this could be used instead since an int might be larger than 4 bytes (which is checked in qcommon/md4.c). Replacing every "unsigned long int" by "uint32_t" in qcommon/md5.c compiles on linux/x86 (32bit), I can't check any other platform. I did _not_ check every integer type in that file for size assumptions, so a simple search and replace might not be enough. Erik From arny at ats.s.bawue.de Wed Apr 26 11:50:18 2006 From: arny at ats.s.bawue.de (Thilo Schulz) Date: Wed, 26 Apr 2006 17:50:18 +0200 Subject: [quake3] md5.c is not 64 bit-safe. In-Reply-To: <20060426153551.GA24795@sushi.unix-ag.uni-kl.de> References: <200604261545.19760.arny@ats.s.bawue.de> <20060426151140.GB14550@morbo.webteam.net> <20060426153551.GA24795@sushi.unix-ag.uni-kl.de> Message-ID: <200604261750.20939.arny@ats.s.bawue.de> On Wednesday 26 April 2006 17:35, Erik Auerswald wrote: > In the file server/sv_rankings.c uint32_t is used, so maybe this could > be used instead since an int might be larger than 4 bytes (which is > checked in qcommon/md4.c). if you peek into the Makefile and search for sv_rankings.c you'll notice that file will never get compiled. -- Thilo Schulz -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tjw at webteam.net Wed Apr 26 12:20:23 2006 From: tjw at webteam.net (Tony J. White) Date: Wed, 26 Apr 2006 11:20:23 -0500 Subject: [quake3] md5.c is not 64 bit-safe. In-Reply-To: <20060426153551.GA24795@sushi.unix-ag.uni-kl.de> References: <200604261545.19760.arny@ats.s.bawue.de> <20060426151140.GB14550@morbo.webteam.net> <20060426153551.GA24795@sushi.unix-ag.uni-kl.de> Message-ID: <20060426162023.GC14550@morbo.webteam.net> On Wed, Apr 26, 2006 at 05:35:52PM +0200, Erik Auerswald wrote: > In the file server/sv_rankings.c uint32_t is used, so maybe this could > be used instead since an int might be larger than 4 bytes (which is > checked in qcommon/md4.c). As long as it's used once already, it won't be my fault if it's undefined for someone, right? :) > Replacing every "unsigned long int" by "uint32_t" in qcommon/md5.c > compiles on linux/x86 (32bit), I can't check any other platform. I did > _not_ check every integer type in that file for size assumptions, so a > simple search and replace might not be enough. Yeah, uint32_t seems like the way to go. I've compared md5.c with the one from the asterisk project (which apperantly has good 64-bit support) and it's equivalent. http://www.asterisk.org/doxygen/md5_8c-source.html Attached patch uses uint32_t as well as some other variable-typing changes taken from the asterisk version. -Tony -------------- next part -------------- Index: code/qcommon/md5.c =================================================================== --- code/qcommon/md5.c (revision 726) +++ code/qcommon/md5.c (working copy) @@ -18,8 +18,8 @@ #include "qcommon.h" typedef struct MD5Context { - unsigned long int buf[4]; - unsigned long int bits[2]; + uint32_t buf[4]; + uint32_t bits[2]; unsigned char in[64]; } MD5_CTX; @@ -33,12 +33,12 @@ */ static void byteReverse(unsigned char *buf, unsigned longs) { - unsigned long int t; + uint32_t t; do { - t = (unsigned long int) + t = (uint32_t) ((unsigned) buf[3] << 8 | buf[2]) << 16 | ((unsigned) buf[1] << 8 | buf[0]); - *(unsigned long int *) buf = t; + *(uint32_t *) buf = t; buf += 4; } while (--longs); } @@ -75,10 +75,10 @@ * reflect the addition of 16 longwords of new data. MD5Update blocks * the data and converts bytes into longwords for this routine. */ -static void MD5Transform(unsigned long int buf[4], - unsigned long int const in[16]) +static void MD5Transform(uint32_t buf[4], + uint32_t const in[16]) { - register unsigned long int a, b, c, d; + register uint32_t a, b, c, d; a = buf[0]; b = buf[1]; @@ -166,12 +166,12 @@ static void MD5Update(struct MD5Context *ctx, unsigned char const *buf, unsigned len) { - register unsigned long int t; + uint32_t t; /* Update bitcount */ t = ctx->bits[0]; - if ((ctx->bits[0] = t + ((unsigned long int) len << 3)) < t) + if ((ctx->bits[0] = t + ((uint32_t) len << 3)) < t) ctx->bits[1]++; /* Carry from low to high */ ctx->bits[1] += len >> 29; @@ -189,7 +189,7 @@ } memcpy(p, buf, t); byteReverse(ctx->in, 16); - MD5Transform(ctx->buf, (unsigned long int *) ctx->in); + MD5Transform(ctx->buf, (uint32_t *) ctx->in); buf += t; len -= t; } @@ -198,7 +198,7 @@ while (len >= 64) { memcpy(ctx->in, buf, 64); byteReverse(ctx->in, 16); - MD5Transform(ctx->buf, (unsigned long int *) ctx->in); + MD5Transform(ctx->buf, (uint32_t *) ctx->in); buf += 64; len -= 64; } @@ -215,7 +215,7 @@ */ static void MD5Final(struct MD5Context *ctx, unsigned char *digest) { - unsigned long int count; + unsigned count; unsigned char *p; /* Compute number of bytes mod 64 */ @@ -234,7 +234,7 @@ /* Two lots of padding: Pad the first block to 64 bytes */ memset(p, 0, count); byteReverse(ctx->in, 16); - MD5Transform(ctx->buf, (unsigned long int *) ctx->in); + MD5Transform(ctx->buf, (uint32_t *) ctx->in); /* Now fill the next block with 56 bytes */ memset(ctx->in, 0, 56); @@ -245,15 +245,15 @@ byteReverse(ctx->in, 14); /* Append length in bits and transform */ - ((unsigned long int *) ctx->in)[14] = ctx->bits[0]; - ((unsigned long int *) ctx->in)[15] = ctx->bits[1]; + ((uint32_t *) ctx->in)[14] = ctx->bits[0]; + ((uint32_t *) ctx->in)[15] = ctx->bits[1]; - MD5Transform(ctx->buf, (unsigned long int *) ctx->in); + MD5Transform(ctx->buf, (uint32_t *) ctx->in); byteReverse((unsigned char *) ctx->buf, 4); if (digest!=NULL) memcpy(digest, ctx->buf, 16); - //memset(ctx, 0, sizeof(ctx)); /* In case it's sensitive */ + memset(ctx, 0, sizeof(ctx)); /* In case it's sensitive */ } Index: code/client/cl_main.c =================================================================== --- code/client/cl_main.c (revision 726) +++ code/client/cl_main.c (working copy) @@ -2549,8 +2549,7 @@ Cvar_Set( "cl_running", "1" ); CL_GenerateQKey(); -// Uncomment this once md5.c has been made 64 bit-safe. -// Cvar_Get("cl_guid", Com_MD5File(QKEY_FILE, 0), CVAR_USERINFO | CVAR_ROM); + Cvar_Get("cl_guid", Com_MD5File(QKEY_FILE, 0), CVAR_USERINFO | CVAR_ROM); Com_Printf( "----- Client Initialization Complete -----\n" ); } From tjw at webteam.net Wed Apr 26 12:33:03 2006 From: tjw at webteam.net (Tony J. White) Date: Wed, 26 Apr 2006 11:33:03 -0500 Subject: [quake3] md5.c is not 64 bit-safe. In-Reply-To: <200604261750.20939.arny@ats.s.bawue.de> References: <200604261545.19760.arny@ats.s.bawue.de> <20060426151140.GB14550@morbo.webteam.net> <20060426153551.GA24795@sushi.unix-ag.uni-kl.de> <200604261750.20939.arny@ats.s.bawue.de> Message-ID: <20060426163302.GD14550@morbo.webteam.net> On Wed, Apr 26, 2006 at 05:50:18PM +0200, Thilo Schulz wrote: > On Wednesday 26 April 2006 17:35, Erik Auerswald wrote: > > In the file server/sv_rankings.c uint32_t is used, so maybe this could > > be used instead since an int might be larger than 4 bytes (which is > > checked in qcommon/md4.c). > > if you peek into the Makefile and search for sv_rankings.c you'll notice that > file will never get compiled. Yeah it appears that uint32_t isn't supported by (at least) Microsoft yet because it's from a C99 standard. At least one more patch coming I guess :) -Tony From tjw at webteam.net Wed Apr 26 16:02:27 2006 From: tjw at webteam.net (Tony J. White) Date: Wed, 26 Apr 2006 15:02:27 -0500 Subject: [quake3] md5.c is not 64 bit-safe. In-Reply-To: <200604261750.20939.arny@ats.s.bawue.de> References: <200604261545.19760.arny@ats.s.bawue.de> <20060426151140.GB14550@morbo.webteam.net> <20060426153551.GA24795@sushi.unix-ag.uni-kl.de> <200604261750.20939.arny@ats.s.bawue.de> Message-ID: <20060426200227.GG14550@morbo.webteam.net> On Wed, Apr 26, 2006 at 05:50:18PM +0200, Thilo Schulz wrote: > On Wednesday 26 April 2006 17:35, Erik Auerswald wrote: > > In the file server/sv_rankings.c uint32_t is used, so maybe this could > > be used instead since an int might be larger than 4 bytes (which is > > checked in qcommon/md4.c). Looking at md4, I don't think the check for integers greater that 4 bytes even works since it depends on SIZEOF_INT being defined, which doesn't seem to be any type of standard at all. In fact I think it might be a reference to a former autoconf generated define that that file used to live under. > if you peek into the Makefile and search for sv_rankings.c you'll notice that > file will never get compiled. This current patch uses uint32_t in both md5.c and md4.c. It adds the uint32_t type in q_shared.h so if sv_rankings.c is ever added back it should be valid. This means that either C99 compatible build environment, or a Microsoft one is required (which doesn't seem too out of line). In the case of Microsoft, it uses: typedef unsigned __int32 uint32_t; Which seems to be the Microsoft Way(tm). It at least should work under VC++ 6.0 and newer. -Tony -------------- next part -------------- Index: code/qcommon/md4.c =================================================================== --- code/qcommon/md4.c (revision 726) +++ code/qcommon/md4.c (working copy) @@ -30,21 +30,9 @@ #include "q_shared.h" #include "qcommon.h" -#ifndef int32 -#define int32 int -#endif - -#if SIZEOF_INT > 4 -#define LARGE_INT32 -#endif - -#ifndef uint32 -#define uint32 unsigned int32 -#endif - struct mdfour { - uint32 A, B, C, D; - uint32 totalN; + uint32_t A, B, C, D; + uint32_t totalN; }; @@ -58,23 +46,19 @@ #define F(X,Y,Z) (((X)&(Y)) | ((~(X))&(Z))) #define G(X,Y,Z) (((X)&(Y)) | ((X)&(Z)) | ((Y)&(Z))) #define H(X,Y,Z) ((X)^(Y)^(Z)) -#ifdef LARGE_INT32 -#define lshift(x,s) ((((x)<<(s))&0xFFFFFFFF) | (((x)>>(32-(s)))&0xFFFFFFFF)) -#else #define lshift(x,s) (((x)<<(s)) | ((x)>>(32-(s)))) -#endif #define ROUND1(a,b,c,d,k,s) a = lshift(a + F(b,c,d) + X[k], s) #define ROUND2(a,b,c,d,k,s) a = lshift(a + G(b,c,d) + X[k] + 0x5A827999,s) #define ROUND3(a,b,c,d,k,s) a = lshift(a + H(b,c,d) + X[k] + 0x6ED9EBA1,s) /* this applies md4 to 64 byte chunks */ -static void mdfour64(uint32 *M) +static void mdfour64(uint32_t *M) { int j; - uint32 AA, BB, CC, DD; - uint32 X[16]; - uint32 A,B,C,D; + uint32_t AA, BB, CC, DD; + uint32_t X[16]; + uint32_t A,B,C,D; for (j=0;j<16;j++) X[j] = M[j]; @@ -111,18 +95,13 @@ A += AA; B += BB; C += CC; D += DD; -#ifdef LARGE_INT32 - A &= 0xFFFFFFFF; B &= 0xFFFFFFFF; - C &= 0xFFFFFFFF; D &= 0xFFFFFFFF; -#endif - for (j=0;j<16;j++) X[j] = 0; m->A = A; m->B = B; m->C = C; m->D = D; } -static void copy64(uint32 *M, byte *in) +static void copy64(uint32_t *M, byte *in) { int i; @@ -131,7 +110,7 @@ (in[i*4+1]<<8) | (in[i*4+0]<<0); } -static void copy4(byte *out,uint32 x) +static void copy4(byte *out,uint32_t x) { out[0] = x&0xFF; out[1] = (x>>8)&0xFF; @@ -152,8 +131,8 @@ static void mdfour_tail(byte *in, int n) { byte buf[128]; - uint32 M[16]; - uint32 b; + uint32_t M[16]; + uint32_t b; m->totalN += n; @@ -178,7 +157,7 @@ static void mdfour_update(struct mdfour *md, byte *in, int n) { - uint32 M[16]; + uint32_t M[16]; if (n == 0) mdfour_tail(in, n); Index: code/qcommon/md5.c =================================================================== --- code/qcommon/md5.c (revision 726) +++ code/qcommon/md5.c (working copy) @@ -18,8 +18,8 @@ #include "qcommon.h" typedef struct MD5Context { - unsigned long int buf[4]; - unsigned long int bits[2]; + uint32_t buf[4]; + uint32_t bits[2]; unsigned char in[64]; } MD5_CTX; @@ -33,12 +33,12 @@ */ static void byteReverse(unsigned char *buf, unsigned longs) { - unsigned long int t; + uint32_t t; do { - t = (unsigned long int) + t = (uint32_t) ((unsigned) buf[3] << 8 | buf[2]) << 16 | ((unsigned) buf[1] << 8 | buf[0]); - *(unsigned long int *) buf = t; + *(uint32_t *) buf = t; buf += 4; } while (--longs); } @@ -75,10 +75,10 @@ * reflect the addition of 16 longwords of new data. MD5Update blocks * the data and converts bytes into longwords for this routine. */ -static void MD5Transform(unsigned long int buf[4], - unsigned long int const in[16]) +static void MD5Transform(uint32_t buf[4], + uint32_t const in[16]) { - register unsigned long int a, b, c, d; + register uint32_t a, b, c, d; a = buf[0]; b = buf[1]; @@ -166,12 +166,12 @@ static void MD5Update(struct MD5Context *ctx, unsigned char const *buf, unsigned len) { - register unsigned long int t; + uint32_t t; /* Update bitcount */ t = ctx->bits[0]; - if ((ctx->bits[0] = t + ((unsigned long int) len << 3)) < t) + if ((ctx->bits[0] = t + ((uint32_t) len << 3)) < t) ctx->bits[1]++; /* Carry from low to high */ ctx->bits[1] += len >> 29; @@ -189,7 +189,7 @@ } memcpy(p, buf, t); byteReverse(ctx->in, 16); - MD5Transform(ctx->buf, (unsigned long int *) ctx->in); + MD5Transform(ctx->buf, (uint32_t *) ctx->in); buf += t; len -= t; } @@ -198,7 +198,7 @@ while (len >= 64) { memcpy(ctx->in, buf, 64); byteReverse(ctx->in, 16); - MD5Transform(ctx->buf, (unsigned long int *) ctx->in); + MD5Transform(ctx->buf, (uint32_t *) ctx->in); buf += 64; len -= 64; } @@ -215,7 +215,7 @@ */ static void MD5Final(struct MD5Context *ctx, unsigned char *digest) { - unsigned long int count; + unsigned count; unsigned char *p; /* Compute number of bytes mod 64 */ @@ -234,7 +234,7 @@ /* Two lots of padding: Pad the first block to 64 bytes */ memset(p, 0, count); byteReverse(ctx->in, 16); - MD5Transform(ctx->buf, (unsigned long int *) ctx->in); + MD5Transform(ctx->buf, (uint32_t *) ctx->in); /* Now fill the next block with 56 bytes */ memset(ctx->in, 0, 56); @@ -245,15 +245,15 @@ byteReverse(ctx->in, 14); /* Append length in bits and transform */ - ((unsigned long int *) ctx->in)[14] = ctx->bits[0]; - ((unsigned long int *) ctx->in)[15] = ctx->bits[1]; + ((uint32_t *) ctx->in)[14] = ctx->bits[0]; + ((uint32_t *) ctx->in)[15] = ctx->bits[1]; - MD5Transform(ctx->buf, (unsigned long int *) ctx->in); + MD5Transform(ctx->buf, (uint32_t *) ctx->in); byteReverse((unsigned char *) ctx->buf, 4); if (digest!=NULL) memcpy(digest, ctx->buf, 16); - //memset(ctx, 0, sizeof(ctx)); /* In case it's sensitive */ + memset(ctx, 0, sizeof(ctx)); /* In case it's sensitive */ } Index: code/qcommon/q_shared.h =================================================================== --- code/qcommon/q_shared.h (revision 726) +++ code/qcommon/q_shared.h (working copy) @@ -113,6 +113,8 @@ #else # ifndef _MSC_VER # include +# else + typedef uint32_t unsigned __int32; # endif #endif Index: code/client/cl_main.c =================================================================== --- code/client/cl_main.c (revision 726) +++ code/client/cl_main.c (working copy) @@ -2549,8 +2549,7 @@ Cvar_Set( "cl_running", "1" ); CL_GenerateQKey(); -// Uncomment this once md5.c has been made 64 bit-safe. -// Cvar_Get("cl_guid", Com_MD5File(QKEY_FILE, 0), CVAR_USERINFO | CVAR_ROM); + Cvar_Get("cl_guid", Com_MD5File(QKEY_FILE, 0), CVAR_USERINFO | CVAR_ROM); Com_Printf( "----- Client Initialization Complete -----\n" ); } From tjw at webteam.net Wed Apr 26 16:14:32 2006 From: tjw at webteam.net (Tony J. White) Date: Wed, 26 Apr 2006 15:14:32 -0500 Subject: [quake3] md5.c is not 64 bit-safe. In-Reply-To: <20060426200227.GG14550@morbo.webteam.net> References: <200604261545.19760.arny@ats.s.bawue.de> <20060426151140.GB14550@morbo.webteam.net> <20060426153551.GA24795@sushi.unix-ag.uni-kl.de> <200604261750.20939.arny@ats.s.bawue.de> <20060426200227.GG14550@morbo.webteam.net> Message-ID: <20060426201432.GH14550@morbo.webteam.net> On Wed, Apr 26, 2006 at 03:02:27PM -0500, Tony J. White wrote: > In the case of Microsoft, it uses: > typedef unsigned __int32 uint32_t; Ugh, I had a typo in that patch. Sorry for the spam, I do hope this is the last. -------------- next part -------------- Index: code/qcommon/md4.c =================================================================== --- code/qcommon/md4.c (revision 726) +++ code/qcommon/md4.c (working copy) @@ -30,21 +30,9 @@ #include "q_shared.h" #include "qcommon.h" -#ifndef int32 -#define int32 int -#endif - -#if SIZEOF_INT > 4 -#define LARGE_INT32 -#endif - -#ifndef uint32 -#define uint32 unsigned int32 -#endif - struct mdfour { - uint32 A, B, C, D; - uint32 totalN; + uint32_t A, B, C, D; + uint32_t totalN; }; @@ -58,23 +46,19 @@ #define F(X,Y,Z) (((X)&(Y)) | ((~(X))&(Z))) #define G(X,Y,Z) (((X)&(Y)) | ((X)&(Z)) | ((Y)&(Z))) #define H(X,Y,Z) ((X)^(Y)^(Z)) -#ifdef LARGE_INT32 -#define lshift(x,s) ((((x)<<(s))&0xFFFFFFFF) | (((x)>>(32-(s)))&0xFFFFFFFF)) -#else #define lshift(x,s) (((x)<<(s)) | ((x)>>(32-(s)))) -#endif #define ROUND1(a,b,c,d,k,s) a = lshift(a + F(b,c,d) + X[k], s) #define ROUND2(a,b,c,d,k,s) a = lshift(a + G(b,c,d) + X[k] + 0x5A827999,s) #define ROUND3(a,b,c,d,k,s) a = lshift(a + H(b,c,d) + X[k] + 0x6ED9EBA1,s) /* this applies md4 to 64 byte chunks */ -static void mdfour64(uint32 *M) +static void mdfour64(uint32_t *M) { int j; - uint32 AA, BB, CC, DD; - uint32 X[16]; - uint32 A,B,C,D; + uint32_t AA, BB, CC, DD; + uint32_t X[16]; + uint32_t A,B,C,D; for (j=0;j<16;j++) X[j] = M[j]; @@ -111,18 +95,13 @@ A += AA; B += BB; C += CC; D += DD; -#ifdef LARGE_INT32 - A &= 0xFFFFFFFF; B &= 0xFFFFFFFF; - C &= 0xFFFFFFFF; D &= 0xFFFFFFFF; -#endif - for (j=0;j<16;j++) X[j] = 0; m->A = A; m->B = B; m->C = C; m->D = D; } -static void copy64(uint32 *M, byte *in) +static void copy64(uint32_t *M, byte *in) { int i; @@ -131,7 +110,7 @@ (in[i*4+1]<<8) | (in[i*4+0]<<0); } -static void copy4(byte *out,uint32 x) +static void copy4(byte *out,uint32_t x) { out[0] = x&0xFF; out[1] = (x>>8)&0xFF; @@ -152,8 +131,8 @@ static void mdfour_tail(byte *in, int n) { byte buf[128]; - uint32 M[16]; - uint32 b; + uint32_t M[16]; + uint32_t b; m->totalN += n; @@ -178,7 +157,7 @@ static void mdfour_update(struct mdfour *md, byte *in, int n) { - uint32 M[16]; + uint32_t M[16]; if (n == 0) mdfour_tail(in, n); Index: code/qcommon/md5.c =================================================================== --- code/qcommon/md5.c (revision 726) +++ code/qcommon/md5.c (working copy) @@ -18,8 +18,8 @@ #include "qcommon.h" typedef struct MD5Context { - unsigned long int buf[4]; - unsigned long int bits[2]; + uint32_t buf[4]; + uint32_t bits[2]; unsigned char in[64]; } MD5_CTX; @@ -33,12 +33,12 @@ */ static void byteReverse(unsigned char *buf, unsigned longs) { - unsigned long int t; + uint32_t t; do { - t = (unsigned long int) + t = (uint32_t) ((unsigned) buf[3] << 8 | buf[2]) << 16 | ((unsigned) buf[1] << 8 | buf[0]); - *(unsigned long int *) buf = t; + *(uint32_t *) buf = t; buf += 4; } while (--longs); } @@ -75,10 +75,10 @@ * reflect the addition of 16 longwords of new data. MD5Update blocks * the data and converts bytes into longwords for this routine. */ -static void MD5Transform(unsigned long int buf[4], - unsigned long int const in[16]) +static void MD5Transform(uint32_t buf[4], + uint32_t const in[16]) { - register unsigned long int a, b, c, d; + register uint32_t a, b, c, d; a = buf[0]; b = buf[1]; @@ -166,12 +166,12 @@ static void MD5Update(struct MD5Context *ctx, unsigned char const *buf, unsigned len) { - register unsigned long int t; + uint32_t t; /* Update bitcount */ t = ctx->bits[0]; - if ((ctx->bits[0] = t + ((unsigned long int) len << 3)) < t) + if ((ctx->bits[0] = t + ((uint32_t) len << 3)) < t) ctx->bits[1]++; /* Carry from low to high */ ctx->bits[1] += len >> 29; @@ -189,7 +189,7 @@ } memcpy(p, buf, t); byteReverse(ctx->in, 16); - MD5Transform(ctx->buf, (unsigned long int *) ctx->in); + MD5Transform(ctx->buf, (uint32_t *) ctx->in); buf += t; len -= t; } @@ -198,7 +198,7 @@ while (len >= 64) { memcpy(ctx->in, buf, 64); byteReverse(ctx->in, 16); - MD5Transform(ctx->buf, (unsigned long int *) ctx->in); + MD5Transform(ctx->buf, (uint32_t *) ctx->in); buf += 64; len -= 64; } @@ -215,7 +215,7 @@ */ static void MD5Final(struct MD5Context *ctx, unsigned char *digest) { - unsigned long int count; + unsigned count; unsigned char *p; /* Compute number of bytes mod 64 */ @@ -234,7 +234,7 @@ /* Two lots of padding: Pad the first block to 64 bytes */ memset(p, 0, count); byteReverse(ctx->in, 16); - MD5Transform(ctx->buf, (unsigned long int *) ctx->in); + MD5Transform(ctx->buf, (uint32_t *) ctx->in); /* Now fill the next block with 56 bytes */ memset(ctx->in, 0, 56); @@ -245,15 +245,15 @@ byteReverse(ctx->in, 14); /* Append length in bits and transform */ - ((unsigned long int *) ctx->in)[14] = ctx->bits[0]; - ((unsigned long int *) ctx->in)[15] = ctx->bits[1]; + ((uint32_t *) ctx->in)[14] = ctx->bits[0]; + ((uint32_t *) ctx->in)[15] = ctx->bits[1]; - MD5Transform(ctx->buf, (unsigned long int *) ctx->in); + MD5Transform(ctx->buf, (uint32_t *) ctx->in); byteReverse((unsigned char *) ctx->buf, 4); if (digest!=NULL) memcpy(digest, ctx->buf, 16); - //memset(ctx, 0, sizeof(ctx)); /* In case it's sensitive */ + memset(ctx, 0, sizeof(ctx)); /* In case it's sensitive */ } Index: code/qcommon/q_shared.h =================================================================== --- code/qcommon/q_shared.h (revision 726) +++ code/qcommon/q_shared.h (working copy) @@ -113,6 +113,8 @@ #else # ifndef _MSC_VER # include +# else + typedef unsigned __int32 uint32_t; # endif #endif Index: code/client/cl_main.c =================================================================== --- code/client/cl_main.c (revision 726) +++ code/client/cl_main.c (working copy) @@ -2549,8 +2549,7 @@ Cvar_Set( "cl_running", "1" ); CL_GenerateQKey(); -// Uncomment this once md5.c has been made 64 bit-safe. -// Cvar_Get("cl_guid", Com_MD5File(QKEY_FILE, 0), CVAR_USERINFO | CVAR_ROM); + Cvar_Get("cl_guid", Com_MD5File(QKEY_FILE, 0), CVAR_USERINFO | CVAR_ROM); Com_Printf( "----- Client Initialization Complete -----\n" ); } From rstotts at cox.net Wed Apr 26 17:45:04 2006 From: rstotts at cox.net (Ryan Stotts) Date: Wed, 26 Apr 2006 16:45:04 -0500 Subject: Build 726, win32, mingw32 compile "error" Message-ID: <000501c6697a$ae4a0150$650fa8c0@amd> code/renderer/tr_image.c: In function `Upload32': code/renderer/tr_image.c:703: error: `GL_TEXTURE_MAX_ANISOTROPY_EXT' undeclared (first use in this function) code/renderer/tr_image.c:703: error: (Each undeclared identifier is reported only once code/renderer/tr_image.c:703: error: for each function it appears in.) make[1]: *** [build/release-mingw32-x86/client/tr_image.o] Error 1 make[1]: Leaving directory `/q3src' make: *** [build_release] Error 2 Win2k, GNU Make version 3.79.1, gcc version 3.4.2 (mingw-special) From zakk at timedoctor.org Wed Apr 26 22:31:50 2006 From: zakk at timedoctor.org (Zachary J. Slater) Date: Wed, 26 Apr 2006 19:31:50 -0700 Subject: [quake3] Build 726, win32, mingw32 compile "error" In-Reply-To: <000501c6697a$ae4a0150$650fa8c0@amd> References: <000501c6697a$ae4a0150$650fa8c0@amd> Message-ID: <44502D16.9070901@timedoctor.org> Ryan Stotts wrote: > code/renderer/tr_image.c: In function `Upload32': > code/renderer/tr_image.c:703: error: `GL_TEXTURE_MAX_ANISOTROPY_EXT' > undeclared (first use in this function) > code/renderer/tr_image.c:703: error: (Each undeclared identifier is reported > only once > code/renderer/tr_image.c:703: error: for each function it appears in.) > make[1]: *** [build/release-mingw32-x86/client/tr_image.o] Error 1 > make[1]: Leaving directory `/q3src' > make: *** [build_release] Error 2 > > > > Win2k, GNU Make version 3.79.1, gcc version 3.4.2 (mingw-special) > Does this solve it for you: https://bugzilla.icculus.org/show_bug.cgi?id=2692 -- - Zachary J. Slater zakk at timedoctor.org zacharyslater at gmail.com From rstotts at cox.net Wed Apr 26 23:30:25 2006 From: rstotts at cox.net (Ryan Stotts) Date: Wed, 26 Apr 2006 22:30:25 -0500 Subject: [quake3] Build 726, win32, mingw32 compile "error" References: <000501c6697a$ae4a0150$650fa8c0@amd> <44502D16.9070901@timedoctor.org> Message-ID: <000b01c669aa$ecadd590$650fa8c0@amd> From: "Zachary J. Slater" > Does this solve it for you: > https://bugzilla.icculus.org/show_bug.cgi?id=2692 That did indeed fix it, thanks. It now compiles fine and the flares do work. The flares are subtle*. To see these, load up q3tourney6 for example. Bind the flares to be on or off to two keys.(The toggle can be made for one key, but I have forgotten how) Example(for those who were never key binding fiends): \bind v "r_flares 0" \bind b "r_flares 1" Or edit your q3config.cfg(easier?) Also, back to back timedemos reveal a 5 fps hit with flares enabled. Cool to have that feature working again though. I haven't seen the flares since one of the earliest test builds way back in 1999 or so.... (again for those new to the code or have forgotten over the years) (in the console) \timedemo 1 \demo four Try it with flares enabled and disabled. *The flares do appear to be adjustable though: r_flareCoeff = "150" r_flareFade = "7" r_flareSize = "40" Thanks again all. From arny at ats.s.bawue.de Thu Apr 27 09:55:26 2006 From: arny at ats.s.bawue.de (Thilo Schulz) Date: Thu, 27 Apr 2006 15:55:26 +0200 Subject: [quake3] md5.c is not 64 bit-safe. In-Reply-To: <20060426201432.GH14550@morbo.webteam.net> References: <200604261545.19760.arny@ats.s.bawue.de> <20060426200227.GG14550@morbo.webteam.net> <20060426201432.GH14550@morbo.webteam.net> Message-ID: <200604271555.32660.arny@ats.s.bawue.de> On Wednesday 26 April 2006 22:14, Tony J. White wrote: > Ugh, I had a typo in that patch. Sorry for the spam, I do hope this is the > last. I committed and tested the patch. cl_guid on 64 bit and 32 bit version was identical. You can see this in q_shared.h: # ifndef _MSC_VER # include # else This file gets included on any non-M$ OS which means that the int??_t types should be available on every OS that ioquake3 supports, or else it would have complained about a non-existent stdint.h much earlier already. As includes in MSVC have kind of similar types, a few simple typedefs converting their names to unix names was the only thing left to do. -- Thilo Schulz -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From arny at ats.s.bawue.de Fri Apr 28 21:06:56 2006 From: arny at ats.s.bawue.de (Thilo Schulz) Date: Sat, 29 Apr 2006 03:06:56 +0200 Subject: VM incompatibilities with anisotropic filtering patch and improvements with ongoing development Message-ID: <200604290309.40529.arny@ats.s.bawue.de> Hello, With the latest patch introducing anisotropic texture filtering an incompatibility to the old VM files has been introduced, too. The glConfig structure that is being passed to these parts has been changed to add info about the status of anisotropic filtering. The original VMs of course do not mirror that change. This is problematic because the complete glConfig struct gets written to address space managed by these VMs that calculate with a lower bytecount for the glConfig structure und overwrites data. For instance, in q3_ui/ui_local.h it overwrites the variables: qboolean debug; qhandle_t whiteShader; in the uiStatic_t struct. As soon as you enable anisotropic filtering using the old VMs the debug value gets overwritten and the menu is suddenly displayed in debug mode. Now there are two ways to fix the problem: 1. move the qboolean textureFilterAnisotropic; int maxAnisotropy; variables from the glconfig_t struct to another one 2. create a compatibility struct with the old data layout from the original iD vm's and use this structure as base for writing to the VM's memory 3. Get all modders on the world to patch their VMs with the same modifications we did to ioq3. The third possibility is of course not really feasible. My suggestion would be to use possibility #2 and let it compile in compatibility mode per default and adding support in the Makefile for compiling with support for an updated version of the virtual machine code. This way we don't break compatibility and are not as much limited by the original VMs while at the same time not giving up any compatibility. People that release stand-alone versions of their games with the ioq3 engine are much more likely to impelement changes/improvements to their versions. As I see it right now, we need to do some "dirty hacks" already because of this limitation. What's your opinion? -- Thilo Schulz -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rstotts at cox.net Fri Apr 28 23:09:18 2006 From: rstotts at cox.net (Ryan Stotts) Date: Fri, 28 Apr 2006 22:09:18 -0500 Subject: [quake3] VM incompatibilities with anisotropic filtering patch and improvements with ongoing development References: <200604290309.40529.arny@ats.s.bawue.de> Message-ID: <000d01c66b3a$4dfa91e0$650fa8c0@amd> >As soon as you enable anisotropic filtering using the old VMs the debug value >gets overwritten and the menu is suddenly displayed in debug mode. Are you talking about when this happens? http://img49.imageshack.us/img49/396/q3m7xa.jpg Press F11 and it turns off the white boxes and the cursor location(until next time..). From auerswal at unix-ag.uni-kl.de Sat Apr 29 07:18:29 2006 From: auerswal at unix-ag.uni-kl.de (Erik Auerswald) Date: Sat, 29 Apr 2006 13:18:29 +0200 Subject: [quake3] VM incompatibilities with anisotropic filtering patch and improvements with ongoing development In-Reply-To: <200604290309.40529.arny@ats.s.bawue.de> References: <200604290309.40529.arny@ats.s.bawue.de> Message-ID: <20060429111829.GA7166@sushi.unix-ag.uni-kl.de> Hi, On Sat, Apr 29, 2006 at 03:06:56AM +0200, Thilo Schulz wrote: > The glConfig structure that is being passed to these parts has been > changed to add info about the status of anisotropic filtering. The > original VMs of course do not mirror that change. This is problematic > because the complete glConfig struct gets written to address space > managed by these VMs that calculate with a lower bytecount for the > glConfig structure und overwrites data. > > Now there are two ways to fix the problem: > 1. move the > qboolean textureFilterAnisotropic; > int maxAnisotropy; > variables from the glconfig_t struct to another one > > 2. create a compatibility struct with the old data layout from the > original iD vm's and use this structure as base for writing to the VM's > memory > 3. Get all modders on the world to patch their VMs with the same > modifications we did to ioq3. > > What's your opinion? I'd prefer the second method. Additionally, patched VM files could be provided in a .pk3 file (that would eliminate the need to use the shared libs to activate all of the ioq3 fixes as well). Erik From ludwig.nussel at suse.de Sat Apr 29 07:24:03 2006 From: ludwig.nussel at suse.de (Ludwig Nussel) Date: Sat, 29 Apr 2006 13:24:03 +0200 Subject: [quake3] VM incompatibilities with anisotropic filtering patch and improvements with ongoing development In-Reply-To: <200604290309.40529.arny@ats.s.bawue.de> References: <200604290309.40529.arny@ats.s.bawue.de> Message-ID: <200604291324.04221.ludwig.nussel@suse.de> Thilo Schulz wrote: > With the latest patch introducing anisotropic texture filtering an > incompatibility to the old VM files has been introduced, too. > > The glConfig structure that is being passed to these parts has been changed to > add info about the status of anisotropic filtering. The original VMs of > course do not mirror that change. > This is problematic because the complete glConfig struct gets written to > address space managed by these VMs that calculate with a lower bytecount for > the glConfig structure und overwrites data. > > For instance, in q3_ui/ui_local.h it overwrites the variables: > qboolean debug; > qhandle_t whiteShader; > in the uiStatic_t struct. AFAICS it also currupts cgs_t in cgame/ and uiInfo_t in ui/. > As soon as you enable anisotropic filtering using the old VMs the debug value > gets overwritten and the menu is suddenly displayed in debug mode. > > Now there are two ways to fix the problem: > 1. move the > qboolean textureFilterAnisotropic; > int maxAnisotropy; > variables from the glconfig_t struct to another one > 2. create a compatibility struct with the old data layout from the original iD > vm's and use this structure as base for writing to the VM's memory > 3. Get all modders on the world to patch their VMs with the same modifications > we did to ioq3. 4. store the values in a cvar. 5. store them in static variables outside glConfig_t. Does mod code need to know about anisotropic filtering anyways? cu Ludwig -- (o_ Ludwig Nussel //\ SUSE LINUX Products GmbH, Development V_/_ http://www.suse.de/ From arny at ats.s.bawue.de Sat Apr 29 08:00:48 2006 From: arny at ats.s.bawue.de (Thilo Schulz) Date: Sat, 29 Apr 2006 14:00:48 +0200 Subject: [quake3] VM incompatibilities with anisotropic filtering patch and improvements with ongoing development In-Reply-To: <200604291324.04221.ludwig.nussel@suse.de> References: <200604290309.40529.arny@ats.s.bawue.de> <200604291324.04221.ludwig.nussel@suse.de> Message-ID: <200604291401.02949.arny@ats.s.bawue.de> On Saturday 29 April 2006 13:24, Ludwig Nussel wrote: > AFAICS it also currupts cgs_t in cgame/ and uiInfo_t in ui/. correct, cgame is affected too. > > 1. move the > > qboolean textureFilterAnisotropic; > > int maxAnisotropy; > > variables from the glconfig_t struct to another one > [...] > 4. store the values in a cvar. > 5. store them in static variables outside glConfig_t. Does mod code > need to know about anisotropic filtering anyways? #4 and #5 is somewhat similar to #1... Still, logically, the data belongs to that glConfig struct. This is only an example, but I wanted to make a suggestion how we could retain full compatibility while at the same time being not so much limited by the original virtual machines. -- Thilo Schulz -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From arny at ats.s.bawue.de Sat Apr 29 14:12:17 2006 From: arny at ats.s.bawue.de (Thilo Schulz) Date: Sat, 29 Apr 2006 20:12:17 +0200 Subject: [quake3] VM incompatibilities with anisotropic filtering patch and improvements with ongoing development In-Reply-To: <20060429111829.GA7166@sushi.unix-ag.uni-kl.de> References: <200604290309.40529.arny@ats.s.bawue.de> <20060429111829.GA7166@sushi.unix-ag.uni-kl.de> Message-ID: <200604292012.22314.arny@ats.s.bawue.de> On Saturday 29 April 2006 13:18, Erik Auerswald wrote: > I'd prefer the second method. Additionally, patched VM files could be > provided in a .pk3 file (that would eliminate the need to use the shared > libs to activate all of the ioq3 fixes as well). Ok, I have done a little patch that fixes the incompatibility issues by introducing a glconfig_compat_t structure that features the original layout. I also added a few defines, bells and whistles that give a bit more flexibility when doing stand-alone games where compatibility issues are of no concern. As is the original goal of the project, the patch shouldn't hurt compatibility at all, per default. Any complaints/comments? (Zakk?) I am typecasting the glconfig_t pointers to a glconfig_compat_t pointer if the API version of the UI is <= 6 and then copy the structs over. I don't know about how sure one can be that all compilers handle memory layout in structures the same way, so I can still add a more proper copying function if it is required. -- Thilo Schulz -------------- next part -------------- A non-text attachment was scrubbed... Name: idq3-compatibility-patch.diff Type: text/x-diff Size: 6024 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From auerswal at unix-ag.uni-kl.de Sun Apr 30 13:55:48 2006 From: auerswal at unix-ag.uni-kl.de (Erik Auerswald) Date: Sun, 30 Apr 2006 19:55:48 +0200 Subject: qvm files Message-ID: <20060430175548.GA30677@sushi.unix-ag.uni-kl.de> Hi, the recent Makefile changes install updated .qvm files to a directory in the quake3 base path. Those files are not used because of the search order for files (those in .pk3 files are preferred). The attached patch changes this search order to prefer files found in the directory over those in .pk3 files. In pure mode files not in a .pk3 file are ignored (and only those .pk3 files that exist on the server are used). Erik -------------- next part -------------- Index: code/qcommon/files.c =================================================================== --- code/qcommon/files.c (revision 735) +++ code/qcommon/files.c (working copy) @@ -2504,17 +2504,6 @@ Q_strncpyz( fs_gamedir, dir, sizeof( fs_gamedir ) ); - // - // add the directory to the search path - // - search = Z_Malloc (sizeof(searchpath_t)); - search->dir = Z_Malloc( sizeof( *search->dir ) ); - - Q_strncpyz( search->dir->path, path, sizeof( search->dir->path ) ); - Q_strncpyz( search->dir->gamedir, dir, sizeof( search->dir->gamedir ) ); - search->next = fs_searchpaths; - fs_searchpaths = search; - // find all pak files in this directory pakfile = FS_BuildOSPath( path, dir, "" ); pakfile[ strlen(pakfile) - 1 ] = 0; // strip the trailing slash @@ -2545,6 +2534,17 @@ fs_searchpaths = search; } + // + // add the directory to the search path + // + search = Z_Malloc (sizeof(searchpath_t)); + search->dir = Z_Malloc( sizeof( *search->dir ) ); + + Q_strncpyz( search->dir->path, path, sizeof( search->dir->path ) ); + Q_strncpyz( search->dir->gamedir, dir, sizeof( search->dir->gamedir ) ); + search->next = fs_searchpaths; + fs_searchpaths = search; + // done Sys_FreeFileList( pakfiles ); }