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.
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 So now I know how to spend the next hour
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:
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.
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.
----- 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
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.
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.
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:
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.
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:
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.
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?
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: