From pomac at vapor.com  Wed Oct  5 17:43:32 2005
From: pomac at vapor.com (Ian Kumlien)
Date: Wed, 05 Oct 2005 23:43:32 +0200
Subject: C++? when did that happen?
Message-ID: <1128548612.11801.25.camel@localhost>

Hi, 

I see that with a lot of the cleanups lately NULL has been replaced with
0 due to warnings? What compiler compiles C code as C++ code and whines
about it not being C++?

I guess it's up to you, but to me it's just plain wrong...

Oh, and btw, during the last commits the build hasn't worked either,
first it was the lack of a build dir and now:
make[3]: Leaving directory `/home/pomac/tmp/quake3/code/tools/lcc'
../tools/q3lcc -o releasex86_64-glibc/baseq3/cgame/cg_main.asm -S
-DQ3_VM -I../cgame -I../game -I../ui ../cgame/cg_main.c
../tools/q3lcc: q3cpp: No such file or directory

-- 
Ian Kumlien <pomac () vapor ! com> -- http://pomac.netswarm.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://icculus.org/pipermail/quake3/attachments/20051005/d6553830/attachment.pgp>

From tim at ngus.net  Wed Oct  5 17:58:55 2005
From: tim at ngus.net (Tim Angus)
Date: Wed, 5 Oct 2005 22:58:55 +0100
Subject: C++? when did that happen?
In-Reply-To: <1128548612.11801.25.camel@localhost>
References: <1128548612.11801.25.camel@localhost>
Message-ID: <20051005225855.79dea246.tim@ngus.net>

On Wed, 05 Oct 2005 23:43:32 +0200 Ian wrote:
> I see that with a lot of the cleanups lately NULL has been replaced
> with 0 due to warnings? What compiler compiles C code as C++ code and
> whines about it not being C++?

I don't know what makes you think setting a function pointer to 0 is
C++, perhaps the syntax for declaring a pure virtual? The compiler that
produces the warnings is (q3)lcc, which builds the vm files.

> I guess it's up to you, but to me it's just plain wrong...

If setting a function pointer to 0 is wrong, setting it to NULL is just
as wrong.

> Oh, and btw, during the last commits the build hasn't worked either,
> first it was the lack of a build dir and now:
> make[3]: Leaving directory `/home/pomac/tmp/quake3/code/tools/lcc'
> ../tools/q3lcc -o releasex86_64-glibc/baseq3/cgame/cg_main.asm -S
> -DQ3_VM -I../cgame -I../game -I../ui ../cgame/cg_main.c
> ../tools/q3lcc: q3cpp: No such file or directory

Yes, this fixed now.


From pomac at vapor.com  Wed Oct  5 18:09:03 2005
From: pomac at vapor.com (Ian Kumlien)
Date: Thu, 06 Oct 2005 00:09:03 +0200
Subject: [quake3] Re: C++? when did that happen?
In-Reply-To: <20051005225855.79dea246.tim@ngus.net>
References: <1128548612.11801.25.camel@localhost>
	 <20051005225855.79dea246.tim@ngus.net>
Message-ID: <1128550143.11801.29.camel@localhost>

On Wed, 2005-10-05 at 22:58 +0100, Tim Angus wrote:
> On Wed, 05 Oct 2005 23:43:32 +0200 Ian wrote:
> > I see that with a lot of the cleanups lately NULL has been replaced
> > with 0 due to warnings? What compiler compiles C code as C++ code and
> > whines about it not being C++?
> 
> I don't know what makes you think setting a function pointer to 0 is
> C++, perhaps the syntax for declaring a pure virtual? The compiler that
> produces the warnings is (q3)lcc, which builds the vm files.

C has it defined as NULL, while C++ started using 0. But ok if the vm
compiler is the one then i get it.

> > I guess it's up to you, but to me it's just plain wrong...
> 
> If setting a function pointer to 0 is wrong, setting it to NULL is just
> as wrong.

Well, yes and no =)
(You might still need to initialize it so it's not wrong, but it
shouldn't be NULL on usage, =))

> > Oh, and btw, during the last commits the build hasn't worked either,
> > first it was the lack of a build dir and now:
> > make[3]: Leaving directory `/home/pomac/tmp/quake3/code/tools/lcc'
> > ../tools/q3lcc -o releasex86_64-glibc/baseq3/cgame/cg_main.asm -S
> > -DQ3_VM -I../cgame -I../game -I../ui ../cgame/cg_main.c
> > ../tools/q3lcc: q3cpp: No such file or directory
> 
> Yes, this fixed now.

Nope... I still get it with rev 144.

-- 
Ian Kumlien <pomac () vapor ! com> -- http://pomac.netswarm.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://icculus.org/pipermail/quake3/attachments/20051006/e03ae2c3/attachment.pgp>

From tim at ngus.net  Wed Oct  5 18:29:10 2005
From: tim at ngus.net (Tim Angus)
Date: Wed, 5 Oct 2005 23:29:10 +0100
Subject: C++? when did that happen?
In-Reply-To: <1128550143.11801.29.camel@localhost>
References: <1128548612.11801.25.camel@localhost>
	<20051005225855.79dea246.tim@ngus.net>
	<1128550143.11801.29.camel@localhost>
Message-ID: <20051005232910.2aa8189a.tim@ngus.net>

On Thu, 06 Oct 2005 00:09:03 +0200 Ian wrote:
> > I don't know what makes you think setting a function pointer to 0 is
> > C++, perhaps the syntax for declaring a pure virtual? The compiler
> > that produces the warnings is (q3)lcc, which builds the vm files.
> 
> C has it defined as NULL, while C++ started using 0. But ok if the vm
> compiler is the one then i get it.

C has what defined as NULL? NULL is defined as either 0 or (void *)0
depending on the system, but in practice they're equivalent. When a C
compiler sees a pointer of any type set to 0, it effectively casts the 0
to a type appropriate for the pointer, so it could be argued that 0 is
"better" than (void *)0 which is an explicit cast. It really doesn't
matter though since dereferencing either value is an error.

> > If setting a function pointer to 0 is wrong, setting it to NULL is
> > just as wrong.
> 
> Well, yes and no =)

Yes and yes. This all seems like a rather pointless quibble to be honest
-- it's a non-issue.

> Nope... I still get it with rev 144.

Yes, it is. make distclean or checkout a clean copy and try again.


From pomac at vapor.com  Wed Oct  5 18:55:13 2005
From: pomac at vapor.com (Ian Kumlien)
Date: Thu, 06 Oct 2005 00:55:13 +0200
Subject: [quake3] Re: C++? when did that happen?
In-Reply-To: <20051005232910.2aa8189a.tim@ngus.net>
References: <1128548612.11801.25.camel@localhost>
	 <20051005225855.79dea246.tim@ngus.net>
	 <1128550143.11801.29.camel@localhost>
	 <20051005232910.2aa8189a.tim@ngus.net>
Message-ID: <1128552913.11801.33.camel@localhost>

On Wed, 2005-10-05 at 23:29 +0100, Tim Angus wrote:
> On Thu, 06 Oct 2005 00:09:03 +0200 Ian wrote:
> > > I don't know what makes you think setting a function pointer to 0 is
> > > C++, perhaps the syntax for declaring a pure virtual? The compiler
> > > that produces the warnings is (q3)lcc, which builds the vm files.
> > 
> > C has it defined as NULL, while C++ started using 0. But ok if the vm
> > compiler is the one then i get it.
> 
> C has what defined as NULL? NULL is defined as either 0 or (void *)0
> depending on the system, but in practice they're equivalent. When a C
> compiler sees a pointer of any type set to 0, it effectively casts the 0
> to a type appropriate for the pointer, so it could be argued that 0 is
> "better" than (void *)0 which is an explicit cast. It really doesn't
> matter though since dereferencing either value is an error.

In C you do NULL, since NULL could be defined in several ways.
Apparently compilers these days workaround such things if you just put 0
there. All i said was that 0 is a C++:ism, which it is.
(and it's not like a cast takes time in c)

> Yes and yes. This all seems like a rather pointless quibble to be honest
> -- it's a non-issue.

A random adress in the variable is much worse since it could
theoretically execute code that shouldn't be run and take time to debug.

> > Nope... I still get it with rev 144.
> 
> Yes, it is. make distclean or checkout a clean copy and try again.

ok, make clean didn't seem to do the trick.

-- 
Ian Kumlien <pomac () vapor ! com> -- http://pomac.netswarm.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://icculus.org/pipermail/quake3/attachments/20051006/a60802c4/attachment.pgp>

From tim at ngus.net  Wed Oct  5 19:37:05 2005
From: tim at ngus.net (Tim Angus)
Date: Thu, 6 Oct 2005 00:37:05 +0100
Subject: C++? when did that happen?
In-Reply-To: <1128552913.11801.33.camel@localhost>
References: <1128548612.11801.25.camel@localhost>
	<20051005225855.79dea246.tim@ngus.net>
	<1128550143.11801.29.camel@localhost>
	<20051005232910.2aa8189a.tim@ngus.net>
	<1128552913.11801.33.camel@localhost>
Message-ID: <20051006003705.5d63d093.tim@ngus.net>

On Thu, 06 Oct 2005 00:55:13 +0200 Ian wrote:
> In C you do NULL, since NULL could be defined in several ways.
> Apparently compilers these days workaround such things if you just put
> 0 there. All i said was that 0 is a C++:ism, which it is.
> (and it's not like a cast takes time in c)

0 is a "C++ism" because of C++'s tighter type checking, and does not
imply 0 is wrong in C. In other words, 0 is used in place of NULL
because there are situations in C++ where from a type checking point of
view, the use of NULL (where it is potentially defined as (void *)0) is
incorrect.

I'll say again, using 0 in place of NULL in C is perfectly valid and
correct. Yes, NULL is implementation defined, but that DOES NOT make the
use of 0 in place of NULL wrong, nor does it make it a "C++ism".

> A random adress in the variable is much worse since it could
> theoretically execute code that shouldn't be run and take time to
> debug.

If you think 0 is a "random address", /you're/ just plain wrong. Why
don't you try deferencing a function pointer set to 0 and see what
happens? May I politely suggest you go and read the C standard? ;)


From pomac at vapor.com  Wed Oct  5 20:52:01 2005
From: pomac at vapor.com (Ian Kumlien)
Date: Thu, 06 Oct 2005 02:52:01 +0200
Subject: [quake3] Re: C++? when did that happen?
In-Reply-To: <20051006003705.5d63d093.tim@ngus.net>
References: <1128548612.11801.25.camel@localhost>
	 <20051005225855.79dea246.tim@ngus.net>
	 <1128550143.11801.29.camel@localhost>
	 <20051005232910.2aa8189a.tim@ngus.net>
	 <1128552913.11801.33.camel@localhost>
	 <20051006003705.5d63d093.tim@ngus.net>
Message-ID: <1128559921.11801.39.camel@localhost>

On Thu, 2005-10-06 at 00:37 +0100, Tim Angus wrote:
> On Thu, 06 Oct 2005 00:55:13 +0200 Ian wrote:
> > In C you do NULL, since NULL could be defined in several ways.
> > Apparently compilers these days workaround such things if you just put
> > 0 there. All i said was that 0 is a C++:ism, which it is.
> > (and it's not like a cast takes time in c)

[Snip: nonusefull stuff ]

Using 0 is a C++:ism since it didn't exist before, but as i said it
doesn't matter since most compilers handles the 0 case as well (since C
++) and does the right thing.

> > A random adress in the variable is much worse since it could
> > theoretically execute code that shouldn't be run and take time to
> > debug.
> 
> If you think 0 is a "random address", /you're/ just plain wrong. Why
> don't you try deferencing a function pointer set to 0 and see what
> happens? May I politely suggest you go and read the C standard? ;)

Sigh, I really thought you'd understand that INITIALIZING it prevent
this.

PS. I said that you was right about this some mails ago but if you keep
misinterpreting me thats up to you and i will reply 

-- 
Ian Kumlien <pomac () vapor ! com> -- http://pomac.netswarm.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://icculus.org/pipermail/quake3/attachments/20051006/f0e186b0/attachment.pgp>

From dkaloper at ffzg.hr  Wed Oct  5 21:01:06 2005
From: dkaloper at ffzg.hr (david kaloper)
Date: Thu, 6 Oct 2005 03:01:06 +0200
Subject: [quake3] Re: C++? when did that happen?
In-Reply-To: <1128559921.11801.39.camel@localhost>
References: <1128548612.11801.25.camel@localhost> <20051006003705.5d63d093.tim@ngus.net> <1128559921.11801.39.camel@localhost>
Message-ID: <200510060301.06213.dkaloper@ffzg.hr>

[ Ian Kumlien: ]
> PS. I said that you was right about this some mails ago but if you keep
> misinterpreting me thats up to you and i will reply

Luckily for all of us who subscribed expecting that precisely.
:cheers his hero:

-- 
Nothing happens to be playing.


From vincent at cojot.name  Thu Oct  6 02:48:59 2005
From: vincent at cojot.name (vincent at cojot.name)
Date: Thu, 6 Oct 2005 08:48:59 +0200 (CEST)
Subject: [quake3] Re: C++? when did that happen?
In-Reply-To: <20051006003705.5d63d093.tim@ngus.net>
References: <1128548612.11801.25.camel@localhost> <20051005225855.79dea246.tim@ngus.net>
 <1128550143.11801.29.camel@localhost> <20051005232910.2aa8189a.tim@ngus.net>
 <1128552913.11801.33.camel@localhost> <20051006003705.5d63d093.tim@ngus.net>
Message-ID: <Pine.LNX.4.63.0510060845040.10415@thorbardin.lasthome.solace.krynn>


Just my 2cents but here's what I had added when I ported the Torque to 
Solaris/Sparc:

#ifndef NULL
// #warning "NULL is not defined..."
#ifndef __cplusplus
#define NULL ((void *)0)
#else   /* C++ */
#define NULL (0)
#endif
#endif

Doing something like this may help keeping the NULL's in the code and 
still make the C & C++ compilers happy, maybe...

Just my 2c (I'm not proficient enough in these languages..).

,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,
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 DER.FABE at gmx.net  Thu Oct  6 06:02:29 2005
From: DER.FABE at gmx.net (DER.FABE at gmx.net)
Date: Thu, 6 Oct 2005 12:02:29 +0200 (MEST)
Subject: [PATCH] small fix to compile with nvidia gl headers
Message-ID: <30719.1128592949@www83.gmx.net>

This patch allows compilation with both nvidia and 
mesa gl headers. 
 
bugzilla: 
https://bugzilla.icculus.org/show_bug.cgi?id=2407 

-- 
Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko!
Satte Provisionen f?r GMX Partner: http://www.gmx.net/de/go/partner


From andreas at syndrom23.de  Thu Oct  6 10:59:51 2005
From: andreas at syndrom23.de (Andreas Kohn)
Date: Thu, 06 Oct 2005 16:59:51 +0200
Subject: [PATCH] avoid find error on freebsd
Message-ID: <1128610792.1273.4.camel@klamath.syndrom23.de>

Hi,

attached is a small fix to code/unix/Makefile that avoids an error when
calling find.

Short explanation: GNU find allows find to be called w/o any paths to
search, it takes the current working directory in that case.
FreeBSD's find does not allow that. I'm not sure if this could be a bug
in FreeBSD's find implementation, but for now the patch will do what was
intended in the Makefile.

Regards,
Andreas

PS: Here's the error message on FreeBSD:
find: illegal option -- n
find: illegal option -- a
find: illegal option -- m
find: illegal option -- e
find: *.d: No such file or directory
gmake[2]: Entering directory
`/storage/quake3/icculus.org/quake3/code/unix'

-- 
<TalisA> was macht man eigentlich auf einer linux-gamer lan ? hl server
aufsetzen und freuen ? *duck* ^^
-------------- next part --------------
A non-text attachment was scrubbed...
Name: code-unix-Makefile-find.diff
Type: text/x-patch
Size: 436 bytes
Desc: not available
URL: <http://icculus.org/pipermail/quake3/attachments/20051006/85f1e855/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
URL: <http://icculus.org/pipermail/quake3/attachments/20051006/85f1e855/attachment.pgp>

From tim at ngus.net  Thu Oct  6 11:13:29 2005
From: tim at ngus.net (Tim Angus)
Date: Thu, 6 Oct 2005 16:13:29 +0100
Subject: small fix to compile with nvidia gl headers
In-Reply-To: <30719.1128592949@www83.gmx.net>
References: <30719.1128592949@www83.gmx.net>
Message-ID: <20051006161329.6f026b05.tim@ngus.net>

On Thu, 6 Oct 2005 12:02:29 +0200 (MEST) DER.FABE at gmx.net wrote:
> This patch allows compilation with both nvidia and 
> mesa gl headers. 
>  
> bugzilla: 
> https://bugzilla.icculus.org/show_bug.cgi?id=2407 

I'm not sure I understand this patch. Both my nvidia (latest version
AFAIK) and mesa headers include glext.h from GL.h anyway. Could you
explain why you need this with your configuration?


From tim at ngus.net  Thu Oct  6 11:17:44 2005
From: tim at ngus.net (Tim Angus)
Date: Thu, 6 Oct 2005 16:17:44 +0100
Subject: avoid find error on freebsd
In-Reply-To: <1128610792.1273.4.camel@klamath.syndrom23.de>
References: <1128610792.1273.4.camel@klamath.syndrom23.de>
Message-ID: <20051006161744.16e08130.tim@ngus.net>

On Thu, 06 Oct 2005 16:59:51 +0200 Andreas wrote:
> attached is a small fix to code/unix/Makefile that avoids an error
> when calling find.

Applied, thanks.

As an aside, do the vm files build correctly on FreeBSD (in
code/unix/[builddir]/baseq3/vm)?


From der.fabe at gmx.net  Thu Oct  6 11:23:50 2005
From: der.fabe at gmx.net (Fabian Bieler)
Date: Thu, 6 Oct 2005 17:23:50 +0200
Subject: [quake3] Re: small fix to compile with nvidia gl headers
In-Reply-To: <20051006161329.6f026b05.tim@ngus.net>
References: <30719.1128592949@www83.gmx.net> <20051006161329.6f026b05.tim@ngus.net>
Message-ID: <200510061723.50247.der.fabe@gmx.net>

On Thursday 06 October 2005 17:13, Tim Angus wrote:
> On Thu, 6 Oct 2005 12:02:29 +0200 (MEST) DER.FABE at gmx.net wrote:
> > This patch allows compilation with both nvidia and
> > mesa gl headers.
> >
> > bugzilla:
> > https://bugzilla.icculus.org/show_bug.cgi?id=2407
>
> I'm not sure I understand this patch. Both my nvidia (latest version
> AFAIK) and mesa headers include glext.h from GL.h anyway. Could you
> explain why you need this with your configuration?

In the nvidia headers that came with driver version 66.29 (which I am using) 
glext.h is not included from gl.h. If this is however the case with the 
current nvidia driver, I guess this patch isn't really necessary.


From andreas at syndrom23.de  Thu Oct  6 11:45:14 2005
From: andreas at syndrom23.de (Andreas Kohn)
Date: Thu, 06 Oct 2005 17:45:14 +0200
Subject: [quake3] Re: avoid find error on freebsd
In-Reply-To: <20051006161744.16e08130.tim@ngus.net>
References: <1128610792.1273.4.camel@klamath.syndrom23.de>
	 <20051006161744.16e08130.tim@ngus.net>
Message-ID: <1128613514.1273.14.camel@klamath.syndrom23.de>

On Thu, 2005-10-06 at 16:17 +0100, Tim Angus wrote:
> On Thu, 06 Oct 2005 16:59:51 +0200 Andreas wrote:
> > attached is a small fix to code/unix/Makefile that avoids an error
> > when calling find.
> 
> Applied, thanks.
> 
> As an aside, do the vm files build correctly on FreeBSD (in
> code/unix/[builddir]/baseq3/vm)?

As far as I can tell they build[1], yes: 
-rw-r--r--  1 andreas  wheel  - 327996 Oct  6 17:36 cgame.qvm
-rw-r--r--  1 andreas  wheel  - 470500 Oct  6 17:36 qagame.qvm
-rw-r--r--  1 andreas  wheel  - 278568 Oct  6 17:36 ui.qvm

[1] Patch needed for q3asm cmdlib.c attached...another one of the
__linux defines :)
I changed the logic to treat POSIXy systems as default, hope that's
okay.

There is also some problem with the clean targets, .o files remain left
after it. Looking into that one currently.

Regards, 
Andreas

-- 
<TalisA> was macht man eigentlich auf einer linux-gamer lan ? hl server
aufsetzen und freuen ? *duck* ^^
-------------- next part --------------
A non-text attachment was scrubbed...
Name: code-tools-asm-cmdlib.c.diff
Type: text/x-patch
Size: 531 bytes
Desc: not available
URL: <http://icculus.org/pipermail/quake3/attachments/20051006/9deec3cb/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
URL: <http://icculus.org/pipermail/quake3/attachments/20051006/9deec3cb/attachment.pgp>

From andreas at syndrom23.de  Thu Oct  6 11:52:02 2005
From: andreas at syndrom23.de (Andreas Kohn)
Date: Thu, 06 Oct 2005 17:52:02 +0200
Subject: [quake3] Re: avoid find error on freebsd
In-Reply-To: <1128613514.1273.14.camel@klamath.syndrom23.de>
References: <1128610792.1273.4.camel@klamath.syndrom23.de>
	 <20051006161744.16e08130.tim@ngus.net>
	 <1128613514.1273.14.camel@klamath.syndrom23.de>
Message-ID: <1128613922.1273.20.camel@klamath.syndrom23.de>

On Thu, 2005-10-06 at 17:45 +0200, Andreas Kohn wrote:
> On Thu, 2005-10-06 at 16:17 +0100, Tim Angus wrote:
> > On Thu, 06 Oct 2005 16:59:51 +0200 Andreas wrote:
> > > attached is a small fix to code/unix/Makefile that avoids an error
> > > when calling find.
> > 
> > Applied, thanks.
> > 
> > As an aside, do the vm files build correctly on FreeBSD (in
> > code/unix/[builddir]/baseq3/vm)?
> 
> [snip]
>

I knew I'll forget about that one...
You can probably not build q3lcc on a stock FreeBSD system, because cc
-print-search-dirs is broken. 

From code/tools/lcc/makefile
143:SYSTEM=$(shell cc -print-search-dirs | head -n 1 | cut -b 10-)

Definitely a FreeBSD error, and I submitted a PR about that one some
time ago:

http://www.freebsd.org/cgi/query-pr.cgi?pr=gnu/85895

Just FYI, perhaps this should end up as a note in the documentation
sometimes :)

Ciao,
--
Andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
URL: <http://icculus.org/pipermail/quake3/attachments/20051006/6604ae80/attachment.pgp>

From tim at ngus.net  Thu Oct  6 15:08:06 2005
From: tim at ngus.net (Tim Angus)
Date: Thu, 6 Oct 2005 20:08:06 +0100
Subject: avoid find error on freebsd
In-Reply-To: <1128613922.1273.20.camel@klamath.syndrom23.de>
References: <1128610792.1273.4.camel@klamath.syndrom23.de>
	<20051006161744.16e08130.tim@ngus.net>
	<1128613514.1273.14.camel@klamath.syndrom23.de>
	<1128613922.1273.20.camel@klamath.syndrom23.de>
Message-ID: <20051006200806.5124c5a3.tim@ngus.net>

On Thu, 06 Oct 2005 17:52:02 +0200 Andreas wrote:
> I knew I'll forget about that one...
> You can probably not build q3lcc on a stock FreeBSD system, because cc
> -print-search-dirs is broken. 
> 
> From code/tools/lcc/makefile
> 143:SYSTEM=$(shell cc -print-search-dirs | head -n 1 | cut -b 10-)
> 
> Definitely a FreeBSD error, and I submitted a PR about that one some
> time ago:

To be honest that variable probably doesn't need to be set, or at least
it shouldn't need to be set. For our purposes q3lcc only actually uses
the bytecode target (which is more or less just the IR of lcc), but
there are still vast chunks of cruft in there that should probably just
be removed. For example q3lcc as distributed with the source release is
still a fully functional alpha/mips/sparc/x86 compiler. Obviously this
functionality is not required, nor is the headache of maintaining it
across platforms.

I'll have a little poke about and see if I can remove the requirement
for cc for the time being, although long term it's probably a good move
to fully audit the q3lcc source and strip out all the target platform
specific stuff.


From jaq at spacepants.org  Thu Oct  6 22:16:37 2005
From: jaq at spacepants.org (Jamie Wilkinson)
Date: Fri, 7 Oct 2005 12:16:37 +1000
Subject: removing jpeglib from svn
Message-ID: <20051007021637.GA3490@spacepants.org>

I've got a patch at bug#2408, which builds, but I haven't yet had a chance
to test that it doesn't crash -- I plan on doing that tonight, but if anyone
else wants to grab it and try it, feel free to do so and complain that it
blew up.

I took the memory buffer code from various examples on the internets, it
appears that the original jpeg loader code was also clagged from example
code, based on the comments in LoadJPG :)  I welcome comments on the
readability and quality of the new functions, because I'm not totally happy
with it :)

Also worth mentioning: the code has a SaveJPG function and support functions
including jpeg_start_compress, and jpeg_write_scanlines, which seem to be
the only reason for needing the define of JPEG_INTERNALS at the top.  Does
quake3 actually need to write jpegs?  I haven't looked to see if SaveJPG is
called from anywhere else, but I would have thought that file transfers from
a game server don't decode and require re-encoding of texture data.  I'm
going to bin this later if I find it's not necessary.


From kell at spoonix.com  Fri Oct  7 03:20:40 2005
From: kell at spoonix.com (K. Spoon)
Date: Fri, 7 Oct 2005 02:20:40 -0500
Subject: [quake3] removing jpeglib from svn
In-Reply-To: <20051007021637.GA3490@spacepants.org>
References: <20051007021637.GA3490@spacepants.org>
Message-ID: <20051007072040.GA11825@inverness.spoonix.com>

On Fri, Oct 07, 2005 at 12:16:37PM +1000, Jamie Wilkinson wrote:
> Also worth mentioning: the code has a SaveJPG function and support functions
> including jpeg_start_compress, and jpeg_write_scanlines, which seem to be
> the only reason for needing the define of JPEG_INTERNALS at the top.  Does
> quake3 actually need to write jpegs?

It might not be necessary, but it could be handy.  I don't know much
about q3, but from my experience with ET, being able to save screenshots
in jpeg is nice for movie makers as it removes a step from the process
of creating an avi (not to mention the fact that a jpeg takes up less
space than a targa, hence more time to record that trickjump in slow-mo :).

Also, one of the features of punkbuster's server side stuff was the
ability to take a screenshot when it detected a violation.  SaveJPG
might come in handy if some intrepid soul attempts to provide a PB
replacement at some point in the future.

Doesn't matter to me either way, just tossing out some reasons to keep
it around as long as it's not misbehaving.  :)

-- 
K. Spoon <kell at spoonix.com>


From arny at ats.s.bawue.de  Fri Oct  7 04:28:00 2005
From: arny at ats.s.bawue.de (Thilo Schulz)
Date: Fri, 7 Oct 2005 10:28:00 +0200
Subject: [quake3] removing jpeglib from svn
In-Reply-To: <20051007072040.GA11825@inverness.spoonix.com>
References: <20051007021637.GA3490@spacepants.org> <20051007072040.GA11825@inverness.spoonix.com>
Message-ID: <200510071028.12624.arny@ats.s.bawue.de>

On Friday 07 October 2005 09:20, K. Spoon wrote:
> It might not be necessary, but it could be handy.  I don't know much
> about q3, but from my experience with ET, being able to save screenshots
> in jpeg is nice for movie makers as it removes a step from the process
> of creating an avi (not to mention the fact that a jpeg takes up less
> space than a targa, hence more time to record that trickjump in slow-mo :).

If you check the standard pak files, you will notice that a large number of 
textures are in jpeg format.

-- 
Thilo Schulz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://icculus.org/pipermail/quake3/attachments/20051007/f6134ab9/attachment.pgp>

From jaq at spacepants.org  Fri Oct  7 10:02:55 2005
From: jaq at spacepants.org (Jamie Wilkinson)
Date: Sat, 8 Oct 2005 00:02:55 +1000
Subject: [quake3] removing jpeglib from svn
In-Reply-To: <200510071028.12624.arny@ats.s.bawue.de>
References: <20051007021637.GA3490@spacepants.org> <20051007072040.GA11825@inverness.spoonix.com> <200510071028.12624.arny@ats.s.bawue.de>
Message-ID: <20051007140255.GC16073@spacepants.org>

This one time, at band camp, Thilo Schulz wrote:
>On Friday 07 October 2005 09:20, K. Spoon wrote:
>> It might not be necessary, but it could be handy.  I don't know much
>> about q3, but from my experience with ET, being able to save screenshots
>> in jpeg is nice for movie makers as it removes a step from the process
>> of creating an avi (not to mention the fact that a jpeg takes up less
>> space than a targa, hence more time to record that trickjump in slow-mo :).
>
>If you check the standard pak files, you will notice that a large number of 
>textures are in jpeg format.

Uh, that's why there's a jpeg loader.  What point are you trying to make?


From jaq at spacepants.org  Fri Oct  7 10:07:34 2005
From: jaq at spacepants.org (Jamie Wilkinson)
Date: Sat, 8 Oct 2005 00:07:34 +1000
Subject: [quake3] removing jpeglib from svn
In-Reply-To: <20051007021637.GA3490@spacepants.org>
References: <20051007021637.GA3490@spacepants.org>
Message-ID: <20051007140734.GD16073@spacepants.org>

This one time, at band camp, Jamie Wilkinson wrote:
>I've got a patch at bug#2408, which builds, but I haven't yet had a chance
>to test that it doesn't crash -- I plan on doing that tonight, but if anyone
>else wants to grab it and try it, feel free to do so and complain that it
>blew up.

Well, it blows up; you get some awesome moire patterns in the skyboxes.
I'll take another look at it tomorrow.


From jaq at spacepants.org  Fri Oct  7 10:10:39 2005
From: jaq at spacepants.org (Jamie Wilkinson)
Date: Sat, 8 Oct 2005 00:10:39 +1000
Subject: [quake3] removing jpeglib from svn
In-Reply-To: <20051007072040.GA11825@inverness.spoonix.com>
References: <20051007021637.GA3490@spacepants.org> <20051007072040.GA11825@inverness.spoonix.com>
Message-ID: <20051007141039.GE16073@spacepants.org>

This one time, at band camp, K. Spoon wrote:
>On Fri, Oct 07, 2005 at 12:16:37PM +1000, Jamie Wilkinson wrote:
>> Also worth mentioning: the code has a SaveJPG function and support functions
>> including jpeg_start_compress, and jpeg_write_scanlines, which seem to be
>> the only reason for needing the define of JPEG_INTERNALS at the top.  Does
>> quake3 actually need to write jpegs?
>
>It might not be necessary, but it could be handy.  I don't know much
>about q3, but from my experience with ET, being able to save screenshots
>in jpeg is nice for movie makers as it removes a step from the process
>of creating an avi (not to mention the fact that a jpeg takes up less
>space than a targa, hence more time to record that trickjump in slow-mo :).

Is there a special key for screening a jpeg?  I just hit F11 in-game and it
wrote out a targa file.


From debeuk at gmail.com  Fri Oct  7 11:08:15 2005
From: debeuk at gmail.com (Sven Beukenex)
Date: Fri, 7 Oct 2005 17:08:15 +0200
Subject: [quake3] removing jpeglib from svn
In-Reply-To: <20051007141039.GE16073@spacepants.org>
References: <20051007021637.GA3490@spacepants.org>
	 <20051007072040.GA11825@inverness.spoonix.com>
	 <20051007141039.GE16073@spacepants.org>
Message-ID: <9a224f8b0510070808l5d5beb08m5a84cf211b502263@mail.gmail.com>

On 10/7/05, Jamie Wilkinson <jaq at spacepants.org> wrote:
>
> This one time, at band camp, K. Spoon wrote:
> >On Fri, Oct 07, 2005 at 12:16:37PM +1000, Jamie Wilkinson wrote:
> >> Also worth mentioning: the code has a SaveJPG function and support
> functions
> >> including jpeg_start_compress, and jpeg_write_scanlines, which seem to
> be
> >> the only reason for needing the define of JPEG_INTERNALS at the top.
> Does
> >> quake3 actually need to write jpegs?
> >
> >It might not be necessary, but it could be handy. I don't know much
> >about q3, but from my experience with ET, being able to save screenshots
> >in jpeg is nice for movie makers as it removes a step from the process
> >of creating an avi (not to mention the fact that a jpeg takes up less
> >space than a targa, hence more time to record that trickjump in slow-mo
> :).
>
> Is there a special key for screening a jpeg? I just hit F11 in-game and it
> wrote out a targa file.
>

Bind a key to "screenshotJPEG"

--

Why are the pretty ones always insane?
-- J.G. Thirlwell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://icculus.org/pipermail/quake3/attachments/20051007/229e45bc/attachment.htm>

From ludwig.nussel at suse.de  Fri Oct  7 21:45:35 2005
From: ludwig.nussel at suse.de (Ludwig Nussel)
Date: Sat, 8 Oct 2005 03:45:35 +0200
Subject: [quake3] Re: C++? when did that happen?
In-Reply-To: <20051006003705.5d63d093.tim@ngus.net>
References: <1128548612.11801.25.camel@localhost> <1128552913.11801.33.camel@localhost> <20051006003705.5d63d093.tim@ngus.net>
Message-ID: <200510080345.36022.ludwig.nussel@suse.de>

Tim Angus wrote:
> [...]
> I'll say again, using 0 in place of NULL in C is perfectly valid and
> correct. Yes, NULL is implementation defined, but that DOES NOT make the
> use of 0 in place of NULL wrong, nor does it make it a "C++ism".

You cannot blindly replace NULL with 0. sizeof(0) != sizeof(NULL) on
64bit platforms. Variadic functions for example will break if you pass 0 where
you wanted to pass NULL. So always use NULL if you refer to a pointer.

cu
Ludwig

