News | Forum | People | FAQ | Links | Search | Register | Log in
Fitzquake 0.85 Released At Last!
New in this version: increased map and protocol limits (can load all known limit-breaking maps,) model interpolation, per-entity alpha support, new network protocol, more external texture support, hardware compatability improvements, many bug fixes, and a cleaner source release to make it easier to install and compile.


(Thanks to the beta-testers: Baker, JPL, negke, Preach, and Vondur.)
First | Previous | Next | Last
FitzQuake 0.85 With MP3 Playback 
cool! thanks! :D 
Excellent Work! A Fog Question... 
Hey, just d/l'd FQ 0.85 the other day after wanting to run through a little Quake SP and remembering I didn't really like DarkPlaces last time I messed with it.

Anyway, FitzQuake has just replaced DP for me. :D

I'm having one problem, though - can't seem to get my fog settings to stick (tried it in both autoexec and in config after figuring out that scr_crosshairscale had to be changed there :D. Anyone have an idea why fog density wouldn't stay set? R,G,and B seem to stay set, fwiw.

System specs: XP Pro, A64 X2, 2GB DDR & 8800GTS 512.

Other than that, FQ works a lot like the UGL Quake I loved back in the day, but MUCH nicer (love the working fullbrights and gamma)- Thanks for the updated version! 
That's a known issue, the current behavior is for each map load to set the fog based on it's setting, and if it has no setting, it gets reset. 
Thanks For The Answer! 
I should have guessed it was something like that, since everything else works quite well. I'll just make a keybind for it if I find myself really missing it. :D Also wow, your update feels like Quake the way it was back in '95, thanks again!

(Now, time to drop some of CZG's, Vondur's and Elek's maps in to try 'em all out again...) 
Don't Forget 
Travail, Quoth and Tronyn's latest efforts :) 
I receive an error I didn't know, as it appears only in hard skill

8062 byte signonbuffer exceeded the standaard limit of 7998

Aguier's glquake doesn't give a message.
Is it the same as too many eddicts? 
no, it just means the overall level has enough stuff that the initial message to new clients is too big.

BUT: if you don't get this warning in aguirre quake, it might be okay. Try in fitzquake using sv_protocol 15 for a more accurate test, or just try it in regular quake (glquake or winquake) and see if it crashes. If it doesn't crash, i think you're okay. 
Surprised Player Who Never Knew New Clients Looked Over Shoulders Of 
I was surprised it was only in hard skill.
easy/159 normal/169 hard/175

So it seems hard skill has 6 entities over the limit. 
Single Player Mappers.... 
and yes, the map is rather full.
925 entities, 263 lights, 26288 faces. 
to give more explanation, the "Signon Buffer" is basically a snapshot of the initial map state, which includes the initial state of all edicts, plus any static entities in the level. So you could reduce it by reducing edicts or by reducing static entities. 
Reducing Signon Tips 
The signon buffer has to detail every entity which spawns with a model set. One of the ways you can reduce the size of the buffer content is to have some entities set their models a few frames after the server starts.

It is possible to do this with a hack that works in virtually any quake mod that contains a func_wall and an info_notnull, but it relies on you having some func_walls to apply this to. Take one of these existing func_wall entities, and change it's classname to info_notnull(without making it a point entity). Then add the following keys:

"nextthink" "0.5"
"think" "func_wall"

This will make the func_wall spawn 0.5 seconds after the server starts, which removes it from the signon buffer. Instead it gets sent as one of the first update packets. You need to be careful picking a func_wall to use for this trick. If some other entity will spawn on the wall or may move into it before it spawns, then this trick will probably trap that entity inside the wall. So be a little careful.

This trick cannot be used on any entity which requires a precache, which limits it a great deal. Brush entities have the advantage of getting their model precached automatically. A silent func_plat is possible, although those will give you warnings about sounds, so not a good idea. A func_illusionary will not work, as they are made into static entities which must be in the signon buffer for players to see them.

Incidentally, this trick can be easily adapted to make func_walls spawn in levels when triggered. Take the info_notnull wall, and instead of think/nextthink, add "use" "func_wall" and give it a targetname. Just be careful about entities getting trapped inside... 
Fitzquake-SDL On ARM? 
Is Fitzquake-SDL likely to run on an ARM-based device (Nokia N900) running Debian Linux, assuming the required libs are present? 
No Idea 
It would have to be recompiled for ARM, that's for sure. AFAIK, SDL can be compiled for ARM, so there's no problem there. What about GL support on that platform? I'm not sure, but I doubt that OpenGL ES is enough to run Fitz. 
OpenGL Support 
Considering that even much "lesser" phones like N95 and even N80 could run accelerated GLQuake and Quake2, I would be surprised if this wasn't the case for N900. 
OpenGL ES 
It seems that Nokia N95 has OpenGL ES 1.1 while the N900 ships with ES 2.0. 
#290 should have been posted in Phone Thread :P 
for the explanation.

I changed six func_wall ents but for some reason the signon buffer keeps alerting.
Think I delete some entities as it seems the most simple solution. 
Talking to a friend about playing Quake on Linux

fitzquake has horrible issues with x86_64
namely using unsigneds to store pointers, VERY BAD PRACTICE

Thought whoever is going to be working on the next version might want to know about this... 
yeah, pointers are treated as 32-bit in various places. Maybe if 64-bit becomes important, I'll figure out what is needed to fix it. 
Since when did quake need to address more than 4 gigabytes of memory? 
Rotating Brush Support 
For the sake of keeping FitzQuake 0.85 stuff where it can easily be found:

FitzQuake085_rotate.exe (with source)

Sample rotating object map (rotate.bsp and compiled with LordHavoc's new version of hmap2)

Rotation support (avelocity) added from this tutorial:

YouTube video of spinning object in DarkPlaces, appears to work and look the same in FitzQuake085_rotate.exe: 
What the hell is going on in that video? :) I can't tell what's rotating ... the player? But why is the room turning ... I .. ARGH!! 
It Looks Like 
the player is not rotating, but the thing he's standing on is.

How is this different, in technical setup and/or mapper use, than Hipnotic's rotating stuff?

Could be a big boon if the texturing of these rotators is more sane. 
no func_movewalls 
I've been following the thread on i3D as you guys discussed this. The remaining things I think would be ideal:

- engine: rotate player orientation as the object they are standing on rotates.

- compiler: origin brush support for ease of use

- compiler: fixed texture alignment on rotating models (right now it's all wrong because the brushes are moved to the world origin during the compile process without locking the textures)

Also I believe the way collision is being done for this is not correct, rotating the collision hulls can have some pretty non-optimal results, especially if you rotate a bmodel onto its side, since player bounding boxes are taller than they are wide. But doing it correctly would be pretty hard. I think what quake2/3 do is, save the original brushes in the bsp file and expand them to collide as needed, and don't use hulls at all. 
Rotating Doors 
Although there are many theoretical things that can be done with rotation and known issues with it in Quake, I only care about rotating doors. ;)

Maybe draw bridges that rotate down too.

Hip rotate doors kill me and otherwise are all weird. And if map authors want spinning things for show and level atmosphere, they can always put some clip around them ... to my knowledge the hiprotate objects have the same problems but at least these are FAR easier to setup. 
Different Problems 
The hiprotation objects have some problems, but they are consistent - the movewalls themselves don't rotate, so they don't start colliding with the player differently depending on the rotation it takes. Score one for hipnotic I guess... 
Avirox Rotation Version 1

Rockets and grenades appear to collide properly. ;) 
point-size entities will behave correctly, since a rotated point is still point-sized. It's hull1 and hull2 which are built around box-shaped entities which will exhibit inaccurate collision when the hull is rotated. 
I believe for legacy maps, and people who simply want to keep using them, hiprotate will not go away... Quoth supports it nicely, RMQ will keep supporting it as part of its backwards compatibility effort etc...

For those of us who would like to do it in a more sane way in the future, the avelocity based rotation will be a gift of the gods.

Meaning, with RMQ and other forwards-compatible mods, you'll be able to have what you prefer. 
what does it mean:

it's from a console log
VID_Gamma_Restore: failed on SetDeviceGammaRamp
It Means 
ATI sucks. 
i got nvidia 
Well, I think it says something about not being able to restore the original gamma (of the OS versus the one ingame). 
it means restoring your desktop gamma setting didn't work, but i'm not sure why -- windows doesn't give any useful error messages when that happens. 
Windows Is A Piece Of Shit 
That's what it means.

A piece of shit geared towards your needs, the users needs.

I can't be arsed - but imagine I'd just gone on for a while about how magical a piece of shit can be, but at the end of the day is still something that won't fuck off no matter how many times you flush. 
also, after talking to somebody by email (baker, jpl, or spirit, or maybe someone else)... that person told me he was getting the message even int cases where the gamma change actually worked! So sometimes the "failure" isn't actually a failure, from that one user's report. 
Error Code 23 
Post failed! 
Crucified Zombies Do Not Work. 
They fall true the map.
In all the other engines they hang on the wall, but in Fitz ver .85 they either appear normal, throwing meat at you, or they fall true the map.
I don't get it.
If I start the start.bsp map, they are all hanging nicely on the wall, but in my own (nearly done) map, they don't. 
Sorry, Spoke Too Soon. Again ... 
Can't delete my previous post.
There was something wrong, but it was because I was using an alternative pack.

Sorry ... 
fitz0.85 is opengl right?

still dont understand what fitzquake have that joequake,qrack,glquake e.t.c dont have because with my ATI X850 in the only that dont screw my image...

