I can't get it to run on Gutsy despite having all libsdl stuff installed apparently. Clicking the executable doesn't do anything. What am I missing? 

Try starting it in a terminal, maybe there is some error message (not likely but worth a try).
./fitzquake in the quake directory. 

"permission denied" 

chmod 777 fitzquake (or chmod +x) helped. 

Just the bugs i posted above - Custom movement keys (wasd) dont work with the shift key and I can't bind mouse buttons in the menu. It's a bummer for me.

Thanks again for porting this engine. It's a shame linux is such a bitch to learn. Hopefully i'll get some inspiration to look at the code in my hols. 

Those bugs are already fixed and I'm working on networking. Once that's done, I'll release another beta. 

How do you compile it ?

You steal a makefile from Tyrquake or something and adapt it.

"You will adapt to service us." :-P

An observation: If it uses SDL for rendering (and sound?) then it should be able to use all of SDL's video drivers. In case someone didn't know this, it's possible to select SDL's video output by exporting an SDL_VIDEODRIVER (or something) environment variable. Should be in the manpage.

X11, framebuffer console, ... it should even run on embedded devices.

Is that the case, sleepwalkR? 

As far as I know, yeah, it should be able to run on whatever device is supported as a target by your C compiler and SDL.

It uses SDL for rendering, sound, input and TCP networking. 

codeblocks-8.02::compilergcc.cpp -

"This functionality has been temporarily removed from Code::Blocks."
"With all the updates from the last couple of months, the makefile exporter"
"is not anymore in-sync with the rest of the build
"We are sorry for the inconvenience..."

Hmmmm.

I tried hacking codeblocks to at least call the makefile generator.

And it does generate a makefile, but it's busted ;< The makefile i got includes rules for dependancy files, (eg cd_sdl.d), but no rule for building the objects (cd_sdl.o). After a little TLC i did get it linking the objects
into a binary though. I'm no "make" guru. 

Fitzquake just killed my xserver. I was switching to tty2 to kill some musicplayer. It worked fine for two times, then I wanted to kill it properly (because I killed only child processes earlier...) and ctrl-alt-f2 resulted in the xserver crashing. :( 

And now it reset color settings in the middle of a map with no way to set them again. gamma was at 0.7 but displayed as 1.0. Brightness slider did nothing. 

Has anyone taken benchmarks on SDL Fitzquake and GL Fitzquake? If there's a loss of efficiency in SDL it would probably be better just to add some system-dependent code to the original Fitzquake source so it retains system-independence without having to run calls to the OpenGL libraries via the SDL ones. 

first problem sounds like a bug in sdl to me. I have no idea about the second problem. I'll see about it, but it also sounds like a problem outside of the fq code, like some event reset hw gamma. Odd.

I haven't benchmarked since it runs good enough for me. If someone wants to do it though, make sure to post the results here. 

1280x1024x32 on Pentium-M 1.2GHz, GeForce 6600GT with those NGO? drivers.

Fitzquake080.exe: 430fps
SDL Fitzquake.exe: 300fps
aguirRe's glquake: 400fps
Joequake (gl): 150fps
Darkplaces (music disabled): 250fps
Tomazquake: 250fps
Qrack: refuses to run with "Couldn't set fullscreen DIB mode"

I'd say even though the SDL Fitzquake is a bit slower it still is more than fast enough. 

Launching Qrack without arguments worked, heh.

Qrack: 400fps 

Tremor: 150fps
Tyrquake (gl): 400fps 

@ jengle: yeah, in principle I don't understand why you would need SDL to run a crossplatform quake client either. But I'm happy enough about SDL fitzquake so let's just not ask stupid questions :-)

SDL bugs are quite possible btw, it's happened before. This is also one of the drawbacks of using it. It's an additional layer of possible bugs. 

Well, for once, it's easier and you can port it to more platforms. There wouldn't be a working linux version if I hadn't used SDL, since I'm not interested in maintaining one. Esp. the sound code is much easier to do in a portable way with SDL I think.

Spirit, interesting numbers. The lower performance of the SDL port could be due to a number of reasons: different compiler that doesn't optimize for windows as well as VC does, routing calls through SDL, and maybe I haven't gotten the game loop right yet. It may very well be capped due to poor timer resolution or whatever. I'm not an expert at these things :-)

Oh, and btw if you can reproduce any of the bugs you mentioned before, be sure to let me know how so that I can maybe fix them (if it's indeed in my code). 

... is a pretty good API. id software use it for the Linux versions of Quake 4, etc. Imho you'll encounter many more problems with poor X.org drivers than with SDL. 

Reproducable (at least for me, Linux):
-Launch Fitzquake
-Switch to other game via game (I tried Quoth and Marcher)
-Load any map (I tried quoth's startmap and marcher)
-segfault 

Bug submited by Spirit is also reproducable for me (Linux). 

http://img164.imageshack.us/my.php?image=joequake004cy5.jpg
Suddenly I run 10 times faster 

What? 

The movement key bugs are apparent after about 5 seconds of playing when the guy moves in totally wrong directions. I use shift for jump. 

The shift problem is already fixed in the code. I just have to release it - sorry it's taking so long. I have to test the networking code a bit more before I can release a new beta.