-- 
 (o_   Ludwig Nussel
 //\   SUSE LINUX Products GmbH, Development
 V_/_  http://www.suse.de/




From pomac at vapor.com  Fri Oct  7 22:29:38 2005
From: pomac at vapor.com (Ian Kumlien)
Date: Sat, 08 Oct 2005 04:29:38 +0200
Subject: [quake3] Re: C++? when did that happen?
In-Reply-To: <200510080345.36022.ludwig.nussel@suse.de>
References: <1128548612.11801.25.camel@localhost>
	 <1128552913.11801.33.camel@localhost>
	 <20051006003705.5d63d093.tim@ngus.net>
	 <200510080345.36022.ludwig.nussel@suse.de>
Message-ID: <1128738578.9905.7.camel@localhost>

On Sat, 2005-10-08 at 03:45 +0200, Ludwig Nussel wrote:
> Tim Angus wrote:
> > [...]
> > I'll say again, using 0 in place of NULL in C is perfectly valid and
> > correct. Yes, NULL is implementation defined, but that DOES NOT make the
> > use of 0 in place of NULL wrong, nor does it make it a "C++ism".
> 
> You cannot blindly replace NULL with 0. sizeof(0) != sizeof(NULL) on
> 64bit platforms. Variadic functions for example will break if you pass 0 where
> you wanted to pass NULL. So always use NULL if you refer to a pointer.

I actually found some information that claimed more or less that:
pointer = 0 would be translated to pointer = 0 or pointer = (void *)0 as
needed... I looked for this more or less specifically since i also use a
64 bit platform. (I do however hope that it's 0L or (void *)0 since that
would handle the to small pointer issues that usually happens)

However this is for ID's own compiler so i don't see it as serious as a
common compiler (ie, if it makes a mistake the fix will be local not
global and it is also a C++ compiler which should have the smarts
mentioned above).

-- 
Ian Kumlien <pomac () vapor ! com> -- http://pomac.netswarm.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://icculus.org/pipermail/quake3/attachments/20051008/40878ece/attachment.pgp>

From tim at ngus.net  Sat Oct  8 11:30:05 2005
From: tim at ngus.net (Tim Angus)
Date: Sat, 8 Oct 2005 16:30:05 +0100
Subject: C++? when did that happen?
In-Reply-To: <200510080345.36022.ludwig.nussel@suse.de>
References: <1128548612.11801.25.camel@localhost>
	<1128552913.11801.33.camel@localhost>
	<20051006003705.5d63d093.tim@ngus.net>
	<200510080345.36022.ludwig.nussel@suse.de>
Message-ID: <20051008163005.0dc420aa.tim@ngus.net>

On Sat, 8 Oct 2005 03:45:35 +0200 Ludwig wrote:
> Tim Angus wrote:
> > [...]
> > I'll say again, using 0 in place of NULL in C is perfectly valid and
> > correct. Yes, NULL is implementation defined, but that DOES NOT make
> > the use of 0 in place of NULL wrong, nor does it make it a "C++ism".
> 
> You cannot blindly replace NULL with 0. sizeof(0) != sizeof(NULL) on
> 64bit platforms. Variadic functions for example will break if you pass
> 0 where you wanted to pass NULL. So always use NULL if you refer to a
> pointer.

In the general case though, if you have a function:

void function( something *p );

...and you call it...

function( 0 );

...what the compiler actually emits is...

function( (something *)0 ); // where sizeof( 0 ) is the appropriate word
size

The sizeof 0 doesn't matter since 0 is really being used as a contextual
token to denote a null pointer, not an actual value.

I'm not suggesting that every NULL be replaced with 0. When writing C, I
use NULL to initialise pointers. My point is that it is OK to use 0
instead of NULL in the general case, and especially in this case.


From tim at ngus.net  Sat Oct  8 11:50:03 2005
From: tim at ngus.net (Tim Angus)
Date: Sat, 8 Oct 2005 16:50:03 +0100
Subject: removing jpeglib from svn
In-Reply-To: <20051007021637.GA3490@spacepants.org>
References: <20051007021637.GA3490@spacepants.org>
Message-ID: <20051008165003.3200061d.tim@ngus.net>

On Fri, 7 Oct 2005 12:16:37 +1000 Jamie wrote:
> I've got a patch at bug#2408, which builds, but I haven't yet had a
> chance to test that it doesn't crash -- I plan on doing that tonight,
> but if anyone else wants to grab it and try it, feel free to do so and
> complain that it blew up.

I've mentioned before* that I don't really see the point in messing with
what already works unless you get some intrinsic (and significant)
benefit. I don't mind the idea of simply updating the jpeg source that
is there to a more recent version (providing it is done carefully), but
dynamically linking sounds like a pain we don't need. It's particularly
a problem on Windows, where you'd thereafter need to request the user to
go and find libjpeg.dll (or whatever) or distribute it with your
binary/source. This is prone to problems.

For anybody who actually wants to do something useful with the source,
Windows is the primary platform (like it or not), and it needs to be
taken into consideration.

> Does quake3 actually need to write jpegs? 

Yes, for jpeg screenshots. (Perhaps this should be the default by the
way? i.e. create a screenshotTGA command and move the screenshotJPEG
command to screenshot. It would certainly make movie creation somewhat
less I/O intensive).

* http://www.quakesrc.org/forums/viewtopic.php?t=5464


From tim at ngus.net  Sat Oct  8 11:53:34 2005
From: tim at ngus.net (Tim Angus)
Date: Sat, 8 Oct 2005 16:53:34 +0100
Subject: removing jpeglib from svn
In-Reply-To: <20051007140255.GC16073@spacepants.org>
References: <20051007021637.GA3490@spacepants.org>
	<20051007072040.GA11825@inverness.spoonix.com>
	<200510071028.12624.arny@ats.s.bawue.de>
	<20051007140255.GC16073@spacepants.org>
Message-ID: <20051008165334.2a845b0d.tim@ngus.net>

On Sat, 8 Oct 2005 00:02:55 +1000 Jamie wrote:
> >If you check the standard pak files, you will notice that a large
> >number of  textures are in jpeg format.
> 
> Uh, that's why there's a jpeg loader.  What point are you trying to
> make?

I think that K. Spoon seemed to think you were proposing removing jpeg
support altogether. Thilo replied to inform him why jpeg support is
required.


From bnoordhuis at gmail.com  Sat Oct  8 13:19:29 2005
From: bnoordhuis at gmail.com (Ben Noordhuis)
Date: Sat, 8 Oct 2005 19:19:29 +0200
Subject: [quake3] Re: C++? when did that happen?
In-Reply-To: <200510080345.36022.ludwig.nussel@suse.de>
References: <1128548612.11801.25.camel@localhost>
	 <1128552913.11801.33.camel@localhost>
	 <20051006003705.5d63d093.tim@ngus.net>
	 <200510080345.36022.ludwig.nussel@suse.de>
Message-ID: <54885e060510081019p1e2093ccna3c510fcb483cad7@mail.gmail.com>

On 10/8/05, Ludwig Nussel <ludwig.nussel at suse.de> wrote:
> You cannot blindly replace NULL with 0. sizeof(0) != sizeof(NULL) on
> 64bit platforms. Variadic functions for example will break if you pass 0 where
> you wanted to pass NULL. So always use NULL if you refer to a pointer.

Chapter 5.9 of the C FAQ (http://www.eskimo.com/~scs/C-faq/q5.9.html):

"Many programmers believe that NULL should be used in all pointer
contexts, as a reminder that the value is to be thought of as a
pointer. Others feel that the confusion surrounding NULL and 0 is only
compounded by hiding 0 behind a macro, and prefer to use unadorned 0
instead. There is no one right answer. (See also questions 9.2 and
17.10.) C programmers must understand that NULL and 0 are
interchangeable in pointer contexts, and that an uncast 0 is perfectly
acceptable. Any usage of NULL (as opposed to 0) should be considered a
gentle reminder that a pointer is involved; programmers should not
depend on it (either for their own understanding or the compiler's)
for distinguishing pointer 0's from integer 0's."

Carefully read the last line, please.
Sincerely,

Ben


From jaq at spacepants.org  Sat Oct  8 19:46:01 2005
From: jaq at spacepants.org (Jamie Wilkinson)
Date: Sun, 9 Oct 2005 09:46:01 +1000
Subject: [quake3] Re: removing jpeglib from svn
In-Reply-To: <20051008165003.3200061d.tim@ngus.net>
References: <20051007021637.GA3490@spacepants.org> <20051008165003.3200061d.tim@ngus.net>
Message-ID: <20051008234601.GA30364@spacepants.org>

This one time, at band camp, Tim Angus wrote:
>On Fri, 7 Oct 2005 12:16:37 +1000 Jamie wrote:
>> I've got a patch at bug#2408, which builds, but I haven't yet had a
>> chance to test that it doesn't crash -- I plan on doing that tonight,
>> but if anyone else wants to grab it and try it, feel free to do so and
>> complain that it blew up.
>
>I've mentioned before* that I don't really see the point in messing with
>what already works unless you get some intrinsic (and significant)
>benefit. I don't mind the idea of simply updating the jpeg source that
>is there to a more recent version (providing it is done carefully), but
>dynamically linking sounds like a pain we don't need. It's particularly
>a problem on Windows, where you'd thereafter need to request the user to
>go and find libjpeg.dll (or whatever) or distribute it with your
>binary/source. This is prone to problems.

Oh; your comments recently about stripping non-bytecode support from q3lcc
seemed to indicate you felt otherwise.  Thanks for the clarification.

Without knowing anything about windows, is it actually that difficult to get
a jpeglib DLL to either build against, or use to play the game?

>For anybody who actually wants to do something useful with the source,
>Windows is the primary platform (like it or not), and it needs to be
>taken into consideration.

I was under the impression the icculus project was all about Linux support.

>> Does quake3 actually need to write jpegs? 
>
>Yes, for jpeg screenshots. (Perhaps this should be the default by the
>way? i.e. create a screenshotTGA command and move the screenshotJPEG
>command to screenshot. It would certainly make movie creation somewhat
>less I/O intensive).

Yeah, as pointed out elsewhere in the thread.


From zakk at timedoctor.org  Sat Oct  8 20:27:54 2005
From: zakk at timedoctor.org (Zachary J. Slater)
Date: Sat, 8 Oct 2005 17:27:54 -0700
Subject: [quake3] Re: removing jpeglib from svn
In-Reply-To: <20051008234601.GA30364@spacepants.org>
References: <20051007021637.GA3490@spacepants.org> <20051008165003.3200061d.tim@ngus.net> <20051008234601.GA30364@spacepants.org>
Message-ID: <20051009002754.GA10566@timedoctor.org>

On Sun, Oct 09, 2005 at 09:46:01AM +1000, Jamie Wilkinson wrote:
> 
> I was under the impression the icculus project was all about Linux support.

icculus.org projects are not solely about Linux support. I created
icculus.org/quake3 in the hope that three major platforms would be
supported. 

The only reason there hasn't been a more official release is due to
my waiting for OS X and Windows builds (Linux will just be a 
source release).
-- 
-Zachary J. Slater
zakk at timedoctor.org
zacharyslater at gmail.com


From ludwig.nussel at suse.de  Sun Oct  9 11:41:54 2005
From: ludwig.nussel at suse.de (Ludwig Nussel)
Date: Sun, 9 Oct 2005 17:41:54 +0200
Subject: [quake3] Re: removing jpeglib from svn
In-Reply-To: <20051009002754.GA10566@timedoctor.org>
References: <20051007021637.GA3490@spacepants.org> <20051008234601.GA30364@spacepants.org> <20051009002754.GA10566@timedoctor.org>
Message-ID: <200510091741.54440.ludwig.nussel@suse.de>

Zachary J. Slater wrote:
> On Sun, Oct 09, 2005 at 09:46:01AM +1000, Jamie Wilkinson wrote:
> > I was under the impression the icculus project was all about Linux
> > support.
>
> icculus.org projects are not solely about Linux support. I created
> icculus.org/quake3 in the hope that three major platforms would be
> supported.
>
> The only reason there hasn't been a more official release is due to
> my waiting for OS X and Windows builds (Linux will just be a
> source release).

FWIW q3 currently builds (which does not necessarily mean it also runs) on
Linux i386, ia64, ppc, ppc64, s390, s390x, x86_64. lcc currently fails on 
ia64.

In case anyone wants to try q3 but is too lazy to compile it, here are
packages: ftp://ftp.suse.com/pub/people/lnussel/quake3/ (glibc 2.3)

cu
Ludwig

-- 
 (o_   Ludwig Nussel
 //\   SUSE LINUX Products GmbH, Development
 V_/_  http://www.suse.de/



From tim at ngus.net  Sun Oct  9 11:46:42 2005
From: tim at ngus.net (Tim Angus)
Date: Sun, 9 Oct 2005 16:46:42 +0100
Subject: removing jpeglib from svn
In-Reply-To: <20051008234601.GA30364@spacepants.org>
References: <20051007021637.GA3490@spacepants.org>
	<20051008165003.3200061d.tim@ngus.net>
	<20051008234601.GA30364@spacepants.org>
Message-ID: <20051009164642.7656483b.tim@ngus.net>

On Sun, 9 Oct 2005 09:46:01 +1000 Jamie wrote:
> Oh; your comments recently about stripping non-bytecode support from
> q3lcc seemed to indicate you felt otherwise.  Thanks for the
> clarification.

The non-bytecode support in q3lcc is completely unnecessary and unused,
whereas jpeg support is fundamentally necessary and used throughout.
Messing with the unused portions of q3lcc is not at all analogous to
changing the jpeg code.


From tim at ngus.net  Sun Oct  9 11:50:29 2005
From: tim at ngus.net (Tim Angus)
Date: Sun, 9 Oct 2005 16:50:29 +0100
Subject: Platform support (was Re: removing jpeglib from svn)
In-Reply-To: <20051009002754.GA10566@timedoctor.org>
References: <20051007021637.GA3490@spacepants.org>
	<20051008165003.3200061d.tim@ngus.net>
	<20051008234601.GA30364@spacepants.org>
	<20051009002754.GA10566@timedoctor.org>
Message-ID: <20051009165029.41ba2bb7.tim@ngus.net>

On Sat, 8 Oct 2005 17:27:54 -0700 Zachary wrote:
> The only reason there hasn't been a more official release is due to
> my waiting for OS X and Windows builds (Linux will just be a 
> source release).

FWIW the MinGW port is 100% working, with identical performace to the
1.32b exe.

(If it were up to me I'd just get rid of the MSVC stuff, since MinGW
works fine and there doesn't seem to be all that much interest in
maintaining the MSVC build... but I can understand why that might be
controversial to some).


From hmd at mail.ru  Sun Oct  9 17:52:15 2005
From: hmd at mail.ru (Eugene 'HMage' Bujak)
Date: Mon, 10 Oct 2005 01:52:15 +0400
Subject: [quake3] Platform support (was Re: removing jpeglib from svn)
In-Reply-To: <20051009165029.41ba2bb7.tim@ngus.net>
References: <20051007021637.GA3490@spacepants.org>	<20051008165003.3200061d.tim@ngus.net>	<20051008234601.GA30364@spacepants.org>	<20051009002754.GA10566@timedoctor.org> <20051009165029.41ba2bb7.tim@ngus.net>
Message-ID: <4349910F.4010601@mail.ru>

Tim Angus wrote:

> (If it were up to me I'd just get rid of the MSVC stuff, since MinGW
> works fine and there doesn't seem to be all that much interest in
> maintaining the MSVC build... but I can understand why that might be
> controversial to some).

Indeed. I am using MSVC6, for example, and am going to do a patch (which 
isn't small, but not huge) that eliminates some warnings while keeping 
GCC from MinGW happy very soon (tested myself with MinGW/current).

-- 
- Eugene 'HMage' Bujak.


From jaq at spacepants.org  Sun Oct  9 20:25:30 2005
From: jaq at spacepants.org (Jamie Wilkinson)
Date: Mon, 10 Oct 2005 10:25:30 +1000
Subject: [quake3] Re: removing jpeglib from svn
In-Reply-To: <20051009164642.7656483b.tim@ngus.net>
References: <20051007021637.GA3490@spacepants.org> <20051008165003.3200061d.tim@ngus.net> <20051008234601.GA30364@spacepants.org> <20051009164642.7656483b.tim@ngus.net>
Message-ID: <20051010002529.GC30364@spacepants.org>

This one time, at band camp, Tim Angus wrote:
>On Sun, 9 Oct 2005 09:46:01 +1000 Jamie wrote:
>> Oh; your comments recently about stripping non-bytecode support from
>> q3lcc seemed to indicate you felt otherwise.  Thanks for the
>> clarification.
>
>The non-bytecode support in q3lcc is completely unnecessary and unused,
>whereas jpeg support is fundamentally necessary and used throughout.
>Messing with the unused portions of q3lcc is not at all analogous to
>changing the jpeg code.

You misread me.  I meant that the general cleanup of code suggested to me
that the project also wanted to reduce maintenance by not having its own
fork of third party libraries.

Do you also plan to include all of SDL in the source?  When the OpenAL patch
is merged, do you plan to ship the openal library also?


From tim at ngus.net  Sun Oct  9 21:21:27 2005
From: tim at ngus.net (Tim Angus)
Date: Mon, 10 Oct 2005 02:21:27 +0100
Subject: removing jpeglib from svn
In-Reply-To: <20051010002529.GC30364@spacepants.org>
References: <20051007021637.GA3490@spacepants.org>
	<20051008165003.3200061d.tim@ngus.net>
	<20051008234601.GA30364@spacepants.org>
	<20051009164642.7656483b.tim@ngus.net>
	<20051010002529.GC30364@spacepants.org>
Message-ID: <20051010022127.65b1af3a.tim@ngus.net>

On Mon, 10 Oct 2005 10:25:30 +1000 Jamie wrote:
> >The non-bytecode support in q3lcc is completely unnecessary and
> >unused, whereas jpeg support is fundamentally necessary and used
> >throughout. Messing with the unused portions of q3lcc is not at all
> >analogous to changing the jpeg code.
> 
> You misread me.

...or you don't make your point clearly enough. ;)

> Do you also plan to include all of SDL in the source?

No, since the point of SDL is that it is a library. It hides all the
platform specific stuff away for you.

> When the OpenAL
> patch is merged, do you plan to ship the openal library also?

I think the best plan with OpenAL is to dynamically load it like OpenGL.
If it fails (i.e. doesn't exist), fall back on platform specific/SDL
sound.

libjpeg is not like either of these examples since it is not platform
specific and Q3 needs it all the time. Delegation of maintenance is not
a big enough pro to outweigh the cons, especially since what is there
works fine and thus doesn't need any maintenance.


From jaq at spacepants.org  Sun Oct  9 22:01:28 2005
From: jaq at spacepants.org (Jamie Wilkinson)
Date: Mon, 10 Oct 2005 12:01:28 +1000
Subject: [quake3] Re: removing jpeglib from svn
In-Reply-To: <20051010022127.65b1af3a.tim@ngus.net>
References: <20051007021637.GA3490@spacepants.org> <20051008165003.3200061d.tim@ngus.net> <20051008234601.GA30364@spacepants.org> <20051009164642.7656483b.tim@ngus.net> <20051010002529.GC30364@spacepants.org> <20051010022127.65b1af3a.tim@ngus.net>
Message-ID: <20051010020128.GE30364@spacepants.org>

This one time, at band camp, Tim Angus wrote:
>On Mon, 10 Oct 2005 10:25:30 +1000 Jamie wrote:
>> >The non-bytecode support in q3lcc is completely unnecessary and
>> >unused, whereas jpeg support is fundamentally necessary and used
>> >throughout. Messing with the unused portions of q3lcc is not at all
>> >analogous to changing the jpeg code.
>> 
>> You misread me.
>
>...or you don't make your point clearly enough. ;)

More probable: I hadn't had any coffee :)

>libjpeg is not like either of these examples since it is not platform
>specific and Q3 needs it all the time. Delegation of maintenance is not
>a big enough pro to outweigh the cons, especially since what is there
>works fine and thus doesn't need any maintenance.

Ok.


From email at asfandyar.cjb.net  Mon Oct 10 02:03:57 2005
From: email at asfandyar.cjb.net (Asfand Yar Qazi)
Date: Mon, 10 Oct 2005 07:03:57 +0100
Subject: Header file errors
Message-ID: <434A044D.8050905@asfandyar.cjb.net>

Hello,

Got the following error (I'm using the nVidia headers from driver 
6111, I can't upgrade since later versions of the driver make X hang 
or crash.)

[asfand at big ~/src/games/quake3/icculus_quake3/quake3.build]
$ make
make -C code/unix release
make[1]: Entering directory 
`/home/asfand/src/games/quake3/icculus_quake3/quake3.build/code/unix'
make  targets B=releasei386-glibc CFLAGS=" -pipe -Wall -Wimplicit 
-Wstrict-prototypes -DUSE_SDL=1 -I/opt/sdl/include/SDL -D_REENTRANT 
-DHAVE_VM_NATIVE -DHAVE_VM_COMPILED -m32 -DNDEBUG -O3 -march=i686 
-fomit-frame-pointer -ffast-math -falign-loops=2 -falign-jumps=2 
-falign-functions=2 -fno-strict-aliasing -fstrength-reduce -MMD"
make[2]: Entering directory 
`/home/asfand/src/games/quake3/icculus_quake3/quake3.build/code/unix'
gcc -pipe -Wall -Wimplicit -Wstrict-prototypes -DUSE_SDL=1 
-I/opt/sdl/include/SDL -D_REENTRANT -DHAVE_VM_NATIVE 
-DHAVE_VM_COMPILED -m32 -DNDEBUG -O3 -march=i686 -fomit-frame-pointer 
-ffast-math -falign-loops=2 -falign-jumps=2 -falign-functions=2 
-fno-strict-aliasing -fstrength-reduce -MMD -o 
releasei386-glibc/client/jerror.o -c ../jpeg-6/jerror.c
In file included from /usr/X11R6/include/GL/glx.h:25,
                  from ../jpeg-6/../renderer/qgl.h:54,
                  from ../jpeg-6/../renderer/tr_local.h:31,
                  from ../jpeg-6/jerror.c:22:
/usr/X11R6/include/X11/Xmd.h:100:1: warning: "SIZEOF" redefined
In file included from ../jpeg-6/jerror.c:17:
../jpeg-6/jinclude.h:105:1: warning: this is the location of the 
previous definition
In file included from /usr/X11R6/include/GL/glx.h:25,
                  from ../jpeg-6/../renderer/qgl.h:54,
                  from ../jpeg-6/../renderer/tr_local.h:31,
                  from ../jpeg-6/jerror.c:22:
/usr/X11R6/include/X11/Xmd.h:134: error: redefinition of typedef 'INT32'
../jpeg-6/../jpeg-6/jmorecfg.h:153: error: previous declaration of 
'INT32' was here
/usr/X11R6/include/X11/Xmd.h:136: error: redefinition of typedef 'INT16'
../jpeg-6/../jpeg-6/jmorecfg.h:159: error: previous declaration of 
'INT16' was here
make[2]: *** [releasei386-glibc/client/jerror.o] Error 1
make[2]: Leaving directory 
`/home/asfand/src/games/quake3/icculus_quake3/quake3.build/code/unix'
make[1]: *** [build_release] Error 2
make[1]: Leaving directory 
`/home/asfand/src/games/quake3/icculus_quake3/quake3.build/code/unix'
make: *** [release] Error 2

Huh?  I'm sleepy so..... I'll work up an #ifdef/#undef style patch 
later, but just bringing it to the attention of the list members for 
now.  BTW, I'm still stuck on XFree86 4.3 vanilla version, perhaps 
they didn't hide their internal defines too well.

Also, may I suggest inclusion of your GL headers with the source?  I 
believe there are many OpenGL projects that do this already, due to 
incompatibilities between header versions (OpenSceneGraph being one of 
them, I think - or was it someone else?)  Having a standard set of GL 
headers would make development easier, I feel.  No errors so far, but 
still, just in case

Thanks


From andreas at syndrom23.de  Mon Oct 10 06:23:20 2005
From: andreas at syndrom23.de (Andreas Kohn)
Date: Mon, 10 Oct 2005 12:23:20 +0200
Subject: [quake3] Header file errors
In-Reply-To: <434A044D.8050905@asfandyar.cjb.net>
References: <434A044D.8050905@asfandyar.cjb.net>
Message-ID: <1128939800.1019.10.camel@klamath.syndrom23.de>

On Mon, 2005-10-10 at 07:03 +0100, Asfand Yar Qazi wrote:
> Hello,
> 
> Got the following error (I'm using the nVidia headers from driver 
> 6111, I can't upgrade since later versions of the driver make X hang 
> or crash.)
>
> [X11/Xmd.h redefining some symbols.]
>
> Also, may I suggest inclusion of your GL headers with the source?  I 
> believe there are many OpenGL projects that do this already, due to 
> incompatibilities between header versions (OpenSceneGraph being one of 
> them, I think - or was it someone else?)  Having a standard set of GL 
> headers would make development easier, I feel.  No errors so far, but 
> still, just in case

Please, no!

The OpenGL headers are system headers, and not headers from some
arbitrary library. 

My 2ct,
Andreas

PS: I'm using Xorg 6.8.2 with nvidia 1.0.6113 driver, and my OpenGL
headers in /usr/X11R6/include/GL are still from Mesa/SGI. Nvidia's
headers are only in the driver's doc/ directory.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
URL: <http://icculus.org/pipermail/quake3/attachments/20051010/134de217/attachment.pgp>

From email at asfandyar.cjb.net  Mon Oct 10 07:38:47 2005
From: email at asfandyar.cjb.net (Asfand Yar Qazi)
Date: Mon, 10 Oct 2005 12:38:47 +0100
Subject: [quake3] Header file errors
In-Reply-To: <1128939800.1019.10.camel@klamath.syndrom23.de>
References: <434A044D.8050905@asfandyar.cjb.net> <1128939800.1019.10.camel@klamath.syndrom23.de>
Message-ID: <434A52C7.4030103@asfandyar.cjb.net>

> 
> Please, no!
> 
> The OpenGL headers are system headers, and not headers from some
> arbitrary library.

Actually, they're all standard, copied from the reference GL 
implementation from opengl.org.  Since the binary interface is 
standard, the headers will always remain standard.  Its only when new 
features are added, and different versions of the headers are used by 
developers and users, that problems occur.

Anyway, it was just a fleeting idea.  I've had problems in the past 
with dodgy headers while compiling stuff, and have had to update or 
even modify my headers a number of times to make stuff work.



From email at asfandyar.cjb.net  Mon Oct 10 07:59:41 2005
From: email at asfandyar.cjb.net (Asfand Yar Qazi)
Date: Mon, 10 Oct 2005 12:59:41 +0100
Subject: [quake3] Header file errors
In-Reply-To: <434A044D.8050905@asfandyar.cjb.net>
References: <434A044D.8050905@asfandyar.cjb.net>
Message-ID: <434A57AD.2060603@asfandyar.cjb.net>

Asfand Yar Qazi wrote:
> Hello,
> 
> Got the following error (I'm using the nVidia headers from driver 6111, 
> I can't upgrade since later versions of the driver make X hang or crash.)
> 
> [asfand at big ~/src/games/quake3/icculus_quake3/quake3.build]
> $ make

<snip>

Here's the dilemma....

In the /usr/X11R6/include/X11/Xmd.h header that comes with XFree86 
4.3, some #defines and typedefs are defined that conflict with the 
ones in the jpeg library included in the quake 3 sources.  I'm 
thinking that the best way of doing this is to change their 
definitions as well all the places where they are used by prefixing 
them with JPEG_ or something.  Would that be acceptable?






From email at asfandyar.cjb.net  Mon Oct 10 08:40:38 2005
From: email at asfandyar.cjb.net (Asfand Yar Qazi)
Date: Mon, 10 Oct 2005 13:40:38 +0100
Subject: [quake3] Header file errors
In-Reply-To: <434A57AD.2060603@asfandyar.cjb.net>
References: <434A044D.8050905@asfandyar.cjb.net> <434A57AD.2060603@asfandyar.cjb.net>
Message-ID: <434A6146.30504@asfandyar.cjb.net>

Asfand Yar Qazi wrote:
> Asfand Yar Qazi wrote:
> 
>> Hello,
>>
>> Got the following error (I'm using the nVidia headers from driver 
>> 6111, I can't upgrade since later versions of the driver make X hang 
>> or crash.)
>>
>> [asfand at big ~/src/games/quake3/icculus_quake3/quake3.build]
>> $ make
> 
> 
> <snip>
> 
> Here's the dilemma....
> 
> In the /usr/X11R6/include/X11/Xmd.h header that comes with XFree86 4.3, 
> some #defines and typedefs are defined that conflict with the ones in 
> the jpeg library included in the quake 3 sources.  I'm thinking that the 
> best way of doing this is to change their definitions as well all the 
> places where they are used by prefixing them with JPEG_ or something.  
> Would that be acceptable?
> 

I went ahead and did it anyway, modifying the jpeg library files so 
now there is no clash between it and the XFree86 4.3 headers.

Also had to '#include <GL/glext.h>' in code/unix/sdl_glimp.c ...

Anyway, it worked for me.  Patch attached.  Perhaps when people are 
searching through the quake3 mailing list archives with a similar 
problem, they'll come across my little post, and it'll make them 
happy.  Signing off!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: quake3-patch-worked-for-me.diff.gz
Type: application/x-gzip
Size: 20832 bytes
Desc: not available
URL: <http://icculus.org/pipermail/quake3/attachments/20051010/b1c1c509/attachment.gz>

From issue at gmx.at  Mon Oct 10 09:34:48 2005
From: issue at gmx.at (IsSuE)
Date: Mon, 10 Oct 2005 15:34:48 +0200
Subject: Sound lag fix
Message-ID: <1128951288.8318.6.camel@localhost.localdomain>

hi everyone :)

as i am too stupid to use mailinglists ( first one i ever joined ) i
wanted to ask you if u could give me some hints how to solve the sound
lag issue. i compiled ioq3 1.33 which gave me sound in generall, but now
i got that damn sound lag. killed esd but didnt give me improvements.

thx in advance

yours IsSuE



From anthaus at tutopia.com  Mon Oct 10 13:20:37 2005
From: anthaus at tutopia.com (Carlos Alberto Lopez Romero)
Date: Mon, 10 Oct 2005 12:20:37 -0500
Subject: [quake3] Re: Sound lag fix
In-Reply-To: <1128951288.8318.6.camel@localhost.localdomain>
References: <1128951288.8318.6.camel@localhost.localdomain>
Message-ID: <434AA2E5.90408@tutopia.com>

IsSuE wrote:

>hi everyone :)
>
>as i am too stupid to use mailinglists ( first one i ever joined ) i
>wanted to ask you if u could give me some hints how to solve the sound
>lag issue. i compiled ioq3 1.33 which gave me sound in generall, but now
>i got that damn sound lag. killed esd but didnt give me improvements.
>
>thx in advance
>
>yours IsSuE
>
>
>  
>
'esd' doesn't cause sound lag in my system. But 'artsd' does (too bad I 
can't uninstall it since so many things depend on it).
Try killing artsd.
Aside from that, sounds like you have a windows sound card with no real 
hardware mixing (nforce). That's really an  issue with Alsa, so you 
might want to check their compatibility lists and buy a fully supported 
soundcard.
My 2 cents.
______________________________
Visita http://www.tutopia.com y comienza a navegar m?s r?pido en Internet. Tutopia es Internet para todos.


From issue at gmx.at  Mon Oct 10 12:21:48 2005
From: issue at gmx.at (IsSuE)
Date: Mon, 10 Oct 2005 18:21:48 +0200
Subject: [quake3] Re: Sound lag fix
In-Reply-To: <434AA2E5.90408@tutopia.com>
References: <1128951288.8318.6.camel@localhost.localdomain> <434AA2E5.90408@tutopia.com>
Message-ID: <434A951C.90406@gmx.at>

i got no task named artsd running oO
my sound card is an onboard soundcard on my abit ic7-g.
the strange thing is, that it worked some time ago....



Carlos Alberto Lopez Romero schrieb:

> IsSuE wrote:
>
>> hi everyone :)
>>
>> as i am too stupid to use mailinglists ( first one i ever joined ) i
>> wanted to ask you if u could give me some hints how to solve the sound
>> lag issue. i compiled ioq3 1.33 which gave me sound in generall, but now
>> i got that damn sound lag. killed esd but didnt give me improvements.
>>
>> thx in advance
>>
>> yours IsSuE
>>
>>
>>  
>>
> 'esd' doesn't cause sound lag in my system. But 'artsd' does (too bad 
> I can't uninstall it since so many things depend on it).
> Try killing artsd.
> Aside from that, sounds like you have a windows sound card with no 
> real hardware mixing (nforce). That's really an  issue with Alsa, so 
> you might want to check their compatibility lists and buy a fully 
> supported soundcard.
> My 2 cents.
> ______________________________
> Visita http://www.tutopia.com y comienza a navegar m?s r?pido en 
> Internet. Tutopia es Internet para todos.
>
>


From phatfil at optusnet.com.au  Mon Oct 10 18:46:47 2005
From: phatfil at optusnet.com.au (Philip Nelson)
Date: Tue, 11 Oct 2005 08:46:47 +1000 (EST)
Subject: [quake3] Re: Sound lag fix
In-Reply-To: <1128951288.8318.6.camel@localhost.localdomain>
References: <1128951288.8318.6.camel@localhost.localdomain>
Message-ID: <47865.203.192.146.151.1128984407.squirrel@home.whatsbeef.net>

IsSuE wrote:
> ... but now i got that damn sound lag. killed esd but didnt give me
> improvements.

I had this problem with all SDL related apps. I solved it by fixing my
~/.asoundrc with some decent dmix settings (I believe buffer_size is the
important thing here). Here's what my ~/.asoundrc looks like now:

pcm.dmixer {
        type dmix
        ipc_key 1024
        slave {
                pcm "hw:0,0"
                period_time 0
                period_size 1024
                buffer_size 8192
                rate 44100
        }
        bindings {
                0 0
                1 1
        }
}

pcm.dsp0 {
        type plug
        slave.pcm "dmixer"
}

pcm.!default {
        type plug
        slave.pcm "dmixer"
}

pcm.default {
        type plug
        slave.pcm "dmixer"
}

ctl.mixer0 {
        type hw
        card 0
}

Hope that helps,
Philip



From icculus at clutteredmind.org  Mon Oct 10 19:51:21 2005
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Mon, 10 Oct 2005 19:51:21 -0400
Subject: [quake3] Header file errors
In-Reply-To: <434A52C7.4030103@asfandyar.cjb.net>
References: <434A044D.8050905@asfandyar.cjb.net> <1128939800.1019.10.camel@klamath.syndrom23.de> <434A52C7.4030103@asfandyar.cjb.net>
Message-ID: <434AFE79.7060408@clutteredmind.org>


> Anyway, it was just a fleeting idea.  I've had problems in the past 
> with dodgy headers while compiling stuff, and have had to update or 
> even modify my headers a number of times to make stuff work.

Fwiw, I use the same GL headers, included in the project, on several
games (including the Unreal ones) and it works fine.

--ryan.



From issue at gmx.at  Tue Oct 11 09:15:04 2005
From: issue at gmx.at (IsSuE)
Date: Tue, 11 Oct 2005 15:15:04 +0200
Subject: [quake3] Re: Sound lag fix
In-Reply-To: <47865.203.192.146.151.1128984407.squirrel@home.whatsbeef.net>
References: <1128951288.8318.6.camel@localhost.localdomain>
	 <47865.203.192.146.151.1128984407.squirrel@home.whatsbeef.net>
Message-ID: <1129036504.7674.0.camel@localhost.localdomain>

m8 i am gonna love u forever, i decreased buffer size to 4 mb and it
works.

*hugs* *kisses*

:D

Am Dienstag, den 11.10.2005, 08:46 +1000 schrieb Philip Nelson:
> IsSuE wrote:
> > ... but now i got that damn sound lag. killed esd but didnt give me
> > improvements.
> 
> I had this problem with all SDL related apps. I solved it by fixing my
> ~/.asoundrc with some decent dmix settings (I believe buffer_size is the
> important thing here). Here's what my ~/.asoundrc looks like now:
> 
> pcm.dmixer {
>         type dmix
>         ipc_key 1024
>         slave {
>                 pcm "hw:0,0"
>                 period_time 0
>                 period_size 1024
>                 buffer_size 8192
>                 rate 44100
>         }
>         bindings {
>                 0 0
>                 1 1
>         }
> }
> 
> pcm.dsp0 {
>         type plug
>         slave.pcm "dmixer"
> }
> 
> pcm.!default {
>         type plug
>         slave.pcm "dmixer"
> }
> 
> pcm.default {
>         type plug
>         slave.pcm "dmixer"
> }
> 
> ctl.mixer0 {
>         type hw
>         card 0
> }
> 
> Hope that helps,
> Philip
> 



From kristleifur04 at ru.is  Tue Oct 11 09:23:35 2005
From: kristleifur04 at ru.is (=?ISO-8859-1?Q?Kristleifur_Da=F0ason?=)
Date: Tue, 11 Oct 2005 13:23:35 +0000
Subject: [quake3] Re: Sound lag fix
In-Reply-To: <1129036504.7674.0.camel@localhost.localdomain>
References: <1128951288.8318.6.camel@localhost.localdomain> <47865.203.192.146.151.1128984407.squirrel@home.whatsbeef.net> <1129036504.7674.0.camel@localhost.localdomain>
Message-ID: <068CE5EC-B2D2-45CA-A42A-BA5F78A96EE6@ru.is>

Lurk mode disabled.

Actually, you decreased the buffer size down to 4096 *samples*. At  
44100 samples per second, that translates to ~0.09 seconds of audio,  
and hence ~0.09 seconds of audio lag (latency). (I don't know what  
period size does in ALSA, but I suspect it might affect audio lag as  
well.)

Back to lurking. It's been great following this mailing list, and  
it's served to increase my courage in tackling the Q3 sources when I  
have time.

-- Kristleifur

On 11.10.2005, at 13:15, IsSuE wrote:

> m8 i am gonna love u forever, i decreased buffer size to 4 mb and it
> works.
>
>> IsSuE wrote:
>>
>> pcm.dmixer {
>>         type dmix
>>         ipc_key 1024
>>         slave {
>>                 pcm "hw:0,0"
>>                 period_time 0
>>                 period_size 1024
>>                 buffer_size 8192
>>                 rate 44100
>>         }
>>         bindings {
>>                 0 0
>>                 1 1
>>         }
>> }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://icculus.org/pipermail/quake3/attachments/20051011/ec13e713/attachment.htm>

From email at asfandyar.cjb.net  Wed Oct 12 02:44:04 2005
From: email at asfandyar.cjb.net (Asfand Yar Qazi)
Date: Wed, 12 Oct 2005 07:44:04 +0100
Subject: [quake3] Header file errors
In-Reply-To: <434AFE79.7060408@clutteredmind.org>
References: <434A044D.8050905@asfandyar.cjb.net> <1128939800.1019.10.camel@klamath.syndrom23.de> <434A52C7.4030103@asfandyar.cjb.net> <434AFE79.7060408@clutteredmind.org>
Message-ID: <434CB0B4.2080903@asfandyar.cjb.net>

Ryan C. Gordon wrote:
>>Anyway, it was just a fleeting idea.  I've had problems in the past 
>>with dodgy headers while compiling stuff, and have had to update or 
>>even modify my headers a number of times to make stuff work.
> 
> 
> Fwiw, I use the same GL headers, included in the project, on several
> games (including the Unreal ones) and it works fine.
> 

As I said, I'm using old headers (XFree86 4.3 vanilla - NOT debian's 
modified ones.)  I'm sure there must be some people around using old 
banged up rubbish like me.

Since you're here, could I ask you why I had to #include <GL/glext.h> 
in code/unix/sdl_glimp.c and code/unix/linux_glimp.c to make it 
compile?  It complained about PFNGLMULTITEXCOORD2FARBPROC, 
PFNGLACTIVETEXTUREARBPROC and PFNGLCLIENTACTIVETEXTUREARBPROC being 
undefined.  I'm just wondering since compiling several other projects 
has given me these sorts of errors.



From icculus at clutteredmind.org  Wed Oct 12 04:00:27 2005
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Wed, 12 Oct 2005 04:00:27 -0400
Subject: [quake3] Header file errors
In-Reply-To: <434CB0B4.2080903@asfandyar.cjb.net>
References: <434A044D.8050905@asfandyar.cjb.net> <1128939800.1019.10.camel@klamath.syndrom23.de> <434A52C7.4030103@asfandyar.cjb.net> <434AFE79.7060408@clutteredmind.org> <434CB0B4.2080903@asfandyar.cjb.net>
Message-ID: <434CC29B.7050109@clutteredmind.org>


> Since you're here, could I ask you why I had to #include <GL/glext.h> 
> in code/unix/sdl_glimp.c and code/unix/linux_glimp.c to make it 
> compile?  It complained about PFNGLMULTITEXCOORD2FARBPROC, 
> PFNGLACTIVETEXTUREARBPROC and PFNGLCLIENTACTIVETEXTUREARBPROC being 
> undefined.  I'm just wondering since compiling several other projects 
> has given me these sorts of errors.

Because you're using older GL headers, and the people on this mailing
list think that your distro should take better care of you on their behalf.

--ryan.



From icesik at mail.ru  Tue Oct 11 19:17:43 2005
From: icesik at mail.ru (Igor Zubkov)
Date: Wed, 12 Oct 2005 02:17:43 +0300
Subject: [quake3] Re: Sound lag fix
In-Reply-To: <434A951C.90406@gmx.at>
References: <1128951288.8318.6.camel@localhost.localdomain> <434AA2E5.90408@tutopia.com> <434A951C.90406@gmx.at>
Message-ID: <200510120217.48556.icesik@mail.ru>

> i got no task named artsd running oO
> my sound card is an onboard soundcard on my abit ic7-g.
> the strange thing is, that it worked some time ago....

Try build quake3 without SDL support. I did this and sound lag is go away.

-- 
Now playing: Oomph! [Unrein] [] Zero Endorphine


From email at asfandyar.cjb.net  Wed Oct 12 08:19:12 2005
From: email at asfandyar.cjb.net (Asfand Yar Qazi)
Date: Wed, 12 Oct 2005 13:19:12 +0100
Subject: [quake3] Header file errors
In-Reply-To: <434CC29B.7050109@clutteredmind.org>
References: <434A044D.8050905@asfandyar.cjb.net> <1128939800.1019.10.camel@klamath.syndrom23.de> <434A52C7.4030103@asfandyar.cjb.net> <434AFE79.7060408@clutteredmind.org> <434CB0B4.2080903@asfandyar.cjb.net> <434CC29B.7050109@clutteredmind.org>
Message-ID: <434CFF40.7000400@asfandyar.cjb.net>

Ryan C. Gordon wrote:
>>Since you're here, could I ask you why I had to #include <GL/glext.h> 
>>in code/unix/sdl_glimp.c and code/unix/linux_glimp.c to make it 
>>compile?  It complained about PFNGLMULTITEXCOORD2FARBPROC, 
>>PFNGLACTIVETEXTUREARBPROC and PFNGLCLIENTACTIVETEXTUREARBPROC being 
>>undefined.  I'm just wondering since compiling several other projects 
>>has given me these sorts of errors.
> 
> 
> Because you're using older GL headers, and the people on this mailing
> list think that your distro should take better care of you on their behalf.
> 

That's all I wanted to know.  Since I compiled my own distro from 
scratch, I'll go spank myself now.



From issue at gmx.at  Wed Oct 12 12:31:46 2005
From: issue at gmx.at (IsSuE)
Date: Wed, 12 Oct 2005 18:31:46 +0200
Subject: [quake3] Re: Sound lag fix
In-Reply-To: <200510120217.48556.icesik@mail.ru>
References: <1128951288.8318.6.camel@localhost.localdomain> <434AA2E5.90408@tutopia.com> <434A951C.90406@gmx.at> <200510120217.48556.icesik@mail.ru>
Message-ID: <434D3A72.6080606@gmx.at>

how to build it w/o sdl support?

Igor Zubkov schrieb:

>>i got no task named artsd running oO
>>my sound card is an onboard soundcard on my abit ic7-g.
>>the strange thing is, that it worked some time ago....
>>    
>>
>
>Try build quake3 without SDL support. I did this and sound lag is go away.
>
>  
>


From bootc at bootc.net  Thu Oct 13 08:36:44 2005
From: bootc at bootc.net (Chris Boot)
Date: Thu, 13 Oct 2005 13:36:44 +0100
Subject: [BUG# 2420] [PATCH] Enable use of all buttons on 10 button mice
Message-ID: <434E54DC.4060202@bootc.net>

Hi all,

I've just posted a bug on bugzilla to add a few extra mouse buttons to 
quake3, so all of us who have mice with a stupid number of buttons can 
use them all!

HTH,
Chris

-- 
Chris Boot
bootc at bootc.net
http://www.bootc.net/



From ludwig.nussel at suse.de  Sun Oct 23 11:59:14 2005
From: ludwig.nussel at suse.de (Ludwig Nussel)
Date: Sun, 23 Oct 2005 17:59:14 +0200
Subject: [quake3-commits] r160 - in trunk/code: client unix
In-Reply-To: <20051014225829.10258.qmail@icculus.org>
References: <20051014225829.10258.qmail@icculus.org>
Message-ID: <200510231759.14189.ludwig.nussel@suse.de>

DONOTREPLY at icculus.org wrote:
> Author: tma
> Date: 2005-10-14 18:58:28 -0400 (Fri, 14 Oct 2005)
> New Revision: 160
>
> Modified:
>    trunk/code/client/cl_input.c
>    trunk/code/client/cl_main.c
>    trunk/code/client/client.h
>    trunk/code/unix/linux_glimp.c
>    trunk/code/unix/sdl_glimp.c
> Log:
> * Removed hard coded mouse acceleration in the unix build(s)
> * Added CVAR_ROM cl_platformSensitivity to normalise the scale
>   of cl_sensitivity across platforms

Unfortunately with this change one cannot simply switch between
1.32b and ioQ3 anymore because sensitivity is always wrong in one of
them. Does the hard coded accel actually matter?

cu
Ludwig

-- 
 (o_   Ludwig Nussel
 //\   SUSE LINUX Products GmbH, Development
 V_/_  http://www.suse.de/



From tim at ngus.net  Sun Oct 23 12:14:40 2005
From: tim at ngus.net (Tim Angus)
Date: Sun, 23 Oct 2005 17:14:40 +0100
Subject: r160 - in trunk/code: client unix
In-Reply-To: <200510231759.14189.ludwig.nussel@suse.de>
References: <200510231759.14189.ludwig.nussel@suse.de>
Message-ID: <20051023171440.2a0cf5a8.tim@ngus.net>

On Sun, 23 Oct 2005 17:59:14 +0200 Ludwig wrote:
> Unfortunately with this change one cannot simply switch between
> 1.32b and ioQ3 anymore because sensitivity is always wrong in one of
> them.

They will be approximately similar, I think you are rather exaggerating
the issue.

> Does the hard coded accel actually matter?

Yes. With it in place it is impossible to have relative mouse movements
of 2 or 3 pixels -- this is clearly wrong. My theory is that the hard
coded acceleration was never intended as acceleration but as a means to
normalise the sensitivity on the *nix build without disturbing any
common code.


From scott at scottbrooks.ca  Sun Oct 23 23:20:47 2005
From: scott at scottbrooks.ca (Scott Brooks)
Date: Sun, 23 Oct 2005 21:20:47 -0600
Subject: [quake3] Re: r160 - in trunk/code: client unix
In-Reply-To: <20051023171440.2a0cf5a8.tim@ngus.net>
References: <200510231759.14189.ludwig.nussel@suse.de> <20051023171440.2a0cf5a8.tim@ngus.net>
Message-ID: <36643A74-8EC6-4CA7-BB15-593963DC0011@scottbrooks.ca>

On 23-Oct-05, at 10:14 AM, Tim Angus wrote:

> On Sun, 23 Oct 2005 17:59:14 +0200 Ludwig wrote:
>
>> Unfortunately with this change one cannot simply switch between
>> 1.32b and ioQ3 anymore because sensitivity is always wrong in one of
>> them.
>>
>
> They will be approximately similar, I think you are rather  
> exaggerating
> the issue.
>
>
>> Does the hard coded accel actually matter?
>>
>
> Yes. With it in place it is impossible to have relative mouse  
> movements
> of 2 or 3 pixels -- this is clearly wrong. My theory is that the hard
> coded acceleration was never intended as acceleration but as a  
> means to
> normalise the sensitivity on the *nix build without disturbing any
> common code.
>

Would a simple solution be to add another config that io-q3 execs on  
startup similar to autoexec.cfg.

That way when i.o-q3 starts it will run the autoexec.cfg, and then  
run io-q3.cfg.  Regular q3 will ignore io-q3.cfg.



From tim at ngus.net  Mon Oct 24 10:19:52 2005
From: tim at ngus.net (Tim Angus)
Date: Mon, 24 Oct 2005 15:19:52 +0100
Subject: r160 - in trunk/code: client unix
In-Reply-To: <36643A74-8EC6-4CA7-BB15-593963DC0011@scottbrooks.ca>
References: <200510231759.14189.ludwig.nussel@suse.de>
	<20051023171440.2a0cf5a8.tim@ngus.net>
	<36643A74-8EC6-4CA7-BB15-593963DC0011@scottbrooks.ca>
Message-ID: <20051024151952.1d1c9cde.tim@ngus.net>

On Sun, 23 Oct 2005 21:20:47 -0600 Scott wrote:
> Would a simple solution be to add another config that io-q3 execs on  
> startup similar to autoexec.cfg.
> 
> That way when i.o-q3 starts it will run the autoexec.cfg, and then  
> run io-q3.cfg.  Regular q3 will ignore io-q3.cfg.

That wouldn't really fix anything, since the sensitivity values are
equivalent as it stands. The only difference is that ioq3 doesn't have
the hardcoded acceleration on *nix (I should point out: like the other
platforms) whereas 1.32b does, which at very slow mouse speeds will be
less sensitive for the same sensitivity value.

If people really care I could add "in_useOldBrokenInput" or some such,
but so far there have been many more complaints (in the IRC channel)
about the acceleration being present than it being removed.


From paszczus at gmail.com  Tue Oct 25 07:12:32 2005
From: paszczus at gmail.com (PaSzCzUs)
Date: Tue, 25 Oct 2005 13:12:32 +0200
Subject: Running q3ded on PPC
In-Reply-To: <daa0fb1e0510250410q1107a669s@mail.gmail.com>
References: <daa0fb1e0510250410q1107a669s@mail.gmail.com>
Message-ID: <daa0fb1e0510250412k42bc6579p@mail.gmail.com>

Hi.
I`ve created spec file for PLD Linux Distribution and it`s almost
done, almost because while running q3 dedicated server i have problem
like this:

8146 files in pk3 files
Loading dll file qagame.
Sys_LoadDll(/var/games/quake3/baseq3/qagameppc.so)...
Sys_LoadDll(/var/games/quake3/baseq3/qagameppc.so) failed:
"/var/games/quake3/baseq3/qagameppc.so: cannot open shared object
file: No such file or directory"
Sys_LoadDll(/var/games/quake3/.q3a/baseq3/qagameppc.so)...
Sys_LoadDll(/var/games/quake3/.q3a/baseq3/qagameppc.so) failed:
"/var/games/quake3/.q3a/baseq3/qagameppc.so: cannot open shared object
file: No such file or directory"
Sys_LoadDll(/usr/share/games/quake3/baseq3/qagameppc.so)...
Sys_LoadDll(/usr/share/games/quake3/baseq3/qagameppc.so) failed:
"/usr/share/games/quake3/baseq3/qagameppc.so: cannot open shared
object file: No such file or directory"
Sys_LoadDll(./baseq3/qagameppc.so)...
Sys_LoadDll(./baseq3/qagameppc.so) failed:
"./baseq3/qagameppc.so: cannot open shared object file: No such file
or directory"
Sys_LoadDll(qagame) failed dlopen() completely!
Failed to load dll, looking for qvm.
Loading vm file vm/qagame.qvm...
Architecture doesn't have a bytecode compiler, using interpreter
Received signal 11, exiting...
Shutdown tty console

Spec file could be viewed at: http://cvs.pld-linux.org/SPECS/quake3.spec

Please help!


From tim at ngus.net  Wed Oct 26 13:10:45 2005
From: tim at ngus.net (Tim Angus)
Date: Wed, 26 Oct 2005 18:10:45 +0100
Subject: Running q3ded on PPC
In-Reply-To: <daa0fb1e0510250412k42bc6579p@mail.gmail.com>
References: <daa0fb1e0510250412k42bc6579p@mail.gmail.com>
Message-ID: <20051026181045.48797eb6.tim@ngus.net>

On Tue, 25 Oct 2005 13:12:32 +0200 PaSzCzUs wrote:
> Failed to load dll, looking for qvm.
> Loading vm file vm/qagame.qvm...
> Architecture doesn't have a bytecode compiler, using interpreter
> Received signal 11, exiting...
> Shutdown tty console
> 
> Spec file could be viewed at:
> http://cvs.pld-linux.org/SPECS/quake3.spec
> 
> Please help!

Please try revision 179.


From paszczus at gmail.com  Thu Oct 27 17:04:18 2005
From: paszczus at gmail.com (PaSzCzUs)
Date: Thu, 27 Oct 2005 23:04:18 +0200
Subject: Running q3ded on PPC
Message-ID: <daa0fb1e0510271404o66eee000y@mail.gmail.com>

Hi.
I tried rev 187 and still i cannot run q3ded server on PPC, now the
error is (full):

[quake3 at mydomain.pl ~]$ q3ded +map q3dm17
ioQ3 1.33 linux-ppc Oct 27 2005
----- FS_Startup -----
Current search path:
/var/games/quake3/.q3a/baseq3
/usr/share/games/quake3/baseq3/pak8.pk3 (9 files)
/usr/share/games/quake3/baseq3/pak7.pk3 (4 files)
/usr/share/games/quake3/baseq3/pak6.pk3 (64 files)
/usr/share/games/quake3/baseq3/pak5.pk3 (7 files)
/usr/share/games/quake3/baseq3/pak4.pk3 (272 files)
/usr/share/games/quake3/baseq3/pak3.pk3 (4 files)
/usr/share/games/quake3/baseq3/pak2.pk3 (148 files)
/usr/share/games/quake3/baseq3/pak1.pk3 (26 files)
/usr/share/games/quake3/baseq3/pak0.pk3 (3539 files)
/usr/share/games/quake3/baseq3
./baseq3

----------------------
4073 files in pk3 files
execing default.cfg
couldn't exec q3config.cfg
couldn't exec autoexec.cfg
Hunk_Clear: reset the hunk ok
--- Common Initialization Complete ---
Opening IP socket: localhost:27960
Hostname: gzowski.opole.pl
IP: 217.197.64.134
Started tty console (use +set ttycon 0 to disable)
------ Server Initialization ------
Server: q3dm17
Hunk_Clear: reset the hunk ok
----- FS_Startup -----
Current search path:
/var/games/quake3/.q3a/baseq3
/usr/share/games/quake3/baseq3/pak8.pk3 (9 files)
/usr/share/games/quake3/baseq3/pak7.pk3 (4 files)
/usr/share/games/quake3/baseq3/pak6.pk3 (64 files)
/usr/share/games/quake3/baseq3/pak5.pk3 (7 files)
/usr/share/games/quake3/baseq3/pak4.pk3 (272 files)
/usr/share/games/quake3/baseq3/pak3.pk3 (4 files)
/usr/share/games/quake3/baseq3/pak2.pk3 (148 files)
/usr/share/games/quake3/baseq3/pak1.pk3 (26 files)
/usr/share/games/quake3/baseq3/pak0.pk3 (3539 files)
/usr/share/games/quake3/baseq3
./baseq3

----------------------
8146 files in pk3 files
Loading vm file vm/qagame.qvm...
Architecture doesn't have a bytecode compiler, using interpreter
Received signal 11, exiting...
Shutdown tty console

It`s after rm -rf .q3a/  (that`s why no *.cfg files)


From tim at ngus.net  Thu Oct 27 17:13:46 2005
From: tim at ngus.net (Tim Angus)
Date: Thu, 27 Oct 2005 22:13:46 +0100
Subject: Running q3ded on PPC
In-Reply-To: <daa0fb1e0510271404o66eee000y@mail.gmail.com>
References: <daa0fb1e0510271404o66eee000y@mail.gmail.com>
Message-ID: <20051027221346.02796f81.tim@ngus.net>

On Thu, 27 Oct 2005 23:04:18 +0200 PaSzCzUs wrote:
> Hi.
> I tried rev 187 and still i cannot run q3ded server on PPC, now the
> error is (full):
> 
> [quake3 at mydomain.pl ~]$ q3ded +map q3dm17

Do this:

$ gdb ./q3ded
..wait for gdb to start
(gdb) r +map q3dm17
..wait for q3 to crash
(gdb) bt
..copy and paste the output into a reply to this email.


From tim at ngus.net  Thu Oct 27 18:47:22 2005
From: tim at ngus.net (Tim Angus)
Date: Thu, 27 Oct 2005 23:47:22 +0100
Subject: r191 - trunk/code/qcommon
In-Reply-To: <20051027223825.21204.qmail@icculus.org>
References: <20051027223825.21204.qmail@icculus.org>
Message-ID: <20051027234722.2f183142.tim@ngus.net>

On 27 Oct 2005 18:38:25 -0400 DONOTREPLY at icculus.org wrote:
> Author: tma
> Date: 2005-10-27 18:38:25 -0400 (Thu, 27 Oct 2005)
> New Revision: 191
> 
> Modified:
>    trunk/code/qcommon/vm.c
> Log:
> * Fix the x86 vm
> 
> 
> Modified: trunk/code/qcommon/vm.c
> ===================================================================
> --- trunk/code/qcommon/vm.c	2005-10-27 22:05:38 UTC (rev 190)
> +++ trunk/code/qcommon/vm.c	2005-10-27 22:38:25 UTC (rev 191)
> @@ -749,10 +749,10 @@
>  #ifdef __i386__ // i386 calling convention doesn't need conversion
>  #if defined(HAVE_VM_COMPILED)
>  		if ( vm->compiled )
> -			r = VM_CallCompiled( vm, (int*)callnum );
> +			r = VM_CallCompiled( vm, (int*)&callnum );
>  		else
>  #endif
> -			r = VM_CallInterpreted( vm, (int*)callnum );
> +			r = VM_CallInterpreted( vm, (int*)&callnum );
>  #else
>  		struct {
>  			int callnum;

Perhaps we should just use the platform independant calling convention
on x86 too? I can't imagine it being that expensive in practical terms.


From paszczus at gmail.com  Fri Oct 28 04:35:06 2005
From: paszczus at gmail.com (PaSzCzUs)
Date: Fri, 28 Oct 2005 10:35:06 +0200
Subject: [quake3] Re: Running q3ded on PPC
In-Reply-To: <20051027221346.02796f81.tim@ngus.net>
References: <daa0fb1e0510271404o66eee000y@mail.gmail.com>
	 <20051027221346.02796f81.tim@ngus.net>
Message-ID: <daa0fb1e0510280135k15c4f4f1w@mail.gmail.com>

[quake3 at foo.pl ~]$ gdb q3ded
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host= --target=ppc-pld-linux"...(no
debugging symbols found)
Using host libthread_db library "/lib/libthread_db.so.1".

(gdb) r +map q3dm17
Starting program: /usr/bin/q3ded +map q3dm17
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
ioQ3 1.33 linux-ppc Oct 28 2005
----- FS_Startup -----
Current search path:
/var/games/quake3/.q3a/baseq3
/usr/share/games/quake3/baseq3/pak8.pk3 (9 files)
/usr/share/games/quake3/baseq3/pak7.pk3 (4 files)
/usr/share/games/quake3/baseq3/pak6.pk3 (64 files)
/usr/share/games/quake3/baseq3/pak5.pk3 (7 files)
/usr/share/games/quake3/baseq3/pak4.pk3 (272 files)
/usr/share/games/quake3/baseq3/pak3.pk3 (4 files)
/usr/share/games/quake3/baseq3/pak2.pk3 (148 files)
/usr/share/games/quake3/baseq3/pak1.pk3 (26 files)
/usr/share/games/quake3/baseq3/pak0.pk3 (3539 files)
/usr/share/games/quake3/baseq3
/usr/bin/baseq3

----------------------
4073 files in pk3 files
execing default.cfg
couldn't exec q3config.cfg
couldn't exec autoexec.cfg
Hunk_Clear: reset the hunk ok
(no debugging symbols found)
--- Common Initialization Complete ---
Opening IP socket: localhost:27960
(no debugging symbols found)
(no debugging symbols found)
Hostname: gzowski.opole.pl
IP: 217.197.64.134
Started tty console (use +set ttycon 0 to disable)
------ Server Initialization ------
Server: q3dm17
Hunk_Clear: reset the hunk ok
----- FS_Startup -----
Current search path:
/var/games/quake3/.q3a/baseq3
/usr/share/games/quake3/baseq3/pak8.pk3 (9 files)
/usr/share/games/quake3/baseq3/pak7.pk3 (4 files)
/usr/share/games/quake3/baseq3/pak6.pk3 (64 files)
/usr/share/games/quake3/baseq3/pak5.pk3 (7 files)
/usr/share/games/quake3/baseq3/pak4.pk3 (272 files)
/usr/share/games/quake3/baseq3/pak3.pk3 (4 files)
/usr/share/games/quake3/baseq3/pak2.pk3 (148 files)
/usr/share/games/quake3/baseq3/pak1.pk3 (26 files)
/usr/share/games/quake3/baseq3/pak0.pk3 (3539 files)
/usr/share/games/quake3/baseq3
/usr/bin/baseq3

----------------------
8146 files in pk3 files
Loading vm file vm/qagame.qvm...
Architecture doesn't have a bytecode compiler, using interpreter

Program received signal SIGSEGV, Segmentation fault.
0x1003c0e4 in ?? ()
(gdb) bt
#0  0x1003c0e4 in ?? ()
#1  0x1003bfec in ?? ()
Previous frame identical to this frame (corrupt stack?)

That`s all i`ve got - is it enought or should i do something else?



2005/10/27, Tim Angus <tim at ngus.net>:
> On Thu, 27 Oct 2005 23:04:18 +0200 PaSzCzUs wrote:
> > Hi.
> > I tried rev 187 and still i cannot run q3ded server on PPC, now the
> > error is (full):
> >
> > [quake3 at mydomain.pl ~]$ q3ded +map q3dm17
>
> Do this:
>
> $ gdb ./q3ded
> ..wait for gdb to start
> (gdb) r +map q3dm17
> ..wait for q3 to crash
> (gdb) bt
> ..copy and paste the output into a reply to this email.
>


From ludwig.nussel at suse.de  Fri Oct 28 08:32:06 2005
From: ludwig.nussel at suse.de (Ludwig Nussel)
Date: Fri, 28 Oct 2005 14:32:06 +0200
Subject: [quake3] r191 - trunk/code/qcommon
In-Reply-To: <20051027234722.2f183142.tim@ngus.net>
References: <20051027223825.21204.qmail@icculus.org> <20051027234722.2f183142.tim@ngus.net>
Message-ID: <20051028123205.GA16822@suse.de>

Tim Angus wrote:
> On 27 Oct 2005 18:38:25 -0400 DONOTREPLY at icculus.org wrote:
> > Author: tma
> > Date: 2005-10-27 18:38:25 -0400 (Thu, 27 Oct 2005)
> > New Revision: 191
> > 
> > Modified:
> >    trunk/code/qcommon/vm.c
> > Log:
> > * Fix the x86 vm

I'm sorry for causing breakage like this yesterday. I was just too
excited that I finally found the bug that caused vm_x86_64 to crash.

> > 
> > Modified: trunk/code/qcommon/vm.c
> > ===================================================================
> > --- trunk/code/qcommon/vm.c	2005-10-27 22:05:38 UTC (rev 190)
> > +++ trunk/code/qcommon/vm.c	2005-10-27 22:38:25 UTC (rev 191)
> > @@ -749,10 +749,10 @@
> >  #ifdef __i386__ // i386 calling convention doesn't need conversion
> >  #if defined(HAVE_VM_COMPILED)
> >  		if ( vm->compiled )
> > -			r = VM_CallCompiled( vm, (int*)callnum );
> > +			r = VM_CallCompiled( vm, (int*)&callnum );
> >  		else
> >  #endif
> > -			r = VM_CallInterpreted( vm, (int*)callnum );
> > +			r = VM_CallInterpreted( vm, (int*)&callnum );
> >  #else
> >  		struct {
> >  			int callnum;
> 
> Perhaps we should just use the platform independant calling convention
> on x86 too? I can't imagine it being that expensive in practical terms.

For better readability VM_CallCompiled and VM_CallInterpreted could
be made variadic just like VM_Call. If extra handling is needed it's
hidden behind the va_* macros then.

cu
Ludwig

-- 
 (o_   Ludwig Nussel
 //\   SUSE LINUX Products GmbH, Development
 V_/_  http://www.suse.de/


From tim at ngus.net  Fri Oct 28 09:11:02 2005
From: tim at ngus.net (Tim Angus)
Date: Fri, 28 Oct 2005 14:11:02 +0100
Subject: Running q3ded on PPC
In-Reply-To: <daa0fb1e0510280135k15c4f4f1w@mail.gmail.com>
References: <daa0fb1e0510271404o66eee000y@mail.gmail.com>
	<20051027221346.02796f81.tim@ngus.net>
	<daa0fb1e0510280135k15c4f4f1w@mail.gmail.com>
Message-ID: <20051028141102.037127d4.tim@ngus.net>

On Fri, 28 Oct 2005 10:35:06 +0200 PaSzCzUs wrote: 
> Program received signal SIGSEGV, Segmentation fault.
> 0x1003c0e4 in ?? ()
> (gdb) bt
> #0  0x1003c0e4 in ?? ()
> #1  0x1003bfec in ?? ()
> Previous frame identical to this frame (corrupt stack?)
> 
> That`s all i`ve got - is it enought or should i do something else?

Complile a debug version (make debug) and do the same thing again.


From andreas at syndrom23.de  Fri Oct 28 09:13:07 2005
From: andreas at syndrom23.de (Andreas Kohn)
Date: Fri, 28 Oct 2005 15:13:07 +0200
Subject: [quake3] Re: Running q3ded on PPC
In-Reply-To: <daa0fb1e0510280135k15c4f4f1w@mail.gmail.com>
References: <daa0fb1e0510271404o66eee000y@mail.gmail.com>
	 <20051027221346.02796f81.tim@ngus.net>
	 <daa0fb1e0510280135k15c4f4f1w@mail.gmail.com>
Message-ID: <1130505187.11098.3.camel@klamath.syndrom23.de>

On Fri, 2005-10-28 at 10:35 +0200, PaSzCzUs wrote:
> [quake3 at foo.pl ~]$ gdb q3ded

[ snip debugging session of release binary ]

> Program received signal SIGSEGV, Segmentation fault.
> 0x1003c0e4 in ?? ()
> (gdb) bt
> #0  0x1003c0e4 in ?? ()
> #1  0x1003bfec in ?? ()
> Previous frame identical to this frame (corrupt stack?)
> 
> That`s all i`ve got - is it enought or should i do something else?

Yes. Please use the debug! version when trying to debug it.
That means: 
[...code/unix]$ gmake debug
[...code/unix]$ cd debugppc (should be named something like this)
[...code/unix/debugppc]$ gdb ./ppcq3d (again, name could be slightly
different)

You may have to put you .pk3 into debugppc/baseq3 directory, softlinking
them should suffice.

Then repeat the debug instructions please, and post the output.

Thanks,
Andreas

-- 
<TalisA> was macht man eigentlich auf einer linux-gamer lan ? hl server
aufsetzen und freuen ? *duck* ^^
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
URL: <http://icculus.org/pipermail/quake3/attachments/20051028/8c654311/attachment.pgp>

From vincent at cojot.name  Fri Oct 28 09:15:08 2005
From: vincent at cojot.name (vincent at cojot.name)
Date: Fri, 28 Oct 2005 15:15:08 +0200 (CEST)
Subject: Questions about compile options (ioq3 on Solaris).
In-Reply-To: <20051028141102.037127d4.tim@ngus.net>
References: <daa0fb1e0510271404o66eee000y@mail.gmail.com>
 <20051027221346.02796f81.tim@ngus.net> <daa0fb1e0510280135k15c4f4f1w@mail.gmail.com>
 <20051028141102.037127d4.tim@ngus.net>
Message-ID: <Pine.LNX.4.63.0510281511540.5762@thorbardin.lasthome.solace.krynn>

On Fri, 28 Oct 2005, Tim Angus wrote:

Guys,

I'm working on making a Solaris port of ioq3 and I have many questions...

Is there some kind of documentation on the use of:
-DHAVE_VM_NATIVE
-DHAVE_VM_COMPILED
-DDLL_ONLY

I have never produced a q3 mod so that may be why I don't know this stuff 
but that would help me if someone would tell me what are these things and 
especially what combination would be recommended when porting to a new 
platform and retaining decent functionnality...

,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,
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  Fri Oct 28 10:06:00 2005
From: vincent at cojot.name (vincent at cojot.name)
Date: Fri, 28 Oct 2005 16:06:00 +0200 (CEST)
Subject: GL_ARB_multitexture on Solaris/Sparc OpenGL
Message-ID: <Pine.LNX.4.63.0510281556520.5762@thorbardin.lasthome.solace.krynn>


Just something I stumbled on:

In quake3 (linux_glimp.c), there is:
     if ( r_ext_multitexture->value )
     {
       qglMultiTexCoord2fARB = ( PFNGLMULTITEXCOORD2FARBPROC ) dlsym( glw_state.OpenGLLib, "glMultiTexCoord2fARB" );
       qglActiveTextureARB = ( PFNGLACTIVETEXTUREARBPROC ) dlsym( glw_state.OpenGLLib, "glActiveTextureARB" );
       qglClientActiveTextureARB = ( PFNGLCLIENTACTIVETEXTUREARBPROC ) dlsym( glw_state.OpenGLLib, "glClientActiveTextureARB" );

This currently doesn't compile on Solaris since OpenGL on Solaris doesn't 
have PFNGLMULTITEXCOORD2FARBPROC, PFNGLACTIVETEXTUREARBPROC and 
PFNGLCLIENTACTIVETEXTUREARBPROC.

In Quake2 we made it work/compile this way:

                 if ( gl_ext_multitexture->value )
                 {
                         ri.Con_Printf( PRINT_ALL, "...using GL_ARB_multitexture\n" );
                         qglMTexCoord2fSGIS = ( void * ) qwglGetProcAddress( "glMultiTexCoord2fARB" );
                         qglActiveTextureARB = ( void * ) qwglGetProcAddress( "glActiveTextureARB" );
                         qglClientActiveTextureARB = ( void * ) qwglGetProcAddress( "glClientActiveTextureARB" );

I don't think it would be a good idea to 'lose' information by replacing 
'(PFNGLMULTITEXCOORD2FARBPROC)' stuff with '(void *)' in order to make 
this compile on Solaris but what would you recommend that I choose?

1) "#ifdef __sun" some stuff in linux_glimp.c
2) #define PFNGLMULTITEXCOORD2FARBPROC et al for Solaris in qgl.h (ugly).
3) Create a solaris_glimp.c and work from there...

(Note: ioq2 already has some solaris-specific routines so I don't mind 
creating a solaris_glimp.c)

Thanks for reading,

-- 
,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,
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 tim at ngus.net  Fri Oct 28 10:31:34 2005
From: tim at ngus.net (Tim Angus)
Date: Fri, 28 Oct 2005 15:31:34 +0100
Subject: Questions about compile options (ioq3 on Solaris).
In-Reply-To: <Pine.LNX.4.63.0510281511540.5762@thorbardin.lasthome.solace.krynn>
References: <Pine.LNX.4.63.0510281511540.5762@thorbardin.lasthome.solace.krynn>
Message-ID: <20051028153134.2eb515af.tim@ngus.net>

On Fri, 28 Oct 2005 15:15:08 +0200 (CEST) vincent at cojot.name wrote:
> I'm working on making a Solaris port of ioq3 and I have many
> questions...

I think ankon was/is working on a Solaris port. I'm not sure what stage
he got to, but perhaps you two should talk and avoid duplication of
effort :).

> Is there some kind of documentation on the use of:
> -DHAVE_VM_NATIVE
> -DHAVE_VM_COMPILED
> -DDLL_ONLY
> 
> I have never produced a q3 mod so that may be why I don't know this
> stuff  but that would help me if someone would tell me what are these
> things and  especially what combination would be recommended when
> porting to a new  platform and retaining decent functionnality...

Q3 mods have three distinct modes of execution. They can be compiled to
native shared libs (i.e. .so/.dll) ala Q2 or to platform independant
bytecode. The libs can only be executed one way, obviously. The bytecode
can be interpreted, or JIT compiled to the native instruction set. Which
of these options is used is specified by the cvars vm_game, vm_cgame and
vm_ui for each module respectively. A value of 0 means to use native
libs, 1 to interpret bytecode and 2 to JIT compile bytecode.

HAVE_VM_NATIVE specifies that the platform is capable of using native
libs.
HAVE_VM_COMPILED specifies that the platform has a bytecode JIT
compiler.
There is no define HAVE_VM_INTERPRETED since in theory the interpreter
should work everywhere (though it is the slowest option).

DLL_ONLY comes from before ioq3 as a means of disabling any bytecode
mechanisms. I'm not convinced this is really useful anymore, perhaps it
should be removed.

As an aside, I've been thinking for a while that HAVE_VM_* should really
live in a header rather than defined by the build system. The main
reason for this is that currently only the linux and mingw builds have
these defined since nobody has added the relevant bits to the build
systems on OS X and VC. In other words these builds can ONLY use
interpreted bytecode at the moment. Obviously it's trivial to fix the
build systems, but from a maintenance point of view it makes more sense
to save us the bother (now and in future) and put the defines in a
header. Also, with the exception of x86_64 for now, I don't really see
the HAVE_VM_* defines as being something that should be end user
optional, especially since the runtime behaviour can be chosen using the
vm_* cvars. Opinions?


From tim at ngus.net  Fri Oct 28 10:45:47 2005
From: tim at ngus.net (Tim Angus)
Date: Fri, 28 Oct 2005 15:45:47 +0100
Subject: GL_ARB_multitexture on Solaris/Sparc OpenGL
In-Reply-To: <Pine.LNX.4.63.0510281556520.5762@thorbardin.lasthome.solace.krynn>
References: <Pine.LNX.4.63.0510281556520.5762@thorbardin.lasthome.solace.krynn>
Message-ID: <20051028154547.65c61943.tim@ngus.net>

On Fri, 28 Oct 2005 16:06:00 +0200 (CEST) vincent at cojot.name wrote:
> 1) "#ifdef __sun" some stuff in linux_glimp.c
> 2) #define PFNGLMULTITEXCOORD2FARBPROC et al for Solaris in qgl.h
> (ugly).
> 3) Create a solaris_glimp.c and work from there...

I think 3) is a bad idea in general unless there is a lot of stuff that
needs to be rewritten. I actually prefer 2) over 1) because you only
need to do it in one place and it doesn't uglify the code where the
extensions are loaded.

