quake-devel — Main discussion forum. Watch the fur fly.

[Quake-devel] Compiling with DJGPP

[<ar...@co...>]

Following the instructions at the Quake Standards Group 
(http://qsg.telefragged.com/tut/misc/compiledos.shtml) I successfully 
compiled the sources under DJGPP.  I'd just like to note that the 
makefile they provide, at least for me, was malformatted.  After 
consulting docs at www.delorie.com, I put some necessary tabs in front of 
some commands (perhaps my editor was stripping them out), and I removed 
extraneous blank lines between items in lists on lines broken by "\".  
The extraneous blank lines were causing parse errors for make.

I got dosquake.exe and went to run it and recieve:

C:\q1source\WinQuake>dosquake
Quake v1.09
Loaded -23 Mb image
Allocated -11 Mb data
malloc'd: -12320772
Exiting due to signal SIGSEGV
Page fault at eip=0006db53, error=0006
eax=fe8f6ffc ebx=fe8f6ffc ecx=00001010 edx=fe8f6ffc esi=00000bd0 edi=00001010
ebp=fef3ff20 esp=fef3ff0c program=C:\Q1SOURCE\WINQUAKE\DOSQUAKE.EXE
cs: sel=00a7  base=83ed7000  limit=ffffffff
ds: sel=00af  base=83ed7000  limit=ffffffff
es: sel=00af  base=83ed7000  limit=ffffffff
fs: sel=0087  base=00007320  limit=0000ffff
gs: sel=00bf  base=00000000  limit=0010ffff
ss: sel=00af  base=83ed7000  limit=ffffffff
App stack: [fef40000..feec0000]  Exceptn stack: [00101950..000ffa10]

Call frame traceback EIPs:
  0x0006db53
  0x0006fa05
  0x0006fab0
  0x0006363b

---
Using the winmem parameter causes the numbers to be less negative.  Is 
there anything special I have to do?  I have turned optimizations off, 
and have tried running cwsdpmi and increasing the winmem memory but I 
always recieve this error.  I'm compiling and running on a pentium...I 
would assume the default compile options generate "safe" x86 instructions 
and I don't have to specify my cpu.

Aaron

[Quake-devel] patch for right shift key

[Uwe H. <uh...@bi...>]

Hi.

I wrote a small patch which allows you to bind the left *and* the
right key to a certain action. I often use left/right shift for
left/right sliding in first-person shooters, and quake wouldn't allow
me to use left/right shift for this. Now it does :-)

Tested only with the svgalib target.

Uwe.
-- 
Uwe Hermann <uh...@bi...>
http://www.bingo-ev.de/~uh1763/index.html
-----------------------------------------
:wq

Re: [Quake-devel] 'Standardizing' QuakeForge

[Uwe H. <uh...@bi...>]

On Fri, Dec 24, 1999 at 03:46:19PM -0800, Joseph Carter wrote:
> >    It should look something like this, IMHO:
> > 
> > /*
> > QuakeForge - a 3D first-person shooter game
> > Copyright (C) 1996-1997 Id Software, Inc.
> > Copyright (C) 1999 <The QuakeForge Development Team>
> 
> My pref is generally:
> 
> /*
>   filename - project

Hmm.. looks nice, too. But according to the GPL this is more standard:

<one line to give the program's name and a brief idea of what it does.>
Copyright (C) 19yy  <name of author>


>   copyright notices
> 
>   GNU blurb
> */
> 

> Here's where you get into some problems though..  You're going to need to
> have all of this stuff in HTML or winhelp or something that non-unix
> people can read.  I'm not sure if I'd consider either of those perfect
> when dealing with dos but I think html is more or less accepted now so it
> MIGHT work.  Please keep in mind multiplatform issues.

There are several possibilities:

 * plain ASCII-text
 * sgmltools -> generates txt, html, info, dvi and more
 * some other meta-doc-package which generates html, text etc.


> >  * lots of comments are // instead of /* */, which is not really C
> 
> Oh stop whining.  ;>  (I'm a "C++ weenie")

:-)

While we're at it... we should add lots of compiler warnings, like
-Wall, -pedantic, -ansi etc.

It compiles quite nice with -Wall, adding -pedantic outputs literally
hundreds of "warning: carriage return in preprocessing directive", but it
compiles, too.
Adding -ansi doesn't work because of the // comments :-)

You can imagine that using some more switches, like

-Wall -O2 -pedantic -ansi -W -Wtraditional -Wshadow -Wpointer-arith \
-Wcast-qual -Wcast-align -Wwrite-strings -Wconversion \
-Waggregate-return -Wstrict-prototypes -Wmissing-prototypes \
-Wmissing-declarations -Wnested-externs -Winline

will *not* compile :-)

If you're *really* insane you could also try to run lint over it :-)


Uwe.
-- 
Uwe Hermann <uh...@bi...>
http://www.bingo-ev.de/~uh1763/index.html
-----------------------------------------
:wq

Re: [Quake-devel] 'Standardizing' QuakeForge

[Blue L. <bl...@ca...>]

> >  * some files have crippled newlines, like:
> 
> Understatement.  Not sure how exactly best to deal with windoze and unix
> using different newline styles though.  CVS doesn't appear to cope for us.

cron job to run a perl script on the cvs tree? erm.. do we have cron
access on the cvs box?


--
Blue Lang, Unix Systems Administrator, QSP Inc. - Raleigh, NC
Phone: 919.875.6994

Re: [Quake-devel] 'Standardizing' QuakeForge

[Joseph C. <kng...@de...>]

On Fri, Dec 24, 1999 at 11:42:31PM +0100, Uwe Hermann wrote:
> here are some suggestions to make QuakeForge a bit more 'standard':

Most of this is basic agreement/justification.  There's a couple small
portability nits I'll pick since we have to deal with EmpireOS's past and
present though..

>  * use autoconf, as several people have stated before
>     * add some standard subdirectories like src, docs,
>       contrib, po and intl and place everything in these directories.

We'll muck around with deek's tree once he's finished..  Hopefully src and
include will end up there, as should doc..  po and intl *shrug*  (We have
to remember brazillian and german translations for our friends in
countries where quake is contraband!)


>     * add AUTHORS, NEWS, README, THANKS, TODO, ChangeLog, INSTALL.
>       INSTALL can be the one generated/copied by autoconf.

I think we're likely to end up with automake which would probably make us
have most of these things if we go with GNU coding standards.  Which is
fine I guess, GNU standards are as good as any others (though I prefer One
True Brace Style as a slight exception to the GNU standards..)


>     * gnu.txt should be replaced by the standard COPYING. The 'layout'
>       in gnu.txt looks weird. The content is the same(AFAICS), except for
>       the "How to Apply These Terms to Your New Programs"-section (which
>       is missing) so there should be no legal problems.

A standard COPYING file can't hurt, mandated by the GNU standards anyway.


>  * add an lsm-entry and submit to metalab (if not already done)

Sure, lsm's are great help for package maintainers who sit ther and wonder
"how the hell do I write a package description for this thing?"  Don't
laugh, I've been there.


>  * each source-file should have the same header. The current header
>    looks like this in most files:
[..]

ACK.


>    It should look something like this, IMHO:
>=20
> /*
> QuakeForge - a 3D first-person shooter game
> Copyright (C) 1996-1997 Id Software, Inc.
> Copyright (C) 1999 <The QuakeForge Development Team>

My pref is generally:

/*
  filename - project
  copyright notices

  GNU blurb
*/


>  * write documentation
>     * man-page
>     * info-pages
>=20
>    I guess parts of the existing docs can be reused but they
>    sure need some updates.

Consider me half tempted to throw out the original docs and start over.  I
have half a quake.6 I never finished with because nothing was documented
quite as I liked it.  A full info document would be nice I suppose (now
that I have pinfo instead of GNU info I am not so loathe to look at them)
and could contain a lot of other info such as the cvars, where they work,
where they don't, etc.

Here's where you get into some problems though..  You're going to need to
have all of this stuff in HTML or winhelp or something that non-unix
people can read.  I'm not sure if I'd consider either of those perfect
when dealing with dos but I think html is more or less accepted now so it
MIGHT work.  Please keep in mind multiplatform issues.


