Quake ported to SDL

The recently released source code to Quake has been ported to the
Simple DirectMedia Layer library!

Check it out at:
http://www.devolution.com/~slouken/SDL/projects/quake/

I quickly hacked this up as a base for porting Quake-based games to SDL.
Ideally this patch would make it back into the mainline quake source code
base.

It includes full autoconf support as an SDL application, and the complete
original Makefile structure is intact in the Makefile.* files.

The graphics and sound work great. I haven’t implemented CD playing yet.

See ya!
-Sam Lantinga (slouken at devolution.com)

Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec

The recently released source code to Quake has been ported to the
Simple DirectMedia Layer library!

My, that was quick :slight_smile: On a first grep there’s not that many “SDL”-calls
in it, but finding your way through the code to know where to change what…

Check it out at:
http://www.devolution.com/~slouken/SDL/projects/quake/

Done. Two points:

  • The MATHLIB in the makefiles is not added to the LIBS, so it tries
    linking without it. NP. Apart from that it compiles fine.
  • It seems to require the full game-data to play, so offering a link
    to the shareware-stuff is of no help. The exact message is:

Added packfile ./id1/pak0.pak (339 files)
FindFile: can’t find gfx/pop.lmp
Playing shareware version.
Error: You must have the registered version to use modified games

Hmm… well, since this is the source… probably that need not stay the
case :slight_smile: So now I know how to spend the next hour :wink:

I guess that hardware-3D works if it does with mesa, right ?

all the best,
robOn Sat, Dec 25, 1999 at 09:06:33AM -0800, Sam Lantinga wrote:

Allright, who likes to reply to his own posts, so I’ll write before I
recieve my first message lol.

To play the sw-version one needs to edit common.c like this:

$ diff common.c common.c.orig
1034d1033
< /*
1037d1035
< */

all the best,
rob

Sam Lantinga wrote:

The recently released source code to Quake has been ported to the
Simple DirectMedia Layer library!

Sam is a god. I briefly thought of doing this, but I’m glad to see I
don’t have to. :slight_smile:

I compiled it fine, but can’t seem to get the WAD off my Quake CD. I
assume it’s buried in the installer. Oh well, next time I reboot into
Windows, I’ll give it a shot…–
Marc Lepage
http://www.antimeta.com/
Minion open source game, RTS game programming, etc.

; ender at admdev.com ;
quake-devel at lists.sourceforge.net ;
slouken at devolution.com

The recently released source code to Quake has been ported to the
Simple DirectMedia Layer library!

Check it out at:
http://www.devolution.com/~slouken/SDL/projects/quake/

OK, what the hell do those guys at Loki pay you to do anyways? :stuck_out_tongue:

-Sam Lantinga (slouken at devolution.com)

Lead Programmer, Loki Entertainment Software

Nicholas

----- Original Message -----
From: slouken@devolution.com (Sam Lantinga)
To: sdl at lokigames.com ; crusader at lokigames.com
Date: Saturday, December 25, 1999 9:24 AM
Subject: [SDL] Quake ported to SDL

Sam Lantinga wrote:

The recently released source code to Quake has been ported to the
Simple DirectMedia Layer library!

When I run with the release Quake distribution, I receive a segmentation
fault while launching the Necropolis demo on startup (always the same
place):

PackFile: ./id1/pak0.pak : sound/ambience/drip1.wav
PackFile: ./id1/pak0.pak : sound/ambience/swamp2.wav
PackFile: ./id1/pak0.pak : sound/ambience/swamp1.wav

Program received signal SIGSEGV, Segmentation fault.
0x80a21e3 in BoxOnPlaneSide ()
(gdb) where
#0 0x80a21e3 in BoxOnPlaneSide ()
#1 0x2 in ?? ()
(gdb)

It looks like the stack is being trashed. Anyone else have this problem?–
Marc Lepage
http://www.antimeta.com/
Minion open source game, RTS game programming, etc.

Sam Lantinga wrote:

The recently released source code to Quake has been ported to the
Simple DirectMedia Layer library!

When I run with the release Quake distribution, I receive a segmentation
fault while launching the Necropolis demo on startup (always the same
place):

PackFile: ./id1/pak0.pak : sound/ambience/drip1.wav
PackFile: ./id1/pak0.pak : sound/ambience/swamp2.wav
PackFile: ./id1/pak0.pak : sound/ambience/swamp1.wav

Program received signal SIGSEGV, Segmentation fault.
0x80a21e3 in BoxOnPlaneSide ()
(gdb) where
#0 0x80a21e3 in BoxOnPlaneSide ()
#1 0x2 in ?? ()
(gdb)

It looks like the stack is being trashed. Anyone else have this problem?

The code is compiled by default with -fomit-frame-pointer, which makes it
a little hard to debug. Look in configure.in for that flag, remove it, and
then do “make clean; make”

-Sam Lantinga				(slouken at devolution.com)

Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec

Program received signal SIGSEGV, Segmentation fault.
0x80a21e3 in BoxOnPlaneSide ()
(gdb) where
#0 0x80a21e3 in BoxOnPlaneSide ()
#1 0x2 in ?? ()
(gdb)