I'm slightly suprised Solaris GL headers don't have the definitions --
AFAIK they should be in GL 1.2 and up.

If it helps here are the relevant lines from my (nvidia) GL headers:
typedef void (APIENTRYP PFNGLMULTITEXCOORD2FARBPROC) (GLenum target,
GLfloat s, GLfloat t);
typedef void (APIENTRYP PFNGLACTIVETEXTUREARBPROC) (GLenum texture);
typedef void (APIENTRYP PFNGLCLIENTACTIVETEXTUREARBPROC) (GLenum
texture);




From vincent at cojot.name  Fri Oct 28 11:01:59 2005
From: vincent at cojot.name (vincent at cojot.name)
Date: Fri, 28 Oct 2005 17:01:59 +0200 (CEST)
Subject: [quake3] Re: Questions about compile options (ioq3 on Solaris).
In-Reply-To: <20051028153134.2eb515af.tim@ngus.net>
References: <Pine.LNX.4.63.0510281511540.5762@thorbardin.lasthome.solace.krynn>
 <20051028153134.2eb515af.tim@ngus.net>
Message-ID: <Pine.LNX.4.63.0510281654080.5762@thorbardin.lasthome.solace.krynn>

On Fri, 28 Oct 2005, Tim Angus wrote:

> I think ankon was/is working on a Solaris port. I'm not sure what stage
> he got to, but perhaps you two should talk and avoid duplication of
> effort :).

