I started adding it in fitzquake mainly to satisfy other users. I'm one of the people that was accustomed to the 10hz animations, and when I saw interpolation in engines, I didn't like it. A small part might have been the unfamiliarity, but a larger part for me was the situations where the interpolation fails miserably, such as NG muzzleflash sliding back and forth, the "spinning" torches, the SNG collapsing onto itself when you stop firing and it tries to turn 180 degrees in a single frame, muzzle flares when monsters/players shoot at you, etc.

But, in the process of implementing it in fitzquake, I inserted various small hacks to address these problems. I think it looks pretty respectable now. So it's a feature I will probably use myself from now on.

There are still some subtle issues that are inherent to linear interpolation which could only be improved with something like bezier interpolation, and only solved with skeletal animation.

There are also issues related to the fact that you always end up getting the next frame from the server later than you like. As a result, all engines that I've seen (including fitzquake) end up animating things 50ms late when interpolating. Since this is most important when someone is shooting, and shooting is one of the places where i automatically disable lerping, it's not actually a big deal. But an ideal engine design would involve the server sending the next frame as well as the current frame, so the client knows what to lerp towards. 

and you're sure that all your other settings are getting written to id1/config.cfg? The "Last Modified Date" on the file is recent, the "vid_restart" is there down at the bottom, etc?

If so, i'm stumped... I don't see how a different configuration, hardware, OS version, etc. could have any effect on this. :( 

Nice ;>. I have some bugs..

* Can't bind mouse keys in the controls menu (though the default mouse keys - fire, forward - work fine).

* The shift key (run) gives problems. (After setting up wasd in the controls menu) holding shift, then pressing any of the custom wasd movement keys... there's no movement. Without shift, they're fine. Funny, cause there's no problem with shift+any_cursor_key.

Also... press and hold w (moves forward) press and hold shift (runs forward) release w (continues to walk forward!, even after releasing shift)

* resize screen with minus key, after a couple of sizes, it goes blank (but this feature sucks anyway)

Fedora7, SDL-1.2.12-1.fc7, xorg-x11-apps-7.1-4.fc7, linux-2.6.23, usb mouse , NVIDIA-Linux-x86-96.43.01-pkg1.run

Will try compiling from source and check things out. 

How do you compile it ? 

Unless someone makes a makefile you will need http://www.codeblocks.org
Codeblocks should be able to export a makefile however I could not find the option to do so. 

Nice work! Any work on Linux Quake clients is very much appreciated. 

.. Installing wxWidgets-2.8.7 and codeblocks-8.02 wasn't too hard. (I'm suprised by the codeblocks IDE - It looks great). The project now compiles nicely though i still have the bugs. Spent a while trying to export a makefile too, without luck. 

why would fitzquake be switched to sdl? 

Spent a while trying to export a makefile too, without luck.

back to Spirit the same thing from my end. It imports and exports windows project files without any problems as well as .dev files from that other IDE built around lcc, but no make files. 

"The main goal of this version is to allow Fitzquake to run on all major platforms." 

What bugs were those again? 

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.