It looks like the stack is being trashed. Anyone else have this problem?

The code is compiled by default with -fomit-frame-pointer, which makes it
a little hard to debug. Look in configure.in for that flag, remove it, and
then do “make clean; make”

BoxOnPlaneSide() is in math.S, an asm file if you compile it on an x86 box.

.globl C(BoxOnPlaneSide)
C(BoxOnPlaneSide):
pushl %ebx

    movl    P(%esp),%edx
    movl    EMINS(%esp),%ecx
    xorl    %eax,%eax
    movl    EMAXS(%esp),%ebx
    movb    pl_signbits(%edx),%al
    cmpb    $8,%al
    jge             Lerror
    flds    pl_normal(%edx)         // p->normal[0]
    fld             %st(0)                          // p->normal[0] | p->nor

mal[0]
jmp Ljmptab(,%eax,4)

I didn’t even wanna think about debugging asm, so I just hacked the relevant
header files and compiled the C-only version.

I’m still trying to figure out the glquake (GLX version with a TNT2 card)
pallete problem. The menus are unaffected, but the gameplay is. Any hints?On Sun, Dec 26, 1999 at 11:24:50PM -0800, Sam Lantinga wrote:


– Michael Samuel <@Michael_Samuel>

Michael Samuel wrote:

Program received signal SIGSEGV, Segmentation fault.
0x80a21e3 in BoxOnPlaneSide ()
(gdb) where
#0 0x80a21e3 in BoxOnPlaneSide ()
#1 0x2 in ?? ()
(gdb)

It looks like the stack is being trashed. Anyone else have this problem?

The code is compiled by default with -fomit-frame-pointer, which makes it
a little hard to debug. Look in configure.in for that flag, remove it, and
then do “make clean; make”

BoxOnPlaneSide() is in math.S, an asm file if you compile it on an x86 box.

.globl C(BoxOnPlaneSide)
C(BoxOnPlaneSide):
pushl %ebx

    movl    P(%esp),%edx
    movl    EMINS(%esp),%ecx
    xorl    %eax,%eax
    movl    EMAXS(%esp),%ebx
    movb    pl_signbits(%edx),%al
    cmpb    $8,%al
    jge             Lerror
    flds    pl_normal(%edx)         // p->normal[0]
    fld             %st(0)                          // p->normal[0] | p->nor

mal[0]
jmp Ljmptab(,%eax,4)

I didn’t even wanna think about debugging asm, so I just hacked the relevant
header files and compiled the C-only version.

I changed my source so the C version of that function is used, but then
experienced another problem in another assembly file. So I changed my
source to use all C versions.

Now the game works fine. However, I cannot change the resolution.
320x200 is pretty small. Is this supported?> On Sun, Dec 26, 1999 at 11:24:50PM -0800, Sam Lantinga wrote:


Marc Lepage
http://www.antimeta.com/
Minion open source game, RTS game programming, etc.

start it with -winsize www hhh at the command line.

Phoenix Kokido
members.xoom.com/kokido
@Wes_Poole

Marc Lepage wrote:

Michael Samuel wrote:

Program received signal SIGSEGV, Segmentation fault.
0x80a21e3 in BoxOnPlaneSide ()
(gdb) where
#0 0x80a21e3 in BoxOnPlaneSide ()
#1 0x2 in ?? ()
(gdb)

It looks like the stack is being trashed. Anyone else have this
problem?

The code is compiled by default with -fomit-frame-pointer, which makes
it

a little hard to debug. Look in configure.in for that flag, remove it,
and

then do “make clean; make”

BoxOnPlaneSide() is in math.S, an asm file if you compile it on an x86
box.

.globl C(BoxOnPlaneSide)
C(BoxOnPlaneSide):
pushl %ebx

    movl    P(%esp),%edx
    movl    EMINS(%esp),%ecx
    xorl    %eax,%eax
    movl    EMAXS(%esp),%ebx
    movb    pl_signbits(%edx),%al
    cmpb    $8,%al
    jge             Lerror
    flds    pl_normal(%edx)         // p->normal[0]
    fld             %st(0)                          // p->normal[0] |

p->nor

mal[0]
jmp Ljmptab(,%eax,4)

I didn’t even wanna think about debugging asm, so I just hacked the
relevant> > On Sun, Dec 26, 1999 at 11:24:50PM -0800, Sam Lantinga wrote:

header files and compiled the C-only version.

I changed my source so the C version of that function is used, but then
experienced another problem in another assembly file. So I changed my
source to use all C versions.

Now the game works fine. However, I cannot change the resolution.
320x200 is pretty small. Is this supported?


Marc Lepage
http://www.antimeta.com/
Minion open source game, RTS game programming, etc.

Now the game works fine. However, I cannot change the resolution.
320x200 is pretty small. Is this supported?

Well, it seems as though it can be done via the command-line, but, well, I
think 640x480 is a much more reasonable default, so in vid_sdl.c I changed
BASEWIDTH to 640 and BASEHEIGHT to 480.On Mon, Dec 27, 1999 at 01:10:06PM -0500, Marc Lepage wrote:


– Michael Samuel <@Michael_Samuel>