Got an e-mail address for him? I hadn't seen anything regarding a Solaris 
port on the list...

> HAVE_VM_NATIVE specifies that the platform is capable of using native
> libs.
> HAVE_VM_COMPILED specifies that the platform has a bytecode JIT
> compiler.
> There is no define HAVE_VM_INTERPRETED since in theory the interpreter
> should work everywhere (though it is the slowest option).

Ok, thanks for the information.

> As an aside, I've been thinking for a while that HAVE_VM_* should really
> live in a header rather than defined by the build system. The main
> reason for this is that currently only the linux and mingw builds have
> these defined since nobody has added the relevant bits to the build
> systems on OS X and VC. In other words these builds can ONLY use
> interpreted bytecode at the moment. Obviously it's trivial to fix the
> build systems, but from a maintenance point of view it makes more sense
> to save us the bother (now and in future) and put the defines in a
> header. Also, with the exception of x86_64 for now, I don't really see
> the HAVE_VM_* defines as being something that should be end user
> optional, especially since the runtime behaviour can be chosen using the
> vm_* cvars. Opinions?

Good idea..

-- 
,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,
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 davebytes at comcast.net  Fri Oct 28 11:05:32 2005
From: davebytes at comcast.net (David Chait)
Date: Fri, 28 Oct 2005 11:05:32 -0400
Subject: Questions about compile options (ioq3 on Solaris).
References: <Pine.LNX.4.63.0510281511540.5762@thorbardin.lasthome.solace.krynn> <20051028153134.2eb515af.tim@ngus.net>
Message-ID: <003301c5dbd1$0ad13de0$6e01a8c0@sixfour>

As someone working with small, embedded systems, without great horsepower, I 
think DLL_ONLY really applies.  I don't want the interpreter even to exist 
in the end code, I just want precompiled binaries/libs for everything.  That 
make sense?

Oh, and as to whether to make them make args vs header-based flags, really 
only matters if you are switching between them I guess -- though as a 
header-based flag, it would hopefully cause all dependent files to 
recompile, whereas the make arg wouldn't necessarily. ;)

-d

----- Original Message ----- 
From: "Tim Angus" <tim at ngus.net>
To: <quake3 at icculus.org>
Sent: Friday, October 28, 2005 10:31 AM
Subject: [quake3] Re: Questions about compile options (ioq3 on Solaris).


> DLL_ONLY comes from before ioq3 as a means of disabling any bytecode
> mechanisms. I'm not convinced this is really useful anymore, perhaps it
> should be removed.



From vincent at cojot.name  Fri Oct 28 11:06:18 2005
From: vincent at cojot.name (vincent at cojot.name)
Date: Fri, 28 Oct 2005 17:06:18 +0200 (CEST)
Subject: [quake3] Re: GL_ARB_multitexture on Solaris/Sparc OpenGL
In-Reply-To: <20051028154547.65c61943.tim@ngus.net>
References: <Pine.LNX.4.63.0510281556520.5762@thorbardin.lasthome.solace.krynn>
 <20051028154547.65c61943.tim@ngus.net>
Message-ID: <Pine.LNX.4.63.0510281702470.5762@thorbardin.lasthome.solace.krynn>

On Fri, 28 Oct 2005, Tim Angus wrote:

> On Fri, 28 Oct 2005 16:06:00 +0200 (CEST) vincent at cojot.name wrote:
>> 1) "#ifdef __sun" some stuff in linux_glimp.c
>> 2) #define PFNGLMULTITEXCOORD2FARBPROC et al for Solaris in qgl.h
>> (ugly).
>> 3) Create a solaris_glimp.c and work from there...
>
> I think 3) is a bad idea in general unless there is a lot of stuff that
> needs to be rewritten. I actually prefer 2) over 1) because you only
> need to do it in one place and it doesn't uglify the code where the
> extensions are loaded.

*Nod*. 3) has created a maintenance nightmare for us/me on ioq2 where the 
Linux people would patch and commit to CVS without backporting the diffs 
to the Solaris files, thereby breaking the port.. I'll go with 2) as per 
your recommendation and remove the solaris_glimp file I just created.. :)

> I'm slightly suprised Solaris GL headers don't have the definitions --
> AFAIK they should be in GL 1.2 and up.

Solaris OpenGL has the GL_ARB_multitexture definitions (lots of 
glMultiTexCoord*) but these things "PFNGLM" do not appear anywhere..

> If it helps here are the relevant lines from my (nvidia) GL headers:
> typedef void (APIENTRYP PFNGLMULTITEXCOORD2FARBPROC) (GLenum target,
> GLfloat s, GLfloat t);
> typedef void (APIENTRYP PFNGLACTIVETEXTUREARBPROC) (GLenum texture);
> typedef void (APIENTRYP PFNGLCLIENTACTIVETEXTUREARBPROC) (GLenum
> texture);

Do you want me to post the Sun OpenGL headers somewhere so we can examine 
them and maybe devise some more portable way to do this?

-- 
,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,
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  Fri Oct 28 11:20:06 2005
From: vincent at cojot.name (vincent at cojot.name)
Date: Fri, 28 Oct 2005 17:20:06 +0200 (CEST)
Subject: [quake3] Re: Questions about compile options (ioq3 on Solaris).
In-Reply-To: <Pine.LNX.4.63.0510281654080.5762@thorbardin.lasthome.solace.krynn>
References: <Pine.LNX.4.63.0510281511540.5762@thorbardin.lasthome.solace.krynn>
 <20051028153134.2eb515af.tim@ngus.net> <Pine.LNX.4.63.0510281654080.5762@thorbardin.lasthome.solace.krynn>
Message-ID: <Pine.LNX.4.63.0510281708120.5762@thorbardin.lasthome.solace.krynn>


One more question:

ioq2 for Solaris uses SDL for sound but native OpenGL for graphics and I 
guess the same should be true for ioq3..

However, with ioq3 it is not currently possible to do this because:

- if USE_SDL is true, I get sdl_glimp.c and sdl_snd.c in Q3OBJS but no 
linux_glimp.c (#if !USE_SDL avoids the use of its code).

- if USE_SDL is false, I do get linux_glimp.c and linux_snd.c but not 
sdl_snd.c.

How could we change that so that ioq3 gets SDL sound and native OpenGL 
under Solaris? I guess we have the following possibilities:

1) patch the #ifdef's in linux_glimp.c, sdl_glimp.c, sdl_snd.c, 
linux_snd.c (Ugly).
2) split USE_SDL to USE_SDL_VIDEO and USE_SDL_SOUND..? (semi-Ugly)
3) Create a solaris_snd.c that'd be Solaris-specific (not a bad idea) and 
disable USE_SDL for Solaris..

What option do you guys/gals like better?

Thanks for reading,

-- 
,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,
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 paszczus at gmail.com  Fri Oct 28 11:30:34 2005
From: paszczus at gmail.com (PaSzCzUs)
Date: Fri, 28 Oct 2005 17:30:34 +0200
Subject: [quake3] Re: Running q3ded on PPC
In-Reply-To: <1130505187.11098.3.camel@klamath.syndrom23.de>
References: <daa0fb1e0510271404o66eee000y@mail.gmail.com>
	 <20051027221346.02796f81.tim@ngus.net>
	 <daa0fb1e0510280135k15c4f4f1w@mail.gmail.com>
	 <1130505187.11098.3.camel@klamath.syndrom23.de>
Message-ID: <daa0fb1e0510280830h20d18c9h@mail.gmail.com>

On debug version:

-bash-3.00$ pwd;gdb ./linuxq3ded
/home/users/builder/rpm/BUILD/quake3-1.33_SVN191/code/unix/debugppc-glibc
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host= --target=ppc-pld-linux"...Using
host libthread_db library "/lib/libthread_db.so.1".

(gdb) r +map q3dm17
Starting program:
/home/users/builder/rpm/BUILD/quake3-1.33_SVN191/code/unix/debugppc-glibc/linuxq3ded
+map q3dm17
ioQ3 1.33 linux-ppc Oct 28 2005
----- FS_Startup -----
Current search path:
/home/users/builder/.q3a/baseq3
/home/users/builder/rpm/BUILD/quake3-1.33_SVN191/code/unix/debugppc-glibc/baseq3/pak8.pk3
(9 files)
/home/users/builder/rpm/BUILD/quake3-1.33_SVN191/code/unix/debugppc-glibc/baseq3/pak7.pk3
(4 files)
/home/users/builder/rpm/BUILD/quake3-1.33_SVN191/code/unix/debugppc-glibc/baseq3/pak6.pk3
(64 files)
/home/users/builder/rpm/BUILD/quake3-1.33_SVN191/code/unix/debugppc-glibc/baseq3/pak5.pk3
(7 files)
/home/users/builder/rpm/BUILD/quake3-1.33_SVN191/code/unix/debugppc-glibc/baseq3/pak4.pk3
(272 files)
/home/users/builder/rpm/BUILD/quake3-1.33_SVN191/code/unix/debugppc-glibc/baseq3/pak3.pk3
(4 files)
/home/users/builder/rpm/BUILD/quake3-1.33_SVN191/code/unix/debugppc-glibc/baseq3/pak2.pk3
(148 files)
/home/users/builder/rpm/BUILD/quake3-1.33_SVN191/code/unix/debugppc-glibc/baseq3/pak1.pk3
(26 files)
/home/users/builder/rpm/BUILD/quake3-1.33_SVN191/code/unix/debugppc-glibc/baseq3/pak0.pk3
(3539 files)
/home/users/builder/rpm/BUILD/quake3-1.33_SVN191/code/unix/debugppc-glibc/baseq3

----------------------
4073 files in pk3 files
execing default.cfg
couldn't exec q3config.cfg
couldn't exec autoexec.cfg
Hunk_Clear: reset the hunk ok
--- Common Initialization Complete ---
Opening IP socket: localhost:27960
Hostname: gzowski.opole.pl
IP: 217.197.64.134
Started tty console (use +set ttycon 0 to disable)
------ Server Initialization ------
Server: q3dm17
Hunk_Clear: reset the hunk ok
----- FS_Startup -----
Current search path:
/home/users/builder/.q3a/baseq3
/home/users/builder/rpm/BUILD/quake3-1.33_SVN191/code/unix/debugppc-glibc/baseq3/pak8.pk3
(9 files)
/home/users/builder/rpm/BUILD/quake3-1.33_SVN191/code/unix/debugppc-glibc/baseq3/pak7.pk3
(4 files)
/home/users/builder/rpm/BUILD/quake3-1.33_SVN191/code/unix/debugppc-glibc/baseq3/pak6.pk3
(64 files)
/home/users/builder/rpm/BUILD/quake3-1.33_SVN191/code/unix/debugppc-glibc/baseq3/pak5.pk3
(7 files)
/home/users/builder/rpm/BUILD/quake3-1.33_SVN191/code/unix/debugppc-glibc/baseq3/pak4.pk3
(272 files)
/home/users/builder/rpm/BUILD/quake3-1.33_SVN191/code/unix/debugppc-glibc/baseq3/pak3.pk3
(4 files)
/home/users/builder/rpm/BUILD/quake3-1.33_SVN191/code/unix/debugppc-glibc/baseq3/pak2.pk3
(148 files)
/home/users/builder/rpm/BUILD/quake3-1.33_SVN191/code/unix/debugppc-glibc/baseq3/pak1.pk3
(26 files)
/home/users/builder/rpm/BUILD/quake3-1.33_SVN191/code/unix/debugppc-glibc/baseq3/pak0.pk3
(3539 files)
/home/users/builder/rpm/BUILD/quake3-1.33_SVN191/code/unix/debugppc-glibc/baseq3

----------------------
8146 files in pk3 files
Loading vm file vm/qagame.qvm...
Architecture doesn't have a bytecode compiler, using interpreter

Program received signal SIGSEGV, Segmentation fault.
0x100527a8 in VM_PrepareInterpreter (vm=0x1025723c, header=0x347f07b8)
at ../qcommon/vm_interpreted.c:268
268                                     codeBase[pc] =
vm->instructionPointers[codeBase[pc]];
(gdb) bt
#0  0x100527a8 in VM_PrepareInterpreter (vm=0x1025723c,
header=0x347f07b8) at ../qcommon/vm_interpreted.c:268
#1  0x100517d8 in VM_Create (module=0x100b1514 "qagame",
systemCalls=0x1000a55c <SV_GameSystemCalls>, interpret=VMI_BYTECODE)
    at ../qcommon/vm.c:597
#2  0x1000de7c in SV_InitGameProgs () at ../server/sv_game.c:950
#3  0x1000ef04 in SV_SpawnServer (server=0x7f9055e0 "q3dm17",
killBots=qfalse) at ../server/sv_init.c:435
#4  0x10008518 in SV_Map_f () at ../server/sv_ccmds.c:189
#5  0x1002a390 in Cmd_ExecuteString (text=0x7f905670 "map q3dm17") at
../qcommon/cmd.c:645
#6  0x100297a8 in Cbuf_Execute () at ../qcommon/cmd.c:220
#7  0x1002fdc0 in Com_Frame () at ../qcommon/common.c:2695
#8  0x100acab4 in main (argc=3, argv=0x7f906c54) at ../unix/unix_main.c:1405
(gdb)


From tim at ngus.net  Fri Oct 28 12:15:32 2005
From: tim at ngus.net (Tim Angus)
Date: Fri, 28 Oct 2005 17:15:32 +0100
Subject: Running q3ded on PPC
In-Reply-To: <daa0fb1e0510280830h20d18c9h@mail.gmail.com>
References: <daa0fb1e0510271404o66eee000y@mail.gmail.com>
	<20051027221346.02796f81.tim@ngus.net>
	<daa0fb1e0510280135k15c4f4f1w@mail.gmail.com>
	<1130505187.11098.3.camel@klamath.syndrom23.de>
	<daa0fb1e0510280830h20d18c9h@mail.gmail.com>
Message-ID: <20051028171532.25dc3a5a.tim@ngus.net>

On Fri, 28 Oct 2005 17:30:34 +0200 PaSzCzUs wrote:
> Program received signal SIGSEGV, Segmentation fault.
> 0x100527a8 in VM_PrepareInterpreter (vm=0x1025723c, header=0x347f07b8)
> at ../qcommon/vm_interpreted.c:268
> 268                                     codeBase[pc] =
> vm->instructionPointers[codeBase[pc]];
> (gdb) bt
> #0  0x100527a8 in VM_PrepareInterpreter (vm=0x1025723c,
> header=0x347f07b8) at ../qcommon/vm_interpreted.c:268
> #1  0x100517d8 in VM_Create (module=0x100b1514 "qagame",
> systemCalls=0x1000a55c <SV_GameSystemCalls>, interpret=VMI_BYTECODE)
>     at ../qcommon/vm.c:597
> #2  0x1000de7c in SV_InitGameProgs () at ../server/sv_game.c:950
> #3  0x1000ef04 in SV_SpawnServer (server=0x7f9055e0 "q3dm17",
> killBots=qfalse) at ../server/sv_init.c:435
> #4  0x10008518 in SV_Map_f () at ../server/sv_ccmds.c:189
> #5  0x1002a390 in Cmd_ExecuteString (text=0x7f905670 "map q3dm17") at
> ../qcommon/cmd.c:645
> #6  0x100297a8 in Cbuf_Execute () at ../qcommon/cmd.c:220
> #7  0x1002fdc0 in Com_Frame () at ../qcommon/common.c:2695
> #8  0x100acab4 in main (argc=3, argv=0x7f906c54) at
> #../unix/unix_main.c:1405
> (gdb)

Could you paste the output of the attached program? (compile with "gcc
-o q3_endian_test q3_endian_test.c")
-------------- next part --------------
A non-text attachment was scrubbed...
Name: q3_endian_test.c
Type: text/x-csrc
Size: 211 bytes
Desc: not available
URL: <http://icculus.org/pipermail/quake3/attachments/20051028/eaeac4b1/attachment.c>

From tim at ngus.net  Fri Oct 28 12:21:57 2005
From: tim at ngus.net (Tim Angus)
Date: Fri, 28 Oct 2005 17:21:57 +0100
Subject: Questions about compile options (ioq3 on Solaris).
In-Reply-To: <Pine.LNX.4.63.0510281708120.5762@thorbardin.lasthome.solace.krynn>
References: <Pine.LNX.4.63.0510281511540.5762@thorbardin.lasthome.solace.krynn>
	<20051028153134.2eb515af.tim@ngus.net>
	<Pine.LNX.4.63.0510281654080.5762@thorbardin.lasthome.solace.krynn>
	<Pine.LNX.4.63.0510281708120.5762@thorbardin.lasthome.solace.krynn>
Message-ID: <20051028172157.52739e68.tim@ngus.net>

On Fri, 28 Oct 2005 17:20:06 +0200 (CEST) vincent at cojot.name wrote:
> ioq2 for Solaris uses SDL for sound but native OpenGL for graphics and
> I  guess the same should be true for ioq3..

Is there a reason for not using SDL for GL too? If yes then...

> 1) patch the #ifdef's in linux_glimp.c, sdl_glimp.c, sdl_snd.c, 
> linux_snd.c (Ugly).
> 2) split USE_SDL to USE_SDL_VIDEO and USE_SDL_SOUND..? (semi-Ugly)
> 3) Create a solaris_snd.c that'd be Solaris-specific (not a bad idea)
> and  disable USE_SDL for Solaris..

...I would go for 3). SDL sound is only really an advantage when you
have a dozen different sound backends (*cough* linux).


From paszczus at gmail.com  Fri Oct 28 12:24:38 2005
From: paszczus at gmail.com (PaSzCzUs)
Date: Fri, 28 Oct 2005 18:24:38 +0200
Subject: [quake3] Re: Running q3ded on PPC
In-Reply-To: <20051028171532.25dc3a5a.tim@ngus.net>
References: <daa0fb1e0510271404o66eee000y@mail.gmail.com>
	 <20051027221346.02796f81.tim@ngus.net>
	 <daa0fb1e0510280135k15c4f4f1w@mail.gmail.com>
	 <1130505187.11098.3.camel@klamath.syndrom23.de>
	 <daa0fb1e0510280830h20d18c9h@mail.gmail.com>
	 <20051028171532.25dc3a5a.tim@ngus.net>
Message-ID: <daa0fb1e0510280924n2a307b15t@mail.gmail.com>

> Could you paste the output of the attached program? (compile with "gcc
> -o q3_endian_test q3_endian_test.c")
>
 ./q3_endian_test
Q3 thinks this machine is little endian


From andreas at syndrom23.de  Fri Oct 28 12:40:27 2005
From: andreas at syndrom23.de (Andreas Kohn)
Date: Fri, 28 Oct 2005 18:40:27 +0200
Subject: [quake3] Re: Questions about compile options (ioq3 on Solaris).
In-Reply-To: <Pine.LNX.4.63.0510281708120.5762@thorbardin.lasthome.solace.krynn>
References: 
	 <Pine.LNX.4.63.0510281511540.5762@thorbardin.lasthome.solace.krynn>
	 <20051028153134.2eb515af.tim@ngus.net>
	 <Pine.LNX.4.63.0510281654080.5762@thorbardin.lasthome.solace.krynn>
	 <Pine.LNX.4.63.0510281708120.5762@thorbardin.lasthome.solace.krynn>
Message-ID: <1130517628.69022.4.camel@klamath.syndrom23.de>

Hi,

> Got an e-mail address for him? I hadn't seen anything regarding a 
> Solaris port on the list...

Sure, use this one: andreas at syndrom23.de :)

