headers
Brian Hook | 2 Mar 2003 11:11

Windows builds

Ack, sent from wrong account.  Anyways, here's a message I meant to 
send earlier...

>The latest CVS doesn't compile on Windows.  I've updated my local
>version and can provide a patch for whomever.  I've also taken the
>liberty of renamed UpdateHardwareGamma() to
>GLimp_UpdateHardwareGamma().
>
>The specific problems encountered included:
>
>- lack of have_stencil for the Windows GL implementation - CD audio
>wouldn't compile (missing brace and return value)
>
>It now builds, haven't checked to see if it runs yet, will do that
>tomorrow hopefully once I remember all the proper command line
>switches to tell it where the data is, etc.
>
>-Hook
Permalink | Reply | 0 comments |
headers
Brian Hook | 2 Mar 2003 18:59

Re: Windows builds

Preliminary testing and it seems to work fine, at least it doesn't 
crash on the first level =)

I still need to implement a gamma routine for Windows.

What's everyone's take on the future direction of this codebase?  
There's a huge stack of shit that can/should be cleaned up in the 
codebase.  It would be nice to pull out Rendition and Glide 
references unless they were 100% necessary, and possibly clean up the 
renderer a bit (this would slow it down somewhat since the main I'd 
like to do is get rid of the current multitexture implementation).

Brian

On Sun, 2 Mar 2003 02:11:00 -0800, Brian Hook wrote:
>Ack, sent from wrong account.  Anyways, here's a message I meant to
>send earlier...
>
>>The latest CVS doesn't compile on Windows.  I've updated my local
>>version and can provide a patch for whomever.  I've also taken the
>>liberty of renamed UpdateHardwareGamma() to
>>GLimp_UpdateHardwareGamma().
>>
>>The specific problems encountered included:
>>
>>- lack of have_stencil for the Windows GL implementation - CD audio
>>wouldn't compile (missing brace and return value)
>>
>>It now builds, haven't checked to see if it runs yet, will do that
>>tomorrow hopefully once I remember all the proper command line
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brendan Burns | 2 Mar 2003 19:38
Picon

Re: Windows builds

Cool,
send me a patch and I'll incorporate it into CVS.

Vis a vis future directions,  my mission statement is:

maintain a version of Quake2 which is faithful to the original Quake2
and works well on as many versions of Linux as possible.

to me "faithful" means that improved graphics are cool, but game-play
and feel should remain the same.  Along those lines, improving the
multi-texture implementation would be okay.

I also think we should maintain operational software renderers since one
of the points of linux is supporting older hardware.

If other people have other ideas for the code, I'd love to hear them. 
I'm also very open to other people having commit privileges to CVS if it
encourages development.

--brendan

On Sun, 2003-03-02 at 12:59, Brian Hook wrote:
> Preliminary testing and it seems to work fine, at least it doesn't 
> crash on the first level =)
> 
> I still need to implement a gamma routine for Windows.
> 
> What's everyone's take on the future direction of this codebase?  
> There's a huge stack of shit that can/should be cleaned up in the 
> codebase.  It would be nice to pull out Rendition and Glide
(Continue reading)

Permalink | Reply | 5 comments |
headers
Laurent Desnogues | 2 Mar 2003 19:41
Picon

Re: Windows builds

Great to see that someone is interested in this and
especially someone who knows the code very well ;)

My main interest in the codebase right now is to
understand it.  And to ease that, removing the stack
of shit you mention could help a lot, but could only
be done by someone who knows if removing something
could break the software...  Some removals are more
or less safe provided one is ok to lose some
functionality such as stereo (who uses that?).

BTW, I don't see that many references to Glide or
Rendition in the code!

And to which renderer do you refer?  OpenGL or SW?

            Laurent

Brian Hook wrote:

>Preliminary testing and it seems to work fine, at least it doesn't 
>crash on the first level =)
>
>I still need to implement a gamma routine for Windows.
>
>What's everyone's take on the future direction of this codebase?  
>There's a huge stack of shit that can/should be cleaned up in the 
>codebase.  It would be nice to pull out Rendition and Glide 
>references unless they were 100% necessary, and possibly clean up the 
>renderer a bit (this would slow it down somewhat since the main I'd
(Continue reading)

Permalink | Reply | 1 comment |
headers
Laurent Desnogues | 2 Mar 2003 19:44
Picon

Re: Windows builds


> If other people have other ideas for the code, I'd love to hear them. 
> I'm also very open to other people having commit privileges to CVS if it
> encourages development.

   I have some patches to make all constants floats
instead of doubles, use sinf, cosf and so on.  The
engine was designed with floats in mind not doubles
(if I got it right)...

   I could also send in my Makefile modifications
so that it compiles on PS2Linux...

			Laurent

Brendan Burns wrote:

>Cool,
>send me a patch and I'll incorporate it into CVS.
>
>Vis a vis future directions,  my mission statement is:
>
>maintain a version of Quake2 which is faithful to the original Quake2
>and works well on as many versions of Linux as possible.
>
>to me "faithful" means that improved graphics are cool, but game-play
>and feel should remain the same.  Along those lines, improving the
>multi-texture implementation would be okay.
>
>I also think we should maintain operational software renderers since one
(Continue reading)

Permalink | Reply | 2 comments |
headers
Brian Hook | 2 Mar 2003 19:41

Re: Windows builds

>maintain a version of Quake2 which is faithful to the original
>Quake2 and works well on as many versions of Linux as possible.

Since that's all in the "game" area, that should be easy to do -- the 
engine can be modified/updated without affecting gameplay, and new 
game modifications/variations can be easily added a la ctf.  No 
worries there.

>I also think we should maintain operational software renderers since
>one of the points of linux is supporting older hardware.

Definitely.  I'm specifically talking about references to PowerVR, 
Verite and Glide.  Is it safe to trash those?

>If other people have other ideas for the code, I'd love to hear
>them. I'm also very open to other people having commit privileges to
>CVS if it encourages development.

I'm not much of a Lunix hax0r, so having me commit blindly is a bad 
idea =)