>  * the directory structure in src/ should be improved.
>    Maybe we should have an extra directory for each platform, containing
>    code only intended to be used on this specific platform:
>     e.g. windows/ linux/ bsd/ etc.
>=20
>    At the moment there are several *.bat *.gif *.sh *.ico *.txt in the
>    directory with the sources which should be moved away from there.
>    In src/ there should only be code, i.e. *.[chs]

dir cleanups should come as part of or be changes made to help improve
deek's tree which is coming along quite nicely.  Our CVS is in as close to
a "freeze" state as we can get it (told everyone not to screw with it for
now) till Deek's tree is finished.  He's merging Q1/QW source (this proves
he's insane) and it's actually working out rather well.

the bats and the belfry and all the pretty pictures should migrate to a
new home.  And expect .xpm's for those .ico's, etc..


>  * some files have crippled newlines, like:
>=20
>    Copyright (C) 1996-1997 Id Software, Inc.^M
>=20
>    This should be fixed.

Understatement.  Not sure how exactly best to deal with windoze and unix
using different newline styles though.  CVS doesn't appear to cope for us.


>  * lots of comments are // instead of /* */, which is not really C

Oh stop whining.  ;>  (I'm a "C++ weenie")


>  * Some things that might be added later: i18n and l10n

Let's just get it working first!  But yes, it's a good plan.

--=20
- Joseph Carter         GnuPG public key:   1024D/DCF9DAB3, 2048g/3F9C2A43
- kng...@de...   20F6 2261 F185 7A3E 79FC  44F9 8FF7 D7A3 DCF9 DAB3
--------------------------------------------------------------------------
Every company complaining about Microsoft's business practices is simply a
rose bush. They look lovely and smell nice. Once a lucky company dethrones
Microsoft they will shed their petals to expose the thorns underneath. A
thorn by any other name would hurt as much.

Re: [Quake-devel] 'Standardizing' QuakeForge

[Loring H. <ls...@cs...>]

Blue Lang wrote:
> 
> >
> >    At the moment there are several *.bat *.gif *.sh *.ico *.txt in the
> >    directory with the sources which should be moved away from there.
> >    In src/ there should only be code, i.e. *.[chs]
> 
> I would further add ../inc for .h and ../asm for .s - This makes it a
> lot easier, IMHO, when working with CVS remotely to see what you're
> grabbing as it comes in..

Not sure if we want to put all the include files in inc/, we may want to
separate all the source (including include files) by function, which makes it
easier to retrieve only the files you need (only glquake files, only Wintel
files, etc).  Other benefits are easier code navigation and possibly
simplifying building.

I have made a list of the WinQuake code, grouped by function and platform
(in)depedence, which can be found at:
http://www.cs.brown.edu/~lsh/WinQuakesrc.txt

Loring

Re: [Quake-devel] 'Standardizing' QuakeForge

[Blue L. <bl...@ca...>]

> 
>    At the moment there are several *.bat *.gif *.sh *.ico *.txt in the
>    directory with the sources which should be moved away from there.
>    In src/ there should only be code, i.e. *.[chs]

I would further add ../inc for .h and ../asm for .s - This makes it a
lot easier, IMHO, when working with CVS remotely to see what you're
grabbing as it comes in.. 

Also, is Qforge working with the winquake code, the QW code, both, some
subset, etc.. ?

--
Blue Lang, Unix Systems Administrator, QSP Inc. - Raleigh, NC
Phone: 919.875.6994

[Quake-devel] 'Standardizing' QuakeForge

[Uwe H. <uh...@bi...>]

Hi all,

here are some suggestions to make QuakeForge a bit more 'standard':

 * use autoconf, as several people have stated before
    * add some standard subdirectories like src, docs,
      contrib, po and intl and place everything in these directories.
    * add AUTHORS, NEWS, README, THANKS, TODO, ChangeLog, INSTALL.
      INSTALL can be the one generated/copied by autoconf.
    * gnu.txt should be replaced by the standard COPYING. The 'layout'
      in gnu.txt looks weird. The content is the same(AFAICS), except for
      the "How to Apply These Terms to Your New Programs"-section (which
      is missing) so there should be no legal problems.


 * add an lsm-entry and submit to metalab (if not already done)


 * each source-file should have the same header. The current header
   looks like this in most files:

/*
Copyright (C) 1996-1997 Id Software, Inc.

This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
[...]

   It should look something like this, IMHO:

/*
QuakeForge - a 3D first-person shooter game
Copyright (C) 1996-1997 Id Software, Inc.
Copyright (C) 1999 <The QuakeForge Development Team>

This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
[...]


 * write documentation
    * man-page
    * info-pages

   I guess parts of the existing docs can be reused but they
   sure need some updates.


 * the directory structure in src/ should be improved.
   Maybe we should have an extra directory for each platform, containing
   code only intended to be used on this specific platform:
    e.g. windows/ linux/ bsd/ etc.

   At the moment there are several *.bat *.gif *.sh *.ico *.txt in the
   directory with the sources which should be moved away from there.
   In src/ there should only be code, i.e. *.[chs]
   

 * some files have crippled newlines, like:

   Copyright (C) 1996-1997 Id Software, Inc.^M

   This should be fixed.


 * lots of comments are // instead of /* */, which is not really C

 * Some things that might be added later: i18n and l10n



Uwe.
-- 
Uwe Hermann <uh...@bi...>
http://www.bingo-ev.de/~uh1763/index.html
-----------------------------------------
:wq

Re: [Quake-devel] [patch] Linux makefile

[Marcus S. <ma...@st...>]

"Zephaniah E. Hull" <wa...@wh...> writes:

> On Fri, Dec 24, 1999 at 02:06:41PM +0100, Marcus Sundberg wrote:
> > "Zephaniah E. Hull" <wa...@wh...> writes:
> <snip>
> > > On Fri, Dec 24, 1999 at 12:21:39AM -0800, Joseph Carter wrote:
> > > <snip>
> > > > but we're planning to dump the whole thing for autoconf and probably
> > > > automake at some point anyway so the contents of the thing called
> > > > "Makefile" soon won't matter anyway.
> > > 
> > > Out of this I only have one comment, errm, can we please just try and
> > > forget that automake even exists? 
> > >
> > > In my experience it is a complete horror to work with the moment you need
> > > to debug something, and sadly you /do/ have to debug things from time to
> > > time..
> > 
> > What does automake has to do with debugging? Or are you talking
> > about debugging the build system?
> 
> Debugging the build system..

Well, having used autmake for over a year in a large project (about
12 MB sources) consisting of programs, shared libraries and dynamicly
loaded libraries, I must say I never had to do much debugging once
I figured out how things worked.

> > In any case it sounds like you haven't used automake very much.
> 
> I've used it a good bit, and I know that I will never willingly use it
> again..
> 
> > Unless you are aiming at only supporting a single platform there
> > is nothing that comes even remotely close to the maintainability
> > you get when using automake.
> 
> This is true for autoconf, however, in my experience, automake is simply
> evil..

The nice thing about automake is that you get two very nice features
for free - being able to build shared libraries (using libtool) on
any supported platform, and being able to build outside source tree.
The latter is invaluable when you have a descent distributed
filesystem and several different platforms.

//Marcus
-- 
-------------------------------+------------------------------------
        Marcus Sundberg        | http://www.stacken.kth.se/~mackan
 Royal Institute of Technology |       Phone: +46 707 295404
       Stockholm, Sweden       |   E-Mail: ma...@st...

Re: [Quake-devel] Makefiles

[Dan O. <the...@qu...>]

-----Original Message-----
From: Blue Lang <bl...@ca...>
To: qua...@li... <qua...@li...>
Date: Friday, December 24, 1999 11:51 AM
Subject: Re: [Quake-devel] Makefiles


>> In regard to classic mode, I think it should be done at execution time
and
>> not at compile time


>Well, there's nothing stopping us from doing both.. I personally might not
>want the old cruft hanging around in my client.. If it's done at configure
>time and then enabled as a switch, or auto-enabled as in your example, I
>think everyone would be happy. ;)

Good point.  I'm curious as to how this would look in the actual code if we
were to implement it in such a fashion.  I'm not at all familiar with the
workings of configure scripts, but I'm guessing it would look something like
this:

#ifdef CLASSICMODE
if(!classicmode)
{
    // New feature code here
}
#endif

That's a lot to write, and as you pointed out, someone could just download
id's client if they wanted (which I'd never actually thought of before =)
Now I think the only advantage of classic mode is so our quake can be played
over the net with other clients, in which case client-side improvements
(graphics, etc) wouldn't need to be bothered with, but new features that
affect multiplayer would.  All in all, it's a lot easier than the method I
proposed before, which is that *every* new feature be included in an
if(!classic) block.