Well, I didn't announce anything, because I can only play with Solaris
in the university computer pools.
My current state was: compiles with gcc 2.8.1 on SunOS 5.7, both client
and dedicated. 
The client has no sound, I used null_snd.c from the dedicated server
with a small modification. The client crashes somewhere when
initializing Mesa, which may be related to the fact that mesa was
forcefully installed by me (non-root) in a non-standard location etc. 
It looks like you are way ahead of me :)

On Fri, 2005-10-28 at 17:20 +0200, vincent at cojot.name wrote:
> 1) patch the #ifdef's in linux_glimp.c, sdl_glimp.c, sdl_snd.c, 
> linux_snd.c (Ugly).
> 2) split USE_SDL to USE_SDL_VIDEO and USE_SDL_SOUND..? (semi-Ugly)
> 3) Create a solaris_snd.c that'd be Solaris-specific (not a bad idea) and 
> disable USE_SDL for Solaris..
> 
> What option do you guys/gals like better?

+1 for 3) as well.

--
Andreas 
(aka ankon)

-- 
<TalisA> was macht man eigentlich auf einer linux-gamer lan ? hl server
aufsetzen und freuen ? *duck* ^^
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
URL: <http://icculus.org/pipermail/quake3/attachments/20051028/2eb731f6/attachment.pgp>

From tim at ngus.net  Fri Oct 28 12:58:42 2005
From: tim at ngus.net (Tim Angus)
Date: Fri, 28 Oct 2005 17:58:42 +0100
Subject: Running q3ded on PPC
In-Reply-To: <daa0fb1e0510280924n2a307b15t@mail.gmail.com>
References: <daa0fb1e0510271404o66eee000y@mail.gmail.com>
	<20051027221346.02796f81.tim@ngus.net>
	<daa0fb1e0510280135k15c4f4f1w@mail.gmail.com>
	<1130505187.11098.3.camel@klamath.syndrom23.de>
	<daa0fb1e0510280830h20d18c9h@mail.gmail.com>
	<20051028171532.25dc3a5a.tim@ngus.net>
	<daa0fb1e0510280924n2a307b15t@mail.gmail.com>
Message-ID: <20051028175842.1b1f8a09.tim@ngus.net>

On Fri, 28 Oct 2005 18:24:38 +0200 PaSzCzUs wrote:
> > Could you paste the output of the attached program? (compile with
> > "gcc -o q3_endian_test q3_endian_test.c")
> >
>  ./q3_endian_test
> Q3 thinks this machine is little endian

Erm sorry, that was a bit hasty. Add...

#include <assert.h>
#include <math.h>
#include <stdio.h>
#include <stdarg.h>
#include <string.h>
#include <stdlib.h>
#include <time.h>
#include <ctype.h>
#include <limits.h>

...to the top of q3_endian_test.c and run it again.


From vincent at cojot.name  Fri Oct 28 13:02:49 2005
From: vincent at cojot.name (vincent at cojot.name)
Date: Fri, 28 Oct 2005 19:02:49 +0200 (CEST)
Subject: [quake3] Re: Questions about compile options (ioq3 on Solaris).
In-Reply-To: <1130517628.69022.4.camel@klamath.syndrom23.de>
References: <Pine.LNX.4.63.0510281511540.5762@thorbardin.lasthome.solace.krynn>
  <20051028153134.2eb515af.tim@ngus.net> 
 <Pine.LNX.4.63.0510281654080.5762@thorbardin.lasthome.solace.krynn> 
 <Pine.LNX.4.63.0510281708120.5762@thorbardin.lasthome.solace.krynn>
 <1130517628.69022.4.camel@klamath.syndrom23.de>
Message-ID: <Pine.LNX.4.63.0510281846140.5762@thorbardin.lasthome.solace.krynn>

On Fri, 28 Oct 2005, Andreas Kohn wrote:

Hi Andreas/Ankon,

> Well, I didn't announce anything, because I can only play with Solaris
> in the university computer pools.

Ok. I can help with that (lots of high-end SUN systems at work and at 
home). :)

> My current state was: compiles with gcc 2.8.1 on SunOS 5.7, both client
> and dedicated.

Do you have a current tarball of your porting work?

> The client has no sound, I used null_snd.c from the dedicated server
> with a small modification. The client crashes somewhere when
> initializing Mesa, which may be related to the fact that mesa was
> forcefully installed by me (non-root) in a non-standard location etc.
> It looks like you are way ahead of me :)

Mesa will be very slow on Solaris. ioq2 uses OpenGL (or XIL, or 
Newt/SunRay since SUN contributed some code) and ioq3 should most likely 
use OpenGL under Solaris too..

>> What option do you guys/gals like better?
>
> +1 for 3) as well.

I'm currently experimenting with option 2) (USE_SDL_VIDEO and 
USE_SDL_AUDIO) since I'm "sound coding impaired" and I'm planning to use 
SDL for sound under Solaris..

-- 
,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,
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 paszczus at gmail.com  Fri Oct 28 13:10:34 2005
From: paszczus at gmail.com (PaSzCzUs)
Date: Fri, 28 Oct 2005 19:10:34 +0200
Subject: [quake3] Re: Running q3ded on PPC
In-Reply-To: <20051028175842.1b1f8a09.tim@ngus.net>
References: <daa0fb1e0510271404o66eee000y@mail.gmail.com>
	 <20051027221346.02796f81.tim@ngus.net>
	 <daa0fb1e0510280135k15c4f4f1w@mail.gmail.com>
	 <1130505187.11098.3.camel@klamath.syndrom23.de>
	 <daa0fb1e0510280830h20d18c9h@mail.gmail.com>
	 <20051028171532.25dc3a5a.tim@ngus.net>
	 <daa0fb1e0510280924n2a307b15t@mail.gmail.com>
	 <20051028175842.1b1f8a09.tim@ngus.net>
Message-ID: <daa0fb1e0510281010u68442b32o@mail.gmail.com>

-bash-3.00$ cat q3_endian_test.c && ./q3_endian_test
#include <assert.h>
#include <math.h>
#include <stdio.h>
#include <stdarg.h>
#include <string.h>
#include <stdlib.h>
#include <time.h>
#include <ctype.h>
#include <limits.h>
#include <stdio.h>

int main( void )
{
  printf( "Q3 thinks this machine is " );

#if __FLOAT_WORD_ORDER == __LITTLE_ENDIAN
  printf( "little endian\n" );
#else
  printf( "big endian\n" );
#endif

  return 0;
}

Q3 thinks this machine is big endian


From ludwig.nussel at suse.de  Fri Oct 28 13:47:11 2005
From: ludwig.nussel at suse.de (Ludwig Nussel)
Date: Fri, 28 Oct 2005 19:47:11 +0200
Subject: [quake3] Re: Questions about compile options (ioq3 on Solaris).
In-Reply-To: <20051028153134.2eb515af.tim@ngus.net>
References: <Pine.LNX.4.63.0510281511540.5762@thorbardin.lasthome.solace.krynn> <20051028153134.2eb515af.tim@ngus.net>
Message-ID: <200510281947.11950.ludwig.nussel@suse.de>

Tim Angus wrote:
> HAVE_VM_NATIVE specifies that the platform is capable of using native
> libs.

This one can be removed. It was needed on 64bit architectures before
I changed the vm interface from int to long.

> HAVE_VM_COMPILED specifies that the platform has a bytecode JIT
> compiler.
> There is no define HAVE_VM_INTERPRETED since in theory the interpreter
> should work everywhere (though it is the slowest option).
>
> DLL_ONLY comes from before ioq3 as a means of disabling any bytecode
> mechanisms. I'm not convinced this is really useful anymore, perhaps it
> should be removed.

I vote for dropping it. Noone is going to test builds with that
enabled anyways. 

> As an aside, I've been thinking for a while that HAVE_VM_* should really
> live in a header rather than defined by the build system. The main
> reason for this is that currently only the linux and mingw builds have
> these defined since nobody has added the relevant bits to the build
> systems on OS X and VC. In other words these builds can ONLY use
> interpreted bytecode at the moment. Obviously it's trivial to fix the
> build systems, but from a maintenance point of view it makes more sense
> to save us the bother (now and in future) and put the defines in a
> header. Also, with the exception of x86_64 for now, I don't really see
> the HAVE_VM_* defines as being something that should be end user
> optional, especially since the runtime behaviour can be chosen using the
> vm_* cvars. Opinions?

Switch to Automake+Autoconf. That would also give us the tools to
handle the tests for the stuff missing on Solaris. I even volunteer
to create and maintain the necessary files. There is no gettext nor
any gnome/kde/<your favorite bleeding edge tech with special m4
macros here> involved so I'm confident that it's not going to be a
mess. We probably can't avoid libtool though.

cu
Ludwig

-- 
 (o_   Ludwig Nussel
 //\   SUSE LINUX Products GmbH, Development
 V_/_  http://www.suse.de/








From tim at ngus.net  Fri Oct 28 14:07:04 2005
From: tim at ngus.net (Tim Angus)
Date: Fri, 28 Oct 2005 19:07:04 +0100
Subject: Running q3ded on PPC
In-Reply-To: <daa0fb1e0510281010u68442b32o@mail.gmail.com>
References: <daa0fb1e0510271404o66eee000y@mail.gmail.com>
	<20051027221346.02796f81.tim@ngus.net>
	<daa0fb1e0510280135k15c4f4f1w@mail.gmail.com>
	<1130505187.11098.3.camel@klamath.syndrom23.de>
	<daa0fb1e0510280830h20d18c9h@mail.gmail.com>
	<20051028171532.25dc3a5a.tim@ngus.net>
	<daa0fb1e0510280924n2a307b15t@mail.gmail.com>
	<20051028175842.1b1f8a09.tim@ngus.net>
	<daa0fb1e0510281010u68442b32o@mail.gmail.com>
Message-ID: <20051028190704.54afdfe8.tim@ngus.net>

On Fri, 28 Oct 2005 19:10:34 +0200 PaSzCzUs wrote:
> Q3 thinks this machine is big endian

Well, I don't understand what your problem is then. The backtrace looks
very much like the problem solved in revision 179. There is at least one
person in the IRC channel that reports the client as working (albeit
with some GL problems). Are you absolutely sure you're using the latest
revision? Check out a clean copy to be certain.


From tim at ngus.net  Fri Oct 28 16:28:42 2005
From: tim at ngus.net (Tim Angus)
Date: Fri, 28 Oct 2005 21:28:42 +0100
Subject: Questions about compile options (ioq3 on Solaris).
In-Reply-To: <200510281947.11950.ludwig.nussel@suse.de>
References: <Pine.LNX.4.63.0510281511540.5762@thorbardin.lasthome.solace.krynn>
	<20051028153134.2eb515af.tim@ngus.net>
	<200510281947.11950.ludwig.nussel@suse.de>
Message-ID: <20051028212842.46e5a687.tim@ngus.net>

On Fri, 28 Oct 2005 19:47:11 +0200 Ludwig wrote:
> > HAVE_VM_NATIVE specifies that the platform is capable of using
> > native libs.
> 
> This one can be removed. It was needed on 64bit architectures before
> I changed the vm interface from int to long.

OK, I guess I'll do so then.

> Switch to Automake+Autoconf. That would also give us the tools to
> handle the tests for the stuff missing on Solaris. I even volunteer
> to create and maintain the necessary files. There is no gettext nor
> any gnome/kde/<your favorite bleeding edge tech with special m4
> macros here> involved so I'm confident that it's not going to be a
> mess. We probably can't avoid libtool though.

Using a different build system on *nix doesn't really fix the problem. I
don't think zakk would agree to this anyway. Thinking about it again,
perhaps the best solution is to negate the value, so the define remains
in the Makefile, but is DOESNT_HAVE_VM_COMPILE (or whatever) instead.
That way the OS X and VC builds get their JIT compiler back for free,
but we still maintain control over whether or not it is enabled from the
Makefile.

I'll have a fiddle later on tonight I guess.


From tim at ngus.net  Fri Oct 28 16:32:08 2005
From: tim at ngus.net (Tim Angus)
Date: Fri, 28 Oct 2005 21:32:08 +0100
Subject: Questions about compile options (ioq3 on Solaris).
In-Reply-To: <003301c5dbd1$0ad13de0$6e01a8c0@sixfour>
References: <Pine.LNX.4.63.0510281511540.5762@thorbardin.lasthome.solace.krynn>
	<20051028153134.2eb515af.tim@ngus.net>
	<003301c5dbd1$0ad13de0$6e01a8c0@sixfour>
Message-ID: <20051028213208.35648971.tim@ngus.net>

On Fri, 28 Oct 2005 11:05:32 -0400 David wrote:
> As someone working with small, embedded systems, without great
> horsepower, I  think DLL_ONLY really applies.  I don't want the
> interpreter even to exist  in the end code, I just want precompiled
> binaries/libs for everything.  That  make sense?

Yes, but I'm not sure ioq3 is really the best choice if you're wanting
to work with embedded systems. There are a couple of projects out there
where the goal is eliminate the libs altogether and end up with a single
glob of code -- maybe this would be better for you.

> Oh, and as to whether to make them make args vs header-based flags,
> really  only matters if you are switching between them I guess --
> though as a  header-based flag, it would hopefully cause all dependent
> files to  recompile, whereas the make arg wouldn't necessarily. ;)

In any normal situation you wouldn't need to be swtiching them so I'm
not sure it really matters, but it's still a valid point.


From zakk at timedoctor.org  Fri Oct 28 17:25:34 2005
From: zakk at timedoctor.org (Zachary J. SLater)
Date: Fri, 28 Oct 2005 17:25:34 -0400
Subject: [quake3] Re: Questions about compile options (ioq3 on Solaris).
In-Reply-To: <20051028212842.46e5a687.tim@ngus.net>
References: <Pine.LNX.4.63.0510281511540.5762@thorbardin.lasthome.solace.krynn> <20051028153134.2eb515af.tim@ngus.net> <200510281947.11950.ludwig.nussel@suse.de> <20051028212842.46e5a687.tim@ngus.net>
Message-ID: <1130534734.4362974eaca5f@mail.icculus.org>

Quoting Tim Angus <tim at ngus.net>:

> Using a different build system on *nix doesn't really fix the problem. I
> don't think zakk would agree to this anyway.

This is correct, Make is it for now. Please see Ryan's e-mail about
 this earlier as to why. Yes I'm sorry that make isn't the best build system
for some things, no I'm not sorry that I'm sticking to it. With other projects
I've been swayed to the autotools side and then had the autotools people bail
on me. Not that you'll do that ludwig, but that is just one more reason I have
for not doing it here, at least not right now.
-- 
-Zachary J. Slater
zakk at timedoctor.org
zacharyslater at gmail.com




From vincent at cojot.name  Fri Oct 28 17:44:26 2005
From: vincent at cojot.name (vincent at cojot.name)
Date: Fri, 28 Oct 2005 23:44:26 +0200 (CEST)
Subject: [quake3] Re: Questions about compile options (ioq3 on Solaris).
In-Reply-To: <1130534734.4362974eaca5f@mail.icculus.org>
References: <Pine.LNX.4.63.0510281511540.5762@thorbardin.lasthome.solace.krynn>
 <20051028153134.2eb515af.tim@ngus.net> <200510281947.11950.ludwig.nussel@suse.de>
 <20051028212842.46e5a687.tim@ngus.net> <1130534734.4362974eaca5f@mail.icculus.org>
Message-ID: <Pine.LNX.4.63.0510282341030.5762@thorbardin.lasthome.solace.krynn>


I'm currently struggling with q3lcc and what it takes to make it build 
successfully on this Solaris setup.. I don't understand why it would spit 
errors on Solaris whereas it works fine on Linux.. Here's what I'm 
getting, if you have any ideas...:

[myhost] gmake
gmake  targets B=releasesparc CFLAGS=" -pipe -Wall -Wimplicit -Wstrict-prototypes -DNO_XF86_DGA -DUSE_SDL_SOUND=1 
-I/usr/local/include/SDL -D_REENTRANT -DHAVE_VM_NATIVE -DNDEBUG -O3 -fomit-frame-pointer -ffast-math -falign-loops=2 -falign-jumps=2 
-falign-functions=2 -fstrength-reduce -fno-strict-aliasing -MMD"
gmake[1]: Entering directory `/net/thorbardin/export/home/raistlin/code/quake3/code/unix'
../tools/q3lcc -o releasesparc/baseq3/cgame/cg_main.asm -S -DQ3_VM -I../cgame -I../game -I../ui -I../qcommon ../cgame/cg_main.c
cpp: ../cgame/../qcommon/q_shared.h:714 ../cgame/cg_local.h:23 ../cgame/cg_main.c:24 Macro redefinition of ID_INLINE
gmake[1]: *** [releasesparc/baseq3/cgame/cg_main.asm] Error 1
gmake[1]: Leaving directory 
gmake: *** [build_release] Error 2

Shouldn't q3lcc be executing 'q3cpp' and not just 'cpp'? (Yes, I modified etc/gcc-solaris.c)

Any ideas?

-- 
,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,
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  Fri Oct 28 17:46:20 2005
From: vincent at cojot.name (vincent at cojot.name)
Date: Fri, 28 Oct 2005 23:46:20 +0200 (CEST)
Subject: [quake3] Re: Questions about compile options (ioq3 on Solaris).
In-Reply-To: <Pine.LNX.4.63.0510282341030.5762@thorbardin.lasthome.solace.krynn>
References: <Pine.LNX.4.63.0510281511540.5762@thorbardin.lasthome.solace.krynn>
 <20051028153134.2eb515af.tim@ngus.net> <200510281947.11950.ludwig.nussel@suse.de>
 <20051028212842.46e5a687.tim@ngus.net> <1130534734.4362974eaca5f@mail.icculus.org>
 <Pine.LNX.4.63.0510282341030.5762@thorbardin.lasthome.solace.krynn>
Message-ID: <Pine.LNX.4.63.0510282345310.5762@thorbardin.lasthome.solace.krynn>

On Fri, 28 Oct 2005, vincent at cojot.name wrote:

Nevermind, q3lcc -is- indeed executing q3cpp:

11875:  execve("../tools/q3cpp", 0x000256D8, 0xFFBFF4C0)  argc = 20
11875:  resolvepath("/net/thorbardin/export/home/raistlin/code/quake3/code/tools/q3cppls/q3cpp", 
"/net/thorbardin/export/home/raistlin/code/quake3/code/tools/q3cpp", 1023) = 65
11875:  stat("/net/thorbardin/export/home/raistlin/code/quake3/code/tools/q3cpp", 0xFFBFF1E8) = 0

That doesn't make the error any clearer, though...

Vincent


From davebytes at comcast.net  Fri Oct 28 18:19:12 2005
From: davebytes at comcast.net (David Chait)
Date: Fri, 28 Oct 2005 18:19:12 -0400
Subject: Questions about compile options (ioq3 on Solaris).
References: <Pine.LNX.4.63.0510281511540.5762@thorbardin.lasthome.solace.krynn><20051028153134.2eb515af.tim@ngus.net><003301c5dbd1$0ad13de0$6e01a8c0@sixfour> <20051028213208.35648971.tim@ngus.net>
Message-ID: <00cb01c5dc0d$9fcbb420$6e01a8c0@sixfour>

I have no need to eliminate libraries, DLLs, etc.  All I need is direct 
OpenGL (well, GL-ES) access, and OpenAL (which sounds like someone's on the 
ball on that).  Given the platforms, things like input/joystick are either 
straight linux or customized... ;)

-d

----- Original Message ----- 
From: "Tim Angus" <tim at ngus.net>
To: <quake3 at icculus.org>
Sent: Friday, October 28, 2005 4:32 PM
Subject: [quake3] Re: Questions about compile options (ioq3 on Solaris).


> On Fri, 28 Oct 2005 11:05:32 -0400 David wrote:
>> As someone working with small, embedded systems, without great
>> horsepower, I  think DLL_ONLY really applies.  I don't want the
>> interpreter even to exist  in the end code, I just want precompiled
>> binaries/libs for everything.  That  make sense?
>
> Yes, but I'm not sure ioq3 is really the best choice if you're wanting
> to work with embedded systems. There are a couple of projects out there
> where the goal is eliminate the libs altogether and end up with a single
> glob of code -- maybe this would be better for you.



From tim at ngus.net  Fri Oct 28 18:21:49 2005
From: tim at ngus.net (Tim Angus)
Date: Fri, 28 Oct 2005 23:21:49 +0100
Subject: Questions about compile options (ioq3 on Solaris).
In-Reply-To: <Pine.LNX.4.63.0510282341030.5762@thorbardin.lasthome.solace.krynn>
References: <Pine.LNX.4.63.0510281511540.5762@thorbardin.lasthome.solace.krynn>
	<20051028153134.2eb515af.tim@ngus.net>
	<200510281947.11950.ludwig.nussel@suse.de>
	<20051028212842.46e5a687.tim@ngus.net>
	<1130534734.4362974eaca5f@mail.icculus.org>
	<Pine.LNX.4.63.0510282341030.5762@thorbardin.lasthome.solace.krynn>
Message-ID: <20051028232149.3e54986a.tim@ngus.net>

On Fri, 28 Oct 2005 23:44:26 +0200 (CEST) vincent at cojot.name wrote:
> Shouldn't q3lcc be executing 'q3cpp' and not just 'cpp'? (Yes, I
> modified etc/gcc-solaris.c)

gcc-solaris is meant to be used with lcc as a solaris compiler (as
opposed to a bytecode compiler). (Slightly confusingly) Try using
etc/linux.c instead. lcc really needs a good going over to remove a lot
of the platform specific stuff; it's on the list.


From vincent at cojot.name  Fri Oct 28 18:28:38 2005
From: vincent at cojot.name (vincent at cojot.name)
Date: Sat, 29 Oct 2005 00:28:38 +0200 (CEST)
Subject: [quake3] Re: Questions about compile options (ioq3 on Solaris).
In-Reply-To: <20051028232149.3e54986a.tim@ngus.net>
References: <Pine.LNX.4.63.0510281511540.5762@thorbardin.lasthome.solace.krynn>
 <20051028153134.2eb515af.tim@ngus.net> <200510281947.11950.ludwig.nussel@suse.de>
 <20051028212842.46e5a687.tim@ngus.net> <1130534734.4362974eaca5f@mail.icculus.org>
 <Pine.LNX.4.63.0510282341030.5762@thorbardin.lasthome.solace.krynn>
 <20051028232149.3e54986a.tim@ngus.net>
Message-ID: <Pine.LNX.4.63.0510290026580.5762@thorbardin.lasthome.solace.krynn>

On Fri, 28 Oct 2005, Tim Angus wrote:

> gcc-solaris is meant to be used with lcc as a solaris compiler (as
> opposed to a bytecode compiler). (Slightly confusingly) Try using
> etc/linux.c instead. lcc really needs a good going over to remove a lot
> of the platform specific stuff; it's on the list.

Hi Tim,

Thanks for your patience... :)
You mean I shouldn't do this in tools/lcc/etc/gcc-solaris.c:

char *com[] = { LCCDIR "q3rcc", "-target=bytecode", "$1", "$2", "$3", 0 };

Should I go back to -target=solaris/sparc (or something similar)?

-- 
,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,
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  Fri Oct 28 18:34:17 2005
From: vincent at cojot.name (vincent at cojot.name)
Date: Sat, 29 Oct 2005 00:34:17 +0200 (CEST)
Subject: LoadTGA problem on ioq3 Solaris..
In-Reply-To: <20051028232149.3e54986a.tim@ngus.net>
References: <Pine.LNX.4.63.0510281511540.5762@thorbardin.lasthome.solace.krynn>
 <20051028153134.2eb515af.tim@ngus.net> <200510281947.11950.ludwig.nussel@suse.de>
 <20051028212842.46e5a687.tim@ngus.net> <1130534734.4362974eaca5f@mail.icculus.org>
 <Pine.LNX.4.63.0510282341030.5762@thorbardin.lasthome.solace.krynn>
 <20051028232149.3e54986a.tim@ngus.net>
Message-ID: <Pine.LNX.4.63.0510290029110.5762@thorbardin.lasthome.solace.krynn>


I'm a little farther down the road (still stuck on the q3lcc stuff but 
I'll see that tomorrow). It crashes at startup after opening a black 
Window (backtrace below with some extra info to show what it says at 
startup on Solaris...).

(gdb) run
Starting program: /net/thorbardin/export/home/raistlin/code/quake3/code/unix/debugsparc/SunOSquake3 
warning: Lowest section in /lib/libpthread.so.1 is .dynamic at 00000074
warning: Lowest section in /lib/libdl.so.1 is .dynamic at 00000094
warning: Lowest section in /lib/libintl.so.1 is .dynamic at 00000074
ioQ3 1.33 Solaris-sparc Oct 29 2005
[...]
-------------------------------
----- Client Initialization Complete -----
----- R_Init -----
WARNING: tess.xyz not 16 byte aligned   <=======================????

------- Input Initialization -------
[...]
GL_VENDOR: Sun Microsystems, Inc.
GL_RENDERER: ZFB, VIS
GL_VERSION: 1.2 Sun OpenGL 1.3 patch 113886-31 for Solaris
[...]
PIXELFORMAT: color(24-bits) Z(24-bit) stencil(0-bits)
MODE: 3, 640 x 480 fullscreen hz:N/A
GAMMA: software w/ 0 overbright bits
CPU: 
rendering primitives: multiple glArrayElement
texturemode: GL_LINEAR_MIPMAP_NEAREST
picmip: 1
texture bits: 0
multitexture: enabled
compiled vertex arrays: disabled
texenv add: disabled
[....]
compressed textures: disabled
Initializing Shaders
...loading 'scripts/lightningnew.shader'
[....]
----- finished R_Init -----

Program received signal SIGSEGV, Segmentation fault. <======================= Dies here..
0x00156628 in LoadTGA (name=0x5edba8 "gfx/2d/bigchars.tga", pic=0xffbfe120, width=0xffbfe128, height=0xffbfe124)
     at ../renderer/tr_image.c:1155
1155            targa_header.colormap_index = LittleShort ( *(short *)buf_p );
(gdb) bt
#0  0x00156628 in LoadTGA (name=0x5edba8 "gfx/2d/bigchars.tga", pic=0xffbfe120, width=0xffbfe128, height=0xffbfe124)
     at ../renderer/tr_image.c:1155
#1  0x00157d7c in R_LoadImage (name=0x5edba8 "gfx/2d/bigchars.tga", pic=0xffbfe120, width=0xffbfe128, height=0xffbfe124)
     at ../renderer/tr_image.c:1875
#2  0x001580c8 in R_FindImageFile (name=0x5edba8 "gfx/2d/bigchars.tga", mipmap=qfalse, allowPicmip=qfalse, glWrapClampMode=10497)
     at ../renderer/tr_image.c:1939
#3  0x00176cc8 in ParseStage (stage=0x6972b0, text=0xffbfe6f4) at ../renderer/tr_shader.c:640
#4  0x0017924c in ParseShader (text=0xffbfe6f4) at ../renderer/tr_shader.c:1441
#5  0x0017bb7c in R_FindShader (name=0x1a6830 "gfx/2d/bigchars", lightmapIndex=-4, mipRawImage=qtrue) at ../renderer/tr_shader.c:2487
#6  0x0017c54c in RE_RegisterShader (name=0x1a6830 "gfx/2d/bigchars") at ../renderer/tr_shader.c:2723
#7  0x0004c870 in CL_InitRenderer () at ../client/cl_main.c:2123
#8  0x0004c9a0 in CL_StartHunkUsers () at ../client/cl_main.c:2149
#9  0x00076ef0 in Com_Init (commandLine=0x9e6e98 "") at ../qcommon/common.c:2492
#10 0x0018c2dc in main (argc=1, argv=0xffbfee44) at ../unix/unix_main.c:1394

Any Ideas?

-- 
,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,
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 paszczus at gmail.com  Fri Oct 28 18:41:31 2005
From: paszczus at gmail.com (PaSzCzUs)
Date: Sat, 29 Oct 2005 00:41:31 +0200
Subject: [quake3] Re: Running q3ded on PPC
In-Reply-To: <20051028190704.54afdfe8.tim@ngus.net>
References: <daa0fb1e0510271404o66eee000y@mail.gmail.com>
	 <20051027221346.02796f81.tim@ngus.net>
	 <daa0fb1e0510280135k15c4f4f1w@mail.gmail.com>
	 <1130505187.11098.3.camel@klamath.syndrom23.de>
	 <daa0fb1e0510280830h20d18c9h@mail.gmail.com>
	 <20051028171532.25dc3a5a.tim@ngus.net>
	 <daa0fb1e0510280924n2a307b15t@mail.gmail.com>
	 <20051028175842.1b1f8a09.tim@ngus.net>
	 <daa0fb1e0510281010u68442b32o@mail.gmail.com>
	 <20051028190704.54afdfe8.tim@ngus.net>
Message-ID: <daa0fb1e0510281541t6917bbcbh@mail.gmail.com>

Well, the client is works fine, but dedicated server not...
The same problem is on sparc (32bit)
Tested on rev 191.

2005/10/28, Tim Angus <tim at ngus.net>:
> On Fri, 28 Oct 2005 19:10:34 +0200 PaSzCzUs wrote:
> > Q3 thinks this machine is big endian
>
> Well, I don't understand what your problem is then. The backtrace looks
> very much like the problem solved in revision 179. There is at least one
> person in the IRC channel that reports the client as working (albeit
> with some GL problems). Are you absolutely sure you're using the latest
> revision? Check out a clean copy to be certain.
>


From vincent at cojot.name  Fri Oct 28 19:04:12 2005
From: vincent at cojot.name (vincent at cojot.name)
Date: Sat, 29 Oct 2005 01:04:12 +0200 (CEST)
Subject: [quake3] Re: Running q3ded on PPC
In-Reply-To: <daa0fb1e0510280830h20d18c9h@mail.gmail.com>
References: <daa0fb1e0510271404o66eee000y@mail.gmail.com> 
 <20051027221346.02796f81.tim@ngus.net>  <daa0fb1e0510280135k15c4f4f1w@mail.gmail.com>
  <1130505187.11098.3.camel@klamath.syndrom23.de> <daa0fb1e0510280830h20d18c9h@mail.gmail.com>
Message-ID: <Pine.LNX.4.63.0510290101090.5762@thorbardin.lasthome.solace.krynn>

On Fri, 28 Oct 2005, PaSzCzUs wrote:

Just a quick message to mention that I'm getting exactly the same error 
on Solaris/Sparc (Maybe that means I'm getting closer.. :) )/

gdb /net/thorbardin/export/home/raistlin/code/quake3/code/unix/debugsparc/SunOSq3ded
GNU gdb 6.2.1
(gdb) set args +map q3dm17 +set ttycon 0
(gdb) r
Starting program: /net/thorbardin/export/home/raistlin/code/quake3/code/unix/debugsparc/SunOSq3ded +map q3dm17 +set ttycon 0
warning: Lowest section in /lib/libdl.so.1 is .dynamic at 00000094
ioQ3 1.33 Solaris-sparc Oct 29 2005
----- FS_Startup -----
Current search path:
/export/home/raistlin/.q3a/baseq3
/usr/local/share/games/quake3/baseq3/pak8.pk3 (9 files)
.....
--- Common Initialization Complete ---
Opening IP socket: localhost:27960
Hostname: ergoth
Alias: loghost
IP: 192.168.128.2
------ Server Initialization ------
Server: q3dm17
Hunk_Clear: reset the hunk ok
.....----------------------
8146 files in pk3 files
Loading vm file vm/qagame.qvm...
Architecture doesn't have a bytecode compiler, using interpreter

Program received signal SIGSEGV, Segmentation fault.
0x0007d4c8 in VM_PrepareInterpreter (vm=0x2903c8, header=0x4a6af58) at ../qcommon/vm_interpreted.c:208
208                             codeBase[pc+0] = loadWord(&code[pc]);
(gdb) bt
#0  0x0007d4c8 in VM_PrepareInterpreter (vm=0x2903c8, header=0x4a6af58) at ../qcommon/vm_interpreted.c:208
#1  0x0007c674 in VM_Create (module=0xe5b18 "qagame", systemCalls=0x2c848 <SV_GameSystemCalls>, interpret=VMI_BYTECODE) at ../qcommon/vm.c:597
#2  0x00031118 in SV_InitGameProgs () at ../server/sv_game.c:950
#3  0x000323f0 in SV_SpawnServer (server=0xffbfe2f0 "q3dm17", killBots=qfalse) at ../server/sv_init.c:435
#4  0x00029c50 in SV_Map_f () at ../server/sv_ccmds.c:189
#5  0x00052128 in Cmd_ExecuteString (text=0xffbfe470 "map q3dm17 ") at ../qcommon/cmd.c:645
#6  0x000514c0 in Cbuf_Execute () at ../qcommon/cmd.c:220
#7  0x000585ac in Com_Frame () at ../qcommon/common.c:2695
#8  0x000e1c84 in main (argc=6, argv=0xffbfee1c) at ../unix/unix_main.c:1411
(gdb)


Vincent


From tim at ngus.net  Fri Oct 28 19:05:51 2005
From: tim at ngus.net (Tim Angus)
Date: Sat, 29 Oct 2005 00:05:51 +0100
Subject: Questions about compile options (ioq3 on Solaris).
In-Reply-To: <Pine.LNX.4.63.0510290026580.5762@thorbardin.lasthome.solace.krynn>
References: <Pine.LNX.4.63.0510281511540.5762@thorbardin.lasthome.solace.krynn>
	<20051028153134.2eb515af.tim@ngus.net>
	<200510281947.11950.ludwig.nussel@suse.de>
	<20051028212842.46e5a687.tim@ngus.net>
	<1130534734.4362974eaca5f@mail.icculus.org>
	<Pine.LNX.4.63.0510282341030.5762@thorbardin.lasthome.solace.krynn>
	<20051028232149.3e54986a.tim@ngus.net>
	<Pine.LNX.4.63.0510290026580.5762@thorbardin.lasthome.solace.krynn>
Message-ID: <20051029000551.2e964077.tim@ngus.net>

On Sat, 29 Oct 2005 00:28:38 +0200 (CEST) vincent at cojot.name wrote:
> You mean I shouldn't do this in tools/lcc/etc/gcc-solaris.c:
> 
> char *com[] = { LCCDIR "q3rcc", "-target=bytecode", "$1", "$2", "$3",
> 0 };
> 
> Should I go back to -target=solaris/sparc (or something similar)?

-target=bytecode is correct, but potentially other bits of gcc-solaris.c
aren't. Think of linux.c as generic.c. The bits specifying platform
specfic linkers and whatnot aren't used when compiling to bytecode.


From tim at ngus.net  Fri Oct 28 19:08:52 2005
From: tim at ngus.net (Tim Angus)
Date: Sat, 29 Oct 2005 00:08:52 +0100
Subject: Running q3ded on PPC
In-Reply-To: <daa0fb1e0510281541t6917bbcbh@mail.gmail.com>
References: <daa0fb1e0510271404o66eee000y@mail.gmail.com>
	<20051027221346.02796f81.tim@ngus.net>
	<daa0fb1e0510280135k15c4f4f1w@mail.gmail.com>
	<1130505187.11098.3.camel@klamath.syndrom23.de>
	<daa0fb1e0510280830h20d18c9h@mail.gmail.com>
	<20051028171532.25dc3a5a.tim@ngus.net>
	<daa0fb1e0510280924n2a307b15t@mail.gmail.com>
	<20051028175842.1b1f8a09.tim@ngus.net>
	<daa0fb1e0510281010u68442b32o@mail.gmail.com>
	<20051028190704.54afdfe8.tim@ngus.net>
	<daa0fb1e0510281541t6917bbcbh@mail.gmail.com>
Message-ID: <20051029000852.37ddf8f2.tim@ngus.net>

On Sat, 29 Oct 2005 00:41:31 +0200 PaSzCzUs wrote:
> Well, the client is works fine, but dedicated server not...
> The same problem is on sparc (32bit)
> Tested on rev 191.

Hmm, that is curious since the place it is crashing is used in both the
client and the server. Evidently the server is somehow doing something
different. I'll maybe use this as an excuse to try qemu -- any ppc
distro recommendations?


From ludwig.nussel at suse.de  Sat Oct 29 08:18:44 2005
From: ludwig.nussel at suse.de (Ludwig Nussel)
Date: Sat, 29 Oct 2005 14:18:44 +0200
Subject: [quake3] Re: Running q3ded on PPC
In-Reply-To: <daa0fb1e0510281541t6917bbcbh@mail.gmail.com>
References: <daa0fb1e0510271404o66eee000y@mail.gmail.com> <20051028190704.54afdfe8.tim@ngus.net> <daa0fb1e0510281541t6917bbcbh@mail.gmail.com>
Message-ID: <200510291418.44886.ludwig.nussel@suse.de>

PaSzCzUs wrote:
> Well, the client is works fine, but dedicated server not...
> The same problem is on sparc (32bit)

Hmm...
- both are big endian
- the dedicated server is probably for historical reasons compiled
  with -DC_ONLY
- idppc is only defined if !C_ONLY

try this:

Index: code/qcommon/vm_interpreted.c
===================================================================
--- code/qcommon/vm_interpreted.c	(Revision 192)
+++ code/qcommon/vm_interpreted.c	(Arbeitskopie)
@@ -124,7 +124,7 @@
 	#define loadWord(addr) __lwbrx(addr,0)
     #endif
 #else
-	#define	loadWord(addr) *((int *)addr)
+	#define	loadWord(addr) LittleLong(*((int *)addr))
 #endif
 
 char *VM_Indent( vm_t *vm ) {


cu
Ludwig

-- 
 (o_   Ludwig Nussel
 //\   SUSE LINUX Products GmbH, Development
 V_/_  http://www.suse.de/




From ludwig.nussel at suse.de  Sat Oct 29 08:38:18 2005
From: ludwig.nussel at suse.de (Ludwig Nussel)
Date: Sat, 29 Oct 2005 14:38:18 +0200
Subject: q3asm miscompilation
Message-ID: <200510291438.18386.ludwig.nussel@suse.de>

Hi,

The attached program miscompiles with q3asm. The syscall trap_Print
has number -1, the argument in the qvm however is 3 (look for 21 08
(OP_ARG 8) followed by 08 .. .. .. .. (OP_CONST) in the hex dump).
The offset seems to be constant. Ie if you use -2 it passed 2
instead. In larger programs it works though.

cu
Ludwig

-- 
 (o_   Ludwig Nussel
 //\   SUSE LINUX Products GmbH, Development
 V_/_  http://www.suse.de/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: miscompile.tar.gz
Type: application/x-tgz
Size: 668 bytes
Desc: not available
URL: <http://icculus.org/pipermail/quake3/attachments/20051029/4c2e4fc9/attachment.bin>

From ludwig.nussel at suse.de  Sat Oct 29 08:49:56 2005
From: ludwig.nussel at suse.de (Ludwig Nussel)
Date: Sat, 29 Oct 2005 14:49:56 +0200
Subject: [quake3] q3asm miscompilation
In-Reply-To: <200510291438.18386.ludwig.nussel@suse.de>
References: <200510291438.18386.ludwig.nussel@suse.de>
Message-ID: <200510291449.57025.ludwig.nussel@suse.de>

Ludwig Nussel wrote:
> The attached program miscompiles with q3asm. The syscall trap_Print
> has number -1, the argument in the qvm however is 3 (look for 21 08
> (OP_ARG 8) followed by 08 .. .. .. .. (OP_CONST) in the hex dump).
> The offset seems to be constant. Ie if you use -2 it passed 2
> instead. In larger programs it works though.

works:

static const char buf[] = "hello world\n";
int vmMain()
{
	return trap_Print(buf);
}

doesn't:

static const char* buf = "hello world\n";
int vmMain()
{
	return trap_Print(buf);
}

cu
Ludwig

-- 
 (o_   Ludwig Nussel
 //\   SUSE LINUX Products GmbH, Development
 V_/_  http://www.suse.de/



From tim at ngus.net  Sat Oct 29 18:08:02 2005
From: tim at ngus.net (Tim Angus)
Date: Sat, 29 Oct 2005 23:08:02 +0100
Subject: Running q3ded on PPC
In-Reply-To: <200510291418.44886.ludwig.nussel@suse.de>
References: <daa0fb1e0510271404o66eee000y@mail.gmail.com>
	<20051028190704.54afdfe8.tim@ngus.net>
	<daa0fb1e0510281541t6917bbcbh@mail.gmail.com>
	<200510291418.44886.ludwig.nussel@suse.de>
Message-ID: <20051029230802.36b7f1bb.tim@ngus.net>

On Sat, 29 Oct 2005 14:18:44 +0200 Ludwig wrote:
> - the dedicated server is probably for historical reasons compiled
>   with -DC_ONLY

This does seem rather odd. Can anybody think of a good reason why we
should be using C_ONLY for the dedicated server?

> -	#define	loadWord(addr) *((int *)addr)
> +	#define	loadWord(addr) LittleLong(*((int *)addr))

So I applied this, as it apparently fixes the problem. Nice catch :).


From paszczus at gmail.com  Sun Oct 30 06:23:27 2005
From: paszczus at gmail.com (PaSzCzUs)
Date: Sun, 30 Oct 2005 12:23:27 +0100
Subject: [quake3] Re: Running q3ded on PPC
In-Reply-To: <200510291418.44886.ludwig.nussel@suse.de>
References: <daa0fb1e0510271404o66eee000y@mail.gmail.com>
	 <20051028190704.54afdfe8.tim@ngus.net>
	 <daa0fb1e0510281541t6917bbcbh@mail.gmail.com>
	 <200510291418.44886.ludwig.nussel@suse.de>
Message-ID: <daa0fb1e0510300323v75e24c5x@mail.gmail.com>

> try this:
[...]

> --- code/qcommon/vm_interpreted.c       (Revision 192)
[...]

I`ve tried 201 revision and now it won`t build:

ease-ppc-linux/ded/unix_net.o release-ppc-linux/ded/unix_shared.o
release-ppc-linux/ded/null_client.o release-ppc-linux/ded/null_input.o
release-ppc-linux/ded/null_snddma.o -ldl -lm
release-ppc-linux/ded/vm.o(.text+0xcf4): In function `VM_Create':
vm.c: undefined reference to `VM_Compile'
release-ppc-linux/ded/vm.o(.text+0x12a0): In function `VM_Call':
vm.c: undefined reference to `VM_CallCompiled'
collect2: ld returned 1 exit status
make: *** [release-ppc-linux/linuxq3ded] Error 1
make: *** Waiting for unfinished jobs....
release-ppc-linux/client/vm.o(.text+0xcf4): In function `VM_Create':
vm.c: undefined reference to `VM_Compile'
release-ppc-linux/client/vm.o(.text+0x12a0): In function `VM_Call':
vm.c: undefined reference to `VM_CallCompiled'
collect2: ld returned 1 exit status
make: *** [release-ppc-linux/linuxquake3] Error 1
make: Leaving directory
`/home/users/builder/rpm/BUILD/quake3-1.33_SVN201/code/unix'

Something broken by my side or yours ?


From andreas at syndrom23.de  Sun Oct 30 07:48:00 2005
From: andreas at syndrom23.de (Andreas Kohn)
Date: Sun, 30 Oct 2005 13:48:00 +0100
Subject: BUG 2464: Polish copyfiles target
Message-ID: <1130676480.1022.1.camel@klamath.syndrom23.de>

Hi,

please have a look at 2464.

https://bugzilla.icculus.org/show_bug.cgi?id=2464

--
Andreas

-- 
<TalisA> was macht man eigentlich auf einer linux-gamer lan ? hl server
aufsetzen und freuen ? *duck* ^^
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
URL: <http://icculus.org/pipermail/quake3/attachments/20051030/8f842900/attachment.pgp>

From darksharkster at gmail.com  Mon Oct 31 05:59:51 2005
From: darksharkster at gmail.com (darkshark atnight)
Date: Mon, 31 Oct 2005 10:59:51 +0000
Subject: quake3 on Solaris x86
Message-ID: <cbc7a72e0510310259r7885e29p741f3b1241b0d28d@mail.gmail.com>

Hi folks,
  I'm trying to get quake3 on solaris x86, specifically running on
SolarisExpress.  Everything
  compiles, but then running it fails to start OpenGL.  It seems that
the the qgl* function
  pointers aren't pointing to the correct addresses of the gl* functions.

 Some details:
    OpenGL version is Mesa (io quake2 compiles and runs on same system).
    Using the quake2 source base as a reference, since theres a lot of
common code there.
    I've got solaris_qgl.c and solaris_glimp.c done, which are really
linux_*.c with a bunch
    of #def's.

 More details at:
   http://blogs.sun.com/roller/page/smg?entry=getting_there_with_quake3_on

  I'm trying to get this port done on x86 platform.  Will be using the
  nVidia opengl drivers later on another box, once I get these problems sorted.

   Any help would really
 be appreciated.
Regards,
Sean.
.


From vincent at cojot.name  Mon Oct 31 06:08:31 2005
From: vincent at cojot.name (vincent at cojot.name)
Date: Mon, 31 Oct 2005 12:08:31 +0100 (CET)
Subject: [quake3] quake3 on Solaris x86
In-Reply-To: <cbc7a72e0510310259r7885e29p741f3b1241b0d28d@mail.gmail.com>
References: <cbc7a72e0510310259r7885e29p741f3b1241b0d28d@mail.gmail.com>
Message-ID: <Pine.LNX.4.63.0510311204490.5762@thorbardin.lasthome.solace.krynn>


Hello Sean,

Do you know what SVN revision of quake3 you are working on? I'm also 
working on bringing Solaris support to q3 and several changes have already 
gone into ioq3. When you say that 'everytying' compiles.. Does that 
include the VM stuff? Have you already made some changes to the sources? 
Make sure you're using a very recent SVN checkout...

For the record, the solaris_qgl.c and solaris_glimp.c from ioq2 originally 
came from the SUN Quake2 porting team and I kept trying to adapt/maintain 
them in ioq2.

I'll go check the URL you posted now...

Vincent

On Mon, 31 Oct 2005, darkshark atnight wrote:

> Hi folks,
>  I'm trying to get quake3 on solaris x86, specifically running on
> SolarisExpress.  Everything
>  compiles, but then running it fails to start OpenGL.  It seems that
> the the qgl* function
>  pointers aren't pointing to the correct addresses of the gl* functions.
>
> Some details:
>    OpenGL version is Mesa (io quake2 compiles and runs on same system).
>    Using the quake2 source base as a reference, since theres a lot of
> common code there.
>    I've got solaris_qgl.c and solaris_glimp.c done, which are really
> linux_*.c with a bunch
>    of #def's.
>
> More details at:
>   http://blogs.sun.com/roller/page/smg?entry=getting_there_with_quake3_on
>
>  I'm trying to get this port done on x86 platform.  Will be using the
>  nVidia opengl drivers later on another box, once I get these problems sorted.
>
>   Any help would really
> be appreciated.
> Regards,
> Sean.
> .


From darksharkster at gmail.com  Mon Oct 31 06:27:59 2005
From: darksharkster at gmail.com (darkshark atnight)
Date: Mon, 31 Oct 2005 11:27:59 +0000
Subject: [quake3] quake3 on Solaris x86
In-Reply-To: <Pine.LNX.4.63.0510311204490.5762@thorbardin.lasthome.solace.krynn>
References: <cbc7a72e0510310259r7885e29p741f3b1241b0d28d@mail.gmail.com>
	 <Pine.LNX.4.63.0510311204490.5762@thorbardin.lasthome.solace.krynn>
Message-ID: <cbc7a72e0510310327s53f60817jd1568c5e84863b19@mail.gmail.com>

On 10/31/05, vincent at cojot.name <vincent at cojot.name> wrote:
>
> Hello Sean,
>
> Do you know what SVN revision of quake3 you are working on? I'm also
> working on bringing Solaris support to q3 and several changes have already

  Are you sparc based though ?  I can do either, but me laptop is
running solaris so
  I'm trying for an x86 port.  I'd like to help in the sparc bits too
though.  Have access
  to some sparc U80's.

> gone into ioq3. When you say that 'everytying' compiles.. Does that
> include the VM stuff? Have you already made some changes to the sources?

  You mean the vm_86.c ?  It compiles and links.
  I have some changes to the sources - though its mainly adding __sun__ to
  ifdef's  I'm trying not to change the actual code in most places.

> Make sure you're using a very recent SVN checkout...

  Will do.  I'm using rev 177 which is a tad old now.

  I'll pull down the newer rev and try with that.

>
> For the record, the solaris_qgl.c and solaris_glimp.c from ioq2 originally
> came from the SUN Quake2 porting team and I kept trying to adapt/maintain
> them in ioq2.

  Ya, read the code comments :)  I'm going to ping some Sun opengl
people about this
  sometime this week.

>
> I'll go check the URL you posted now...
>
   Thanks !.

Sean.
.
> Vincent
>
> On Mon, 31 Oct 2005, darkshark atnight wrote:
>
> > Hi folks,
> >  I'm trying to get quake3 on solaris x86, specifically running on
> > SolarisExpress.  Everything
> >  compiles, but then running it fails to start OpenGL.  It seems that
> > the the qgl* function
> >  pointers aren't pointing to the correct addresses of the gl* functions.
> >
> > Some details:
> >    OpenGL version is Mesa (io quake2 compiles and runs on same system).
> >    Using the quake2 source base as a reference, since theres a lot of
> > common code there.
> >    I've got solaris_qgl.c and solaris_glimp.c done, which are really
> > linux_*.c with a bunch
> >    of #def's.
> >
> > More details at:
> >   http://blogs.sun.com/roller/page/smg?entry=getting_there_with_quake3_on
> >
> >  I'm trying to get this port done on x86 platform.  Will be using the
> >  nVidia opengl drivers later on another box, once I get these problems sorted.
> >
> >   Any help would really
> > be appreciated.
> > Regards,
> > Sean.
> > .
>


From vincent at cojot.name  Mon Oct 31 09:21:40 2005
From: vincent at cojot.name (vincent at cojot.name)
Date: Mon, 31 Oct 2005 15:21:40 +0100 (CET)
Subject: [quake3] quake3 on Solaris x86
In-Reply-To: <cbc7a72e0510310327s53f60817jd1568c5e84863b19@mail.gmail.com>
References: <cbc7a72e0510310259r7885e29p741f3b1241b0d28d@mail.gmail.com> 
 <Pine.LNX.4.63.0510311204490.5762@thorbardin.lasthome.solace.krynn>
 <cbc7a72e0510310327s53f60817jd1568c5e84863b19@mail.gmail.com>
Message-ID: <Pine.LNX.4.63.0510311514260.5762@thorbardin.lasthome.solace.krynn>

On Mon, 31 Oct 2005, darkshark atnight wrote:

>  Are you sparc based though ?  I can do either, but me laptop is running 
> solaris so I'm trying for an x86 port.  I'd like to help in the sparc 
> bits too though.  Have access to some sparc U80's.

I'm mostly sparc based but I am trying to keep my bits arch-neutral. If 
you have a working NVidia + Solaris setup, that's interesting as you will 
be able to test the bits I won't (I don't have a PC with NVidia graphics 
running Solaris at this time, they all run Linux).

>  You mean the vm_86.c ?  It compiles and links.
>  I have some changes to the sources - though its mainly adding __sun__ to
>  ifdef's  I'm trying not to change the actual code in most places.

Ok, check the recent checkouts, you shouldn't need to add any new #ifdef.. 
Tell me if I broke something.. I'm having a lot of trouble with LCC on 
sparc at this time so if it works fine on i386, that's a good sign.
Oh and btw, I thought it was recommended by SUN to use "__sun", not "__sun__".


>> For the record, the solaris_qgl.c and solaris_glimp.c from ioq2 originally
>> came from the SUN Quake2 porting team and I kept trying to adapt/maintain
>> them in ioq2.
>
>  Ya, read the code comments :)  I'm going to ping some Sun opengl
> people about this sometime this week.