:( but i whould love to know what it is :| need joequake to record speedruns demos :( 
gl_ztrick 0 
Mr Fribbles are you joking or serious?

I dont understand nothing about those things... if true i will try when i get home


if joequake have this command... 
Mr Fribbles 
gl_ztrick i google it, and i guess you are right... zomggg will be the first thing I will do when I get home... 
I think fitz sets ztrick to 0 by default. 
there is no such command in fitzquake0.85 
finaly got home and try!


is working

/me kisses Mr Fribbles 
I removed ztrick long ago. It was basically a hack to avoid clearing the z-buffer between frames, at the cost of half the z-buffer precision. It didn't play well with my sky rendering code, plus it's not needed any any card newer than the voodoo1. 
MP3 In Fitz0.85 
I'm using the fitzquake085_mp3 build supplied in Baker's mp3 support tutorial but I can't get it to actually play any mp3 files. :(

I have no idea what could be possibly wrong. My soundtrack is in id1\music (or travail\music for that matter), and not within a .pak either. The playback related console messages appear for me, and I can use the mp3 commands just fine (without any errors that is). Nothing plays, still.

Is it as simple as turning it on with a cvar, or something? 
Travail Music 
You have to use these mp3s due to the file names:

They go in id1\music or travail\music folder. 
I have already renamed the mp3's myself beforehand. I also have the original Quake soundtrack in id1\music, also named track##.mp3. 
On Start Map 
If it says ...

"track name is 03"
"playing track03.mp3"

Then check the volume control in Windows.

If it is just saying ...

"track name is 03"
and doesn't say "playing track03.mp3"

Then you don't have track03.mp3

If you aren't using -nocdaudio and aren't getting either of the above messages, something else is wrong. 
It says:

Track name is 03
playing track03.mp3

It's not my sound being disabled from within Windows, either, I can listen to anything else just fine. 
Stupid Test 
Have you tried renaming any old map and replacing one? 
After testing several maps from several gamedirs, I can safely say it's not a mapside problem ;) 
If it says playing, you can rule out everything the user is doing as a problem. It isn't the map or anything else.

It's either the engine, DirectX drivers or possibly Windows settings somehow.

In the future, I'll get broader testing of the change to get wider feedback. This modification hasn't had broad testing at this point. 
Dear Fitzquake 
These are some features I think any Quake engine should have these days:

1. connect blah:port working well (this is the game that introduced online multiplayer after all)

2. NAT fix

3. Ping in scoreboard (it's just useful)

4. Support for fake CD tracks from ogg or mp3 files

The reason for having the basic multiplayer functions is that some people test their multiplayer-capable mods in Fitzquake because they're doing singleplayer maps as well.

The reason for the ogg/mp3 support (ogg is fine) is that finding and swapping and maintaining and storing CDs is a nightmare, especially since Quake CDs are getting older and rarer, and the Steam version doesn't come with the CD. 
My stupid test suggestion was made stupider. I meant to say 'mp3' not 'map'. 
An SP engine feature request / question.

Could we have global sounds play genuinely globally, and not only when in the player's LOS? 
Yeah, that should go into QSB 1.0.

Sorry for thread hijacking :-P 
Condebug Lag 
Unlike other ports, Fitzquake freezes for a couple of seconds when using the edicts command in conjunction with -condebug. 
Interesting... I'll Have To Check That Out. 
Edicts Command With -condebug 
That actually sounds normal enough. The edicts command spews a *lot* of text to the console, all of which is written to the HD using unbuffered IO when -condebug is enabled. I'd be surprised if an engine does anything other than freeze for a short while, in fact. 
the solution is to buffer that stuff, but the negative of buffering is if you crash before you flush the buffer, you end up not logging whatever was buffered.

I guess it depends on what the primary use case of -condebug is. If it's diagnosing a crash, vs. just a convenient reference for later use. 
Well, it works flawlessly in GLquake and Ezquake for example. Winquake freezes, too.
The delay varies depending on the OS. On XP, it takes roughly 40 seconds for E1M1, on Win7 almost 100 seconds (and I even had to close it from the task manager afterwards). GL seems to handle the buffering differently then? 
ah, good to know. I can look at how they do it, maybe i did break something. 
> Well, it works flawlessly in GLquake and Ezquake for example. Winquake freezes, too.

That's odd because it's the same code in WinQuake as in GLQuake... 
On my linux C2D box, there's a noticeable delay, but nothing really. Day of the lords with 144/166 kills takes less than 2 secs with -condebug. Whatever it is, i think it's in quore-0.3.0 too, which uses some fitzquake code. 
1s here (athlon 2 x2 240). Exe: 16:04:11 Jul 5 2008 on Lunix. 
One Difference... 
The original glquake generally would redraw the screen once for every line of text printed to console. For large dumps (like the edicts command) this took a long time, so I changed it to write everything first, then update the screen once at the end.

This is faster overall, but results in a small period of no screen redraws. Since in my testing it only takes a fraction of a second, I never saw this as being a problem. I suppose that with -condebug, it takes longer and this hang is noticable. However, the alternative is that printing 500 lines takes 500 render frames, i.e. like 5+ seconds.

I still haven't tested this so it may be there is some other dumb bug causing the lag. But that's my current theory. 
i guess there's some coding reason why you couldn't just make it print 100 characters at a time instead of all or nothing? 
probably the whole system needs to be re-thought. Quake has some weird linkage between console updates and screen renders which doesn't make a lot of sense; I think the original motivation was when you are disconnected there is no map rendering to trigger a screen redraw, so the console printing needs to do it.

Really we should just redraw the console at a fixed rate when disconnected, and then printing doesn't have to be linked to drawing. 
Reasons For -condebug 
I'm just curious as to the reasons why someone would want -condebug on all of the time. I suspect that it's not intended for this kind of general use (the presence of "debug" in the name kind of gives that away...) so it shouldn't really be considered performance-critical.

Seems to me that people might be using it to keep a log of events in a multiplayer game rather than it's intended purpose (checking console messages immediately prior to a crash - see the Quake readme) so maybe switching it to buffered I/O as a default is the way to go.

I'd suggest adding a "condebug" cvar, so it can be toggled if it causes trouble. Value 1 uses buffered I/O, value 2 uses unbuffered I/O. Also use unbuffered I/O if developer is 1. You can keep -condebug on the command-line, check it at startup and set the appropriate cvar value if you wanted as well. 
I Forgot To Add... 
...that the edicts command is a pathological worst-use-case as well. Expecting performance from it might be a little bit unreasonable.

And also that it's actually quite important for the intended use of condebug that it be unbuffered and write each line individually, otherwise you might not get the console message indicating what caused the crash. 
I'm just curious as to the reasons why someone would want -condebug on all of the time.

Multiplayer stats. Sometimes people want to log all the console output, and use an app/script to parse the logs for death messages or whatever (to generate a breakdown of kills, deaths etc).

Just one scenario where you may want it enabled all the time. 
Non trivial disk accesses are best left to the OS anyway.
One way with linux is "fitzquake | tee FILENAME", which duplicates stdout to a file. Neg_=!ke's worst case was with Win7 too.. which may still have the occassional disk performance issue, ala vista. Just out of curiousity, Negke - in win7, shut down everything which uses sound, run fitzquake with -nosound, and see if there's any improvement.

Still, 40 seconds on XP indicates there is a problem. Hmmm... I just tried a 170 enemy map by tronyn. Linux - 2 secs, XP - 7 secs. Perhaps it's the crappy vfat filesystem, which performs really bad when it's getting full ? 
I don't have it enabled all the time. It's only to get a copy of the edicts list - when looking for modelindex values, for example. The condump command often doesn't help here because of the console text limit.

stevenaaus: still freezing with -nosound, too. 
> Multiplayer stats. Sometimes people want to log all the console output, and use an app/script to parse the logs for death messages or whatever (to generate a breakdown of kills, deaths etc).

That's what I kinda suspected, and supports the case for changing it to buffered by default. 
Holy cow - by "unbuffered" i didn't realise we're performing a file-system open and close on every line written to console! No wonder there's problems. Hmmm... but tyrquake does it too, and i suppose others.

Anyway, i ran strace on quakespasm and tyr-glquake with
strace -ologtyr ./tyr-glquake -condebug +timedemo demo1
strace -ologqs ./quakespasm -condebug +timedemo demo1
which records all system calls.

Playing the demo, qs makes 666 (!) calls to "open", and tyr-glquake 218.
qs opens every file in the "quake" directory (probably checking for mods), which accounts for 83 "opens" on my box, but there's also a heap of qs-only opens which i think are related to the texture manager, and look like this

open("./id1/textures/cop3_4.tga", O_RDONLY) = -1 ENOENT (No such file or directory)
open("./id1/textures/e1m3/wswamp2_1.tga", O_RDONLY) = -1 ENOENT (No such file or directory)

(except the forum is inserting some "..." here)

I guess it's something to do with the fitzquake texture manager, perhaps using a file system open ?? I've never played with strace before, so i could be mistaken about something too. 
I guess the extensions are .tga and maybe .jpg? Fitzquake probably checks if replacement textures exist for each texture in the current map load. I have no idea but maybe one could change that to something that does not try open right away but simply pings for an existing file? 
About how fitz dies on win 7, perhaps the delay is so long it's causing a server timeout or buffer overflow of some sort. 
It Only Died Once 
I just tried it again and could continue/quit normally after the delay. 
I'm not sure it means anything actually. There's certainly a lot of extra "open" system calls - in the travail demo1 it's 275 for tyr and 1053 for qs and bakers fitzquake-sdl. But looking at ~when~ they're occurring, afaics they don't seem to overlap the repeated open and closes of qconsole.log. 
Open Calls 
External textures need an open and close call to load, so that's probably it. Especially as I doubt TyrQuake supports external textures. The number of open calls is quite likely misleading here, as each open call isn't necessariy a success, and one that fails won't be leading to any consequent IO. Measuring the number of close calls would give you a better yardstick.

A possibly better solution for the condebug thing would be to buffer the text into main memory instead and only write it to disk when the memory buffer fills. Even a 1 KB memory buffer would remove a lot of the pain.

Still need to keep an unbuffered version for crash diagnostics though, and I say run with my suggestion of the cvar and "condebug 2" for that. 
Yup, that works. :)

We're down from a lockup of up to 10 seconds to almost instantaneous.

I use a buffer size of MAXPRINTMSG and copy text into that instead of writing immediately to file. When a new update would overflow the buffer I write to file then, and reset it.

When disconnected from a server everything gets written to file immediately. This handles the final necessary buffer flush when shutting down, and I reckon it's not so performance critical anyway.

condebug 2 or developer 1 will force the writing into no memory buffer and unbuffered IO mode. 
bit of a storm in a teacup anyway, laugh.

Buffering sounds feasible... but a little overcomplicated with condebug and condebug2 or whatever, because using buffered output will screw up with a program crash. Code ?

Would using windows redirection commands suffice... or is there an fsync for win32 ? 
It depends on what condebug is used for. If it's only used for crash diagnostics then it's perfectly fine to change nothing. But if it's going to be used for general-purpose logging of multiplayer games then obviously something more needs to be done. In any event the default behaviour should be what people expect it to be, and if people are complaining about stalls with it, then that's obviously not the case.

Does anyone even use it for crash diagnostics any more?

I don't think that creating a condebug cvar with values of 1 or 2 is necessarily a complicated thing. Certainly no more complicated than all the crap that you had to do to get WinQuake working on an old SVGA card for example.

Oh, and code: (all in console.cpp) 
Mehhmmmm... It's a bit of futzing around, but looks ok. Are you flushing the buffer when Sys_Quit ? 
No need to cos it flushes anyway when cls.state != ca_connected which will be true during a Sys_Quit. 
having some odd problems with fq085 in windows 7.
host_maxfps is set at 72, but the game runs too fast. i tried lowering maxfps to 60 and even 10, but the game plays at the same (too fast) rate.

my desktop res is 1600x1200x32 so i run the game at that as well. tried both fullscreen and windowed.

the game runs without compatibility mode, but i tried xp sp2 and sp3 mode but it didn't make a difference.

the exact command line is:
fitzquake085 -heapsize 192000 -particles 20000 -nocdaudio -width 1600 -height 1200 +gl_clear 1 +scr_conspeed 32768 -bpp 32 +developer 1 
is it multicore? Apparently there's a clock bug in quake (including fitzquake) which screws up the timer if the process switches cores (since the different cores have different clock speeds sometimes? not sure exactly.)

Some engines claim to fix this, including DirectQ and Proquake, though they seem to have different approaches to fixing it. 
weird, i never had the problem in winxp even though i had a multicore processor back then.
the win7 i'm using is 64bit though, and my copy of winxp is 32bit..?

am i SoL for fitzquake then? o.o 
well i'm not sure, here is the info i have found about it (assuming it's actually the problem you're experiencing):

Here's a possible workaround:

Another possible workaround is to tweak host_timescale to try to get the time back to normal (or at least close) ... 
also Quakespasm is based on fitz 085 and might have this fixed (it uses SDL, which has its own clock code i think...) 
Brief description of the problem here:

The relevant part is: "What QueryPerformanceCounter doesn�t understand, we�re finding out, is multi-core processors. On an Athlon64 X2 processor, QueryPerformanceCounter will sometimes report negative elapsed time, for reasons that are as yet unclear. One theory was that the timing code was being shuttled between the processor cores and that the cores� time bases weren�t always in sync. That might indeed be the problem, but just setting the timer thread�s affinity to a single core doesn�t appear to be the solution.".

Also more here:

Using timeBeginPeriod and timeGetTime seems to be the way. You can test if these avoid the issues by running QuakeWorld, Quake II or Q3A on the same system: all of these use timeGetTime instead. 
Another good one here:

"The 1st glitch is that the returned value easily exceeds the boundary of the 64bits for the QuadPart, because current CPUs are so fast."

DirectQ's implementation by the way keeps the returned value from timeGetTime as a DWORD for as long as possible, using that in all calculations and comparisons, and only converting to float when absolutely necessary. 
that definitely sounds like the problem, and i can confirm that just setting cpu affinity doesn't do anything.
i think the problem might have more to do with 64vs32 bit rather than dual core though, since as i mentioned, the problem was non-existent on a winxp 32bit system with the same cpu (core2duo 6300). 
i nabbed direct fitzquake, but it still has that timing problem, so i tried out directq, which does not. (quake3 didn't have the problem either, but the sound stuttered, including ioquake3) 
Triple Posting, Sorry 
just wanted to also mention that quakespasm also was fine, so both directq and quakespasm are alternatives if you get the timing problem. 
Definitely QueryPerformanceFrequency and QueryPerformanceCounter then. I guess the SDL guys are well aware of the issues with them and used alternate approaches in the SDL timer.

Ironically the reason I did this in DirectQ was *not* to resolve the timer issue, but to deal with a completely separate matter (D3D manipulating the FPU control word). 
Thanks man, your engine worked perfectly for me and it made playing Q1 a pleasure again. Thanks for all the hardwork on this, awesome work :) 
glad to be of service :)

as you can see above, i still have some work to do :| 
i ran some mod via fitz085 and sometimes 'SV_TouchLinks: next != l->next' message popups

what is it? , i know this is somehow related to a teleporter, 
The Mysterious Engine Killing Teleporter 
I saw that message, too, a couple of times and wondered what it means. For apparently, it's not THE sv_touchlinks issue, the one that crashes unprepared engines (like in E2M2). Check the pent secret in my coag map for reference. 
it's a fix for what mh linked to.

However this fix ended up being a problem because it crashes White Room, so i need to figure out how to fix it correctly for my next release. 
My implementation of the more robust fix is here:

Works with both proxmap2 and whiteroom. 
Seems like the issue doesn't always necessarily lead to a crash/freeze then. 
Depends on the QC. Apparently calling remove while touching links is what can cause the lock-up, but no doubt it's possible to construct QC that does other lesser but still nasty things. 
It seems like quite a dangerous restriction on the qc, because a lot of the time you're writing code for which you have no idea if it's going to be run in a touch function or something safe like a think function instead. For example, a death function might get called from a collision or a hitscan attack originating from playerpostthink.

Still, it's nice to think that the original QC authors have made sure to take this instruction to heart. They would never call remove directly within a function used as a touch function, Especially not one as common and clearly labelled as spike_touch

Oh, wait...

In conclusion, I'd guess that removing one of the entities involved in the collision is generally safe, and it's when you start removing 3rd party entities that the problems arise. Can anyone who understands the e2m2 crash better than me confirm or deny that? And would making sure killtarget uses SUB_Remove on a short-delay think fix that case? 
I'm not certain that I'd see it as a restriction on QC, but more a case of QC authors either not knowing their tool or not testing well enough. It's possible to write software that crashes in any language, and QC should be no exception. If writing in C for example I'd conform to the rules of the language, and not expect something I write to always work just because I wanted it to.

If it breaks in ID Quake then by definition it's broken is my opinion, and this one breaks in ID Quake.

I think the short-delay think sounds like a good idea, but my own QC knowledge is quite limited. 
What I'm saying is that it's virtually impossible to write QC which guarantees it doesn't remove things during touches - calling that a case of QC authors either not knowing their tool or not testing well enough. is disingenuous. A mapper could potentially apply any function in the progs as a touch function to an entity, including SUB_Remove.

Even if you argue that this one is the mapper's fault, that's just the least subtle problem. When I cited the example of a death function which could be called from both touch and non-touch functions, the important thing to note is that the two cases are indistinguishable from the QC. There's no flag you can read, and you can't create one yourself because any function could be made into a touch somewhere.

If you were willing to compromise some responsiveness in removing entities and guessed at the most likely circumstances, you could probably reduce the amount of "remove during touch" by 90% compared to the original progs. But totally preventing it on the qc side isn't just a case of a little bit of care - it's so hard I don't even know if it's possible. 
Timing Issues 
Here's what's used in quakeworld clients like Zquake, that I've used in Qrack with 64bit windows 7 without any problems.

void Sys_InitDoubleTime (void)
timeBeginPeriod (1);

double Sys_DoubleTime (void)
static DWORD starttime;
static qboolean first = true;
DWORD now;

now = timeGetTime();

if (first)
first = false;
starttime = now;
return 0.0;

if (now < starttime) // Wrapped?
return (now / 1000.0) + (LONG_MAX - starttime / 1000.0);

if (now - starttime == 0)
return 0.0;

return (now - starttime) / 1000.0;

Hope this doesnt reitterate what someone else said as I didnt read the whole thread :P 
i think it's great to raise awareness of this issue as more of us pick up dual (or more) core processors and 64 bit operating systems. 
Cheat Commands.. 
regarding this feature from the readme:

- god, noclip, notarget, and fly can now be explicitly set. example: "god 0" will disable god mode

how possible would it be to make cheats, specifically notarget, be enableable from the command line? ie, by adding +notarget 1 to the end of your batch file or whatever so the map loads with it turned on... unless i am missing another way to do this? 
have you tried it? It sounds like it would work. 
yes, and no.. 
try the different possible orders of command:

+map e1m1 +notarget
+notarget +map e1m1

I'm not sure which order things are executed from the command line, it might be reverse order. And since i think "notarget" etc. gets reset at map load, that might be the reason it doesn't always work. 
And since i think "notarget" etc. gets reset at map load, that might be the reason it doesn't always work.

yeah that's what i figured. neither combination works (whether it has a '1' after it or not)

say i wanted to make it function like 'skill' - ie, carryable across maps, would that be qc-side or engine-side? 
+notarget +map e1m1 works ok on WinQuake. Best way however to make something carry across maps is to use the changelevel command instead of map. Unfortunately changelevel needs an active server to carry over state from so it won't work on the command-line. 
Running Fitzquake 
I need some help. When I try to run fitzquake it says it could not load gfx.wad I don't know what that is or what I should do does anyone know? 
are you trying to run fitzquake using a shortcut, or using a batch file? Or are you simply double-clicking on it directly? 
R_stereo 1 = Crash 
Looks like typing r_stereo 1 in the console in FitzQuake 0.85 causes a crash or some sort of infinite loop. 
hmm, i thought that was fixed already... Or maybe the old bug was r_lightmap 1 + r_stereo 1.

Anyway, i'll look at it when i get a chance (crunching at work right now, so it might be a while.) 
Music Issue 
Sorry if this as been answered already; I don't want to look through 400 posts.

How exactly are you supposed to get the music to work? I saw a link posted somewhere of fitzquake with MP3 support, but sadly the link is dead. 
Re: Music Issue 
I would also like to add that I do have a physical copy of Quake I, purchased about 14 years ago (god I feel old). I read on the Steam forums that the music should play if you have the CD in the CD drive while you play, though I'm not sure if that applies to fitzquake. I also tried mounting it to the E drive with Daemon Tools. 
It should play from the CD if you put it into the drive with the "highest" letter. So if you have 2 ROM drives F and G, you would put it into F. I am not sure if they need that ancient cd audio cable to the motherboard/soundcard or if those even exist anymore. 
Re: Music Issue 
Whoops, my Daemon Tools virtual drive was D and Quake I was E. Going to disable the virtual drive and see if that fixes it. Thanks for the fast reply. 
Re: Music Issue 
Yep, that solved it. Thanks. 
Re: Music Issue 
Yay, another issue. The music doesn't loop. Has anyone else had this problem and/or have a solution?

I tried using fitzquake085_mp3.exe but I have the same problem as poster #326. 
Thanks Necros 
profile during demo playback segfaults the engine. 
wait, that was 0.80.
Quakespasm works. 
Also When Not Connected 
What's the purpose of the command anyway? 
Re 406 
thanks for?

profile dumps stats on which progs functions are being called the most. you can use it to see which functions are using up the most cpu time and take measures to either make them simpler (thus requiring less calculations) or make the functions get called less often. 
thanks for making me try that command. 
Fitzquake Not Saving Config 
Good Day folks, pleasure to see Quake enthusiasts are still alive and kicking, even if the golden era of the mapping scene has long died away.

Simply put, upon modifying console cvars such as "scr_conalpha, r_lerpmodels, r_shadows" Fitzquake won't save this settings upon exit. I've tried setting 'Savedgamecfg' to '1' but to my frustration no effect. Any assistance would be appreciated.

Thank you! 
Gun Models Sit Below The HUD 
This bug has always befuddled me but in both conventional GLquake and Fitzquake the weapon models appear from below the HUD rather than sit above it. Needless to say, it looks awkward and I've seen a YT vid of GLQuake where this problem does not occur 
just put them in autoexec.cfg 
Skin Trashed (ARWOP) 
I thought this was fixed in FitzQuake 0.85 versus FitzQuake 0.80 but somehow it happened:


FitzQuake 0.85 on windows hosting a coop game in listen mode with maxplayers 2 playing ARWOP with other client being a QuakeSpasm client (not that I can see how that'd matter).

On ARWOP start map, other player's skin is fine but after advancing through changelevel teleporter to first ARWOP map, other player's skin is trashed. 
is this the heapsize thing? i had a problem with the player skin getting mangled (along with other textures) and solved it by increasing heapsize.
but your question leads me to believe this isn't the same thing. 
That looks more like a texture cache problem to me. 
More info: Fitz's texmgr uses CRC to identify matching textures, but CRC is horribly prone to collisions. RSA have published some nice public domain MD5 code that I would generally recommend be used instead. 
5 Mousebutton Support 
I'd love to see 5 Mousebutton support being added to FitzQuake so I can use it as my default SP engine. 
yeah, this! ^^^

well, actually if all engines supported more than just mouse 1-3 that'd be awesome. :) 
The reason for 5 MB support is that I have +/-attack aliases for the weapons. As far as I know, all good players, like speedrunners, need to be able to fire the correct weapon instantly, without having to cycle through them to select and then using another button to fire. That is just stupid and you'll never get good in Quake that way, you only think you are.

It's painful enough that there's no 'bestweapon' support, which is supported by ProQuake, JoeQuake, DarkPlaces and QRack, but it feels even more handycapped when I can't at least use the extra mouse buttons to create some simple aliases.

Yes, I know that there's this little group of people here that is against everything that's different from how Quake was in '96 in terms of movement and weapon scripts, but I'm bringing it up once more because if FitzQuake would have these things, it can become much more popular in the SP scene and people like myself would actually be interested in playing all these great looking maps (from the screenies it looks great).

If you wanna be oldschool yourselves, fine. But at least let people have the choice for THE shooting-experience that sets Q1 apart from the sequels...and perhaps all other FPS games for that matter. 
Bah, you don't need such binds for singleplayer unless you are a pussy. Just like FOV 90 (or the widescreen equivalent) is fine. 
fov 90 is evil 
Bah, you don't need such binds for singleplayer unless you are a pussy. Just like FOV 90 (or the widescreen equivalent) is fine.

bollocks on both counts 
..that was sarcasm i failed to pick up in time. hrm 
I actually think that in terms of features FitzQuake is pretty fine. Maybe it errs a little on the side of features for maps/mods while in development at the expense of features useful for actually playing the game, but that's understandable enough given the author's background, and overall there's nothing dramatically *wrong* with it (in terms of general features that is; I do think that there is some room for improvement elsewhere). A few nips and tucks in places is really all that it needs (let's have mouselooking enabled by default in the next version *please*). 
I welcome these types of requests... if I haven't added a feature to fitzquake yet, it's usually because my to-do list is huge; not because I think the feature is a bad idea.

Also Baker: Thanks for the bug report; is it consistently repeatable? I'll see if i can track it down. It seems unlikely that it's a cache/crc problem (player skins are allocated specially) but it could be anything at this point. 
I am serious. I used a bind to fire grenades with a key for ages but it felt like cheating.

Also I played with FOV 120 for a long time (because I was like OMG I CAN SEE SO MUCH MORE AND IT FEELS FASTER TOO!!!1), then I realise that it was idiotic. So I gradually went down again. 110 for a while, then 90. Now I have a widescreen monitor where ~110 is like old 90 according to some list by LH. 
@Metl Re: Skin Issue 
I haven't tried to cause it to do it again, but I'll try to repeat the issue to verify it wasn't some one-time weirdness.

There is an outside chance it could have been caused by something silly like FitzQuake briefly losing focus during startup while video initialization was going.

@ Spirit

The reason "bestweapon" is "acceptable" to a Quake conversative is because the behavior is already attainable via other methods. It just reduces the number of keys you have to use and makes it so you don't have to write complex aliases.

So the effect of a bestweapon command is:

1. Reduce the number of keys you use
2. Reduce the complexity of binds
3. Make that kind of functionality available to non-experts in easier fashion.

It's kind of like impulse 10 and impulse 12, really. Of video mode switching. It doesn't offer anything new, it is just less of a pain. 
I have nothing against people using it, I just think it is kinda lame. And potentially bad. If you eg have the SSG or SNG as "better" weapon than the SG/NG, then you are wasting ammo. How do people actually use it?

I am obviously talking about singleplayer. 
I like using 3 keys:

1. One that switches the strongest non-explosive weapon. Lightning gun, SNG, etc.

2. One that throws a grenade and then switches me back to some safe weapon that won't kill me in close combat.

3. Something that switches to the rocket launcher or a fall back to the grenade launcher. To deal with clusters of enemies or zombies.

Pressing 1 through 8 is a bit slow and inconvenient. And impulse 10 and 12, while very useful and bound to my mousewheel, aren't always a good fit.

Not having those available just means I have to play more conservatively and save more often instead of playing more naturally.

I'm sure different ppl have different preferences. 
Reading back through my last post it sound a bit harsh. I like to emphasize that Fitzquake is great and I'm thankful metlslime made it. It's just that I once read stuff about this 'bestweapon' subject and people where very nagative (and ignorant) about it.

So Spirit, since you are one of the ignorant people (heheh :P) I'm going to answer your question in this lengthy post:

The whole point is to have MORE then one weapon priority script for as many buttons as you'd like to use. I'm a QW player mostly, and I like to keep my SP config similar to my QW cfg.

I'll post some examples from my QW config. 'impulse' can be replaced by 'bestweapon' if you use Qrack or DarkPlaces:

alias +boomstick "impulse 2 1; +attack"
alias -boomstick "-attack"
bind MOUSE2 "+boomstick"

The above simply makes me instantly fire a long distance shot with MOUSE2. If I'm out of ammo, I hit with the axe, which makes no sense in this case. The boomstick is VERY precise and pesky long range weapon. With Quad, this is basicly the Railgun for Q1, which shouldn't be underestimated. In other words: you need a script and button for it so you can fire it instantly at any given time.


alias +rocketlauncher "impulse 7 5 3 4 2 1; +attack"
alias -rocketlauncher "-attack"
bind MOUSE1 "+rocketlauncher"

The above simply makes me instantly fire a rocket. If i'm out of rockets, I'll switch to the SNG and keep firing with that. Don't have nails? Then I instantly shoot with the SSG, etc. All by pressing just 1 single button. How cool is that?

But... what if an enemy is standing too close to me? I'd damage myself with the rocketlauncher... therefore:

alias +shaft "impulse 8 5 3 4 2; +attack"
alias -shaft "-attack"
bind SHIFT "+shaft"

The above simply makes me instantly use LG. Don't have it or don't have cells? I shoot with SNG, etc. All by pressing just 1 single button. This is my main button for close encounters. Why shift? Because when I don't put pressure on my mouse by holding down a mouse button, I can aim better with LG.

alias +supernailgun "impulse 5 4 3 2 1; +attack"
alias -supernailgun "-attack"
bind MOUSE5 "+supernailgun"

So I already had a button for close encounters, right? But what if I have LG and I'm in the water? I'd discharge myself. The best weapon underwater is the SNG... you can figure out the rest by now.

alias +supershotgun "impulse 3 5 2 1; +attack"
alias -supershotgun "-attack"
bind MOUSE4 "+supershotgun"

The SSG is awesome for close encounters, especially when you got no LG and even better when you got Quad (obviously) and want to take out most enemies with one single bang without damaging yourself.

THIS, ladies and gentlemen, is why you see these insanely good players change weapons so quickly and efficiently. It is superior to the old way.

Tere's one problem:

The only downside is when you play a SP mod that includes NEW weapons that sometimes replace standard weapons or toggle between standard and new. This can screw up some of the weapon scripts since a certain number will now stand for a different weapon that has a different function (long range instead close range, etc.).

A solution for that is either create a new .cfg or just change the MOUSE1 into the good old +attack and cycle through the weapons with mouse wheel or by pressing the 1-0 keys, which is very in-efficient but, I suppose, more realistic since in real life you also must take some time to switch weapons.

But then again: Quake isn't about realism because irl most ppl wouldn't survive jumps from great heights while losing only 5% of their 'well being' and you can't carry all these weapons either.

So I hope this clears up the big mystery about weapon scripts. It can be a lot of fun to experiment with them, including when you're playing against bots because bots can switch weapons REALLY fast.
I remember that, back in the day, the good old Reaper bots by Steven Polge gave me quite some problems. Nowadays, since I can switch just as fast as they can, I laugh about it and they are no threat to me at all. In QW I practice against Frogbot level 20 (highest) and I almost always win (1on1). 
I find I set up different binds for the keys around the wasd keys for different maps -- but then I am (or was, realistically) a speedrunner, so have a rather different outlook :-) 
Strange Mwh... 
Seems to me that it's best to have the weapon binds organized in such a way that pressing them won't stop you from pressing movement keys at the same time... So having these weapon buttons around your movement keys doesn't sound smart for a speedrunner 'cause it will interfere with your movement.