How do you like patches generated, just using the cvs diff output?

Brian
Permalink | Reply | 0 comments |
headers
Brian Hook | 2 Mar 2003 19:45

Re: Windows builds

>My main interest in the codebase right now is to understand it.  

I happen to think it's a great codebase to dork with, since it 
implements everything you'd want/need and it's pretty easy to follow. 
 Not to mention compiles very fast.

>BTW, I don't see that many references to Glide or Rendition in the
>code!

I think there are lots of little things here and there that simply 
make the code a little more complicated for not much benefit.  For 
example, the Glide SST_GAMMA stuff is referenced on every single 
platform (even irix!).  It could safely be removed IMO and would 
increase the readability marginally.  Same with the REF_POWERVR, 
REF_VERITE, etc.

If no one objects, I'll start yanking that stuff out.

I'm willing to do that work on the Windows side -- someone can/should 
remove it as well from the non-x86 stuff, since AFAIK there was never 
a Voodoo board for Solaris =)

Brian
Permalink | Reply | 0 comments |
headers
Brian Hook | 2 Mar 2003 20:27

Ideas

Some things that I would like to do, mostly to satisfy my own anal 
retentive coding practices, so feel free to shoot down at will =)

1.  For a "learning" code base, I really do think prefixing functions 
helps a lot.  A function like FindItemByClassname() to me is a bit 
easier to identify when it's called something like 
Q2_FindItemByClassName().  This way when you see SetDeviceGammaRamp() 
you don't have to wonder "is that an API call or is that a Q2 
internal call?!".  That's the point of the R_*, VID_*, etc. but not 
everything was done that way, specifically a lot of the game code.  
I'm willing to change this stuff over as it gets done.

2.  The source base is not const correct.  I fixed this once, which 
was a HUGE pain in the ass, and I'm willing to fix it again if you 
guys want.

3.  This is a pretty major change, but I think integrating a 
scripting language like Lua would be nice.  The primary benefit is 
that mods become portable again.  I think it could be done 
incrementally as well -- moving leaf functions into Lua and slowly 
move up the call tree until most of the game code is in script.

Once those changes are in place I think it would be great if we could 
get the user community involved in doing mods and stuff without 
having to have a compiler and know C, etc.

What's the story with Q_MAX?

Thoughts?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Vincent Cojot | 2 Mar 2003 20:56
Picon
Picon

Re: Windows builds

On Sun, 2 Mar 2003, Laurent Desnogues wrote:

>    I have some patches to make all constants floats
> instead of doubles, use sinf, cosf and so on.  The
> engine was designed with floats in mind not doubles
> (if I got it right)...

Careful with that.. :) Solaris/Sparc only has sinf/cosf if you buy the
FORTE compilers.. if your compiler is gcc, then you can only use
sin()/cos() routines because you're lacking the specialized math library..
:) Careful not to break other platforms.. :) But anyway, modify whatever
you want and I'll take the time to test it on Sparc..

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

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
Permalink | Reply | 1 comment |
headers
Brian Hook | 2 Mar 2003 21:08

Re: Windows builds

For those functions I'd recommend making Q_sinf(), etc. and then 
putting those in q_shared or somewhere similar and each platform can 
implement it as necessary.  The code in md4.c, for example, relies on 
inttypes.h which doesn't exist on MSVC 6, so those hardcoded type 
sizes should either be in-lined or possibly made a part of q_shared.h 
e.g. qu32_t, qi32_t, etc.

I'm willing to do that as well.

Just noticed that va() isn't buffer safe, which could lead to some 
exploits as well.  Putting in snprintf.c might not be such a bad 
idea.

Brian

On Sun, 2 Mar 2003 14:56:21 -0500 (EST), Vincent Cojot wrote:
>Careful with that.. :) Solaris/Sparc only has sinf/cosf if you buy
>the FORTE compilers.. if your compiler is gcc, then you can only use
Permalink | Reply | 0 comments |

Gmane