That'd be great to have them on-board.. I have both an sb2k+XVR-1000 and 
an sb150+XVR-600 but any other coder/debugger/tester will be welcomed.. :)

Regards,

Vincent


From tim at ngus.net  Mon Oct 31 09:32:22 2005
From: tim at ngus.net (Tim Angus)
Date: Mon, 31 Oct 2005 14:32:22 +0000
Subject: quake3 on Solaris x86
In-Reply-To: <Pine.LNX.4.63.0510311514260.5762@thorbardin.lasthome.solace.krynn>
References: <cbc7a72e0510310259r7885e29p741f3b1241b0d28d@mail.gmail.com>
	<Pine.LNX.4.63.0510311204490.5762@thorbardin.lasthome.solace.krynn>
	<cbc7a72e0510310327s53f60817jd1568c5e84863b19@mail.gmail.com>
	<Pine.LNX.4.63.0510311514260.5762@thorbardin.lasthome.solace.krynn>
Message-ID: <20051031143222.58d7867c.tim@ngus.net>

On Mon, 31 Oct 2005 15:21:40 +0100 (CET) vincent at cojot.name wrote:
> Tell me if I broke something.. I'm having a lot of trouble with LCC on
> 
> sparc at this time so if it works fine on i386, that's a good sign.

Have you tried using etc/linux.c as the HOSTFILE? I know this sounds
wrong, but it should be used on every platform.


From vincent at cojot.name  Mon Oct 31 09:47:47 2005
From: vincent at cojot.name (vincent at cojot.name)
Date: Mon, 31 Oct 2005 15:47:47 +0100 (CET)
Subject: [quake3] Re: quake3 on Solaris x86
In-Reply-To: <20051031143222.58d7867c.tim@ngus.net>
References: <cbc7a72e0510310259r7885e29p741f3b1241b0d28d@mail.gmail.com>
 <Pine.LNX.4.63.0510311204490.5762@thorbardin.lasthome.solace.krynn>
 <cbc7a72e0510310327s53f60817jd1568c5e84863b19@mail.gmail.com>
 <Pine.LNX.4.63.0510311514260.5762@thorbardin.lasthome.solace.krynn>
 <20051031143222.58d7867c.tim@ngus.net>
Message-ID: <Pine.LNX.4.63.0510311545250.5762@thorbardin.lasthome.solace.krynn>

On Mon, 31 Oct 2005, Tim Angus wrote:

> Have you tried using etc/linux.c as the HOSTFILE? I know this sounds
> wrong, but it should be used on every platform.

Let me try that. At any case, we may need to change some stuff under 
code/tools/lcc because:
1) Only q3lcc gets rebuilt (not q3cpp et al.) which means 
binary-incompatible version might be laying around.

-- 
,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,
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  Mon Oct 31 09:54:38 2005
From: vincent at cojot.name (vincent at cojot.name)
Date: Mon, 31 Oct 2005 15:54:38 +0100 (CET)
Subject: [quake3] Re: quake3 on Solaris x86
In-Reply-To: <20051031143222.58d7867c.tim@ngus.net>
References: <cbc7a72e0510310259r7885e29p741f3b1241b0d28d@mail.gmail.com>
 <Pine.LNX.4.63.0510311204490.5762@thorbardin.lasthome.solace.krynn>
 <cbc7a72e0510310327s53f60817jd1568c5e84863b19@mail.gmail.com>
 <Pine.LNX.4.63.0510311514260.5762@thorbardin.lasthome.solace.krynn>
 <20051031143222.58d7867c.tim@ngus.net>
Message-ID: <Pine.LNX.4.63.0510311551410.5762@thorbardin.lasthome.solace.krynn>

On Mon, 31 Oct 2005, Tim Angus wrote:

> On Mon, 31 Oct 2005 15:21:40 +0100 (CET) vincent at cojot.name wrote:
>> Tell me if I broke something.. I'm having a lot of trouble with LCC on
>>
>> sparc at this time so if it works fine on i386, that's a good sign.
>
> Have you tried using etc/linux.c as the HOSTFILE? I know this sounds
> wrong, but it should be used on every platform.

Tim,

You were right!!! :) Copying code/tools/lcc/etc/linux.c to 
code/tools/lcc/etc/gcc-solaris.c made it work. I will be keeping a 
separate HOSTFILE, just in case but it got *much* farther that way and 
compiled all the way though. Thanks for requesting (again) that I use the 
Linux HOSTFILE.. I'll be sending you a patch soon (it should also "make 
all + make clean" in both code/tools/lcc and code/tools/asm)

Thanks again,

-- 
,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,
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  Mon Oct 31 10:41:56 2005
From: vincent at cojot.name (vincent at cojot.name)
Date: Mon, 31 Oct 2005 16:41:56 +0100 (CET)
Subject: [quake3] Re: quake3 on Solaris x86
In-Reply-To: <20051031143222.58d7867c.tim@ngus.net>
References: <cbc7a72e0510310259r7885e29p741f3b1241b0d28d@mail.gmail.com>
 <Pine.LNX.4.63.0510311204490.5762@thorbardin.lasthome.solace.krynn>
 <cbc7a72e0510310327s53f60817jd1568c5e84863b19@mail.gmail.com>
 <Pine.LNX.4.63.0510311514260.5762@thorbardin.lasthome.solace.krynn>
 <20051031143222.58d7867c.tim@ngus.net>
Message-ID: <Pine.LNX.4.63.0510311635450.5762@thorbardin.lasthome.solace.krynn>


Tim,

Could you please commit this patch? It changes the following items:

- Makes lcc work on Solaris
(gcc-solaris.c is a copy of linux.c at this time but will evolve).

- Changes install/mkdir with $(INSTALL)/$(MKDIR)
(Solaris mkdir/install does not accept GNU fileutils args).

- Removes snd_mixa.s and matha.s from the SunOS port for Solaris/Sparc.

I'm glad this lcc stuff is over.. :)

PS: Don't drop the IRIX port/comments just yet, it's still on target for 
me but the Solaris port gets done first.. :) I'm trying to get in touch 
with the friends at sgi to see if they have any copy left of their old 
diffs..

Regards,

-- 
,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,
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

-------------- next part --------------
Index: code/unix/Makefile
===================================================================
--- code/unix/Makefile	(revision 203)
+++ code/unix/Makefile	(working copy)
@@ -85,6 +85,10 @@
 VM_PPC=
 
 LIB=lib
+
+INSTALL=install
+MKDIR=mkdir
+
 ifeq ($(PLATFORM),linux)
 
   GLIBC=-glibc
@@ -360,6 +364,8 @@
   GLIBC= #libc is irrelevant
   CC=gcc
   CXX=g++
+  INSTALL=ginstall
+  MKDIR=gmkdir
   COPYDIR="/usr/local/share/games/quake3"
 
   ifneq (,$(findstring i86pc,$(shell uname -m)))
@@ -528,23 +534,23 @@
 targets: $(TARGETS)
 
 makedirs:
-	@if [ ! -d $(B) ];then mkdir $(B);fi
-	@if [ ! -d $(B)/client ];then mkdir $(B)/client;fi
-	@if [ ! -d $(B)/ded ];then mkdir $(B)/ded;fi
-	@if [ ! -d $(B)/ref ];then mkdir $(B)/ref;fi
-	@if [ ! -d $(B)/baseq3 ];then mkdir $(B)/baseq3;fi
-	@if [ ! -d $(B)/baseq3/cgame ];then mkdir $(B)/baseq3/cgame;fi
-	@if [ ! -d $(B)/baseq3/game ];then mkdir $(B)/baseq3/game;fi
-	@if [ ! -d $(B)/baseq3/ui ];then mkdir $(B)/baseq3/ui;fi
-	@if [ ! -d $(B)/baseq3/qcommon ];then mkdir $(B)/baseq3/qcommon;fi
-	@if [ ! -d $(B)/baseq3/vm ];then mkdir $(B)/baseq3/vm;fi
-	@if [ ! -d $(B)/missionpack ];then mkdir $(B)/missionpack;fi
-	@if [ ! -d $(B)/missionpack/cgame ];then mkdir $(B)/missionpack/cgame;fi
-	@if [ ! -d $(B)/missionpack/game ];then mkdir $(B)/missionpack/game;fi
-	@if [ ! -d $(B)/missionpack/ui ];then mkdir $(B)/missionpack/ui;fi
-	@if [ ! -d $(B)/missionpack/qcommon ];then mkdir $(B)/missionpack/qcommon;fi
-	@if [ ! -d $(B)/missionpack/vm ];then mkdir $(B)/missionpack/vm;fi
-	@if [ ! -d $(B)/q3static ];then mkdir $(B)/q3static;fi
+	@if [ ! -d $(B) ];then $(MKDIR) $(B);fi
+	@if [ ! -d $(B)/client ];then $(MKDIR) $(B)/client;fi
+	@if [ ! -d $(B)/ded ];then $(MKDIR) $(B)/ded;fi
+	@if [ ! -d $(B)/ref ];then $(MKDIR) $(B)/ref;fi
+	@if [ ! -d $(B)/baseq3 ];then $(MKDIR) $(B)/baseq3;fi
+	@if [ ! -d $(B)/baseq3/cgame ];then $(MKDIR) $(B)/baseq3/cgame;fi
+	@if [ ! -d $(B)/baseq3/game ];then $(MKDIR) $(B)/baseq3/game;fi
+	@if [ ! -d $(B)/baseq3/ui ];then $(MKDIR) $(B)/baseq3/ui;fi
+	@if [ ! -d $(B)/baseq3/qcommon ];then $(MKDIR) $(B)/baseq3/qcommon;fi
+	@if [ ! -d $(B)/baseq3/vm ];then $(MKDIR) $(B)/baseq3/vm;fi
+	@if [ ! -d $(B)/missionpack ];then $(MKDIR) $(B)/missionpack;fi
+	@if [ ! -d $(B)/missionpack/cgame ];then $(MKDIR) $(B)/missionpack/cgame;fi
+	@if [ ! -d $(B)/missionpack/game ];then $(MKDIR) $(B)/missionpack/game;fi
+	@if [ ! -d $(B)/missionpack/ui ];then $(MKDIR) $(B)/missionpack/ui;fi
+	@if [ ! -d $(B)/missionpack/qcommon ];then $(MKDIR) $(B)/missionpack/qcommon;fi
+	@if [ ! -d $(B)/missionpack/vm ];then $(MKDIR) $(B)/missionpack/vm;fi
+	@if [ ! -d $(B)/q3static ];then $(MKDIR) $(B)/q3static;fi
 
 #############################################################################
 # QVM BUILD TOOLS
@@ -823,9 +829,7 @@
     $(B)/client/linux_qgl.o \
     $(B)/client/linux_glimp.o \
     $(B)/client/linux_snd.o \
-    $(B)/client/sdl_snd.o \
-    $(B)/client/snd_mixa.o \
-    $(B)/client/matha.o \
+    $(B)/client/sdl_snd.o
 
   Q3POBJ_SMP=\
     $(B)/client/unix_main.o \
@@ -836,12 +840,10 @@
     $(B)/client/linux_qgl.o \
     $(B)/client/linux_glimp_smp.o \
     $(B)/client/linux_snd.o \
-    $(B)/client/sdl_snd.o \
-    $(B)/client/snd_mixa.o \
-    $(B)/client/matha.o
+    $(B)/client/sdl_snd.o
 
   ifeq ($(ARCH),i386)
-    Q3POBJ += $(B)/client/ftola.o $(B)/client/snapvectora.o
+    Q3POBJ += $(B)/client/ftola.o $(B)/client/snapvectora.o $(B)/client/snd_mixa.o $(B)/client/matha.o
     Q3POBJ_SMP += $(B)/client/ftola.o $(B)/client/snapvectora.o
   endif
 
@@ -1532,22 +1534,22 @@
 
 copyfiles: build_release
 	@if [ ! -d $(COPYDIR)/baseq3 ]; then echo "You need to set COPYDIR to where you installed Quake III!"; false; fi
-	install -s -m 0755 $(BR)/$(PLATFORM)quake3$(BINEXT) $(COPYDIR)/quake3
-	#install -s -m 0755 $(BR)/$(PLATFORM)quake3-smp$(BINEXT) $(COPYDIR)/quake3-smp
-	install -s -m 0755 $(BR)/$(PLATFORM)q3ded$(BINEXT) $(COPYDIR)/q3ded
-	-mkdir -p -m 0755 $(COPYDIR)/baseq3
-	install -s -m 0755 $(BR)/baseq3/cgame$(ARCH).$(SHLIBEXT) \
+	$(INSTALL) -s -m 0755 $(BR)/$(PLATFORM)quake3$(BINEXT) $(COPYDIR)/quake3
+	#$(INSTALL) -s -m 0755 $(BR)/$(PLATFORM)quake3-smp$(BINEXT) $(COPYDIR)/quake3-smp
+	$(INSTALL) -s -m 0755 $(BR)/$(PLATFORM)q3ded$(BINEXT) $(COPYDIR)/q3ded
+	-$(MKDIR) -p -m 0755 $(COPYDIR)/baseq3
+	$(INSTALL) -s -m 0755 $(BR)/baseq3/cgame$(ARCH).$(SHLIBEXT) \
 					$(COPYDIR)/baseq3/.
-	install -s -m 0755 $(BR)/baseq3/qagame$(ARCH).$(SHLIBEXT) \
+	$(INSTALL) -s -m 0755 $(BR)/baseq3/qagame$(ARCH).$(SHLIBEXT) \
 					$(COPYDIR)/baseq3/.
-	install -s -m 0755 $(BR)/baseq3/ui$(ARCH).$(SHLIBEXT) \
+	$(INSTALL) -s -m 0755 $(BR)/baseq3/ui$(ARCH).$(SHLIBEXT) \
 					$(COPYDIR)/baseq3/.
-	-mkdir -p -m 0755 $(COPYDIR)/missionpack
-	install -s -m 0755 $(BR)/missionpack/cgame$(ARCH).$(SHLIBEXT) \
+	-$(MKDIR) -p -m 0755 $(COPYDIR)/missionpack
+	$(INSTALL) -s -m 0755 $(BR)/missionpack/cgame$(ARCH).$(SHLIBEXT) \
 					$(COPYDIR)/missionpack/.
-	install -s -m 0755 $(BR)/missionpack/qagame$(ARCH).$(SHLIBEXT) \
+	$(INSTALL) -s -m 0755 $(BR)/missionpack/qagame$(ARCH).$(SHLIBEXT) \
 					$(COPYDIR)/missionpack/.
-	install -s -m 0755 $(BR)/missionpack/ui$(ARCH).$(SHLIBEXT) \
+	$(INSTALL) -s -m 0755 $(BR)/missionpack/ui$(ARCH).$(SHLIBEXT) \
 					$(COPYDIR)/missionpack/.
 
 clean:clean-debug clean-release
Index: code/tools/lcc/etc/gcc-solaris.c
===================================================================
--- code/tools/lcc/etc/gcc-solaris.c	(revision 203)
+++ code/tools/lcc/etc/gcc-solaris.c	(working copy)
@@ -1,4 +1,4 @@
-/* Solaris 10 sparc */
+/* x86s running Linux */
 
 #include <string.h>
 
@@ -9,49 +9,70 @@
 removed __linux__ preprocessor define (confuses the preprocessor, we are doing bytecode!)
 */
 
-
 #ifndef LCCDIR
 #define LCCDIR ""
+//#define LCCDIR "/usr/local/lib/lcc/"
 #endif
-#ifndef GCCDIR
-#define GCCDIR "/usr/sfw/bin/"
+
+#ifdef _WIN32
+#define BINEXT ".exe"
+#else
+#define BINEXT ""
 #endif
-#ifndef GCCLIB
-#define GCCLIB "/usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/"
-#endif
-#define BINEXT ""
 
-char *suffixes[] = { ".c", ".i", ".asm", ".s", ".o", ".out", 0 };
+char *suffixes[] = { ".c", ".i", ".asm", ".o", ".out", 0 };
 char inputs[256] = "";
+// TTimo experimental: do not compile with the __linux__ define, we are doing bytecode!
 char *cpp[] = { LCCDIR "q3cpp" BINEXT,
-	"-D__STDC__=1", "-Dsparc", "-D__sparc__", "-Dsun", "-D__sun__", "-Dunix", "-D__sun",
+	"-U__GNUC__", "-D_POSIX_SOURCE", "-D__STDC__=1", "-D__STRICT_ANSI__",
+	"-Dunix", "-Di386", "-Dlinux",
+	"-D__unix__", "-D__i386__", "-D__signed__=signed",
 	"$1", "$2", "$3", 0 };
-char *include[] = { "-I" LCCDIR "include", "-I" LCCDIR "gcc/include",
-	"-I" SYSTEM "include", "-I/usr/include", 0 };
-/* char *com[] = { LCCDIR "q3rcc", "-target=bytecode", "$1", "$2", "$3", 0 }; */
-char *com[] = { LCCDIR "q3rcc", "-target=sparc/solaris", "$1", "$2", "$3", 0 };
-char *as[] = { "/usr/ccs/bin/as", "-o", "$3", "$1", "$2", 0 };
-char *ld[] = { "/usr/ccs/bin/ld", "-o", "$3", "$1",
-        GCCLIB "crti.o", GCCLIB "crt1.o",
-        GCCLIB "crtbegin.o", "$2", "", "", "-L" LCCDIR, "-llcc",
-        "-L" GCCLIB, "-lgcc", "-lm", "-lc", "",
-        GCCLIB "crtend.o", GCCLIB "crtn.o", 0 };
+char *include[] = {"-I" LCCDIR "include", "-I" LCCDIR "gcc/include", "-I/usr/include",
+		   "-I" SYSTEM "include", 0 };
+char *com[] = {LCCDIR "q3rcc" BINEXT, "-target=bytecode", "$1", "$2", "$3", 0 };
+char *as[] = { "/usr/bin/as", "-o", "$3", "$1", "$2", 0 };
+// NOTE TTimo I don't think we have any use with the native linkage
+// our target is always bytecode..
+char *ld[] = {
+	/*  0 */ "/usr/ccs/bin/ld", "-m", "elf_i386", "-dynamic-linker",
+	/*  4 */ "/lib/ld-linux.so.2", "-o", "$3",
+	/*  7 */ "/usr/lib/crt1.o", "/usr/lib/crti.o",
+	/*  9 */ SYSTEM "crtbegin.o", 
+                 "$1", "$2",
+	/* 12 */ "-L" LCCDIR,
+	/* 13 */ "-llcc",
+	/* 14 */ "-L" LCCDIR "/gcc", "-lgcc", "-lc", "-lm",
+	/* 18 */ "",
+	/* 19 */ SYSTEM "crtend.o", "/usr/lib/crtn.o",
+	/* 20 */ "-L" SYSTEM,
+	0 };
 
 extern char *concat(char *, char *);
 
 int option(char *arg) {
-	if (strncmp(arg, "-lccdir=", 8) == 0) {
+  	if (strncmp(arg, "-lccdir=", 8) == 0) {
 		cpp[0] = concat(&arg[8], "/gcc/cpp");
 		include[0] = concat("-I", concat(&arg[8], "/include"));
-		ld[10] = concat("-L", &arg[8]);
+		include[1] = concat("-I", concat(&arg[8], "/gcc/include"));
+		ld[9]  = concat(&arg[8], "/gcc/crtbegin.o");
+		ld[12] = concat("-L", &arg[8]);
+		ld[14] = concat("-L", concat(&arg[8], "/gcc"));
+		ld[19] = concat(&arg[8], "/gcc/crtend.o");
 		com[0] = concat(&arg[8], "/rcc");
 	} else if (strcmp(arg, "-p") == 0 || strcmp(arg, "-pg") == 0) {
-		ld[8] = "-lgmon";
-	} else if (strcmp(arg, "-g") == 0)
+		ld[7] = "/usr/lib/gcrt1.o";
+		ld[18] = "-lgmon";
+	} else if (strcmp(arg, "-b") == 0) 
 		;
-	else if (strcmp(arg, "-b") == 0)
+	else if (strcmp(arg, "-g") == 0)
 		;
-	else
+	else if (strncmp(arg, "-ld=", 4) == 0)
+		ld[0] = &arg[4];
+	else if (strcmp(arg, "-static") == 0) {
+	        ld[3] = "-static";
+	        ld[4] = "";
+	} else
 		return 0;
 	return 1;
 }

From tim at ngus.net  Mon Oct 31 11:46:29 2005
From: tim at ngus.net (Tim Angus)
Date: Mon, 31 Oct 2005 16:46:29 +0000
Subject: quake3 on Solaris x86
In-Reply-To: <Pine.LNX.4.63.0510311635450.5762@thorbardin.lasthome.solace.krynn>
References: <cbc7a72e0510310259r7885e29p741f3b1241b0d28d@mail.gmail.com>
	<Pine.LNX.4.63.0510311204490.5762@thorbardin.lasthome.solace.krynn>
	<cbc7a72e0510310327s53f60817jd1568c5e84863b19@mail.gmail.com>
	<Pine.LNX.4.63.0510311514260.5762@thorbardin.lasthome.solace.krynn>
	<20051031143222.58d7867c.tim@ngus.net>
	<Pine.LNX.4.63.0510311635450.5762@thorbardin.lasthome.solace.krynn>
Message-ID: <20051031164629.36f9cfba.tim@ngus.net>

On Mon, 31 Oct 2005 16:41:56 +0100 (CET) vincent at cojot.name wrote:
> - Makes lcc work on Solaris
> (gcc-solaris.c is a copy of linux.c at this time but will evolve).

OK good. Bear in mind that once somebody gets around to auditing lcc
properly, linux.c will most likely be replaced by bytecode.c or some
such so there is unlikely to be any forward evolution. Most of the
contents of this file are irrelevant for our purposes. All of the as and
ld arrays are unnecessary and many of the defines in cpp array are just
plain incorrect for compiling bytecode. What I'm saying is that there
really is no platform dependant code defined in the hostfile so it
probably doesn't make sense to maintain a separate solaris version. I
guess I'll just leave it up to you until lcc is cleaned up though (may
not happen for a while).

> PS: Don't drop the IRIX port/comments just yet, it's still on target
> for  me but the Solaris port gets done first.. :) I'm trying to get in
> touch  with the friends at sgi to see if they have any copy left of
> their old  diffs..

OK.


From darksharkster at gmail.com  Mon Oct 31 17:59:06 2005
From: darksharkster at gmail.com (darkshark atnight)
Date: Mon, 31 Oct 2005 22:59:06 +0000
Subject: [quake3] quake3 on Solaris x86
In-Reply-To: <Pine.LNX.4.63.0510311514260.5762@thorbardin.lasthome.solace.krynn>
References: <cbc7a72e0510310259r7885e29p741f3b1241b0d28d@mail.gmail.com>
	 <Pine.LNX.4.63.0510311204490.5762@thorbardin.lasthome.solace.krynn>
	 <cbc7a72e0510310327s53f60817jd1568c5e84863b19@mail.gmail.com>
	 <Pine.LNX.4.63.0510311514260.5762@thorbardin.lasthome.solace.krynn>
Message-ID: <cbc7a72e0510311459x4a6a8aaax9f624af3d82f1614@mail.gmail.com>

On 10/31/05, vincent at cojot.name <vincent at cojot.name> wrote:
> On Mon, 31 Oct 2005, darkshark atnight wrote:
>
> >  Are you sparc based though ?  I can do either, but me laptop is running
> > solaris so I'm trying for an x86 port.  I'd like to help in the sparc
> > bits too though.  Have access to some sparc U80's.
>
> I'm mostly sparc based but I am trying to keep my bits arch-neutral. If
> you have a working NVidia + Solaris setup, that's interesting as you will
> be able to test the bits I won't (I don't have a PC with NVidia graphics
> running Solaris at this time, they all run Linux)

   SolarisExpress with the nVidia drivers (ya, Solaris drivers from
nvidia :) would
   be an option for you on any of those linux PCs :)

>
> >  You mean the vm_86.c ?  It compiles and links.
> >  I have some changes to the sources - though its mainly adding __sun__ to
> >  ifdef's  I'm trying not to change the actual code in most places.
>
> Ok, check the recent checkouts, you shouldn't need to add any new #ifdef..
> Tell me if I broke something.. I'm having a lot of trouble with LCC on
> sparc at this time so if it works fine on i386, that's a good sign.
> Oh and btw, I thought it was recommended by SUN to use "__sun", not "__sun__".
>

   Yup, use __sun instead of __sun__.  I was being rather hacky.

   Got the newer rev, 202, had to change _very_ little this time which is nice.
   Though somehow managed to wipe the code base.. was trying a diff per file and
    overwrote every src file..  Argh...

qgl.h:
#if defined(MACOS_X) || defined(__sun)

to

#if defined(MACOS_X) || ( defined(__sun) && defined(__sparc) )

  OpenGL on Solaris x86 will be either Mesa based or nVidia based.
  Solaris will use the Xorg server on x86.

gcc-solaris.c (i.e. linux.c plus little changes. s/__linux/__sun/)

snapvectora.s:
C(Sys_SnapVector_cw):
to
C(Sys_SnapVectorCW):

  Theres one or two other little changes, which I'll send on once I
get things going again.
  Nothing major.

  I had no problems getting lcc compiled, just the linux.c copy to
gcc-solaris.c.  The
  q3lcc then compiled up the various .qvm files no problem.  I should
be able to try
  compiling on sparc this week.

  Running:
SunOSquake3 + set r_allowSoftwareGL 1

  I now get a window (plain black).  And then its stuck in a loop in
Sys_ConsoleInput()
  reading 1 char from stdin all the time.

>
> >> For the record, the solaris_qgl.c and solaris_glimp.c from ioq2 originally
> >> came from the SUN Quake2 porting team and I kept trying to adapt/maintain
> >> them in ioq2.
> >
> >  Ya, read the code comments :)  I'm going to ping some Sun opengl
> > people about this sometime this week.
>
> That'd be great to have them on-board.. I have both an sb2k+XVR-1000 and
> an sb150+XVR-600 but any other coder/debugger/tester will be welcomed.. :)

  I've nothing so fancy P-) an U80 is about it.  But may be able to
test on sb* though.

>
> Regards,

  Thanking you :)

Sean.
.
>
> Vincent
>