Anyway, I've decided not to play (much) anymore, so I don't really care if the support gets added to Fitzquake. 
Those Scripts Show Well 
why instant weapon switching is not a good thing. 
Z_Realloc: failed on allocation of 38912 bytes in quakespasm-20100821.exe

i know this is for fitzquake, but quakespasm is based on fitzquake.

happened in a mod and custom map. events that were going to occur as the crash happened:

a monster was about to spawn a new entity with a model that was precached but never used until that point.
it was also going to play a sound that was precached but never played till that point.
model was a standard quake model, but fairly large (maybe ~512 units across?) and used alpha settings.
sound was 44khz 16bit mono .wav file.

dunno if that's helpful. i was unable to reproduce the crash and have fought said monster many many many times before without ever crashing either. 
Z_Realloc: failed on allocation of 38912 bytes
It appears you're hitting the Z memory limit for some reason. You can use "-zone 512" in your start-up script (default is 256k), or we could bump it in future versions whenever that is. If it's not reproducible... 
what is z memory? is this specific to quakespasm? 
Zone Default 
On desktop operating systems there is really no reason to default the zone allocation in the engine to less than 1 MB.

1 MB provides compatibility with all mods.

I mean, the FitzQuake protocol uses a lot of memory itself and defaulting an extra 3/4 of MB for zone is nothing in comparison. 
...not to mention that lightmaps require 16MB...

To be honest, scrimping and saving on zone memory in that kind of situation is like fretting over a pinhole in a leaky bucket when there's a great big gaping wide rent on the other side of it. 
ok, so it's safe to just suggest to people playing my map to use, say, -zone 2048 just to be safe? 
The zone memory system can be replaced outright by standard malloc/free, and doing so shifts the technical burden from the player (where it shouldn't belong) back to the developer (where it should). I think there's one potential crash condition in the command processor with this, but can't remember specific details right now. It's easily worked around anyway.

True, memory fragmentation might become an issue, but the Big Dirty Secret of zone memory is that it is already prone to fragmentation as is (and actually contains code to deal with it).

One has to remember that Quake's memory system was developed under the constraints of running on a machine with 8 MB RAM and no virtual address space. A lot of the decisions made with it may have been valid for those constraints, but they're not so valid - and indeed limiting - today. 
what exactly does the engine use zone memory for anyway? it already has the -heapsize memory. 
as far as i know, the 'zone' command somewhat related with a large/messy .cfg files 

Type: Parameter

Syntax: game.exe -zone (bytes)

Description: Specify the amount of memory in bytes to allocate to holding dynamic information such as aliases.

Note: You will need to specify a value such as 512 if you experience game crashes because of too many aliases being loaded into memory. It is not necessary specify any larger value, since this value will work suffice.

Example: game.exe -zone 512
Key bindings, the command buffer (used for every time you press a key in-game, includes cfg files which go through the same system), cvar strings, aliases, and certain types of file loading. -heapsize (known as "the hunk" in the engine) is used for loading models, maps and other big things. A part of this "hunk memory" is also used for keeping permanent copies of a part of MDL files so that they don't need to be reloaded between maps.

This isn't the only memory that Quake uses. GLQuake in particular uses several fairly large fixed-size buffers for lightmaps and texture loading (about 8 MB total; Fitz uses more for lightmaps but less for textures), and all versions of Quake use other memory buffers outside of this system for console prints, network traffic (also applies to SP games which go through the same code; will use more if large map support is enabled, and also allocates for up to 4 players as standard, even if you never run an MP game) and other bits and bobs.

OpenGL itself will keep backup copies of all textures in system memory which are used to recreate the hardware copies if you Alt-Tab away, and which were also used for texture swapping in the Bad Old Days of low video RAM. The framebuffer itself may even be backed up by system memory; I haven't found anything to indicate either way.

Windows Task Manager shows a standard unmodified GLQuake with no command-line params as using about 66 MB of memory on my machine, and I doubt if it's much different on yours.

So in other words the amount of memory specified by -zone (or even by -heapsize) is really mickey mouse stuff compared to the overall memory usage of Quake. Being conservative about them seems to be a waste of time and effort these days, in particular when more or less everybody is guaranteed to have 256 MB as an absolute bare minimum, and 95% of people will have 1 GB or more. 
wow, there's even more going on than i realized...

thanks for the clarification, i'll just go ahead and start suggesting a 2mb zone or something from now on. :) 
Possible Bug? 
I'm in the process of porting protocol 666 into QuakeForge, and I ran into this (in SV_WriteEntitiesToClient):

//johnfitz -- don't send model>255 entities if protocol is 15
if (sv_protocol == PROTOCOL_NETQUAKE && (int)ent->v.modelindex & 0xFF00)

Shouldn't that be sv.protocol? 
sv_protocol is the cvar, IIRC. 
> Shouldn't that be sv.protocol?

I suspect that you're right. sv_protocol is the command whereas sv.protocol is the currently active protocol which only gets updated when a new server is spawned. Using sv_protocol here would mean that server messages would go all wacko if the protocol was changed while a server was running. 
that's a mistake. I'm not sure what happens if you compare the cvar directly rather than cvar.value ... it's a struct which means are you comparing the first element of the struct? 
.. is not a cvar, it's a global associated with the sv_protocol console command which sv.protocol is assigned to at server creation. So the comparison in SV_WriteEntitiesToClient() really needs sv.protocol and not sv_protocol. 
Yeah it's been a little while since i looked at the code. I guess it works as written but is unsafe. Should be sv.protocol. 
Ha ha ;>

Nice to see QuakeForge is getting updated. 
Due to a series of unfortunate events, QF more or less went into hibernation for a few years, though I kept poking at it occasionally (there is no year with 0 commits). I've been fairly busing hacking on things this past year, and lately, the maps on quaddicted have given me some real motivation :). git helps a lot, too (easy branching and stash).

I'm glad to have been of help. 
When running Fitz 0.85 with -quoth, it's impossible to switch to the id1 gamedir with game id1, because the engine thinks that the Quoth dir is the id1 dir, and thus nothing changes. 
Not A Bug 
If it weren't like this, certain releases wouldn't work they way they do. Those that come with an extra pak/mod dir but still require quoth as a base. 
But I Know That 
I'm just saying that typing 'game id1' in the console should probably revert that behavior. 
that was implemented by request because BJP quake has it. ideally there would be ways to turn that stuff on/off in the console. (maybe multiple gamedirs like darkplaces would do it.) But to get the alternate hipnotic/rogue statusbars, you'd also need special variables for those. 
i was really happy you added the -quoth thing, but i guess it does make more sense for a more generalized multimod loading order thing.
maybe there'd be a way to detect what kind of hud layout to use based on what the gfx.wad contains? or are they all the same? 
if (hipnotic || quoth)

it would be awesome if it wasn't determined by folder name of the mod so you can make other mods that use the hud without having to get people to do a -hipnotic -game mymod.

checking quickly, the gfx.wad in hipnotic has all those extra weapon icons and id1 doesn't, so they do use different gfx.wad files. is that possible then, to look at what entries are in the wad file and then use an appropriate hud? 
Hey, I have a widescreen monitor (1920x1080) and changed my resolution in FitzQuake accordingly, and it works fine, except the UI (HUD, console, main menu) is terribly tiny. Are there any commands to prevent them from being downsized while maintaining the proper resolution? 
Sort Of 

pretty self-explanatory... '1' is the default value, '2' doubles the size and so on. i find 1.5 a nice value 
Just what I was looking for, also nice to be able to adjust the speed of the console. 
what's that command? :) 
Also, when I started up FitzQuake just now everything suddenly moved twice as fast, as if host_framerate had been altered, even though it hadn't. What gives? 
you must have a 64bit system and dual core (or more) cpu.

atm, there isn't a solution that i know of apart from using a different engine. you can use quakespasm for now, which is basically fitzquake, except it uses some sdl stuff for timing which gets rid of the problem.
apparently, the way glquake (and by extension fitzquake) calculates time is with some method that doesn't take into account more than one processor. 
Yeah, I do. I normally use DarkPlaces anyway, just thought I'd give FitzQuake a shot. There was nothing wrong with it earlier today though, and I didn't disable any cores or anything in the meantime. Strange... 
i think i recall some people saying disabling additional cores worked for them, but that didn't work for me. 
> Also, when I started up FitzQuake just now everything suddenly moved twice as fast, as if host_framerate had been altered, even though it hadn't. What gives?

Quake's default timer is shit and Fitz still uses it. :( 64-bit, multi-core or power saving will wreck it, and it really needs an engine-side fix. 
iirc, during the discussion, it was mentioned there's an alternative to the way stock glquake does timing without having to switch to sdl. 
But pasting a .dll in the Quake folder is easy... 
And QuakeSpasm is simply FitzQuake + a bunch of nice fixes. If you like Fitz, you'll like QS as well. It doesn't alter the look and feel of FQ. 
SDL is a good idea anyway, for cross platform support and for audio stuff etc (able to use a lot of different output devices / sound systems etc). 
Slightly Improved FitzQuake 0.85.exe 
1) Clock fix
2) Session to session command line history via the up arrow
3) Half-Life .bsp support
4) Rotating brush model support and extra chase camera options

Source included, of course, and has 2 project files: MS VC++ Express and Code::Blocks

Mostly made to satisfy someone who wanted Half Life map support in FitzQuake. 
5 Button Mouse Support 
5) 5 button mouse support

^^ Add. Forgot to mention. 
Session to session command line history via the up arrow

i noticed this in quakespasm and i thought i was going insane for a while before i realized what was going on.

5 button mouse support

you are a quake hero for a week and three days. 
Is the next Fitzquake going to have Nehahra support? 
It's Possible... 
I've considered it before, but it was never a high priority. I still need to generate a list of necessary features (e.g. spr32, special protocol for the demos, fake cvars so the fog works, alpha (already done), not sure what else...) 
Nehahra support is quite tricksy and it doesn't sit too well with more modern engine features. Aside from anything else it does evil things like changing the protocol without defining a new PROTOCOL_VERSION; obviously a relic of earlier times. 
There's A Bug With Weapon Anim Interpolation 
i can't quite figure out exactly what causes this, but as i am building a map, once the map reaches a certain point in size, weapons stop interpolating their animations.

yeah. wtf indeed. :P

is there maybe like a certain number of slots that fill up for models to interpolate? i haven't seen monsters being affected by this though.

this happens in quakespasm and rmqengine as well as fitzquake085. 
weird. I can't even think about how that's possible :| 
But Uh... 
can you send me a map that causes this bug? Or is there an already-released map out there that does? (if it's due to size, maybe warpspasm or something?) 
That's wacky. Must be a protocol thing then as RMQ's MDL renderer is significantly different. 
i did actually notice that on an unvised e2m4rq (which is massive) in rmqengine a few months back. seemed to disappear once everything was vised though 
Model Progs/centurion.mdl Not Found 
Rubicon 2 looks flashy ;>
But regards the demo crash, is there a reason "Model not found" doesn't throw a Host_Error ?

- Con_Printf("Model %s not found\n", model_precache[i]);
+ Host_Error("Model %s not found\n", model_precache[i]); 
Probably A Silly Question 
can fitz play nehahra? 
Unfortunately Not... 
it's on the wishlist though. 
Ok Cool 
I couldnt find it in the readme. Would be a good feature IMHO. Aguire/Nehquake engine doesnt appear to be widescreen friendly. 
and Directq doesn't support the neh Fog, so we are waiting for a "perfect engine" lol 
Load Last Save Upon Death 
It this possible by some toggle or console command I'm missing somewhere? Would be very handy. 
there's no way to keep track of the last save spot (aside from quicksave) in the qc, and it's the qc that handles what happens when you die. (for button presses and reloading the map).
if the engine had some extended builtin function 'getLastSave' then it'd be a simple matter to hook it into the qc. 
That's a shame :( Thanks for the response. 
Are You Asking As A Player Only? 
or for a mod?

if you implement an autosave system, you can hook that in easily enough so that pressing fire when dead loads the last autosave.

also, if you coopt the quicksave key and redirect it to an impulse, you can assign a function to quicksave as normal, but then you can mark a variable somewhere to remember that the player has quicksaved and to load that save when dead. 
Late reply - As a player only. It's simply for convenience since Duke/Doom/HL do it, I've wondered if it were possible in Q1. 
I Implemented That 
as an engine patch on Quakespasm (but it could be applied to any engine.) It's really nice; keeps the gameplay pace high when you die - just shoot and you're back in the game :D.

The patch also autosaves every so often, based on a heuristic (picking up health = probably a good time to autosave)

Here is a windows binary:
and the source: 
I just did it in DirectQ as a restart2 command; it tracks the name of the last save you make and just reloads it if something valid was in there. Probably not very robust (what if the load fails?) but hey! - it's a hack anyway. 
if you're gonna add it, you should really make it controllable via qc instead. :(

should be a 'getLastSave' command that outputs a text string or something.

restart2 works i guess, though. you just call that in qc instead of restart. 
Probably not very robust

Make sure the save is from same map that the player died on maybe :) 
Make sure the save is from same map that the player died on maybe :)

(...rushes to source code...) 
probably you should invalidate the "last save" if you load a map using the map command, or the changelevel command. So you only get a valid save again if you have saved/loaded a savegame since your last map/changelevel commands.

save/load -- sets the relevant savegame as the last valid save

map/changelevel -- clears the last valid save, now restart will go to the beginning of the current level as usual. 
could you look at these demos

since i've got a new pc, some strange issues chases me while i'm using fitz085

the 1st one is very strange the plat/lift behavior

and 2nd, weird navigation on an uneven surface(s) 
Bet you anything you've got host_maxfps set to something higher than 72. If so, set it back to 72 and they'll go away. 
thank you 
For Future Consideration ... External .Ent Support 
The ability to load quake\id1\start.ent or whatever with just the entities in a text file instead of loading from the map.

5 second cut and cut paste easy tutorial: 
Icons Change 
I've noticed that whenever I run fitzquake, the icons of quicklaunch/taskbar shortcuts change to random others, such as my notepad icon changes to the MS admin icon, and my firefox icon changed to the camera and printer devices icon, and my open folders icon changed to the media player classic icon. I am running windows 7 64 bit. I also noticed this on my old computer from a few years ago, but I never reported it. That computer was running Vista 64bit. Thanks! 
Resetting My Configs 
FitzQuake doesn't save any cvars I enter in the console, so I have to reenter all the variables every time I start it up, like scaling menu/hud/console, which is incredibly annoying. I noticed someone else already posted about the same problem, with the solution of entering the variables into autoexec.cfg, but that doesn't appear to work for me. I have autoexec.cfg as well as the FitzQuake executable in my main Quake folder, which I presume is correct?

Appreciate any help. 
it must be in the id1 folder for it to work. :) 
Sweet, that did the trick :) 
Another Mapper-oriented Idea For Future Consideration 
Allow mapper to freeze game world like DarkPlaces existing feature. Quicky engine tutorial: 
Or something. It seems Fitzquake treats the self.message thing in secret_touch incorrectly. So what happens is stepping on a secret door (without a message field of course) creates an empty centerprint. This is annoying because it beeps for no reason. Can some verify? 
Well Ok 
Apparently it's not Fitz's fault but something that happens in conjunction with my id1-devmod. Sorry. And I only just noticed the "use mouse" thing in the options. Is it +mlook or mouse capturing in windowed mode? 
Using OPEN_ONCE instead of wait -1 seems to solve it. 
Re: Glitch 
negke, the glitch may not be a FitzQuake only problem. The problem could be the qc assuming string_null is null all of the time. Unfortunately, this may not be true.

string_null, and all other global strings, are no longer null after loading a savegame. If the qc checks for string_null assuming it is null, it may not work after loading a savegame. 
Request: Raise Default Max_edicts 
One of the maps in Tronyn's upcoming Unforgiven can exceed the default of 1024 max_edicts. Can there be a minor update to Fitz that increases the default to 2048 or even 4096 max_edicts?

I know of the max_edict command, but I bet Tronyn and I will read many complaints about one map not working because someone failed to read the readme. 
If you're refering to the max_edict issue in unf2, it seemed more like an accidental thing, a glitch in the code or some misfiring script. The map itself feels like the least extreme of the pack. Even unf3 'only' starts at ~800. Or what is the exact reason for the edict explosion? 
Hm, I guess you could write "max_edicts 2048" in the quake.rc to be safe? 
Edicts Explosion Due To Snow Effect. 
unf2 has light snow, and it makes the map look pretty, but requires a high number of edicts. With the snow, max_edicts peak a hundred or two below 2000. Related to this is the rain in arcanum1. This is why rain falls in clumps in arcanum1. If I had an edict for each rain drop, edict count would be very high and would not run in FitzQuake without increasing max_edicts. For unf2, I cannot make the snow fall in clumps and still make it look good. Turning on corpse removal will disable the snow.

Other engines with higher default max_edicts do not have this problem. 
Oh Right 
I didn't think about that. I assume it wouldn't be possible to make the snowfall trigger-based or something and still work/look the same? So that snow flakes are only generated within the current trigger volume. And each outside area is surrounded by a large trigger. 
One of the maps in Tronyn's upcoming Unforgiven can exceed the default of 1024 max_edicts. Can there be a minor update to Fitz that increases the default to 2048 or even 4096 max_edicts?

I know of the max_edict command, but I bet Tronyn and I will read many complaints about one map not working because someone failed to read the readme.

i kind of wish fitzquake defaulted to protocol 666 (it's own protocol) instead of defaulting to old quake protocol.

i remember back when i released ne_tower, some people didn't change to protocol 666 and some items were invisible to them or something.
the thing is that you can't just force protocol 666 in a cfg file because other engines have their own protocols and this causes crashes.

we need a better way to generally tell one engine 'i need extra stuff' that won't cause problems in other engines. 
Default Protocol 
Fitz does default to 666 on map load. For demos it will use whichever of the two protocols the demo was recorded with.

One potential problem with a higher default max_edicts is memory usage. The size of an edict is variable, and the way they are accessed by the engine (in particular the VM) makes true dynamic allocation incur a cost in code complexity. Set the default too high and memory costs will soar, even for maps that don't need to use so many. 
John, do you plan on adding .mp3 support to FitzQuake? In its current state, the engine fits to my needs perfectly apart from this single issue. It's getting tiresome to insert the cd everytime I want to load up a map. 
Key Door Sound 
Could it be that Fitzquake doesn't play the proper sound when opening a key door? I think so. 
Thanks! It works without a hitch. Working link for the .zip: 
that is a quakec bug. 
But it works in some clients. Old winquake for instance. That's how I noticed the difference. 
you mean that unlocking sound? afaik, it never worked correctly.

in the qc, the unlock sound is played on the same channel that the door move sounds are played on and it is played before the move sounds and it's all done on the same frame, so the engine never even 'sees' the request to play the unlock sound.

are you sure it works in winquake? i can't think of why it would. 
Yeah, You're Right 
My bad. I must have toggled the console at the right moment or something. 
i've been experimenting with a rain effect and i'm pretty happy with what i've ended up with.

essentially, it's an edict intensive method: spawn one entity with a sprite model and treat it like a particle for every rain drop.

looks pretty sweet, and with increased max_edicts, it's not a problem since even large areas will only take up maybe 800~ edicts (since max is 32k i'm not worried at all.

problem is that it seems like the engine can't cope with drawing all those models because lightning bolts flicker or just don't get drawn at all.

it's weird because other temp entities like rocket explosions are drawn just fine. it's only the beam effects.

this happens in both fitzquake085 and quakespasm.
using sv_protocol 666 and max_edicts 8192. 
so you're saying -- you have X number of lightning bolts being drawn correctly, then you add your many raindrops, and the raindrops are fine but it causes the lightning bolts to not be drawn? 
Sounds Like... 
MAX_VISEDICTS is defined to 1024 in Fitz. 
well, so this might be the problem:

The lightning bolts are made up of individual segments. Each segment requires a new "temp entity" to be spawned which also occupies a "visedict" slot. So if you reach MAX_VISEDICTS, or MAX_TEMP_ENTITIES, you the rest of the beam segments and any other beams after it will not be visible.

The raindrops wouldn't affect your temp entity budget, but they do use up visedicts if they are visible. So the addition of all these raindrops has probably used up the visedicts (max 1024 in fitzquake) before the beams can get fully drawn. (I believe the beams are added to the list after everything else, so they are the first to go.) 
so you're saying -- you have X number of lightning bolts being drawn correctly, then you add your many raindrops, and the raindrops are fine but it causes the lightning bolts to not be drawn?

yes, this is it exactly. :) 
So Yeah... 
aside from using another engine or modding fitzquake, i would recommend trying to optimize raindrop count by only spawning rain when the spawner entity is within a sphere around the player (e.g. 512 or 1024 units), since far-away drops will be less visible anyway. Unfortunately, that's probably the best approach :(

Or switch the behavior so up close the drops are independent, but past the middle distance you spawn fewer instances of a second model which is a clump of drops? 
some experimentation is in order i guess.
thanks anyway. :) 
Max Edicts, Etc. 
FitzQuake 0.85 protocol 666 supports 32000 entities/edicts, 32000 being a rather huge number. Server edicts eat up a ton of memory, client entities not so much.

Throwing one idea out there ... well, less of an idea since I've already done it, is to count the entities in the entity string [while ...strstr(entities, "classname")] and then on the client side use the server's estimate if Requires moving allocation of sv.edicts to after loading the map and another block of code. Beats allocating 8192 edicts or 32000 and also beats running out of edicts. You might call this the "max_edicts 0" option (if not specified, "guess").

r_nolerplist or whatever it is called. This code doesn't properly check for null termination and can drift off into memory beyond the cvar string. Just by chance it actually doesn't do this with the default string. Not really important, but throwing it in the thread.

I hope someone comes up with a "standardized" rain/snow effect that can be used that ... well .. isn't QuakeC. Snow/rain fall into the fog/particles department and if not, fall into the "view presentation" and not the 3d world. Can you imagine how large a demo would be with 2000 rain particles being written every frame.

I know there isn't a standardized plug-and-play compressed and predictive protocol for coop at the moment, but I kinda of think this is not far off (considering the list of hated engine challenges/problems has shrunk considerably in the last 2 years or so).

Someone needs to solve the rain/snow thing. It looks so nice in Nehahra ... and then turn it into 3 or 4 worldspawn params or optionally as a "rain" or "snow" command in the console. 
I hope someone comes up with a "standardized" rain/snow effect that can be used that ... well .. isn't QuakeC. Snow/rain fall into the fog/particles department and if not, fall into the "view presentation" and not the 3d world. Can you imagine how large a demo would be with 2000 rain particles being written every frame.

i hope NOT. i tried using Darkplace's rain effect and it's just terrible, mainly because there's just no control over the thing.
if you want to have your own simple drops next to a wide open torrential downpour, your drops end up looking different. the current implementation i have for DP doesn't use the DP effect at all.
Built-ins suck! :P
or if you're going to do it, you must give total control over it so it can be properly integrated into the rest of a mod. ie: the ability to specify what model to use (not just a built in effect), initial speed, how much gravity affects it (if at all), collision and fine control over when and where a drop falls. 
Would FTEQW's particle system help? 
have you tried actually talking to Lord Havoc about the rain effect?

I can second FTE, it is an awesome engine and Spike is an awesome guy. IIRC FTE recently had its renderer rewritten and should also run more stable now than in old times. Give the nightly builds a try.

otherwise you can always use func_emitter from extras with a rain sprite you make yourself (e3m1rq did this, but the raindrop model sucked).

Maybe DP's effectinfo.txt allows you to alter rain drops? 
have you tried actually talking to Lord Havoc about the rain effect?

no, and, i don't want to. not really interested in having to chase after someone else for personal changes (and likely bug them too).

as for fte, i was told it wasn't really a modding engine, so i didn't invest too much time into trying to figure it out.
also, it turns off mouse accel in windows and doesn't re-enable it when the engine closes, which... i don't know, why does it even disable it in the first place? just needlessly annoying.

