No, I was going to do an SDL port of Quake 2 for Zoid once upon a time but
when he left Id he stopped having time to think about it and I haven’t had
the time either. I may help with such an SDL port for a time when (if)
the code gets released to the public, but probably only in an advisory
capacity on some of the nits people will hit with Quake and SDL and the
Quake filesystem code, etc.
I hate to sound a bit megalomanic, but I don’t NEED Quake 2. A list of
improvements:
-
Marginally better network code
I could do much better now.
-
Ability to restart the renderer
No Quake 1 engine has this feature yet, but Zeph and I do know how to
do it–it’s just not an overnight task. Suffice it to say that what
is needed to toggle fullscreen/windowed in OpenGL using SDL is half
the battle right there.
-
Skyboxes instead of 2 layer "Quake sky"
It’s been done. Many times.
-
Colored lighting in OpenGL
It’s been done. Even more times than skyboxes.
-
Cinematic files (easier to create than demo movies)
A series of PCX files (8bpp) at 14 fps with a wav file. The files are
huge, lerping the images so they look good in software is probably
best done with some carefully tuned asm (I don’t know if Id did it
this way or not…) I’d rather support JNG or MNG or at least MPEG.
-
Renderer plus half the OS code (video, input) are modular
I used to think this was a good thing, but then on my box Quake 2 does
not work out of the box. Due to a bug in the video code (which
existed in Quake 1 as well), X can only be used at 8 or 16 bit. Since
svgalib on NVidia GeForce cards at best a sad joke, my only option is
to set up OpenGL and run the game with commandline parameters that
attempt to set it up right… ref_glx.so is needed, but due to a bug
in ref_glx.so, you must put a symlink opengl32.dll pointing to
libGL.so someplace. (Oh stop snickering, like you’ve never had a bug
like that before…)
-
Dynamic OpenGL loading
As mentioned above, it almost works even. 
But then, we have this
nice code written by Zeph which does that for SDL. It would also do
it for non-SDL with about 20 minutes of modification and works great
if you don’t mind about 3 dozen function pointers or so. Talk to me
off-list if you are having trouble getting this most useful feature of
SDL to work, I’ll send you the code.
[Attempting to steer this offtopic discussion back ON topic] SDL could
drastically improve Quake 2, to be sure. I’ll offer some sagely advice to
anyone considering working on it, since the source was originally to be
released in October, but rumors are that it’s been pushed back a bit.
Sound code need not be touched if you want to keep the port simple, but I
really think you’ll find that you’re better moving to SDL. I have a
drop-in snd_sdl.c which replaces snd_linux.c in Quake 1 outright. I do
not know for certain that it will replace snd_win.c, but it’d be trivial
to make it do that if need be. Quake 2’s sound code is either virtually
or actually identical to Quake 1.
SDL video and input are obvious, and my CURRENT vid_sdl.c would probably
replace gl_vid{linuxglx,nt}.c without much pain, but software rendering
will take more work and you might want to go back to Sam’s SDLQuake stuff
and just redo the input to not suck. Sam didn’t recall for certain
last time I asked him, but he believes the input code in SDLQuake may
predate SDL 1.0, if that’s an indication of how bad it was. Window tends
to lose the mouse, etc.
I would recommend dumping ref_.{so,dll} entirely. Compile the SDL-using
stuff right in to the renderer and create a Cvar vid_renderer which inits
to “stub”. Then write a stub renderer which is also compiled-in and
provides software menu and console, but that’s about it. This way if all
else fails, you at least have a method by which you can configure things
without resorting to trying to track down a commandline param which may or
may not be listed in some README file. Keep the code that loads ref_ and
use it to load r_soft.so and r_opengl.so as needed. Renderer plugins, no
pain for the user.
If anyone is serious about working on this, I can probably offer a dozen
more suggestions and chunks of code once there is source. I can only
offer so much based on info I’m probably not supposed to have (Zoid’s
fault) and a set of stripped binaries. Inquire off-list please, I seem to
have a bad habit of getting off-topic around here lately.On Thu, Sep 06, 2001 at 09:40:34AM +0100, Dominique Louis wrote:
There’s an SDL Quake which is vastly improved over Sam’s original SDLQuake
port using OpenGL at http://twilight.sf.net/ if you’re interested. It
still has many Quake-isms which need to die before I can declare it a true
SDL-native application, but they are planned. Will post a proper announce
when we have something other than just development snaps for download.
Looks like a really good project.
This is probably a silly question, but I will ask anyway. Is this a port
of the Quake 1 or Quake 2 engine? Or will you takle them in order?
–
Joseph Carter Free software developer
taniwha: Quote material 
Endy:
Endy: I already snipped it
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20010906/7ac629d2/attachment.pgp