theoddone33

Re: [Quake-devel] Makefiles

[Joseph C. <kng...@de...>]

On Fri, Dec 24, 1999 at 12:19:36PM -0500, Blue Lang wrote:
> Should the graphics platforms all be configured by default, and seperated
> in the makefile as targets? IE,=20
>=20
> make gl, make x11, etc..=20
>=20
> or done as=20
>=20
> ./configure --enable-gl --classic

I'd really like to see the graphics drivers become modules ala quake2.

In that case you could pretty much build them all with something like:

=2E/configure --enable-softsvga --enable-softx11 --enable-gl --enable-3dfx


You could autodetect all of these things naturally, and why not?  The
enable or disable would be good to either require (stop configure with an
error if it can't be built telling you to go install the needed devel
headers or something *g*) or force configure to skip something it founds,
say you don't want to build a lib3dfxgl.so-using version you would simply
--disable-3dfx and call it good.

That depends of course on modularizing the drivers which I haven't exactly
done yet.  And it's not on my immediate highest priority todo list either
unfurtunately.  I'm guessing I'll probably be doing something like this in
the meantime to build the Debian quake packages:

build: build-x11 build-svga build-gl build-3dfx

build-x11:
	dh_testdir

	mkdir x11 && \
	cd x11 && \
	../configure --prefix=3D/usr --enable-softx11

	touch build-x11