anyway, yeah, my foray into fancy custom engines was not a fun one, so i hope FQ stays close to what it is currently. even after all this time, i still consider it perfect (except for that multicore timing problem, which is easily fixed). 
How Is The Multi Core Problem Fixed? 
I quickly searched through the thread and didn't find threw answer. :x 
no idea, personally. but from what i recall when the problem first surfaced, it has something to do with the timing function (or whatever) used, and replacing it with a newer function fixes it.
quakespasm has this fix, which is what i use.
i believe baker may have made a version as well? but i have no idea where to get that. 
Texture Transparency? 
No texture transparency support of any kind? TGAs alpha chan dosent work, couldnt find anything about it in the radme either. (((
Any hope of getting texture transparency for fitzquake at all? 
Yeah, there's hope. How do other engines do it? Any tga with an alpha channel gets rendered with transparency no matter what model or brush it's applied to?

The main work in implementing it is creating a sorting algorithm for transparent objects (and maybe for individual triangles) a nd then rendering them in the right order. I assume most engines either don't bother or they do it per-object only. 
To Confirm This Is Hard 
This is not solved in, for example, darkplaces*: polygons with alpha transparency do not render properly against triangles from the same model behind those polys. You end up seeing the background behind the model rather than the rest of the model geometry as expected.

*At least last time I bothered checking... 
I solved this in DirectQ but it does involve sorting everything on a per-poly basis (rather than per-model, which would be standard for most). It's not hard but it is messy. You should probably also sort particles, water surfaces, sprites, MDLs (which I left sorted per-object rather than per-tri for performance reasons), and possibly other stuff into the same list.

(Aside: There is still a case where 3 or more triangles could partially overlap each other, and which no sorting algorithm could solve. That needs proper order-independent translucency, at which stage you've raised the hardware requirements for the engine so high that few enough people would be able to run it.)

What I did not do was allow for any TGA (or other type) with an alpha channel to have transparency. There are a lot of other BSP format-related problems with this, and ultimately Q1 BSP is just not set up for it. If nothing else, these polys would need to be treated the same as water for visibility determination/portalization, but still be able to generate clipping hulls, which I believe Q1BSP just does not allow at all.

You would need to make them "*" models which is one potential workaround. It would probably also make sense to have a texture naming convention for them, so that you're not slowing down load times by scanning every TGA for alpha (although some engines already do that anyway). 
"Any tga with an alpha channel gets rendered with transparency no matter what model or brush it's applied to?"

Yes, apparently thats what they all do.
DP has no problem sorting huge number of bmodels with alpha. But slapping the translucent tex on the entire ground caused some minor sorting issues. 
Spd, Is That You??? 
Very nice screenshots, pretty dark though. Good to see you're working on a town map - I don't have to feel bad for not finishing mine then. 
Sv_main.c World Sub Models Models > 999 
sv_main.c world sub models models > 999 can overflow string buffer.

szo fixed this in Quakespasm: 
good catch, thanks for the info 
Fitzquake Crash 
I noticed that Willem's White Room map hard locks fitzquake085 (have to ctrl+alt+del) but not fitzquake080. Happens for Negke also, I've got no idea why just giving a headsup :) 
Ah :) 
Ok its a known issue, I missed that! 
RE: Fitzquake Crash 
Fixed in quakespasm since version 0.85.4. See here for the fix, which is actually from quakeforge: 
Shambler's Lightning Animation Not Interpolated 
FitzQuake 0.85 on Windows: Shambler's lightning attack animation not smoothed, even with r_lerpmodels and r_lerpmove enabled and r_nolerp_list cleared. Not a big deal, but still. 
That's intentional; Fitz doesn't interpolate when an entity goes into a muzzleflash frame. 
i think it might be something else (or the muzzle flash no lerping is linked to .owner in some way?) because checking the 106 progs, the muzzleflash is played on the shambler, not the lightning entity. 
New Feature Idea 
Just a quick brainfart, thought I would post it to see if anyone else found it interesting. No idea if its even possible or easy to implement! :)

A worldspawn key for map specific colour grading / tinting.

Something like _colourmod R G B that will tint the screen image to the mappers preference. So if you have a slime/green themed map you could accentuate the greens/yellows slightly to give a customized final look. Together with fog some interesting visuals could be achieved.

/2 pence 
uhhhh what? you mean tinting the screen like a v_cshift command but automatically? 
I've never heard of this command :) I just tried it but im unsure what values it wants to do anything ;)

A suppose a simple explanation of what im on about would be that you could enter a theoretical "_colourmod" with values of .5 .5 .5 which would desaturate the entire image by removing half of every colour. 
It's The Muzzleflash... 
mh is correct: the shambler attack has 7 frames in a row with EF_MUZZLEFLASH enabled. Fitzquake is set up to not lerp frames that have that effect, because usually it's accompanied by muzzle flare geo poking out of the front of a gun, which looks bad when lerped (i.e. on grunt, enforcer, and all player weapons.) Unfortunately it is an unnecessary feature for the shambler lighting attack.

If you don't like that feature, you can set r_lerpmodels to 2 instead of 1 and it should ignore those special exceptions. But, this will also disable the r_nolerp_list feature...

Ideally (note to RMQ team), there would be a way for quakec to tell the engine when lerping is acceptable (EF_NOLERP?), and even which frame to lerp to, and how long to spend lerping. This would only work with progs.dat written to provide that extra information, which is why all quake engines have to make various assumptions to try and make lerping look good. For example, Fitzquake uses .nextthink to guess how long to spend lerping, and EF_MUZZLEFLASH and r_nolerp_list to decide when it's a good idea to lerp. 
With DirectQ I decided that if a vertex moves 10 or more units from back to front between frames 0 and 1 then it's not interpolated. It works well with all current content, but of course something is going to break it at some point in time. That's something I accept for now. I didn't bother with enemy muzzleflashes.

For RMQ we're building new content and it can be made interpoaltion-friendly from the get-go. 
this is done per vertex?
like, if a zombie swings it's arm, the shoulder and upper arm are lerped, but the lower arm and hand (since they are moving fast) are not? 
JoeQuake Lerps Per Vertex 
And in some cases it works great.

It some cases, if you rapidly press pause and then unpause ... you see the most foobared looking thing imaginable.

I'm talking view weapons here. 
It's a little more complex than that.

First of all it's only done with the view model. The check is actually run inside of R_DrawViewModel so that's absolutely guaranteed: "if (!mod->delerped) {Mod_DelerpVertexes (mod); mod->delerped = true;}" or something like that. The viewmodel also runs a slightly different code-path, so even if somebody did decide to use zombie.mdl as a viewmodel (those wacky modders!) it's also guaranteed to not happen with regular zombies too.

Secondly, it only checks vertexes that move between frames 0 and 1 of the model (if the model has only 1 frame - and there are some - it doesn't bother). So no matter how much a vertex may move in any other frame doesn't matter and doesn't affect the result; it's only "if it was in this position in frame 0 and in that postion in frame 1" that counts.

Thirdly, it's only movement in the back-to-front direction that is measured. So apply aliashdr_t::scale and aliashdr_t::scale_origin to the positions in each trivertx_t, then check the difference between element[0] of each - over 10 indicates a positive result - this vertex was way at the back of the model in frame 0, in frame 1 it's way out at the front, so we don't want to interpolate it.

The result from this comparison carries through to other frames, and so far it's proven to be valid with all ID1, Rogue, Hipnotic, Zerstorer, Quoth, etc weapon models (it even worked perfectly with Hellsmash) - it successfully removes interpolation from the muzzleflash verts, and only from the muzzleflash verts.

I have an idea that a nicer implementation might be to weigh the blend factor depending on the distance between the current and previous verts for any pair of frames; that could be run on the GPU in a vertex shader, wouldn't need any special case handling, and it's something I may experiment with some day. 
oh ok, i didn't know if was only for view models.
sounds like you've got all the bases covered i guess; i've never looked at the engine code much, so i don't really get the specifics of it all. 
So that's why the lightning effect on the RMQ Cauteriser interpolates, even though that's not intended.

So with the proposed solution it'd just be a case of moving the lightning part of the mesh very far back in the 'miss' frames. 
Yup; just move it as far back as possible in frame 0.

I tried the vertex shader idea, and it works fairly well. Things are occasionally jerky during dying animations, but it's a reasonable enough general solution. I think I might save it up as a fallback if my current method ever breaks. 
Smooth Lite Bolt 
Is it anyhow possible to smooth the movement of the lightning gun bolt (when you fire and sweep around with that weapon)? 
that is a different problem from the view model interpolation issue.

i got around this problem in ne_ruins by changing the lightning code to update the beam position every frame. this gives an extremely smooth smooth sweep. you also need some code to maintain the old 30 damage per 0.1 seconds as well as a way to keep track of missed damage (if the player gets less than 10 fps) but that's not a big deal. 
The Bolt Effect... also framerate-dependent. If you're running at 20fps it looks different to if you're running at 1000fps, because the engine assigns each bolt segment a random angle each frame. 
yeah, that bugged me a lot. i've been building custom beams out of entities lately. more control that way too. 
FritzlQuake - Most Captivating Quake Experience Ever 
Literally now. Ever since installing the latest Nvidia driver (I believe), FQ doesn't work in fullscreen anymore. The screen is just black and there are no sounds. I can't alt-tab or reach the task manager to close it. Apparently Windows is still active in the background, at least ctrl+alt+del and random key mashing seems to do something - i often hear the Windows logout sound - but it's impossible to bring it back, so only a reset helps. No problem in -window mode, and QS can be run in fullscreen fine.

I had somewhat similar problems with DirectQ every now and then. However, there the monitor would at least show an "out of range" message.

Any idea what I could do to fix it - or get more information on what's going on? 
have you tried forcing the screen res with -width and -height? 
What Necros Said 
Mind you, I find that unless I am setting it to the monitor's native resolution, changing the res via the command line will cause a black screen, but the app hasn't locked up - I can alt-tab back to it and it fixes itself. 
Also try changing the video settings stored in the config files to what you want if the command line force doesn't work. Might be worth a shot. 
I'd double-check what you're setting for refresh rate and bpp too, as it definitely seems like you're trying to select a mode that hardware acceleration isn't available in but that is nonetheless being reported by the engine (perhaps one of the low res modes?) 
A Request Re: External Textures 
is it possible to scan the 'wad' key in the worldspawn to get the texture wads used, and then, when loading external textures, also look in folders named the same as the wad files?

map is mymap.bsp
so my worldspawn has:
'wad' 'gfx/common.wad;gfx/quake.wad;gfx/hipnotic.wad'

so fitzquake would look in:

this would make keeping external textures folders organized a simpler task, especially if you have a map pack with more than one map referencing the same texture without having to resort to mixing all the packs together into /textures. 
'wad' 'gfx/common.wad; gfx/quake.wad; gfx/hipnotic.wad'
but all together, without spaces (like normal). 
I personally think it's a more elegant approach than using the map name, but it has the disadvantage that when multiple wads are used it must attempt an extra file search for each extra wad. Depending on how many textures you have, how many of those are already cached, and how many image formats you support, it could measurably slow down map loading.

There's also the fact that using the mapname is standardized in so many texture packs.

I suppose you could do both and cache a qboolean for whether or not the search path exists after the first attempt. 
Depending on how many textures you have, how many of those are already cached, and how many image formats you support, it could measurably slow down map loading.

From, say, 0.5 seconds to a full 1.0? :) 
You always say that like optimization wouldn't matter and was pointless if it doesn't have an highly noticable effect. But look at DP, for example. It gradually went up from a couple of extra 0.5s to 'let's compute everything from scratch', and now loading even a simple map takes 30 seconds. 
Oh, I agree. and I'm really sort of half trolling here.

But if an engine takes 30 seconds to load a Quake level, there's something fundamentally wrong with that engine ... IMO. If I can get a Gears of War level into my editor faster than that, the Quake engine is doing something REALLY wrong. :) 
I mean, what you're describing is the sort of "death by a thousand cuts" syndrome that makes things very hard to optimize into a better state because there aren't any large wins. There are tons of wins in there but they're all small and taken on their own aren't significant ... so, yeah, maybe improving this one little thing would be useful. I dunno! 
All it takes is a handful of millisecond or sub-millisecond optimizations to get a Quake engine running (or loading) twice as fast (or skimp on them and you're running twice as slow).

That's not a big deal for id1 content - 600 vs 1200 fps? Getouttahere.

For non-id1 content it's critical. It means bigger maps, more enemies, more game logic, more visual effects (particles, lights) and still being able to maintain good performance.

In the specific case of texture loading, a useful cutoff point seems to be something like: "if it takes longer to establish that an external texture doesn't exist than it takes to just load the native texture, then it's worth doing". 
2 Movement Interpolation Gems ...

This thread has 2 interesting thoughts and semi-obscure thoughts on weaknesses in movement interpolation in Fitz 666 protocol (which is far better than old QER tutorial).

One by MH on lerp movement (and I bet lerp anim!) should reset if entity is frustum culled, and one that I inadvertently came up with thinking about a chase camera improvement that ultimately coughed up an oversight or potential obvious movement interpolation improvement.

Storing this here with the rest of the FitzQuake buried future ideas/unearthings. 
Make That 3 ??? 
If view weapon goes off screen ??? 
thanks for the tip, Baker. I did know about the enemies riding lifts problem, but hadn't noticed the frustum culling problem.

Btw, a clarification: fitzquake model interpolation is completely independent thing from the fitzquake protocol -- you can have either one without the other. The one small overlap is the protocol contains a timing hint for lerping, but that hint could be used by other interpolation systems, plus the fitzquake system still works if you set "sv_protocol" to 15. 
Riding Lifts Problem 
I've been doing some more investigation of this one and have traced the cause - it's hinted at by the header comment of SV_Physics_Step:

"Monsters freefall when they don't have a ground entity, otherwise all movement is done with discrete steps."

Some tests confirm it (basically just not sending an entity that meets the freefall conditions in SV_Physics_Step) - a monster on a lift isn't MOVETYPE_STEPping, it's in freefall. 
sorry to interrupt but: groundentity is exposed in qc, does it do anything there? ie: will it report a lift that the player/monster is standing on? 
Whatever you do, just don't break the suspended monsters trick like DP does. 
don't worry, this would be a cosmetic change only (purely client-side.)

BTW, darkplaces has a lot of cvars that control features that break compatibility, you might be able to un-break that trick too if you know the right cvar (i think they are all named sv_gameplay_fix_*) 
why does fitzquake (and quakespasm) put the qconsole.log file in /quake/qconsole.log instead of /quake/mod/qconsole.log?

is this the original functionality? just seems a little odd (and had me searching around for it!) 
Is there anyway to force fitz to start in a windows mode via the command line? I tried with config files and it just keeps going full screen and then back to windowed mode. 
-width 1680 -height 1050 -bpp 32 -window 
Re: Qconsole.log 
Because it is the engine's log. Besides, the mod directory can be changed when the game is still alive, so there is no point in putting it under /quake/gamedir/ 
I tried the -window command line and it worked perfectly but the +mlook no longer works, even if I do a vid_restart console command.

For some reasons if I start the engine normally and tell (via config file) the engine to go windowed the +mlook still works. (it also grabs the mouse pointer permanently, I have to close the engine down to use the mouse with other window apps. 
sock: try pulling down the console before tabbing? that works in quakespasm anyway. i agree though, it would be nice if mouse control was release as soon as focus was lost. 
MP3 (or Ogg) Support 
Ok, maybe I'm an idiot (well, ok, maybe might be understating it a bit) but how do I get FQ 0.85 to play the ripped tracks (I've tried both formats)?

I've tried placing the files (named through where xxx is the two different format extensions) in:


I know that the music works (ogg plays fine in DarkPlaces and the mp3's work in a few different media players) and when I put in the game CD it plays just fine. I'd just rather not risk damaging the original CD if I don't have to.

Is this not supported in this engine or am I missing something obvious? 
I'm Not Sure 
i know baker made a version where he added it in himself, so i don't think the stock fq085 does. 
Yeah, I saw that but the link to the binary is dead and I don't really want to mess with compiling a new exe. I'd probably just screw it up.

Oh well, maybe in the next version... 
quakespasm does play mp3/oggs (in /id1/music) and it's very similar to fq.

name them track02-11 and they will play normally. 
incidentally, you can make your own custom music by making music files track13 and up, then just using the sounds field in worldspawn or the builtin SVC for cd playing in the qc. 
Spiffy! Thank you. 
many engines support arbitrary filenames so for custom tracks please avoid numbers but use distinct unique filenames Instead. 
numbers are better because you can use the builtin qc function to start music as well as the worldspawn key, which, if the engine integrates the mp3 playing PROPERLY should redirect to the mp3 reliably as opposed to stuffcmd'ing console commands that may vary between engines. 
engines should support any filenames for both of these options. the "cd play" command should be fully transparent/oblivious. 
Arbitrary Filenames 
"cd play 5" should play the 5th file in the list - easy as that. No need for requiring any track naming convention at all. 
5th file in the list.... the list being all music files located in the id1 music dir + mod's music dir? So if someone adds "aaa.mp3" to their id1 dir, then every other level you own will now play a different track? 
cd play 5 must play the cd track 5 or the equivalent external files which is track005 or track05 or something like that. 
"cd play 5" playing the 5th file in the list is unreliable and also is against the purpose of the cd command which is "playing track 5 of the cdrom in the drive" and nothing else.

The reliable solution is using a unique filename for every different music which what hexen2 did 15 years ago: see svc_midi_name of hexen2. In uHexen2, I further extended its use for music files other than midi such as ogg, mp3, wav. (Of course the drawback of the server message is that it dictates a new protocol.) 
I'm Not Seeing 
How somebody adding an extra file to the directory is any way different to somebody popping in a different CD. Other problems arise. What if somebody puts both track01.mp3 and track01.ogg into the directory for an engine that supports both mp3 and ogg formats? What if somebody deletes one of the files? What if the author of another popular engine decides to use a different naming convention because they feel that it's somehow superior? There's only so far you can go to protect against this kind of thing before it becomes counter-productive. Ultimately I favour the approach that is most pragmatic and that offers the least surprise and least unexpected behaviour to the player - not the engine coder, not the mapper/modder - the player. If the player puts an extra music file in there, what do you think the player's expected behaviour is going to be? So code to that. 
since everyone has their own protocols anyway, i'd rather see a new builtin svc. 
CD Play 
What's wrong with testing in the following order:

cd play X
First attempts to find a file exactly called x
If that fails, but X is numeric, try to load a file called track0X.wav, then track0X.ogg, then track0X.mp3 (in decending order of *likely* quality).

Finally if none of those files exist then play track X on the cd in the drive

This lets you play extra files and is consistent with previous behaviour, except where players have intentionally put new trackXX files in the music directory. You can even do fallbacks: play gorkypark.mp3 if it exists (and the engine supports it), otherwise play track 4 from the CD, through the commands
cd play 4
cd play gorkypark.mp3

You can replace the first one with the SVC command from qc as well, stuffcmd only the custom one. I wouldn't worry about the overhead of a stuffcmd, because you aren't going to change the music on a frame by frame basis (the drive wouldn't even have spun up) 
your method makes a lot of sense for the use case of "user puts 10 audio tracks in a folder and expects the game to use those instead of the phyical CD in the drive."

The other use case, where modders want to include music with their levels, seems problematic to me. To correctly specify the music track, they can't use a number (since they don't know what else the user has installed, they don't know where their track falls in the order.) So they could use a name instead, and we could say that is the standard for modders including music. But, then we need a new mechanism for the server telling the client what track to play, since svc_cdtrack only allows a single byte.

However, the presence of mod music in id1 would screw up the user's music, since now there are extra tracks inserted in arbitrary order between the original 10 installed by the user. 
However, The Presence Of Mod Music In Id1 
Should a mod even be putting music in id1? If a mod messed with id1 content to this kind of extent I would think it's overstepping bounds.

Maps are OK, but other kinds of content? That's the beginning of a slippery slope.

I appreciate the desire to play nice with what a modder might want, but the ultimate arbiter of everything is the player. If a mod shows disrespect to the player's desires, then the player will just not use that mod.

That's where I'm trying to come from here - what is the behaviour that the player expects? I'm not particularly religious about this - if it turns out that the player's expected behaviuour is something different to the way I've done it, then fine. I'll change. But it's the player's expected behaviour that calls the shots, not the modder or the engine coder. 
Naming Convention 
The naming convention for tracks benefits players, because it lets them selectively replace tracks and keep the CD for others. It's a side benefit that it opens the door for custom track playing in mods. 
agree that putting mods in id1 is not ideal, but in practice people do it when the mod is only adding files and not replacing them -- for example a map that comes with a custom skybox might just get installed in id1, the skybox won't hurt any other map by its presence. Or maps that have custom mapmodels as external bsp files -- those get installed in id1 also. 
Or maps that have custom mapmodels as external bsp files -- those get installed in id1 also.

you don't have to do this though. unless you mean replacement items? 
Just As A Note ... 
GLQuake or WinQuake cannot actually connect to FitzQuake 0.85 running protocol 15.

You get "CL_ReadFromServer: lost server connection".

If I revert MAX_DATAGRAM from 32000 to 1024, it works. I made an effort to track down exactly where as a server this is failing, but the "cascading dependency tree of this constant" is rather staggering and I'm not quite sure how to plan how to catch this problem.

For all practical purposes, it isn't really "a problem" except that this issue breaks the intended design that it should be backwards compatible to GLQuake (which no one is using).

I made a few attempts to pin down the cirumstances, but that MAX_DATAGRAM constant gets reused in the form of other constants (#define NET_DATAGRAMSIZE (MAX_DATAGRAM + NET_HEADERSIZE)) and a the number of "> sizeof(something)" statements in the client, server and network code is no small count.

Recording here for the sake of doing so. I discovered this issue a year ago. I had preferred the idea of posting the problem with a the solution as well. 
Another Small One I Found 
R_Novis_f sets variable "vis_changed = true"

The vis_changed variable doesn't get reset to false in R_Marksurfaces. 
If You Want Another Bug... 
MAX_DLIGHTS is 64 but dlightbits is still a single int. What is the result of "surf->dlightbits |= (1 << num)" where num > 31? 
Looks like FitzQuake isn't the only engine with the dlights issue.

I do see that Qrack doesn't have that issue, it is commented "//MH: robust support for increased dynamic lights" 
Oh boy, that's a nice one. What is the solution? changing dlightbits to long long type? 
int dlightbits[MAX_DLIGHTS >> 5];

if (!(surf->dlightbits[lnum >> 5] & (1 << (lnum & 31)))) continue;

surf->dlightbits[num >> 5] |= 1 << (num & 31);

Exact same code is as used for vis; that should work for everything. 
I see. and the int should possibly be changed to unsigned, too. 
Good catch on the "dlightbits[(MAX_DLIGHTS + 31) >> 5];" part - I'd missed that. 
I keep getting this error when reload my map, it is not always happening but I am not sure why. I have searched for any solution but could not find any. Using Fitz 0.85 engine, I have not generated any coloured lighting and not using a LIT file.

TexMgr_ReloadImage: can't colormap a non SRC_INDEXED texture: lightmap027
TexMgr_ReloadImage: can't colormap a non SRC_INDEXED texture: lightmap027

When I wander around the map, certain parts (always random as far as I can tell) seem to be missing all colour information and look greyscale. If I reload the map again, it often goes away or just moves around to another texture.
Any clues what this is? 
sounds like a code bug; somewhere the pointers are getting messed up i think. I don't think there is anyway for data to cause that error.

FYI: what's happening is it is trying to set up the player texture (which has swappable colors i.e. "colormapping") but the data pointer is referencing a lightmap instead. 
More Info 
I initially thought it affected only certain textures (X/Y) sizes, but it happened on a 64x64 pixel texture last night. I was using a fast compiled map to do some testing, so I did a full compile and still got the problem, just not as frequent as before. It also gets worse the more times I use quick save/load. It does not affect the game besides being a visual glitch that goes away if I reload the map.

My config settings are mostly standard, I have 2048 edicts but the rest is default. (well as far as I know!) I don't use extra heapsize, zones or any extra command line parameters besides -game and +map. The BSP I am using breaks a couple of standard limits and produces warning, marksurfaces are above 32k and I am using 98 textures. 
it's probably heapsize then. You should use at least 128000 but i use 256000 in my quake batch file to just save myself the trouble.

I was getting odd corrupted textures until I upped heapsize. 
There Is A Problem In FitzQuake 0.85 
in the gl_texmgr.c where it reloads the entire file that a texture was found in.

In a lot of cases, a texture is in the map or model. And many times, the .mdl or .bsp in a .pak.

So in that case, it is going to load the entire .pak into memory. So, for instance, to reload a grunt's skin, it will load the entire pak0.pak into memory (17MB). For a Quoth Pyro, it will load the entire quoth/pak1.pak into memory (81 MB).

It will do this on any video mode change. I'm not sure if this how/why the described issue is happening, but this mean you need a substantial -heapsize allocation (probably at least 128 MB).

One way to test if this is the likely origin of the problem would be if Quakespasm/RMQ engine/Fitz Mark V don't have the issue [Quakespasm fixed it, fix was inherited to the other 2]. If you don't have the issue, this could have something to do with the problem. 
hmm, strange that it's loading source files onto the heap when normally textures are loaded with a file pointer. I guess I'm using the wrong method to re-open files in that case. I was not aware of this bug; do you know which quakespasm version introduced the fix? 
Just Scanned The Changelists... 
is it this?

Changes in 0.85.7
Reduced memory usage during reloading of textures
I'm Not Sure Which Version 
and the Quakespasm changelog I think this falls under "video bug fixes" so maybe 0.85.5?

The fix is simple and mostly goes like this ...

int datasize;
COM_FOpenFile (glt->source_file, &f);

if (!f) goto invalid;

datasize = glt->source_width * glt->source_height;
if (glt->source_format == SRC_RGBA)
datasize *= 4;

data = Hunk_Alloc (datasize);

// need SEEK_CUR for PAKs and WADs
fseek (f, glt->source_offset, SEEK_CUR);
fread (data, datasize, 1, f)

Where the above instead of loading the whole file, does an fseek to the right source_offset and loads <width x height x appropriate bpp> bytes.

You know ... looking at the above code, I'm not convinced offhand that is going to work right for a .tga or .pcx in a pak file.

[Then again, maybe it does for reasons that aren't immediately obvious to me ...] 
I'm thinking the fix isn't 100%

PCX data is generally (always?) compressed and TGA data can be RLE compressed or might be 8-bit expanded and then expanded to 32 bit.

Then again, I might not be seeing in the code where that is addressed.

[+1 to list of things to check out ...] 
I'm pretty certain that code originated with me, but memory is hazy. The comment on the code you quoted is in my style anyway, and I'm in the habit of always initializing pointers to NULL, but I note that the current QS version is a little different (different comment, uninitialized FILE *f).

Anyway, TGAs and PCXs will fall through to the second condition as external texes use offset 0: "else if (glt->source_file[0] && !glt->source_offset)" - the "read the full PAK file into memory" problem should only happen with native textures inside BSPs or MDLs, where the offset is an offset into the BSP or MDL file, not into any PAK that may contain it (COM_FOpenFile will set up the file pointer correctly for the base file whether it's a loose file or a PAKed file, then we fseek from there).

There was a hack I did for DDS files where I added a SRC_DDS format and put the full file size into width, but with hindsight and in light of the above that wasn't even necessary.

Nowadays I'd probably be more inclined to glGetTexImage into an array of system memory buffers (malloc, not hunk) and delete each texture from GPU memory as it goes in. Then glTexImage from that array and free each buffer immediately after restart. Since textures are backed up by system memory copies anyway that wouldn't be any extra overhead that wasn't there to begin with. Would be much simpler and cleaner, and should also reload faster (no file I/O). 
GLQuake Can't Connect To Fitz Protocol 15 ... 
Possible location of issue:

sv_main.c -> SV_ConnectClient ...

strcpy (client->name, "unconnected");
client->active = true;
client->spawned = false;
client->edict = ent;
client-> = client->msgbuf; <---- HERE
client->message.maxsize = sizeof(client->msgbuf);
client->message.allowoverflow = true;

Because ... server.h ...

byte msgbuf[MAX_MSGLEN];

And quakedef.h ...

#define MAX_MSGLEN 32000 // max length of a reliable message //johnfitz -- was 8000

And ...

sv_main.c SV_SendClientDatagram ...

qboolean SV_SendClientDatagram (client_t *client)
byte buf[MAX_DATAGRAM];
sizebuf_t msg; = buf;
msg.maxsize = sizeof(buf); <--- Here

Because server.h

#define MAX_DATAGRAM 32000 // max length of unreliable message //johnfitz -- was 1024

Maybe ... not a sure thing but looks very likely right now. Not that anyone is going to be using GLQuake ...

I also kind of wonder if sv_protocol 15 demos will play back on GLQuake.

Knowledge pile +1 
Ok this is bloody wierd because I'm pretty sure it didn't happen before...

You know mods that replace start.bsp? (e.g. czg's czg07, or honey)

Well, I'm finding now that when running these mods it only ever loads the ID1 start.bsp

Anyone else had this problem? 
Oh Wait I'm A Retard 
ignore the above I was being being a 'tard. 
Apsp1 Platform Bug 
I was playing apsp1 in quakespasm last night and noticed the mis-positioned elevator that mfx mentioned seeing too:

The bounding box is fine, so it doesn't affect gameplay, but it's just rendered in the wrong place.

I tried some different engines, and the problem started in Fitz 0.85. Fitz 0.80 is fine, as well as glquake/winquake. The lastest Darkplaces has the problem too though.

This is the entity text, from opening the bsp in a text editor:

"classname" "func_train"
"angle" "-1"
"sounds" "4"
"speed" "184"
"target" "3f_lift_p1"
"dmg" "5"
"noise" "plats/plat2.wav"
"noise1" "plats/plat1.wav"
"targetname" "tllift"
"model" "*10"

If I put a breakpoint in R_DrawBrushModel, e->origin is (0, 0, 0) and e->angles is (0, -1.40625, 0). The second component of e->angles seems to be related to the problem, if I zero it before the R_RotateForEntity call, the plat appears in the correct position. (I don't understand why adding a rotation to the OpenGL matrix shows up visually as the plat translated diagonally.) 
I have seen this before. The root cause is that func_train should not have an "angle" set. So I could blame it on the mapper. But, under most engines the -1 is rounded to 0, causing no visible problem. Therefore it's hard to blame the mapper when the engine came out years after the map!

Fitzquake (and apparently Darkplaces) round the angle to the nearest representable value instead of flooring it towards zero, resulting in more accurate angles for rotating entities. However as you can see, -1.4 may be closer to -1 than 0 is, but -1.4 results in the mapper's harmless error now being highly visible.

As to why the small rotation appears to be a diagonal translation, remember that bmodels have their origins at the world origin, so a small rotation around the world origin would result in a large lateral move for the visible geometry of the lift.

The solution may be to disable the "improvement" of better rounding for angles. 
Ah, Good To Know 
I remember seeing this with a lift in A Desert Dusk too, and, checking the bsp, sure enough it has a func_train with "angle" "-1". 
Rounding toward the nearest value is actually what the Quake code attempted to do, but did it wrong (due to an int cast of a float rounding toward zero, but the Quake code assumed it rounded down consistently).

So I'm both a little unnerved by the error, and inclined to blame it on the map rather than the engine, I could do a spot-fix for this specific map name but I don't normally do any spot-fixes for anything in the engine as I believe in having no map-specific or model-specific logic anywhere in the engine.

A .ent file could easily fix this...

sv_saveentfile while playing it, and then edit that one entity in there and any future loads will use the modified .ent file instead of the data in the .bsp.

A more important issue is that this angles is going to affect the MOVETYPE_PUSH directly because darkplaces supports rotated (and rotating) plats, so there is a physical difference here.

An alternative - however with unknown side effects - what if the engine chose to ignore incomplete vectors when parsing the entities? Because angles is a .vector field in the progs.dat, it is being parsed as a vector, it is an incomplete vector whose value is just "-1", right now this gets expanded to "-1 0 0" but perhaps it should expand to "0 0 0" due to incompleteness? 
i feel this is just a map bug that went unnoticed due to an engine bug.

the problem lies with the map. 
Angle Vs Angles 
Just to clarify, this is "angle", so that second approach I mentioned won't work as this isn't an incomplete vector.

A spot fix for specific map names to ignore "angle" "-1" seems to be the safest solution but still a complete hack and I don't like hacks. 
One Specific Workaround 
The engine could detect the following combination:
classname == func_train
origin == 0 0 0
angles != 0 0 0

And clear the angles in that case.

Any entity with origin 0 0 0 that is using angles is suspicious, but a func_train is highly suspect. 
I believe the cause for this is a mapper who started with a func_door with angle -1, then later changed the classname to func_train/plat to get better behavior, but didn't clear out the "angle" key.

As to the question of fixing it with an engine hack, i guess testing for "func_train" or "func_plat" with angle != 0 would be a fairly targeted way to do it. It's a hack no matter what unfortunately, and I'm not 100% against hacks (for example i put in a hack for the large shell ammobox texture) but what worries me is we don't know the complete list of existing levels that have this problem. 
I believe the cause for this is a mapper who started with a func_door with angle -1, then later changed the classname to func_train/plat to get better behavior, but didn't clear out the "angle" key.

To be clear, i mean that of the 3-4 cases I know about, the cause seems to always be the same. 
(not That I Know About Func_trains) 
but if they're not supposed to have angles, why don't you just always throw it away? 
quakec could do that. Engine doesn't know what is supposed to have what. 
Func_train Angles And Origins 
In engines that support rotating platforms (which darkplaces for example does), I can't just throw away angles on func_train automatically.

But in the specific case that the func_train has origin 0 0 0 (which is the default for any brush model), the angles make no sense - as it would just orbit around the center of the map. 
That's something I could see in abstract maps though. 
fair enough. I was assuming that all mods with rotation support would use func_rotate_train isntead, but i guess that isn't guaranteed. 
How bad would the side effects be of reverting to the original rounding code? whereabouts in the code is the rounding?

The hacks do sound dangerous to me, unless they were restricted to the known filenames with this bug.

The only good news is mappers won't make this mistake on new maps, since most SP mappers probably test in a fitz0.85 derived engine and/or darkplaces. 
The rounding is only for the networking (I.E. visual only), if the engine supports rotation in the underlying sv_phys.c code, then even if the visuals are not rotated, the physics will be (leading to a rather confusing jump and fall-through in this case).

DarkPlaces supports that, so I can't really just revert my rounding change.

Furthermore, the same rounding change gives a significant improvement in aiming, where it is widely known that stock quake has kind of a "down and to the right of the crosshair" characteristic, the aiming is more accurate because of this rounding fix (although darkplaces goes further and uses 16bit angles for aiming so you can hit a pinpoint location across the room). 
Negative Angles 
It is okay to throw away negative angles for a func_train.

Even in DarkPlaces, negative angles don't make any sense (except for func_wall or func_door where -1 and -2 have special meaning) because negative angles are invalid.

Rotated brushes/entities in any map editor have positive angles from 0 to 359.999999.

[This excludes the idea that someone would write custom func_train code that supported angles, but even then the values would be positive]. 
FitzQuake Sky Slowness 
My main reason for bumping this thread is this.

FitzQuake renders rather slow compared to other engines because of the sky. The sky draws first and in the case of a skybox, it literally draws the entire screen.

I'd like to Z-fail the sky, but I want the fog to render on the sky in the proper FitzQuake manner. And I'm not entirely sure what process sky entities does.

I always use A Roman Wilderness of Pain (arwop) map ROMAN1 as the example of an fps killer in engine testing. In Mark V, I get 20 FPS. DirectQ gets an insane 169 fps. In other engines, typically the fps is close to 30, which sounds low but is a 50% improvement over FitzQuake. (Even on a low end video card, some other engines often are hitting 600 fps with ease on id1/start.bsp and the FitzQuake renderer struggles to break 300).

FitzQuake does rendering far better than other engines, in my opinion, but the slowness is an obstacle and I think it is exclusive to the sky.

[There are other ways to increase the FitzQuake frame rate, like using 3 texture units to draw texture, fullbright and lightmap in the same pass, instead of using 2 texture units, but even if I essentially disable that with gl_fullbright 0, I still get 20 fps on ARWOP (no improvement).] 
with modern graphics cards, fitzquake could draw skyboxes using a cubemap (directly rendering the sky faces instead of drawing an actual giant cube.) And for the classic scrolling sky, i think you could do it with a pixel shader. 
To Disagree 
[This excludes the idea that someone would write custom func_train code that supported angles, but even then the values would be positive].

I don't think engines should make this kind of assumption based on the mods that exist today. Suppose someone writes a mod that unifies func_train and func_rotate_train under the former name. Then a negative angle is a deliberate signal to the mod - make the rotation towards the next waypoint move in the positive direction. 
Baker, I'm surprised sky is a bottleneck.

If I make Sky_DrawSky return immediately without drawing anything, I get essentially no change in fps. This is with a fairly fast cpu (2.3ghz i7), 2 year old laptop gpu (nvidia gt 650m).

For me over half the time in the roman1.bsp starting position is spent drawing entities (mostly on alias models), a bit less than half drawing the world. In Mark V I get 90fps, 205fps with "r_drawentities 0" and 135fps with "r_drawworld 0" (but r_drawentities 1). Try setting those to draw only the world / only entities, to see relatively how much time is spent on each. 
sky is expensive in terms of overdraw - if its drawn fullscreen anyway.
the vanilla code is ugly as heck, it warps in a horrible way as you move around.
the skybox code that seems to be fairly abundant has a few issues with certain situations, like side windows, that increase overdraw unnecessarily, which can be expensive. a good example is dm2, where the side windows (that noone remembers are there) result in the sky basically covering the entire screen.

it can be significant when you're framerate limited, but at least the worst-case is limited to (less than) only half the framerate. 

I suppose so, I hadn't considered that. The traditional func_train would never move up/down like a door or plat. ;)


Load up a skybox and instead of not drawing the sky, don't draw the world.

Now I understand what you say in regards to speed, I'm not blaming the fps in arwop on the sky (make no mistake) -- if you load up ARWOP and in Mark V and type in "cl_shownet 1" and then type "sv_cullentities 2" (which is DarkPlaces/FTE anti-wallhack level of culling server-side) --- you will watch the network traffic drop by 2/3rds --- ARWOP is a prime example of a beneficiary of network optimization (DarkPlaces and FTE probably breeze by it).

But I think the sky may be costing 100 fps on a map like id1\start.

I'll be finding out ... 
And By The Way ... 
Make no mistake, I love the FitzQuake renderer, obviously.

The sky has been bothering me for years! And it reared up yet again.

The way the rest of the rendering works, I have never been able to determine or intent of the sky drawing the way it does --- everything else in the engine is clearly a clockwork and quite deliberate.

My only guess is to render fog on it consistently. And I intend to find another way to do that, if so. 
Goals of the fitzquake sky rendering:

* sky should only be visible when looking at a sky brush, not void
* if a sky brush is in front of some other geometry in the PVS, you should see sky, not the geometry behind it.
* brush entities with sky texture on them should look like sky too
* sky should be rendered as if it was a giant cube, and should not be distorted by the actual geometry of the sky brushes or the movement of the camera

So what i do is clear the zbuffer, then draw all the sky surfaces (brush faces) untextured (to write to the zbuffer), then draw the skybox with the depth-test reversed so that only farther objects pass the test. This means the giant, distant box of the sky will only appear on portions of the screen where the sky brushes were already rendered. Then I draw the rest of the world, and since the sky surfaces have correct depth values, they occlude any polygons farther away.

Even when drawing the scrolling cloud sky, i use a giant cube that has been subdivided enough to approximate the dome shape (r_sky_quality controls the subdivisions)

There's also some code to attempt to draw less than a full box, when only part of the screen shows sky. This was disabled for skyboxes (couldn't get it right at the time, due to tjunctions), but enabled for the cloudy sky (since it's subdivided into a grid anyway, there are no tjunctions.) 
I've been looking at MH's home work, and because I want any speedup I do to render identical to FitzQuake 0.85, I think I'm going to try this:

1) Instead of drawing the sky first, run through the sky texture chain + sky entities and see if any sky surfaces are visible. Set frame_skyshown to true or false.

2) Provided frame_skyshown, at end of drawing instead of beginning, either do a sky surface stencil pass or draw with glColormask (FALSE, FALSE, FALSE, FALSE) using sky surfaces + sky entity surfaces.

3) Then use the drawing code more or less as-is.

I understand the trickery of handling the skybox, ironically the software engine Makaqu supports skyboxes in WinQuake and draws the skybox only on those brushes (and it looks perfect too).

While tempting to give that a shot in Fitz, I think I'll try the more simple method outlined above at least at first.

Hopefully, it results in some fps. 
Stencil buffer sounds like a reasonable way to do it. At the time I didn't want to introduce a new hardware requirement but since every card for 15 years has had stencil, it's probably safe :) 
In Fitz 0.85's Host_Game_f (), do you remember why this is commented out?

//Cbuf_InsertText ("exec quake.rc");

We were discussing re-adding it in Quakespasm. Not doing it creates a disparity between the "-game" flag and the "game" console command, where "-game" will exec the mod's quake.rc possibly with custom settings, but "game" won't. This is a problem for some mods, e.g. those that set an increased max_edicts required for their maps in their quake.rc.

The only issue I can see is execing quake.rc might trigger a video mode change, if the gamedir you're switching to has some different vid_width/vid_height saved in the config.cfg. But it's easy to work around that with the vid_locked mechanism. 
both are annoying every time you change gamedir. and yeah, engines that unconditionally shove a vid_restart into configs are annoying too.

if you can change gamedir without any side effects then you're a miracle worker.

your current settings getting wiped is pretty annoying too, if you bind your controls then change gamedir.

changing gamedirs without restarting is actually quite complicated if you want to to do it properly. plus its annoying if its not done properly.

FTE checks if the various configs change over the gamedir change, so it doesn't oblierate settings if there was no point in doing it in the first place. this helps reduce how annoying it is. There's still other issues, but they don't appear as often thanks to this. :P 
I originally added that line for the same reasons you want to resurrect it; to help make the mod's configuration closer to intended. But I disabled it because i encountered a lot of awkward problems as mentioned by Spike.

I decided it's better to do to little rather than too much, in this case.

I still think the config behavior is awkward, due to the fact that it only saves when you quit, and this means only one mod dir gets the updated config. I had plans to save it before switching mods, so the mod you are leaving gets any modified settings you created while in that mod.

It's still weird, though; and there are some settings that should probably be engine-specific vs. mod-specific, like graphics and audio settings. So there really should be two configs, one that is always stored in id1 and the other that is saved per mod. Each cvar would know which config it belonged to. 
Engine-specific Configs 
A system where engines effectively intercepted the "exec config.cfg" command and converted it to the moral equivalent of "exec config.cfg;exec fitzquake.cfg" could work, especially if engine specific persistent variables got saved to that custom file instead of config.cfg itself. 
Thanks For The Hints 
It sounds like the best option for QS right now is not changing anything and just document the behaviour/bug. 
So much old mods that can be broken by these sort of changes. 
Viewmodel Lerping Bug 
I saw an interesting bug report on quaddicted by NoNameUser, here:

Also, "r_lerpmodels" is set to 1 by default, but the weapon models lose their smooth animations outside the start map; monsters are ok, though, and everything else seems fine too. I've had this problem with the weapons animations with other mods too (Warp Spasm, The Horde of Zendar, and others).

I was able to reproduce it in two big maps (warpd.bsp, zendar.bsp) on various Fitz engines (0.85, QS 0.90.0, MarkV). What was happening was, this condition in CL_ParseClientdata was firing every frame, even when I wasn't changing weapons:

if (cl.viewent.model != cl.model_precache[cl.stats[STAT_WEAPON]])
cl.viewent.lerpflags |= LERP_RESETANIM; //don't lerp animation across model changes

The cause was, the above check was done before handling the SU_WEAPON2 byte, so only the bottom 8 bits of cl.stats[STAT_WEAPON] were set, which would cause the test to always fail if the weapon model was > 255. I just moved the if() statement to the end of the function, seemed to fix up the issue; here's the diff.

Does that look sensible? The lerping if() block used to be inside
if (cl.stats[STAT_WEAPON] != i), but I think it should be safe to move it outside of that, because the lerping if() is also testing that the weapon changed. 
Good catch. Your fix makes sense to me. 
Sounds like a great catch. 
Model Lerp And R_shadows 
Is there a way to code in so modders can choose which models can and cannot cast shadows, and which weapons/enemies are lerped?

I am using a bunch of models in one of my maps and they cast unwanted shadows. 
Fitz/Quakespasm/Mark V all have r_nolerp_list.

Mark V has r_noshadow_list too. 
Huh... how do you add to this list? Rc file? Cfg file? 
Nolerp/noshadow List 
They're just cvars so you set their values the same as any other.

It would probably be a usability improvement to have commands to add individual items to these lists rather than having to require the user (or moder) to respecify the entire list. 
yeah, it's not very user or modder friendly, but for modders adding it to quake.rc is the best idea. (alternate idea: use stuffcmd)

In the case of modders, you should be able to create a full list of what should have shadows and what should interpolate (since you wrote the mod!)

As a player you end up creating a really long list that applies to multiple mods, since most mods do not provide their own lists.

The ideal would be an extension to the model format or new fields on quakec entities for the modder to define the behavior for each model or entity. All of those things require engine support, plus either a tools change or protocol change.

Hence, the hacky config file method. 
who's idea was it to add all this stuff to console commands anyway? can we change this to some text file where we just put a full path in from the mod dir (eg: progs/flame.mdl) and anything in that text file is not lerped?

config files are infinitely easier for modders and users alike. 
necros, it already works like that, you can set up the list in your config file. 
Darkplaces has a EF_NOSHADOW flag (4096) for the 'effects' entity field that you can set from qc, but it won't work in protocol 666 which only has 1 byte for 'effects'.

r_noshadow_list sounds like a decent compromise, thinking of adding it to Quakespasm too. 
Mdl Bboxes 
We got a bug report for QS that the changelevel triggers in Xmen TC are harder to hit than with winquake. The changelevel triggers are point entities with an mdl model set on them.

What's happening is in Fitzquake, calling setmodel() also sets the mins/maxs based on the contents of the mdl, while winquake just sets them to '-16 -16 -16' '16 16 16'.

The Xmen code was calling setmodel() as the last thing in the setup code for this entity (xmen_teleport), so they were relying on the hacky behaviour of vanilla quake to set a 32x32x32 bbox.

Anyway - just thought I would document this for future reference; I suppose there could be a sv_gameplayfix cvar to revert to Winquake compatible behaviour, but it doesn't seem very urgent - lol. 
Oh... That would explain some seriously annoying issues I had with qc in the past 
if 1, uses the model's bbox. if 0, uses +/- 16 for mdls.
just using +/-16 for *.mdl means that dedicated servers need not bother loading mdls at all, note that the vanilla quakeworld server does not support loading .mdl at all.
FTE uses +/-16 purely based upon the filename extension, while uses the real size in other cases. This means that replacement content still gets a suitable size with things that were originally .bsp (where they always got the bsp's size) while .mdl entities get their +/-16, and convieniently sidesteps issues that are so problematic in DP with replacement content.
Depending upon the filename extension like that is a bit of a hack, but it does indicate the original expectation much better than anything else.

quakerally is similarly (and severely) broken by mdls not getting size +/-16. 
That would explain some seriously annoying issues I had with qc in the past

Same! I figured it out after vtos() printing sizes of misbehaving things in desperation and getting non-power-of-2 dimensions. I started always calling setsize after setmodel assuming it was another QC quirk everyone knew about but me, and not something specific to Fitzquake. 
Haha, ages ago Spike and some QuakeC modders discussed that.

I did notice that anomaly in the FitzQuake source code last year when carefully comparing versus WinQuake.

I thought about it 10 seconds, and decided no one ever complains about FitzQuake.

This may be the first time someone has spotted a behavior difference in the wild and brought to someone's attention. 
Personally I'm baffled that engines still use this style of MDL bbox handling when all the code needed to handle them properly - including full rotation support - is there in Quake 2 -

It's not hugely difficult to port that to Q1 and all of these problems just go away. 
@metslime / Mh / Spike ... Re: Realmodelbox 
I don't QuakeC much, but I've listened to plenty of conversations of QC.

I always thought in QuakeC, you were *always* supposed to do setmodel and then setsize.

But QRally doesn't, it would seem. And perhaps above comments from Necros and Lunaran indicate they don't always do setmodel and setsize too? And other mods may have made similar mistakes.

@metslime ...

Could you describe what FitzQuake was solving with the sizing the model?

Spike advocates all engines using the -16,-16,-16 to 16,16,16 but ...

I know you *never* implemented anything without a reason.

You made one of the most conscientious and thorough engines typically having a broad set of knowledge from a great number of sources. (The change wasn't accident or an oversight, but rather to solve something).

Was the issue for place_model, misc_model, mapobject_custom type of entities? 
iiuc it fixes glquake's model culling.

on the other hand, software rendering has more complicated culling, hence how it got away with hacking the size. I ought to verify that because frankly its an assumption.

and yes, qrally is NOT nice code. it violates other obscure rules too.

using +/-16 means that the server can avoid even loading the mdl in the first place. that's the biggest advantage. :) 
I am also curious about Baker's question.

Spike mentioning culling made me think.. if the server-side bbox is the +-16 units default, but the MDL is really huge (e.g. vermis), you could have a situation where the player can see the tip of the MDL, but the entity origin is outside of the player's PVS so the server culls it (wrongly).

It does seem like the main advantage of fitz's approach is for mapobject_custom type things, so very large MDL's can be supported without the mapper having to manually input the bbox size. 
I meant client-side frustum culling, rather than serverside pvs culling. 
Look at Quake 2's alias model culling code. It's easily adaptable (the key difference is that Quake 2 stores a bbox per frame) and handles rotation better than the FitzQuake code.

If it looks weird on first encounter then I'd encourage you to cross-check with modelgen.c, specifically the code it uses to scrunch the position data down to bytes. 
If you're talking about Mod_CalcAliasBounds the purpose is to calculate the bounds for the client.

GLQuake has a bug where large models are culled incorrectly, for example a dead shambler can disappear if you turn to a certain angle even though his arm should still be on screen. So my goal was to fix that.

e->model->mins/maxs are used by client for frustum culling, and that is what my change affects. ent->v.mins/maxs are used by server for PVS culling, and that is controlled by PF_setsize which I did not modify. 
@metslime -- the change isn't setsize actually, it's setmodel. I triple checked and ... well ... it is different.

I'd like to go the Spike route of -16,-16,-16,16,16,16 since it is standard Quake default.

But if even one FitzQuake targeted single player release would act up ... *sigh*

DarkPlaces defaults to original behavior with that sv_gameplayfix_setmodelrealbox 0 ... but I think many people if they heard a "DarkPlaces don't work right" with this 5 year old release would automatically blame DarkPlaces. 
I think I see what happens now in post #691 (Xmen TC). metl didn't change PF_setmodel (except for an unrelated change to do with BSP bmodels), but when a mod doesn't call setsize() after setmodel(), the new size calculated by CalcAliasBounds "leaks" into the server ent->v.mins/maxs bbox, because PF_setmodel reads e->model->mins/maxs, and uses those to set ent->v.mins/maxs.

While it sounds like an unintentional bug, I also think you are right that changing it might break serverside PVS culling for mods that are relying on the behaviour, especially in the case of a mapobject_custom with a large MDL (quoth, AD?) 
I think the only way we can know is by asking people to test sv_gameplayfix_setmodelrealbox 0 (Quake original).

Arcane Dimensions works in DP and is tested in DP and DP uses sv_gameplayfix_setmodelrealbox 0 (Quake original) and thus far no one has *seemed* to nothing anything.

/But yeah, I'm very afraid of sv_gameplayfix_setmodelrealbox 0 since nearly all single player releases have targeted that.

You'll like my source code on that, it's basically a 2 liner. 
(*) "single player releases have targeted FitzQuake in the last 10 years." 
I never realized setmodel sets the size as a side effect and that some mods rely on that.

Sounds like the fix is to set a minimum (or just force) size of 32^3 in PF_setmodel. I guess this could introduce PVS culling bugs, but only in mods that don't call setsize afterwards? And anyway culling bugs are not as bad as gameplay functionality bugs. 
Quake 2! Quake 2! Quake 2! Quake 2!

Seriously, Quake 2 has the fix for this. It has the correct +/- 16 for the server-side stuff, and it culls small/large models correctly for the client-side stuff.

There's really no need for this discussion. Grab the Quake 2 code (, adapt it for the Quake differences, and all of these problems Just Go Away. 
@mh -- you 100% this is only about culling?

What does setmodelsize do? What does QuakeC do with the mins/maxs?

Is it ever used for physics?

Spike says has Q-Rally has a *physics* issue with the FitzQuake way.

/My somewhat limited QuakeC internals is why I ask 
Clarity ...

If QRally has a physics issues with the FitzQuake way.

How do we know that there aren't single player releases designed for FitzQuake that will show physics problems if this is reversed? 
Probably Not A Problem -- Here Is Why ... 
Very few single player authors do QuakeC.

Enhanced GLQuake was often used before FitzQuake 0.85 so releases from 2009 and earlier should be safe.

Preach, Tronyn, metslime, necros are among the group. I would presume that they are sticklers for setmodel and then setsize. Most of the others are multi-engine types.

Sock is also targeting DarkPlaces.

Until Preach doesn't setmodel in mapobject_custom in Quoth, using the original Quake box should be fine. 
Arcane Dimensions works in DP and is tested in DP and DP uses sv_gameplayfix_setmodelrealbox 0
DP defaults this cvar to 0 but experienced DP users set it back to 1 for compatibility with some custom maps. 
Do you know the name of any particular map that it is known to make a difference? 
Well, before I set the gameplay fixes to 1 there were several maps in which I encountered bugs with pickups stuck in walls or missing altogether. I don't remember which maps specifically, except Solarfall: at the beginning of the map, turn right then left and you arrive in a room with a green armor pickup which was missing when I first played it. Though I suspect this particular issue might be fixed with sv_gameplayfix_droptofloorstartsolid 1, not setmodelrealbox. 
Similar problem with latest darkplaces in VR on android port.

Set gl_nopartialtextureupdates 1 to fix 
1 post not shown on this page because it was spam
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2019 John Fitzgibbons. All posts are copyright their respective authors.