News | Forum | People | FAQ | Links | Search | Register | Log in
Fitzquake SDL Version Beta
I just published a beta release of my SDL version of the Fitzquake engine. The main goal of this version is to allow Fitzquake to run on all major platforms. I provide builds for Windows, Mac OS X and Linux.

Grab them at

Windows and Linux users take note that you have to install SDL 1.2.10 or better.

Windows users please also be aware that this port does not do anything better on Windows than metlslimes original version. Actually, it does less, but I would still like to get your feedback because there's a chance that the official version will be switched to SDL eventually. That would go a lot smoother if we ironed out the bugs on all platforms first.

Have fun and don't forget to send in your feedback and bug reports.
First | Previous | Next | Last
This seems to work for some people.

Download the source and patch
tar xzf SDL-1.2.14.tar.gz
cd SDL-1.2.14
patch -p1 <libsdl-new_gamma_ramp_support.patch
Remove your old libSDL somehow, or "configure --prefix=/usr" will overwrite libs in /usr/lib
configure && sudo make install
sudo ldconfig
SDL Keymap 
Does FitzQuake SDL automatically properly keymap a keyboard ... like if someone is using a US-101 keyboard versus, say, a German keyboard user?

From the code, I am guessing it does but I don't have an easy way to verify this. 
EN/US layout 
I Wanted To 
do that, but it would have required replacing Quake's own keyboard codes with SDL codes throughout the entire codebase, and I didn't want to do that way back.

I do think it should be done though, and maybe I'll convince the QS guys to let me fix this in QS. 
I was trying to determine why the Key_Map function was converting the key code whenever the Key_Event function was called.

Ok ... I was reading too much into it. 
Apart from the umlauts QuakeForge does it, if you need a starting point. 
Almost 3 years ago, I added international keyboard support into ProQuake with a cvar (with a keypad bug I keep forgetting to fix) on Windows, but it is dependent on Windows messaging stuffs so it is totally non-portable.

I was just looking to understand the FitzQuake 0.80 implementation of the SDL build and the Key_Map thing threw me off. I thought some non-obvious keymapping was going on using libsdl somehow. 
It just maps SDL key codes to Quake key codes IIRC. 
Autosave/autoload Patch 
I don't know if other people have this problem, but I find that the more immersed I am in playing a Quake map, the less likely I am to remember to quicksave. When I die, having to replay several minutes really breaks the immersion :-(

To fix this problem, I'm working on a patch which adds autosave/load to QuakeSpasm. Here's a snapshot:

Here's how it works: at regular intervals (no more frequently than every 30 seconds), it automatically creates a save called auto_{mapname}. When you die, the most recent save is loaded - regardless of whether it's an autosave, quicksave or normal save.

If you want to start a map from the beginning, you can use the "restart" command, or "map mapname".

It needs more testing - there are heuristics for deciding when to autosave which need to be tweaked - but check it out!

the code is here: 
Very Cool! 
Great feature ericw! 
^ Spammer 
Mod Testing 
While working on a convertion of the qtest1 I have a lot of issues in the coding part.
A lot of the script has changed in the original version so I'm tinkering to get a right one that includes all original entities, and has some add-ons like earthquake, serpent, earlier shallrath and so on.

Now one thing breaks me up, and I don't know if it is the code or Fitzquake. Halfway the level the map just hangs, and there is no oppertunty to finish the level or make a quit outcome.

I think it has to do something with my broken code attempts, but fortunately Quakespasm or BengtGl, Afterquake don't have this error. 
sounds a bit like a remove/setmodel/setorigin/setsize/walkmove/movetogoal/droptofloor call inside a touch function.
certain ordering can result in infinite loops if you violate the rule that you don't do the above (all of those functions can change the entity links in the physics cache states which is a problem if the engine is walking them at the time). 
Possible, most of the time I have not the slightest idea what I'm doing. As long as the code produces a progs.dat it's allright with me.
I just wondered why the different engines have such a strange impact on behaviour.

Aftershock seems to handle the earthquake code with much more disaster then other ones.
When I added the dragon code from Patrick Martin lots of other changes were made I have no controll of.

Mixing several codes can make it a bit blurry as much statements depend on each other.
I have a great code for the Serpent, but it uses fbx that is not easy to integrate. 
Funny How This Thread Keeps Getting Resurrected 
only to confuse madfox ;-) 
Let's Report 
a "sv_touchlinks: next != L->next" error.

My blame_code, it somehow has something to do with a touch code. 
madfox, see the rule above. :)
touchlinks is specific to a trigger's touch function. hence all the self.think=SUB_Remove; lines in the vanilla qc. 
8 posts not shown on this page because they were spam
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.