=2E..etc

But the modular drivers would still be a LOT better IMO.  =3D>

--=20
- Joseph Carter         GnuPG public key:   1024D/DCF9DAB3, 2048g/3F9C2A43
- kng...@de...   20F6 2261 F185 7A3E 79FC  44F9 8FF7 D7A3 DCF9 DAB3
--------------------------------------------------------------------------
<Oryn> anyone know if there is a version of dpkg for redhat?

Re: [Quake-devel] Makefiles

[Blue L. <bl...@ca...>]

On Fri, 24 Dec 1999, Dan Olson wrote:

> >./configure --enable-gl --classic
> 
> In regard to classic mode, I think it should be done at execution time and
> not at compile time, either through a command line option, and/or have the
> program default into classic mode when it tries to connect to a server
> that's running id's quake or with an incompatible version.

Well, there's nothing stopping us from doing both.. I personally might not
want the old cruft hanging around in my client.. If it's done at configure
time and then enabled as a switch, or auto-enabled as in your example, I
think everyone would be happy. ;)

I guess someone should issue an edict (to the mailing list or the site,
please, some people might not want to deal with IRC :) concerning the
goals of the project.. What sort of users is this aiming at? What do we
hope to have, in a year, or six months from now? Do we expect to ship
binaries, a toolkit, libararies, source-only?

Re: classic mode.. I'm not sure about the effort to maintian that. Can't
someone who wants to play the "real" Quake I client just.. download it? :)
There has to be some point at which we say 'this is behavior that people
might want to preserve' - and I don't think that point is at the bugfix
level, as someone suggested earlier.

Awaiting orders,

--
Blue Lang, Unix Systems Administrator, QSP Inc. - Raleigh, NC
Phone: 919.875.6994

Re: [Quake-devel] Makefiles

[Dan O. <the...@qu...>]

-----Original Message-----
From: Blue Lang <bl...@ca...>
To: Qua...@li... <Qua...@li...>
Date: Friday, December 24, 1999 10:58 AM
Subject: [Quake-devel] Makefiles

>IE, should gl. 3dfx support be built at ./configure level? Should those
>all be done as #ifdefs into a single header? We also need to check for and
>support various processors and compilers, blah blah.. all the usual stuff.
>
>Should the graphics platforms all be configured by default, and seperated
>in the makefile as targets? IE,
>
>make gl, make x11, etc..
>
>or done as
>
>./configure --enable-gl --classic

In regard to classic mode, I think it should be done at execution time and
not at compile time, either through a command line option, and/or have the
program default into classic mode when it tries to connect to a server
that's running id's quake or with an incompatible version.
  As far as compiling, I think we should separate it in the makefile, much
like your first example.

theoddone33

Re: [Quake-devel] [patch] Linux makefile

[Joseph C. <kng...@de...>]

> >  quake-gl gets linked with BOTH svgalib and glide here, no idea why
> svgalib is used for input.

quake-gl is formerly glquake.glx..  This is an X program that should be
using DGA and X input events.  *bop*  Read the makefile patch, I went
through a whole 30 seconds of trouble to make it.  =3DD

--=20
- Joseph Carter         GnuPG public key:   1024D/DCF9DAB3, 2048g/3F9C2A43
- kng...@de...   20F6 2261 F185 7A3E 79FC  44F9 8FF7 D7A3 DCF9 DAB3
--------------------------------------------------------------------------
<liw> damn, the autonomous mouse movement starts usually after I use a
      mouse button
<wichert> don't use a mouse button then :)
<liw> yeah, right :)

Re: [Quake-devel] glquake.glx and current mesa...

[Joseph C. <kng...@de...>]

On Fri, Dec 24, 1999 at 12:24:49PM -0330, Steve Anthony wrote:
> > Add -window to the cmdline.  If you`re running a 32bpp xserver like I am
> > and have MESA_GLX_FX=3D3Df in your environment you`ll get a fullscreen =
quake
> > with a working keyboard.  You`ll still need the gl_ztrick 0 naturally. =
 I
> > also couldn`t get _windowed_mouse to work but I haven`t tried to track
> > that down yet.
>=20
> I tried the gl_ztrick hack, and while it stops the texture flashing, ther=
e are
> still redraw problems.  For example, if I turn around onscreen, its as if=
 the
> textures are being "smeared", like they aren't being updated correctly.  =
What
> else could be wrong with my setup, as "gl_ztrick" fixes the flashing, not=
 the
> smearing?

No idea offhand, John Carmack told me that he had reports of the ztrick
thing working.  He said if the Mesa people don't fix the ztrick code,
he'll have a look at it before too long.


> Also, I'd like to point out that while '-window' gives one keyboard acces=
s, you
> have to be careful to not move the mouse.  If it moves outside the window
> (without you knowing), you lose input focus and will not be able to exit.

_windowed_mouse doesn't work in the gl version for some reason.  Zoid's
bug I suspect.  I haven't tried to fix it yet, someone will probably offer
a patch that does the deed in the next day or two.


> I compiled with pgcc (egcs 1.1.2 with Pentium patches) on Mandrake 6.1, t=
he
> newest XFree86 3.3.5 and /dev/3dfx module from 3dfxgamers.com, and the ne=
west
> Mesa lib (released 1 week ago).  BTW, quake3 uses the same Mesa lib and w=
orks
> fine, as does all quake games in Windows (dual boot), so I assume the pro=
blem
> is with glquake.glx for linux.

Quake2 also is built for Mesa 2.6 and works fine with Mesa 3.1, I think
there's some differences in how the video drivers work in the original
that explain the problem.  I'll try to play with it a bit more today if
I'm feeling better than I was last night.

--=20
- Joseph Carter         GnuPG public key:   1024D/DCF9DAB3, 2048g/3F9C2A43
- kng...@de...   20F6 2261 F185 7A3E 79FC  44F9 8FF7 D7A3 DCF9 DAB3
--------------------------------------------------------------------------
<Knghtbrd> aggh!
<Knghtbrd> MAKE IT STOP!
<Knghtbrd> MAKE IT STOP!!

Re: [Quake-devel] Linux Makefile

[Joseph C. <kng...@de...>]

On Fri, Dec 24, 1999 at 01:26:07PM +0100, Filip Van Raemdonck wrote:
> > MAINDIR=3D<path_where_you_install_quake/QW>
> >=20
> Make that
>=20
> MAINDIR=3D$(shell pwd)

I suppose this means I need to finish rewriting quake.6 ?

--=20
- Joseph Carter         GnuPG public key:   1024D/DCF9DAB3, 2048g/3F9C2A43
- kng...@de...   20F6 2261 F185 7A3E 79FC  44F9 8FF7 D7A3 DCF9 DAB3
--------------------------------------------------------------------------
<Kensey> RMS for President???
<RelDrgn> ...or ESR, he wants a new job ;)

Re: [Quake-devel] Hello, quake list

[Joseph C. <kng...@de...>]

On Fri, Dec 24, 1999 at 01:22:14PM +0100, Filip Van Raemdonck wrote:
> > Is anyone planning on splitting the source out and using GNU configure?
> >=20
> IMHO it would be a bad choice in splitting *anything* out, even if using
> configure. This is even more true for qw than plain q1. There's lots of
> shared stuff in there, and it future patches are more likely to break
> things if Windows and Linux source each go their own way.

Doesn't mean you can't autoconf it all the same.  All it means is that
you're probably going to end up with specific files in certain subdirs for
platform specific stuff.  If we go the SDL route that might be a bit more
limited to stuff outside the quake codebase though.  SDL looks SWEET!

--=20
- Joseph Carter         GnuPG public key:   1024D/DCF9DAB3, 2048g/3F9C2A43
- kng...@de...   20F6 2261 F185 7A3E 79FC  44F9 8FF7 D7A3 DCF9 DAB3
--------------------------------------------------------------------------
<Iambe> conning the most intellegent people on the planet is not easy

Re: [Quake-devel] [patch] Linux makefile

[Dan O. <the...@qu...>]

-----Original Message-----
From: Joseph Carter <kng...@de...>
To: qua...@li... <qua...@li...>
Date: Friday, December 24, 1999 4:29 AM
Subject: [Quake-devel] [patch] Linux makefile

<snip>

>Caveats:

>  quake-gl gets linked with BOTH svgalib and glide here, no idea why
svgalib is used for input.

theoddone33

Re: [Quake-devel] Shareware levels

[Joseph C. <kng...@de...>]

On Fri, Dec 24, 1999 at 10:46:26AM -0600, Ted Milker wrote:
> > http://tank.debian.net/quake106.zip if you really need to get it from
> > somewhere.
>=20
> Uhh, you guys can still get these at:
>=20
> ftp://ftp.cdrom.com/pub/quake/idstuff/quake/quake106.zip.  If you're in
> linux, just use the lha extractor on the resource.1 file.

Thanks, I was pretty sure it was still there, but figured I'd help out by
putting it where it could be found.  Since it's not needed, I'll pull it
out of that dir.

My quake-lib package already does use lha to extract it in "build" process
(read: copy) but I forgot to mention that you had to do that, so thanks.
=3D>

--=20
- Joseph Carter         GnuPG public key:   1024D/DCF9DAB3, 2048g/3F9C2A43
- kng...@de...   20F6 2261 F185 7A3E 79FC  44F9 8FF7 D7A3 DCF9 DAB3
--------------------------------------------------------------------------
I am amazed that no-one's based a commercial distribution on Debian yet -
it is by far the most solid UNIX-like OS I've ever installed, and I've
played with HP/UX, Solaris, FreeBSD, BSDi, and SCO (not to mention OS/2,
Novell, Win95/NT)
        -- Nathan Norman

[Quake-devel] Makefiles

[Blue L. <bl...@ca...>]

Well, while we're on the subject of makefiles, we need to decide what gets
dealt with at what level during the build.

IE, should gl. 3dfx support be built at ./configure level? Should those
all be done as #ifdefs into a single header? We also need to check for and
support various processors and compilers, blah blah.. all the usual stuff.

Should the graphics platforms all be configured by default, and seperated
in the makefile as targets? IE, 

make gl, make x11, etc.. 

or done as 

./configure --enable-gl --classic

etc.. 

Thanks!

--
Blue Lang, Unix Systems Administrator, QSP Inc. - Raleigh, NC
Phone: 919.875.6994

Re: [Quake-devel] Shareware levels

[Ted M. <tm...@ra...>]

On Thu, Dec 23, 1999 at 11:52:06PM -0800, Joseph Carter wrote:
> On Thu, Dec 23, 1999 at 09:15:05PM -0500, Blue Lang wrote:
> > Can someone post a link/copy of the q1 shareware levels? I'm trying to
> > hunt them down..
> 
> http://tank.debian.net/quake106.zip if you really need to get it from
> somewhere.

Uhh, you guys can still get these at:

ftp://ftp.cdrom.com/pub/quake/idstuff/quake/quake106.zip.  If you're in
linux, just use the lha extractor on the resource.1 file.

Ted

RE: [Quake-devel] glquake.glx and current mesa...

[Steve A. <ste...@ro...>]

On Sat, 25 Dec 1999, you wrote:
> > 
> > I tried the gl_ztrick hack, and while it stops the texture flashing, there are
> > still redraw problems.  For example, if I turn around onscreen, its as if the
> > textures are being "smeared", like they aren't being updated correctly.  What
> > else could be wrong with my setup, as "gl_ztrick" fixes the flashing, not the
> > smearing?
> > 
> 
> You have to comment the call to VID_Init8bitPalette() : it is buggy

Actually, when I recompiled with the debug version (instead of release), this
problem went away.  But I'll try commenting out the line you suggest and see if
I can compile with more optimizations.

> > Also, I'd like to point out that while '-window' gives one keyboard access,
> you > have to be careful to not move the mouse.  If it moves outside the window
> > (without you knowing), you lose input focus and will not be able to exit.
> > 
> 
> I adressed that in the patch i just posted

Thanks, I'll try that now as well.

Steve

RE: [Quake-devel] glquake.glx and current mesa...

[Michael P. <mp...@ma...>]

> 
> I tried the gl_ztrick hack, and while it stops the texture flashing, there are
> still redraw problems.  For example, if I turn around onscreen, its as if the
> textures are being "smeared", like they aren't being updated correctly.  What
> else could be wrong with my setup, as "gl_ztrick" fixes the flashing, not the
> smearing?
> 

You have to comment the call to VID_Init8bitPalette() : it is buggy


> Also, I'd like to point out that while '-window' gives one keyboard access,
you > have to be careful to not move the mouse.  If it moves outside the window
> (without you knowing), you lose input focus and will not be able to exit.
> 

I adressed that in the patch i just posted



--
il fait bo!

[Quake-devel] Patch: adding _windowed_mouse to glquake.glx

[Michael P. <mp...@ma...>]

Mouse now lworks like quake.x11
dga mouse handling is still broken with my voodoo3.

PS: I wanted to do a patch (my fisrt!) with diff -c but the patch was 2x bigger
than the original file...what's the standard way to produce smaller patches ?

--
il fait bo!

RE: [Quake-devel] glquake.glx and current mesa...

[Steve A. <ste...@ro...>]

On Fri, Dec 24, 1999 at 01:37:36AM -0700, Chris Borowski wrote:

>> Same results here with glquake.glx (also Mesa 3.2 and a Voodoo 3).
>> Setting "gl_ztrick `0`" in my autoexec.cfg cleared up the flashing
>> texture thing, but alas no keyboard or mouse here either. I see that
>> the non-X quakes want to use svgalib for keyboard and mouse input.
>> Anybody know what the glquake.x11 would like to use for this?
>> The gl_ztrick thing makes the game look perfect, so I assume that
>> glquake.glx only needs to have the input thing fixed up before it is
>> playable.

> Add -window to the cmdline.  If you`re running a 32bpp xserver like I am
> and have MESA_GLX_FX=3Df in your environment you`ll get a fullscreen quake
> with a working keyboard.  You`ll still need the gl_ztrick 0 naturally.  I
> also couldn`t get _windowed_mouse to work but I haven`t tried to track
> that down yet.

I tried the gl_ztrick hack, and while it stops the texture flashing, there are
still redraw problems.  For example, if I turn around onscreen, its as if the
textures are being "smeared", like they aren't being updated correctly.  What
else could be wrong with my setup, as "gl_ztrick" fixes the flashing, not the
smearing?

Also, I'd like to point out that while '-window' gives one keyboard access, you
have to be careful to not move the mouse.  If it moves outside the window
(without you knowing), you lose input focus and will not be able to exit.

I compiled with pgcc (egcs 1.1.2 with Pentium patches) on Mandrake 6.1, the
newest XFree86 3.3.5 and /dev/3dfx module from 3dfxgamers.com, and the newest
Mesa lib (released 1 week ago).  BTW, quake3 uses the same Mesa lib and works
fine, as does all quake games in Windows (dual boot), so I assume the problem
is with glquake.glx for linux.

Steve