News | Forum | People | FAQ | Links | 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.)
you magnificent bastard 
Sorry I did not reply to your mail, totally forgot about it.

Great stuff! :)

Quick suggestion: If max_edicts were exceeded mention that cvar in the error message? Took me a moment to realise I had the control over it. 
I mean, something like "max_edicts is currently set to 1024, try setting it higher, eg. max_edicts 2048." 
Awesome news!

"model interpolation"

Is this an option? :) 
Good News !! 
I had the opportunity to test it on my latest huge map, and it is running like a charm ! Now I can polish my project and release it with FitzQuake as the prefered engine !!
Metlslime did again a fucking good job here: Congratulations ! 
Cant Wait To See 
Sickbase with decent lighting :) 
Wasn't there a SDL port? Why not continue the development from the SDL version so those who don't use Windows be able to use FitzQuake?

Beyond that, the new release seems fine and finally it remembers my video option :-P 
..I can't evn prnns yur name... I'm soo excited... Yu soo sxy... 
Hell Yes W00t 
hope the changes make it to the sdl port. i think its networking is broken 
read included txt file, there's everything 

I would but, as Bad Sector said, I'm waiting for the SDL port to be updated. There's no point in my downloading a Windows only release. :)

Nice work, metlslime! I can't wait to play with this stuff. Alpha will be cool. 
SDL Port 
I have to talk with metl about what his current plans are for merging the original source and my SDL version, but either way, there will either be a merge of the two projects or I will port his changes to the SDL version. 
Thats Brilliant! 
If you do that then Mac users will be able to play WARPSPASM, nsoe, +others :) 
Also *nix users... 
Great News 
Does this finally mean no more having to worry about keeping Quake's original engine limits now that Fitzquake can play maps that exceed them? 
Great Job, 
thank you very much. you are a wonderful man and I hope you have a long and healthy dick. 
I can't wait to replay all the huge maps I've been forced to run in horrible engines for years on end. 
Just test it!

Very smooth and fast, nice work John I will play more with the client now for sure! 
I love you.

This engine works really well with fog and skyboxes simultaneously. The first one eva :) Actually AGLQuake had it but not as good (s00ry AguirRe)... 
Wasn't there a SDL port? Why not continue the development from the SDL version so those who don't use Windows be able to use FitzQuake?

Much of the work on this version was done before the SDL port existed; basically it seemed easier to finish this version first, then attempt a merge.

As for what happens next, I'll have to figure that out with SleepwalkR. 
To The Brave 
& wonderfull engine that speaks Quakes to my winXP! rock! 
The Rubicon 2 test map was not included in the ZIP file though ;-) 
It's Like Christmas And Birthday Together 
I won't replay warpspasm now, already played it twice, but I hope that we will see a lot of huge, massive epic sp episodes. 
Just Want To Re-itterate Post #20 
Seriously though this is a big thing! It annoyed me that if you put a little fog on you couldnt see the skybox at all in every single engine. But I had a look at thehand before and it seemed to be working fine! 
I love you. 
Some Maps Worth A Second Look Now ... 
Forwards Compatible ...

This might have secretly been one of the best releases in 2008: a lot of alpha brushes, Enforcer reskinned grunts and Hell Knights, SNG wielding mega-enforcer for a nice base theme with traditional play. Was not enjoyable in FitzQuake 0.80 due to the lack of alpha support.

Laboratory X

Some very large areas. Some very different looking textures. Couldn't previously run in FitzQuake. 
Loads All Known Limit Breaking Maps? 
Sounds good to me! Nice work. 
thanks for adding support for that command line. :) now i can keep all my files in their own pak0.pak in a completely seperate folder and not have to muddy up the quoth folder anymore. 
Great work metlslime.
Thanks for the v_gunkick variable and model interpolation.

I have found one small bug. The variable - scr_crosshairscale isn't working because the client has it coded as "- scr_crosshaircale" (the "s" is missing I mean) 
I have found one small bug. The variable - scr_crosshairscale isn't working because the client has it coded as "- scr_crosshaircale" (the "s" is missing I mean)

aw, damnnit :P 
This is more exciting than almost any new game release! Some great changes listed, thank you for your continual work on this, metl.

As for this...

Does this finally mean no more having to worry about keeping Quake's original engine limits now that Fitzquake can play maps that exceed them?

Yes, but I look forward to watching with amusement as people complain that they're hitting the new limits in 1-2 months... 
Is The Model Interpolation Code 
different to that used in other engines? It seems to be a bit more jerky and/or delayed than something like aglquake. Using r_lerpmodels 1 and r_lerpmove 1. 
disables r_lerpmodels and r_lerpmove

It's too weird when Quake's awesome jerky animation is suddenly all smooth :)

Still, nice release. I think the engine limits stuff is the most important this time round.

p.s. I still love you, Metl 
yes, it's different. I looked at the tutorial code found on QER, which i think is where most people get their code, but wrote my own based on what i learned there.

Can you tell me what seems jerky? With r_lerpmodels 1, some specific things aren't interpolated, such as the firing frames of weapons and monsters, and all frames of various torch models. If you want to enable interpolation all the time for everything, try r_lerpmodels 2. 
Lerpmodels 2 
that was it. I was used to seeing everything interpolated so when I saw it in lerpmodels 1, I could notice the difference when certain frames were not interpolated (especially when monsters fired).

Holy Cow! 
This one was long awaited for sure! I will try to run Warpspasm on this! Thanks for your hard work! 
Warpspasm Looks Funny Without Interpolation 
Thanks for the release. 
metl, did you sneakily add double precision angles into your new protocol? Because I swear I can feel the difference... 
i just checked, and there is a big difference between 080 and 085! :D 
Yeah, the new protocol has two-byte angles for client aiming (implied by the "Improved crosshair accuracy" feature) :) 
am i imagining it or are all the rotating objects smoother now? 
Fitz 85 Is Worth A Look... 
Monsters move prefectly smooth now on my Radeon 9000 Pro and Fitz 85.
Couldn't get it with Fitz 80 (really choppy movement at first, then
slowly gets better around the middle of the game). Previously only
Aguirre's GL ran pefectly for me. Now I got all those nice .lit maps
to try out, and still, the best looking animated sky ! 
Demo Compatibility 
Which other engines can play back Fitz 0.85/protocol 666 demos? 
None right now. I plan to look at aguirre's convdem tool to see if I could add support for this new protocol, otherwise I may write my own. 
Congrats Metl ! 
great job!, yeah, there is a big difference between 080 and 085 as said previously :) 
Wasted Some Hours 
This does not open Warpb? 
Are you sure you're running Warp with increased heapsize and/or edicts? 
How do I increase edicts? I am running with Heapsize 120000 
in the console, type "max_edicts 2000" or similar. (default is 1024.) 
What's the technical solution used for "gl_flashblend 0" effects? Firing rockets with that setting is a real fps killer on my hardcore intel integrated graphics :( (apart from that FQ runs very well) 
the app keeps local copies of all lightmaps; when dynamic lights touch a surface, the dynamic light is added to the static light levels and the new data is uploaded to the texture using glTexSubImage2D.

Does fitzquake 0.85 actually run slower than earlier fitzquakes, or any other glquake ports with the same setting? 
Seems To Be For Fitzquake >065 
vanilla Glquake also runs fine so I guess it has to be related to some of the changes you've made.

I'm mostly interested in figuring out the limits of the graphics card (GMA4500mhd) to avoid running into problems with projects of my own. It seems the intel drivers are lagging far behind in OpenGL support compared to DirectX and so far the lesson seems to be to stay away from OpenGL if you want to be safe :| 
well, adding colored light capability in 0.75 probably increased the total amount of upload data somewhat (3 bytes per sample instead of 1) but if you also have the problem in 0.70 i'm not sure what it could be. 
Fitzquake 0.80 had graphics problems on my Intel G945 card, but not 0.85. Aguirre's nehquake works fine also. 
there are a couple of intel-specific fixes in the latest build, for example the "loading" icon isn't drawn because intel doesn't like rendering to the front buffer. Plus, some sort of alt-tab fix. Glad it all works! 
Hmm That's Pretty Weird 
If nothing related was changed between those versions. 
well, in my 0.70 changelist it does say "dynamic lighting has been moderately sped up." So maybe I actually did something to make it slower, instead, at least on some cards. 
Hmm Yeah 
and not just slower but awfully slow in this case.. one nice thing I learned by testing all the different fitzquakes was that generally FPS has been improved a lot and in 0.85 and seems to be in the 100-200+ range as long as there's no dynamic lighting but fire a rocket and it can drop as far as into the single digit realm. 
One thing that has bothered me for a while is that While playing Quake with Fitzquake/Aquirre Quake is that you sometimes get lower framrates when there a lot of of light flickering/torches, such as at the beginning of Nightjourney and Five Rivers Land, or Event Horizon. I know that r_flatlightstyles can be used to fix this, but then the flicker lights are gone also. However, If I use an Old version of Darkplaces, such as DPnehahra, DP1.05, or DP1.02, I can get good framerates as well as keep the dynamic light. Does anyone know why DP can do this and Fitzquake/Aguirre Quake cannot? 
i'm not really sure; in general, fitzquake and aguirre quake are much closer to the original glquake in terms of lighting code, and darkplaces is much more modified. As to why old darkplaces does it well and new darkplaces doesn't, that i also don't know.

How does glquake itself compare? And what about older versions of fitzquake? 
To be honest with you, I never noticed such frame rate drop down with my maps (i.e Five Rivers Land / Event Horizon), whatever the engine I used in between aguirRe's GLQuake, and your engine...
Maybe it depends also of the CPU speed ... though.. 

I used to think that it was the flickering lights itself lead to the framerate drop, but then like I said, old DPs do not have this problem.

For the record, the Old DP did not have problems generating the Doors to Ricky's map either.

I don't have the original GLquake, but Fitzquake 0.80 also had the framerate drop, as did Agirre nehquake and nehwarp


I believe the framerate problems were reflected in the FRL and the EH threads by multiple people. I used the old DP to run your maps because I think that dynamic lights adds to the atomsphere of a base map. Hopefully you won't place too many enemies alongside flickering lights in your next map because I know that it is going to break the limit of the old DP. 
I did notice it even on a fast computer. Try to add
-nomtex to the command line, that helped. 
Intel GMA (integrated Media)

The problems bear and yhe are having with Intel GMA cards are not related to the "computer" or the "cpu".

These Intel GMA cards are default 3d accelerator ("onboard intergrated video card") on all machines with a Intel processor (even Intel Mac Minis).

If you have an Intel processor and didn't buy a graphics card, this is what you have (2001 and later). This is most computers .. well not most .. the overwhelming majority.

Their performance is "fair", about 120-250 frames per second with standard GLQuake with the default settings (gl_flashblend 1, etc.).

It is very nice that metlslime added in the "Intel display adapter fixes" to make it so a lot more people can use FitzQuake.

But keep in mind, the performance of these is on the lower end of the spectrum.

If aguirRe's GLQuake has the framerate drop too -- consider that the lighting in that engine is original GLQuake (no lit support, etc.) and original GLQuake is 1997.

The Intel GMA series is nice in the sense that virtually all computers can be expected to be able to play games, but it is still on the low end of graphics performance.

They have OpenGL 1.2 compatibility with some drivers having portions of the OpenGL 1.3/1.4 specification.

/Note: in old DarkPlaces there are some comments by LordHavoc stating "major lighting speedup" in the dynamic lights section. 
Intel Opengl Compat 
The higher end GMA:s (including mine) have OpenGL 2.0 support with the latest drivers and if intel felt like implementing more than that it should be possible considering what the card supports in DirectX. 
On Intel Topic Pherhaps But Not Really FQ 
Found this Direct3D quake port which seems to run really great: 
Give MH's new engine a try, it's DirectX 9 or 10 and definitely better than that old one: 
Well maybe you should have checked the link because "that old one" seems to be the same one you suggest! 
It sounds like all glquake ports will give you the same problem, with the exception of engines that specifically improved things.

I'll check out darkplaces again and see what I can learn from it.

Can you tell me if the version of darkplaces that runs fast also supports .lit files? 
Yes, the old DPs also supports lit files 
DP Version 
I downloaded several DP sources to identify the first version with the dynamic lighting speedup, DarkPlaces 0.72 appears to be the first occurrence.

The important changes appear to be in gl_rsurf.c and r_light.c (R_DynamicLightPoint, R_DynamicLightPointNoMask, RecursiveLightPoint, ...) 
Dear Bear 
oops, I thought you linked to 
Hopefully you won't place too many enemies alongside flickering lights in your next map because I know that it is going to break the limit of the old DP.

Yhe1: Unfortunately, I do not test my maps with DarkPlace. I am using metlslime FitzQuake (0.85 now) as reference engine, and I think it is largely enough... So I cannot ensure that you will not face issues with old DP version... sorry for this ;) 
That's poor mapping style. Giving the map a quick run-through in the most common engines is not too much to ask. 
I installed DP once, a while ago, and for some dark reasons it crashes after some minutes... so I decided to stick to more than most common engine... FitzQuake is the reference here, so it is largely enough for me if my maps run properly on it...

And I don't think it is a poor mapping style: it is rather a poor testing style :P 
Had This Slowdown On Fitz Too (0.80) 
Agree With JPL 
DarkPlaces doesn't mix well with ATI. It's ATI's fault for a long history of shitty Opengl support, but that doesn't change the fact that when Dark Places crashes it REALLY crashes. I lost my firewall registration information the last time my computer crashed after installing the latest ATI drivers and running Dark Places and it was a big hassle to get everything back in order on that front, so I will never take that risk again. 
Common Engines 
Testing in common engines is one thing, but darkplaces compatibility shouldn't be expected. DP is from my experience just too far removed from a regular quake engine for people to negotiate around it. It's like where you have horses and donkeys: they can interbreed, but the offspring is sterile. Usually things fall into two categories, made only for DP, and made for other engines. If the latter work in DP, then great, but often it's too much work or sacrifice to achieve. 

Does the old DPs still crash for you, like DP1.02?

And your new map, is it going to be limit breaking (the Fitzquake 0.80 limit)? 
Ironically, one of your Travail secret maps also had the same Framerate problems as Five Rivers Land ;) 
I don't remember which version it was.... so I can't tell you. Also, I deleted DP from my HD, just playing with aguirRe's GLQuake, and FitzQuake..

Fortunately, it was not as dramatic as HeadThump mentionned: I didn't had to re-install everything on my computer... 
The think with Darkplaces is that many people use it (because it looks SO AWSUM!). If you want your stuff to be played by newbies then you should test it. 
Donkeys And Horses 
Lemme give you my canonical bugbear. When regular engines report the size of a sprite "model" in the QC fields mins and max, they set them to the dimensions of the sprite in pixels, relative to the origin of the sprite. Since quake renders at 1 unit to 1 pixel, this is a very useful feature, and Quoth uses this information to create a solid bounding box around wire-mesh/grill entities.

Darkplaces sets these fields differently. It reports roughly sqrt(2) times the largest dimension in each coordinate, effectively giving a bounding box for the sprite at any rotation. I didn't actually know it did this until someone reported that the quoth basetest wasn't completable. As a result of the difference, the solid bounding box generated by each mesh is much larger, blocking off the hole next to the mesh through which you must climb.

The thing is, there isn't much that can be done about this particular difference in engines, besides throw out the "solid" feature or make it much more effort to use (by requiring mappers to manually enter the dimension of the sprite on the entities). So even if I had known ahead of time, I probably would have said it was something for DP to fix. Perhaps it's a bit different when it comes to making maps compatible, but that's my take on the matter. 
probably best to let mappers place clip brushes. That's how I did it back when I had sprite-based grates in rubicon2. I decided to stop using them because:

1. they don't take the ambient or dynamic lighting at all (I actually had 6 frames which were the same grate but different light levels.)

2. on almost all non-fitzquake engines, they have ugly pink edges. 
The solid box is optional, you can also use clipping brushes. It's whether you want to allow projectiles to pass through or not. It seemed a shame to require an extra entity to be the invisible hull if you want to block shots as well as players. As for the orange edges, people can usually see past them, if you go for rusty textures at least. 
true, the pink edges are fairly subtle when the artwork itself is warm orange/red in color, such as the light globe sprite in original quake.

As for blocking bullets/projectiles, this can also be accomplished with a skip brush instead of a clip brush. Except the skip brush will cast a shadow, unless you make it a func_wall, which as you say, is an extra entity.

Unless! maybe you can assign a brush model to the sprite entity, which the quakec code uses to call setsize() and then changes the model to a sprite after that. Of course this uses a model precache :P 
The burning can I made with the zdoom model had the same strange line along the sprite.
It seemed as if the used pictures needed an extra line surrounding them. And to stay within the 4 divided measure for gl they became bigger.
Without line. 
The think with Darkplaces is that many people use it (because it looks SO AWSUM!). If you want your stuff to be played by newbies then you should test it.

Careful here.

It has a couple useful extensions (like nonsolid, but shootable corpses), it runs TWIG, and it supports CSQC, which allows you to do lots of otherwise impossible stuff like moving sound sources, inventory, keyboard input - ever tried to getchar() in qc? and more things like that.

Yes, the newbie/awsum effect is there, but careful plz, modders don't prefer it for nothing.

DP/FTE/QSG extensions and csqc have been the answer to a surprising amount of questions I came up with during RMQ development, and by now I think Darkplaces is rather awesome.

I used to think like you, though. ;-)

I would like to see CSQC supported by Fitzquake type engines, please. Because quite frankly, it is awesome. 
Down On Darkplaces Is *bad* 
DarkPlaces is structured in a radically forward thinking way.

The memory management, the QuakeC handling, movie playing capability, the protocol, true interpolation (try setting max fps to 500 and watch what other engines do when you use a lift) and on and on.

Most engines don't even have simple basic fixes like not aborting when a model isn't found, a chase cam that doesn't poke through walls, colormapping of dead player bodies, view weapon capability and on and on.

Most new features engines have added in recent times are things that DarkPlaces has had for several years.

LordHavoc's work has been far, far ahead of the times even in the early days (DP has had color mapping of dead bodies since 2000). 
To Be Honest 
I don't think that because DP has a different behaviour and different features compared to "standard" engines (e.g FitzQuake... ) that it can be said that DP is "bad": it is just different.
Well, I don't want to drop down DP just because it crashes my PC once, and I'm pretty sure I can find many people that think DP is better than FitzQuake, just because there are used with it 
I think you think to know my thoughts while you don't. :p

Darkplaces is an amazing engine in my opinion. Sadly it breaks Quake "compatibility" a bit too much. So I don't think it is that good to play Quake singleplayer maps/mods.

What I said up there should be read as: Many newbies go for Darkplaces just because it has realtime lighting, parallax(?) mapping, shiny water and maybe the soundtrack support. They don't give a fuck about the "developer features". But then they mostly don't play custom maps either I guess, so ... 
I Love You! 
I have been waiting for SO long for someone to create a quake client that properly interpolates the monsters, yet doesn't stick in a ton of eyecandy....

Darkplaces was nice and had correct interpolation, but changed too much stuff and had too much eyecandy and the exe size got too big.

Every other client used the same copy&paste interpolation from some tutorial that would not correctly smooth the monsters' movement when connecting to a remote server.... They would still be all jerky.

But this new fitzquake does it right! The monsters on FvF look great now that they aren't hopping around like they are spastic!

Finally a GOOD ProQuake replacement....

Great Work!

Feature Request 
How about adding in ProQuake remote console functionality for remote administration of servers (RCON)?

I could really, really use that.... It makes things so easy. 
do you mean, adding support so a fitzquake client can RCON to a proquake server? 
Yes, or some other way to remotely control a server. ProQuake's RCON works well and is easy to use. And since ProQuake already contains this functionality, it seems like it would be easiest to just copy the ProQuake stuff. Then FitzQuake would be able to RCON to a ProQuake server or to a FitzQuake server.

Another nice ProQuake feature that would be easy to add is the longer text chat lines....

I'm going to compose an e-mail with more feedback/bug reports/suggestions. 
Late To The Party, As Always 
Christ, if someone's naming Forwards Compatible as "secretly one of the best releases of 2008" then the rest of y'all should be ashamed of yourselves. 
I was wondering if you looked into LordHavoc's dynaimc lights speed up option and the possibility of putting it in Fitzquake? Thx 
I haven't really looked into it yet, but based on baker's post, it sounds like that was merely a speedup to the code for determining the floor light value under a monster (since that is how monsters and players are lit, based on what they're standing on.)

Second, i already probably use that optimization, since i got my .lit support code from darkplaces, and that includes the changes to R_LightPoint and related functions.

The major issue with glquake lighting in general is that it requires uploading new lightmap textures anytime the lightmaps change, which is one of the slowest things you can do with a video card. At some point I will look at ways that can be improved; I can think of a bunch off the top of my head (using 8bpp textures when level has no colored light, uploading more, smaller rectangles of texture data instead of fewer, larger ones, etc.) 
One More Question 
What is the proper command line to run nehahra with Fitzquake 0.85? 
no Nehahra support (...yet) 
Haha, "for Some Reason" 
I installed DP once, a while ago, and for some dark reasons it crashes after some minutes...

You're using DP. 
For Some (very Good) Reasons 
... I'm not using it anymore :P 
This Engine 
Is the business. 
Another Question... 
Can somebody explain what the -nomtex command line option does? 
That disables multitexture rendering. 
Can you explain a little bit more in depth? I was wondering how disabling the multitexture rendering helped the dynamic light speed up issue. 
In Fitzquake, (and glquake with gl_texsort 1) polygons are sorted by texture and then all the polygons for each texture are rendered, then all polygons for the next texture, and so on.

With multitexture enabled, the lightmaps are rendered at the same time, and when a lightmap needs to be updated for dynamic lighting, it triggers an upload.

Without multitexture, the lightmaps are rendered in a second stage after all textures. And, during this second stage, the polygons are sorted by which lightmap they use. And there might be a difference in how the uploads are done, since the lightmaps are encountered in a different order.

Since switching textures while rendering is somewhat expensive, but uploading textures is more expensive, but the total amount of lightmap uploads vs. the actual total number of lightmap pixels uploaded might have different costs, either one could be faster on different maps, different video cards, etc.

One of the things on my to-do list is a general optimization and rendering overhaul, so i might be able to get this stuff sped up even more. 
Water Too Foggy. 
Very happy with this other than water is very foggy and hard to see in it. What inputs make it clear? Otherwise it is deff. keeper! :P 
It Does Seem Foggier 
And I think the Ring of Shadows fog is too foggy as well.... and when you're wearing a ring AND are underwater, it's way-too-super-foggy!

I don't want the fog effects turned off completely though....

(metlslime, did you get that e-mail I sent?) 
sorry, haven't had a chance to respond to your email yet, but i did recieve it.

About the screen coloring for water and powerups, i haven't changed this from GLQuake as far as i can remember, so i'll have to check again and see what's up with that. 
There seems to be some issue with ATI.

Some german guy reported this:
Ati Radeon X1250 with latest drivers
AMD Turion 64 X2 TL-60 2x2,0 GHz & 2 GB Ram
Windows XP SP2 (32 Bit)

If he starts the game it looks like that. If he alt-tabs out and right back in it fixes itself. But as soon as the next map is loaded it is garbled again and he has to alt-tab out and in once more.

He encounters the same in GL Quake, GL QuakeWorld and Hexen II. 
I Have Similar On My X1300 
at work (shhh) ;) 
any idea, does he have this issue with all glquake engines or do some have fixed behavior? 
Dunno, I could ask him to try some. Which ones would be good? aguirRe's and Joequake maybe? 
-bpp 32 
I have the same problems on ATI hardware. The fix? Add -bpp 32 to the command line or in the case of Fitzquake it can be set in the config. 
That fixed it for that guy too. Thanks!
Maybe make 32 bit the default in the future? 
Doesn't it run slower then? 
These days? I can't imagine. 
Not Slower... 
but it uses more memory (since quake loads all textures are at the same color depth as the framebuffer.) So 32bpp uses twice the total video memory compared to 16bpp. 
Oh And... 
I forgot to add as it might be a clue for someone as to what is happening. When I adjust my laptop's volume there is an on screen over lay to indicate the volume change and that will also fix the screen corruption... That is, until I enter the menu, then I can enter and leave without issue but moving the menu selection will often corrupt again and always when I change level/demo.

I think my nvidia machine had the problem as well but is has been out of order for a while and I really cant remember, it has a GTX 280 so when it was working I was playing CoD4 and L4D and Unreal3 a bit more then Quake. 
I had the same problem that was solved as soon as the japanese text input overlay appeared. Going in and out of the console (same key as to activate the overlay) fixed it all. Hardly ideal though, but I think it all works now, though I've not tried in a little while 
Transparent Water On Funcs 
If the water volume touches a wall which is part of the same entity, it will be transparant, too, so you can see through the wall (think skip window trick). 
that's because quake bmodels don't support liquid contents, even though they support liquid textures. The inside of a water-textured func_door brush is considered solid by the compiler, so when solid touches solid the interior faces are removed. 
Ideas For The Future 
FitzQuake 0.85 is a pretty rock solid release.

Whenever you get the itch for 0.86 or 0.90 a couple of a nice and convenient fixes would be:

1) Record a demo at any time
2) Multiple core bug-fix which mostly relates to the clock code. Some of the dual/quad core machines can have some serious issues with the clock (DarkPlaces, Qrack, JoeQuake, every Quakeworld mod, ProQuake all have the fix).
3) Demo to AVI capability. Some of these better custom maps deserve a video (YouTube or otherwise) but because FitzQuake is really the only remaining engine (well, and aguirReQuake too) without dem to avi and because it is the single player map making community standard, it hasn't caught on here (not that most people know how to do it, but seeing it in the Quakeworld or modding community is somewhat common and believe me it isn't hard to do either from the make the video standpoint or even the add it to the engine standpoint -- I added it to aguirReQuake in 30 minutes last year [and then sent aguirRe the source in the event he was interested, but alas he's kinda moved on]). 
Regarding #2... 
is this just the switch from a float to a double for the system time calls? 
#2 is a Windows specific issue (Mac/Linux not affected)

To fix you are mostly changing sys_win.c for the clock initialization and the Sys_Doubletime calls.

It is rather straightforward, I added to ProQuake when someone reported the problem about a year and a half ago and did it in 3 hours or less without any advance planning.

I believe I had included the change in the modified FitzQuake 0.80 source I made last year.

Someone experiencing the problem will have very erratic speeds when playing a demo (too fast or too slow) and gameplay will be choppy and jerky. 
FitzQuake 0.85 SDL Prototype 
I have a prototype FitzQuake 0.85 SDL almost done [because without a FitzQuake 0.85 SDL I can't play the maps on my Mac I like in the context I want].

I posted this here [versus the FitzQuake SDL thread] mostly because I'm thinking about attempting to merge FitzQuake 0.85 and FitzQuake SDL into a single set of source code. 
(Sometimes) You rock!

I was bugging metl the other day when that merge would happen and expected it some time in 2010. 
You Know ... 
It's just a lot of busy work to do it really.

I'll let you do the compile on Linux ;) 
that's pretty cool, i'm sure a lot of people will find it useful.

My fitzquake work is pretty much in stasis right now, as i'm trying to actually finish rubicon2, finally. 
A Mac engine which supports limit breaking maps!?!??!! A benchmark has been hit!!! :))) 
That sounds awesome! I was going to try and merge the two myself, but now it looks like I don't have to. i can help out with the OS X launcher if you like. Or you can just copy it from my old SDL sources. 
I have a prototype FitzQuake 0.85 SDL almost done [because without a FitzQuake 0.85 SDL I can't play the maps on my Mac I like in the context I want].
Do you need someone to carry your first born, Baker? You would be my personal Jesus if you get this done. I too play on Mac and would LOVE to get some of these new features and limits! 
And ... 
in an almost anti-climatic way -- after fixing 3 compile errors -- it's done.

Now all I need to do is FTP in my Mac and RAR up the source and post links here.

I imagine Spirit can compile the Linux version.


I was going to try and merge the two myself, but now it looks like I don't have to.

It should be set, but the project files and the source could use a quick look over on a rainy day.

I'll probably upload this here in 15 mins or so. 
I had to make one tiny change in net_sdlnet.c.
#include <SDL/SDL_net.h>
#include <SDL_net/SDL_net.h>

But this might be Debian's fault I guess.
Careful, it's a tarbomb (well, just two files inside). 
SDL Gamedir Crash 
Spirit, on OS X FitzQuake SDL has always crashed if I do a gamedir change and then load a map.

If I do "game travail" and then "map start"

The map loads for a microsecond, FitzQuake SDL freezes and then in several seconds the app terminates.

Does the Linux SDL have this problem? I inquire because I'd like to take a look at fixing it (but I'm not that proficient debugging on a Mac, I know how to dump the memory on Windows but have no clue on OS X). 
Broken limits in multiplatform are now a thing of the dark ages then, or soon.

Good work. 
I tried it but I got 2 hard lock ups in a row on my Mac (at seemingly random times). Is there something I can post that would help you?

Like, the game would freeze in full screen and I had no way of getting back to my desktop. 
I'm not so familiar with debugging on a Mac especially if I don't have the problem firsthand.

Updating the Fitz SDL 0.80 to Fitz SDL 0.85 mostly involved updating the rendering and protocol changes that Metlslime made in 0.85

The only freeze I have -- and I had this with 0.80 -- was trying to change gamedir via "game whatever" and then trying to play a map.


1. Had you had this problem with FitzQuake SDL 080? (very important question, tells me whether something preexisting or new is likely cause of problem)

2. What were you playing? (What map? Is a gamedir involved? This will let me play the map).

3. Do you have the problem in windowed mode? I saw lots of Linux users have fullscreen issues in the FitzQuake SDL release thread.

4. What resolution are you using width/height/bpp?

Maybe Sleeperwalker will have some ideas. 
Good Job 
Linux version works.

Request for future versions: the keyboard layout is still messed up on my German setting - some keys use the German layout, while others still use the English one. This means I can't type characters like quotation marks, for example, which is annoying in some situations. I wouldn't mind a non-localized layout.
Or can I fix this by using another keyboard setting ("dead acute" or whatever)? 
Baker: Yes, I get a segfault too. I had that bug earlier and told sleepwalkr, forgot to check back though (or maybe I discovered it only after the 080 sdl release).

negke: "setxkbmap us" in the shell before launching. Don't forget to go back to "de" later. ;) 
Coitus Interruptus... 
Loaded Fitz085sdl on my mac, happy as a bird...

Still no chance of mapping the Command function... Oh, shit.

I'm a keyboardly impaired Fitz user... 
I Meant Command Key. 
Stupid me. 
Is there any way to fix that initial mouse weirdness? Whenever I load the game, moving the mouse the first time snaps wildly to some seemingly random position. From that point forward, it's fine. It's weird. 
And this isn't just on the new one. Fitz has always done this mouse thing for me. 
All engines do that for me. 
Max_edicts + Loadgame On SDL = Crash 
I've been trying to play through Warpspasm on OSX and on the 2 second level it obviously drops to console and complains about max_edicts which is 1024 by default.

If I start up FitzQuake SDL and change max_edicts and then load a game = crash.

If I start up FitzQuake SDL and leave max_edicts as-is and load a game = no crash.

Investigation continuing ... 
First Off 
Which version of SDL did you base this on? Metl and I were planning on waiting for SDL 3, because it has some useful new features.

The mouse thingy willem describes is a known issue. I had tried to fix it, but it didn't work. Don't imagine it to be too hard to fix though.

Keyboard mapping is difficult because you have to translate SDL key codes to Quake key codes. I intended to ditch Quake key codes and use SDL throughout, which would squash all those problems. 
FQ 0.85 
I haven't read the small print but what is the difference between Protocol 15 and Protocol 666? 
Which version of SDL did you base this on?

I just updated your version exactly as-is. 
Re: #152 
Increased a handful of limits from 255 to 65535 (models, sounds, ammo, frames), allowed for edict limits above 8192, added per-entity alpha support, added high-precision aiming, and added a timing hint for interpolating models that aren't animating at 10Hz. I think that's it. 
Next/previous Weapons 
hey guys,

I just picked up Quake with FitzQuake and I'm LOVING IT. Newb question: how do I bind the keys for next/previous weapon?

Post A New Fitz 0.85 SDL Thread ? 
SDL FitQuake-0.85 seems to run ok for me :>. Finally i can piss off Darkplaces again - god that thing is slow.
First impressions: like the redone status bar, and it's very smooth - but maybe i'm just a little blotto tonight.

Here's a hack to allow for switching between fullscreen/window modes (SDL version) using the ALT-ENTER key combo. It's bloody rough, and may not apply cleanly because of tabs/spacing so ping me if there's any probs. I might get the inspiration to polish it up now i have the 0.85 source, but in case i don't/can't:

-------------------start of patch
--- keys.c.orig 2009-04-13 11:58:08.000000000 +1000
+++ keys.c 2009-04-13 12:18:28.000000000 +1000
@@ -1023,17 +1023,27 @@

// johnfitz -- alt-enter to toggle fullscreen. FIXME -- this does NOT work
-#if 0
- if (!down && (key == K_ENTER) && keydown[K_ALT])
- {
- extern cvar_t vid_fullscreen;
+// stevenaaus -- but this hack (from for SDLFitz works for me. SDL ;>
+ if (!down && (key == K_ENTER) && keydown[K_ALT]) {
+ extern SDL_Surface *draw_context;
+ extern cvar_t vid_fullscreen;
+ // VID_Restart ();
+ S_ClearBuffer ();
+ if ( SDL_WM_ToggleFullScreen(draw_context) > 0 )
+ {
if (vid_fullscreen.value)
- Cvar_Set ("vid_fullscreen", "0");
+ Cvar_Set ("vid_fullscreen", "0");
- Cvar_Set ("vid_fullscreen", "1");
- VID_Restart ();
+ Cvar_Set ("vid_fullscreen", "1");
+ } else {
+ Con_Printf ("SDL_WM_ToggleFullScreen failedn");
+ }
// johnfitz

-------------------end of patch 
"game" Command Segfault *seems* Sound Related 
I get a segfault too when using the "game" command to change games and then loading a map. I made a debug client and there's two backtraces below. Looking at them, I then tried running with "-nosound" and it f-ing works!

Hmmm.... I tested fitzquake-0.80 on FreeBSD and the diagnosis is the same: it only segfaults with sound enabled. But testing on my laptop (with the same OS as my desktop, AC97 sound and ATI mobility radeon), there's no segfault at all. I'm a little confused here, but this may indicate it has to do with CPU optimisations or memory structure allignments (this box is a Core 2 Duo, laptop is a PIII), but can't see anything too unusual happening really. Making with gcc3.4 is no diff.

Gdb reports "Program terminated with signal 11", which from the signal manpage ("man 7 signal"), is:
Signal 11 is "SIGSEGV 11 Core Invalid memory reference"

# gdb fitzquake core
Program terminated with signal 11, Segmentation fault.
#0 GetLittleLong () at snd_mem.c:186
186 val = val + (*(data_p+1)<<8);
(gdb) bt
#0 GetLittleLong () at snd_mem.c:186
#1 0x0807522f in FindNextChunk (name=0x809d487 "cue ") at snd_mem.c:206
#2 0x08075434 in GetWavinfo (name=0xaf485850 "dragon/sight2.wav",
wav=0xb7045498 "RIFF];", wavlength=15205) at snd_mem.c:296
#3 0x080757e1 in S_LoadSound (s=0xaf485850) at snd_mem.c:128
#4 0x0806bd05 in S_PrecacheSound (name=0xbff68fec "dragon/sight2.wav") at

and othertimes:

Program terminated with signal 11, Segmentation fault.
#0 0xb7effd16 in glGetIntegerv () from /usr/lib/
(gdb) bt
#0 0xb7effd16 in glGetIntegerv () from /usr/lib/
#1 0x0805f823 in Draw_BeginDisc () at gl_draw.c:691
#2 0x0808e9e6 in COM_LoadFile (path=0xb44541d4 "sound/ambience/wind2.wav",
at common.c:1649
#3 0x080757b1 in S_LoadSound (s=0xb50feb5c) at snd_mem.c:120
#4 0x0808440f in S_PaintChannels (endtime=139264) at snd_mix.c:189 
Anon - Weapon Change Commands 
Welcome to fun!

Here's an example of the commands to change weapons. You can type them in the console or put them in your config files.

//cycle weapon forward
bind SHIFT "impulse 10"

//cycle weapon back
bind CTRL "impulse 12" 
Metl, any chance at CSQC support in a future Fitzquake?

It would pretty much be at the top of my wish list. I believe the full potential of client-side qc hasn't really started to sink in, but it should.

Anything that uses custom keys or items could benefit from a nice looking inventory (instead of microscopic status bar slots) and an equally nice looking HUD.

Not to mention moving sounds (example: rockets emitting sound in flight, sound following trains, monsters etc) and stuff like completely new HUD elements controlled from qc.

Not to even remotely mention the possibility of choosing a player model etc. via a CSQC menu. (I know that Quake only has one player model, but that will change.)

As far as I know the stuff works by having a clientside progs.dat as well as a server side one. 
As time permits, Spike has a prototype CSQC WinQuake he gave me to do a test integration with ProQuake.

I'm pretty good at working with Avirox (QuakeC CSQC and FTE lover) and over the coming time there may be a standardized NetQuake implementation of CSQC with great docs and a good tutorial for engine authors to use.

Without this, really no one can implement CSQC and there certainly needs to be a standard implementation so any engine author's engine behaves in an expected manner.

This will unfold. 
That sounds great. Much better than anything I would have hoped for! :-) 
I'm hoping that someday I will add support for this. Right now the standard needs to actually be finalized. I am also looking forward to example implementations or tutorials that might spring into existence in the future. 
CSQC Will Likely Never Be Finalized 
At least not any time in the next few years... 
It has to be finalized to be mainstream. You try the line somewhere, accept the limits and write up the specs.

The secret to success is to finish, standardize, educate.

Commercial companies are good at this because things have to shipped.

You can always do more, but at some point in time you have to pull the cake out of the oven and call it a day ...

... knowing is it better than what you have today.

DarkPlaces and FTE have many features and yet so few mods because they are impressive science projects with some level of stability but never reach done.

And that's fine except no one can't write up specs and documentation.

Perhaps the best thing about FitzQuake 0.80 is it didn't have updates for nearly 4 years, drawing a new "standard" and giving everyone time to adjust.

(yes fog, skyboxes, enhanced limits, lits isn't the world but no one targets glquake as the main engine in single player any more. Probably largely due to Fitzquake 0.80) 
Perhaps the best thing about FitzQuake 0.80 is it didn't have updates for nearly 4 years

I hope that's not the best thing about it :P 
Haha ;)

Context, context, context ... 
but I agree, standards are important and if an engine implements something without a standard, that implementation can become a standard. It mostly depends on what content (maps/mods) actually use the feature.

I have tried to be cautious about adding crazy new features, and luckily most of the features I've added had a near-complete standard for how they worked (lit files, skybox, fog, external textures, .alpha, etc.)

When I do have to do my own thing (new protocol) I try to at least make it sane, and in the case of the protocol, I tried to add as much as possible in the first version to reduce the need to constantly make new protocol versions which only add one new feature.

Bumping limits is a stealthy way to set (or break) informal standards of course, and luckily aguirRe's engine has stabilized on which limits it bumps, and I was able to mostly bump all of those limits in a single release. 
hey, this is anon again..

don't know if this is a bug or just me being stupid BUT, upon completing all of the episodes/runes nothing happens. Specifically, I get back to "Introduction" and the last two episodes are locked (passed). The rest are open, even though I clearly remember them being locked upon completion. Also I only see 2 runes in the HUD.

You accidentally launched a new game after completing episode 2 and did not notice. 
You saved somewhere other than the start map. Which doesn't work too well... 
Old Mobility Radeon (gonna check the type later).

gl_clear 1 makes the game run ultra slow (think ~1 fps) in 32 bpp. In 16bpp it is slightly better (3-4fps I guess). 
No idea what type the chip is.
M6, 1002-4C59, 1028-00E3 (Dell Latitude something 610)

This is a new bug in 085. 080 works fine. 
Re: Bah 
The M6 Radeon is a mobile derivative of the Radeon 7000. Whatever the bug is, if it's on the Win32 driver side then it won't be fixed. I'd probably just keep gl_clear set to 0 until metlslime has had a chance to look at it. 
Regarding #171 / #173 
is this a bug specific to fitzquake 0.85 or do other fitzquakes (or glquake and derivatives) do it too? 
Fitzquake 085 only.

It seems related to how Fitzquake sets the resolution.

If I launch it with -width xxx -height xxx -bpp xx it works fine.
If I launch it normally, it does it's resolution change flicker and then runs so slow. I also noticed that the loading pentagram in the top right corner (always?) shows in funky colours then (like a normal map). Also a part on top of the display might flicker a bit.

PS: Setting a windowed mode with 16bpp when Windows is 32bpp is not fun. :P 
SDL Buggy Sound ? 
Testing large maps with FitzSDL-0.85beta on my desktop i'm getting quite a few crashes, sometimes every 5 minutes. And it just killed Xorg/Linux on my laptop while playing "timedemo demo1".

Hmmm... playing "-nosound" and have yet to get a crash. (Still.. negations can't prove a theory). 
I played multiplayer some days ago at office with FitzQuake0.85... it was running like a charm till it hang up, without any possibilities to unblock the game, except Ctrl+Alt+Del, and kill the process... and no error message at all... Maybe a network protocol issue, or something else, not sure...
Did you ever had heard about such issue before ? 
no, never heard of that. Can you tell me what map, what mod, and what you were doing at that moment? 
Hang up happened twice with 2 different mods: Reaper 0.80 and Killer 0.90.
The map was THF the first time, and DM3 the second time.
I was just running (bunny-hopping) and firing spikes with SNG on an another guy the first time, and the second I was ambushed with RL..
I am actually trying to educate my collegues at Quake DM at office :) 
Monster Movement Animation 
kinda liked the laggy monster movement animation v0.8 provided more than smooh v0.85 one. any way to set the imprefect monster movement at v.085 pls? would really like to downgrade this feature. thanks 
r_lerpmodels 0
r_lerpmove 0 
Oh Yeah... 
the documentation states that they both default to 0, but it is wrong, they default to 1 :P 
Some Kind Of Bug 
i'm not certain, but i believe i've found some kind of odd bug to do with .blocked for doors.

this happens in fitzquake, but not in aguire's glquake, which leads me to believe it's a bug with the engine.

basically, you get crushed by a door when you're standing on top of it while it is traveling downwards. this shouldn't be able to happen since you can't block a door in that manner.

the instance where this was happening was originally in a map that was breaking many limits, but i've transplanted the bit of map into a seperate map and the problem still occurs...

any idea what this is? i can give you the bsp/map if you're interested. 
Have you increased your max FPS at all? At very high framerates glitches like that can start to appear, and it might be that aguirre's engine keeps a hard cap on server frames. If you can reproduce it at 72 fps then it isn't that. 
if you can upload the map somewhere and email me the URL, that would be useful. (or just mail it to me if that's easier for you.)

Also what Preach said. 
Very Interesting... 
my host_maxfps was set at the default 72.
i set it to 10 and 60 and the bug didn't happen.
setting it to 71 (and 70, 69) makes it happen at a different spot, but setting it to 68 makes it go away, however, i get a single 'unstuck' message as the door hits the top of it's movement so i think it still has the potential to happen.

i'll send you the stuff in the mail. 
should have thought to test this sooner, but the bug also happens in normal glquake.

i'm pretty confused right now, because i've never had this problem before. i'm trying to figure out if i've built something different somehow, but as far as i can tell, it's the exact same combo of entities i've used many times before. o.o 
Yes, this happens at the start of Drew's speed map and at the start of White Room as well. Any kind of long distance door like that which you ride downwards has the potential to start hurting you for no apparent reason. It sucks. 
Ah, Okay... 
it's good to know it's not a bug i personally created. Still good to know about it, though. 
Directional Dependent Music 
So I'm finally playing warpspasm on fitzquake .85 sdl mac beta, and it's lovely (the way it was meant to be played, no less), but I notice that the background music is directional; that is, I only fully hear it facing a certain direction.

I don't know if this is an issue with fitz or warp, but I confirmed that it doesn't happen playing warpspasm in Darkplaces. 
It's an issue with all engines that don't do something special to fix it. Basically all sounds in the level have an origin point, even if they are attenuation = 0 sounds. I don't know what darkplaces does specifically to fix it, but it must treat those sounds specially, forcing them to be the same volume in both channels. 
I hacked it by putting four sound entities in each level, at the primary cardinal points.

The best fix is a fair bit of messing about - null sounds and playing them from outside. But nothing breaks immersion like alt-tabbing.

Basically sounds in quake can only be heard when seen. ATTN_NONE makes them full volume despite distance. 
Thanks Guys 
I suspected it had something to do with attenuation. It didn't really detract from the atmosphere anyways, I was just curious.

Keep up the good work and all; I really appreciate and enjoy it. 
#177 / 179 
metlslime, I made others tests in multiplayer.
I played with 5 collegues, and no errors / hang up / issues occured during more than an hour, hence the fact I think the issue comes from the mods itself... weird... 
That's why more engines need Ogg Vorbis cdtrack emulation (with cd play # support). 
Full Dark Torches 
what causes that? every so often, a wall torch (or quoth brazier) is full dark, even though the floor directly under it is very bright. 
... because it is in a wall ? I already experimented this dark-ish behavior with impaled corpses... maybe same issue.. though... :P 
here's a screenshot:

as you can see, the entity is inside the level (the origin on the braziers is up where the flame is) and the floor underneath is nearly full brightness.

it doesn't happen in aguirre's glquake though. 
so this is a fitzquake-only bug? Perhaps it's due to entity lighting interpolation (the code that uses the floor lightmap brightness to determine lighting, in fitzquake interpolates between neighboring lightmap samples.) 
i am hesitant to declare it's a fitz only bug since i can only really test in fq and aguirreGlquake (henceforth aglq, curse you aguirre for never actually naming your engine!). do the tools used to compile (in this case, aguirre's light util) make a difference when the engine reads the data?

otoh, i cannot ever remember seeing this happen in glquake. the 'zone' where an entity is full dark also appears to be more than just a single pixel or whatever. i've had it continue to happen up to 16~ units away from where i first noticed it.

in any case, if it's interpolating, then it's definitely not getting some lightmap data at all since that entire area is full of light. 
ok, too look at this a different way, perhaps it's interpolating with lightmaps on surfaces not parallel to that floor.

this is an unsealed map, so there are 2 planes, one that is the bottom of the wall brushes, and one that is the side of the floor brush. those 2 planes/collection of faces are full dark. 
Stupid Question But... 
.. did you add an angle value to give direction to the light ? It may explain the issue...
Also, I remember (correct me if i'm wrong) that depending of the light tool, the angle / mangle, anglesense / etc.. fields may be interpreted differently by different light tool... though... 
Quake Mission Packs ... 
Is FitzQuake capable of running the official Quake mission packs (Armagon / Dissolution) ?

From what I understand one of the packs requires a change to the engine to allow rotating brushes and I was hoping this change has been implemented in FitzQuake ?

I'm currently running 0.80 SDL on a mac and I'm not sure if 0.85 SDL has been released yet.

yes, it supports them -- the engine change was already in the source code when id software released it. 
Metlslime ... 
Fantastic - Thanks for the quick response.

On another note, I sent you an email a few days ago regarding FitzQuake and I was wondering if you'd managed to get chance to read it ?


How Do I 
Raise maxplayers in fitz? Setting it to 10 just tells me 'maxplayers set to 4'. 
In bog standard quake at least you can only raise the limit above 4 on the command line: -maxplayers 6

It only goes to 8 though, I think. 
'-listen 16' will do it for you 
Model Limits ... 

What are the model limits in FitzQuake in terms of vertices/triangle/faces etc ?

(I'm specifically refering to .mdl models)


Seems like the engine doesn't read my preferred fog value from autoexec, even though it has no problems with other related cvars, like r_skyfog. Any suggestions metl? 
fog gets cleared on map load, so it's becuase autoexec happens before you load whatever map you want to play.

I've had other questions/requests like this, it seems like people want to use fog as a user preference rather than as a mapper testing feature, so i probably need to figure out a way to do this. Probably need to track whether the current fog value was set from the console vs. the worldspawn, and clear it only if it was set in the worldspawn. Of course this breaks any mod that uses stuffcmd to hack fog into a level, maybe i need to publicise SVC_FOG so that doesn't happen.... 
That some mods will change fog as well - Quoth's trigger_iforgetwhatitscalled can change the fog. 
Thanks for the explanation. I remember trying out some 'fancy' engines years ago - those kept the fog throughout the map changes once it was enabled from the main menu. I didn't know it was a complicated issue till you explained it to me. It isn't that important anyway, just a minor annoyance that can be easily dealt thru' the use of a simple alias. Even though I prefer playing custom levels the way they're intended to, I thought minimal use of fog would spicen things up a bit when replaying the classics. 
Re: 213 
i'm kicking myself that i never made an info_interpolateFogValues :P 
It Was Good 
In Lazarus, but the only way to make it really work visually was to trap the player in a lift whilst it interpolates. 
Windows 7 
I have just finished doing a round of benchmarking using the Windows 7 RTM.


FitzQuake: timedemo demo1: 1227 fps


Curiously, on Windows Vista SP2, I was getting roughly 400-500fps using the same config and same hardware and was thinking that the engine plain doesn't scale any further anymore. But apparently you can squeeze a fair bit out of it with new underlying OS tech.

Core 2 Duo E6600 2,4 Ghz, 4gb ram, NVIDIA 8800 GTS 
And For The Curious 
I am seeing a 3-10% performance increase in Windows 7 compared to Vista across the board, depending on the game. However, Quake and Quake 3 stand out in an absurd fashion.

FitzQuake: 400-500 fps => 1227 fps
Quake3: 380fps => 775 fps 
does 0.85 support external textures for sprites? couldn't find it in the documentation, so it probably doesn't, but on the off chance it does..? 
no, it doesn't. 0.90 maybe :) 
Cool :) 
about external textures though...

why do they seem to be lit in a slightly different way from embedded textures? it's hard to describe, but they seem universally darker and don't seem to get over-lit like embedded textures. they seem to be like old glquake where lighting caps out at 100% light.

any chance 0.90 could help smooth out those differences to make embedded and external textures more similar in game? 
that's suprising to me, the lighting should be the same on both types of textures.

If you're using idgamma, then that would explain it, since it alters the appearance of all quake image files without affecting any external replacement images. 
Any chance you could run that test on XP too? The cynic in me suspects that the speed boost has less to do with Win7's improvements than it does with Vista's (how to put this delicately?) crapiness. 
No, I am not going to be install XP on this machine :) 
Fps Related Problems 
On my Pc I have some problems that only appear at high framerates, with 120fps it starts and with 500-700fps it gets really really anoying.

so host_maxfps is set to 999

When walking on a ramp like in E1M1 with those buttons the movement becomes really strange I simply can't move forward I have to jump down those ramps. This happens only at high fps rates like 500+, but at 200 fps at the start of the downward ramps there is a little bit of lag. at 60fps everything runs fine.
I noticed another problem in sm155_ankh, it seems that I get hurt by the elevators when standing on them, in fact it becomes unplayable, the problem does not occur with vsync=1 /60fps.
Those problems seem to happen with aglquake too. However with darkplaces it runs fine even at higher framerates.
Testet on vista32 and Ubuntu 9.04 32
gfx card 9600gtgreen driver 190.38win 185.18.36lin 
host_maxfps be left at 72? 
per-entity alpha doesn't work on sprites?

what if a setting != 1 (or 0) would change blending mode on sprites to additive and then, depending on the alpha variable, multiply the sprite's pixel colours by a shade of gray corresponding between 0 and 1?

or just make it do what you did for brushes and models? :P 
it can be done with alpha blending, and will probably make it into a future version. The reason it's not in there now is it seemed less important than the other entity types and i was trying to wrap up that version so i could actually Ship It. 
that's cool. it's not like it's a huge problem or anything. brushes and models are more important, as you said.
still, it was odd that alpha wasn't supported for all types of entities, which is the only reason i brought it up. :) 
just a question, in the fq085 readme, it says:
fixed sliding around while standing on solid entities' bounding boxes (monsters, players, etc)

but it's not actually fixed. was this a planned feature or something that was scrapped? 
That was fixed in a really early version (like 0.60 or something)and later reverted when I realized it had side effects. I am now more cautious about changes that affect gameplay. Plus I think thus can be fixed in qc instead. 
yeah, i can be. i was only wondering if it was going to be re-added and if it was worth skipping the qc fix. 
I think i'd have to be convinced that it would be a good idea to re-fix it in the engine, since it seems like that would just lead to inconsistent behavior across engines. Probably better to fix in in qc so that it works in all engines. 
in runequake its fixed so u don't slide on players heads

leads to great towers of players now and then 
Keep The Sliding. 
Players standing on monsters and the like as if standing on the ground is a potential gameplay changer. Players can use such entities as platforms to reach places more easily or are otherwise inaccessible.

I would rather see the "fix" either left out, or included as an option, with the fix turned off as default. One reason why I play FitzQuake is it has useful features such as frame interpolation and increased limits while retaining the behavior and feel of the original engine. 
Scrag Riding Would Function Finally 
with this fix 
i think, if i ever revisit some of this stuff, i will follow the Darkplaces method of having a seperate cvar for each gameplay-changing "fix" so that you can turn them off as you wish. 
here i am again... :P

this bug (at least, i believe it is a bug) is very strange. specifically, i experience a large performance drop (1ms frames become 20ms frames and the pentagram icon appears) in start.bsp when the light_flame_large_yellow in those 2 big braziers next to the start point are in the pvs on the first loadup of the map. they also, sometimes (depending on your position and view angle), appear partially black except for a few pixels.

if you walk to the end where the normal skill teleporter is (but don't take the teleporter), the light_flame_large_yellow entities disappear out of the pvs (from vis) and performance goes back to normal.

if you restart the map (either by suiciding or restart command), two things happen.
1. the wall torches on the dividing pillars facing the start point turn black, but only on that last frame as the map is reloading. (you see it as the frame is displayed while loading, i mean)
2. the performance drop goes away as does the black pixels problem. (which i am guessing are linked?)

now, here's the complicated part. this happens in a mod, and doesn't happen in stock progs.
this performance drop is a recent developement though, afaik.

so, onto some more weirdness:
the mod allows you to spawn a 'pet' fiend. now, if you load start.bsp (performance drop now) then reload the map (performance drop is gone) and then spawn the fiend, the performance drop is back!
now, if you walk back to the normal skill teleporter and the light flames disappear from the pvs, the performance drop is gone!
also, if the pet fiend goes out of the pvs, while the flames are in the pvs, the performance drop also goes away.

some final info, as it may be relevant:
the player model is also custom with above average vertices and faces and gl_nocolor is 1.

finally, the 'pet' fiend uses a new movetogoal function:
void(float step) movetogoal_ext =
local float stepIncrement, stepRemain, tempYaw;

if (step > 10)
stepIncrement = step / 10;
stepIncrement = 1;

stepRemain = 0;
tempYaw = self.angles_y;
while(step > stepRemain)
stepRemain = stepRemain + stepIncrement;
self.angles_y = tempYaw;

(movetogoal_builtin is the original function)
so you can see, multiple calls to movetogoal are happening in a single frame.

if you replace this with the old movetogoal, the performance drop doesn't happen when spawning the pet fiend, but the performance drop is still present when first loading start.bsp.

any ideas? o.0 i know this is technically my fault as it's a mod, but the occurrence is so strange and unique, i felt i should post about it. :P 
as always happens when i post about some bug or whatever, i figure out what was wrong. o.o

my heapsize was too small. 9_9 
Why isn't heapsize init-ed to something bigger by default. I know FitzQuake is conservative in some ways, but couldn't this be done ? 
I guess i could; in the past i've just assumed that my users are people that switched from glquake, so they already know how to configure settings that were present in glquake (heapsize, gl_flashblend, etc.) On the other hand, maybe that's not true and maybe many people don't know about those types of settings. If they don't, then I guess i need to figure out the best way to have defaults for those settings which satisfy the most people possible. 
I think defaulting to values that the average machine these days can handle is smart. I hate whenever I have to pass in -heapsize. It irritates me because I can't believe I'm still doing it in 2009. :) 
64 MB heapsize seems reasonable these days, and should be enough to handle all but the most extreme cases. 
Especially considering that machines these days come with a few GB of RAM standard. Seriously, jack the default up to 128MB and be done with it. :) 
for me, i never even thought about it because i never actually run the executable itself.

i always have my fq.bat file which does things like -particles 10000 -heapsize 64000 -bpp32 etc etc.

if you wanted to make the stuff standard, that's cool, but it doesn't bother me either way. :) 
I was thinking about adding permanent parameters to the next version of fitz sdl on mac. There would be a preferences dialog where you can set some permanent parameters, and then add other parameters using the standard launcher dialog. 
Well it's not DOS anymore, even a 32-bit OS will be able to address ~4GB of virtual memory, irrespective of how much actual physical memory you have. Using a heapsize of 128MB is enough to run warpc with quite a bit of headroom (you can squeeze it into 64MB if your engine is careful enough about what it allocs), so I'm wondering is there any requirement for this command-line option to even exist any more? My own engine got rid of it a good while back, but then I use my own custom allocators which are NOT a trivial thing to write. 
Who doesn't have 128MB oF RAM? Seriously, it's time to just set it to something huge and move on. :) 
is there a way to dynamically set it?

i mean, it would be pretty bad ass if the engine just reallocated everything if it ran out of room automatically... ^_^; 
writing a whole new memory system would solve this :P 
Has some code IFDEF'd labelled "DarkPlaces memory manager" that dynamically allocates memory as needed. 
Oh, dynamically allocating as needed is easy. Keeping track of what memory you have allocated, freeing it in the correct places, keeping contiguous blocks where needed, ensuring nothing gets stomped, and transitioning from Quake's cache/hunk/zone system - that's hard.

It's the kind of thing where - unless you *REALLY* need it, or unless it scratches some particular itch you have - you might be better off just upping the default Heapsize. 
I forgot "...and doing it all efficiently..." :) 
If It Works ... 
The ezQuake #IFDEF DARKPLACES_MEMORY_MANAGER code -- if it works -- is rather simple.

Shockingly simple, actually. 
Alias Models + External Textures 
Does FitzQuake support external textures for alias models?

/Btw ... FitzQuake is about the only non-DarkPlaces engine that renders a skybox when submerged in a liquid with r_wateralpha < 1. I never had a doubt ;) 
Argh .. Nevermind 
I thought this was added in 0.85 
Regarding -heapsize And Such 
Is there any particular reason why things like -heapsize aren't automatic and dynamic? 
Yes, check 5 posts above yours. 
This Thread Beats The Record Folks 
On september 16, year 2000, 'maiden' posted the #237 message on the infamous thread at Qmap, called:

- - - - - - - - - - - - - - - - - - - - - - -
QuakemapDesigner... Err Designs Quake Maps.
Posted by Shambler [], 31/08/2000 09:13 GMT
" The modestly named QuakeMapDesigner has been shouting about the Quake maps he's, err, designed at his QuakeMapDesigner site. They look like deathmatch and/or CTF maps to be (though I can't be sure), and QMD is after some reviews, so be sure to pick up some maps and give him an honest appraisal of their quality.
P.S. He's French apparently - any relation to you, Bal?? =) "
- - - - - - - - - - - - - - - - - - - - - - -

So just for you to remember the " good old days " folks and congrats on this thread, because it has a higher number of posting message.


"Where imagination means, levels!"
P.S.: QMD stands for "QuakeMapdesigner" and not " Quick Masturbation Discharge ". 
When that message was posted I was running around, truant from 6th form, popping magic pills and sleeping in every day. 
"FitzQuake is about the only non-DarkPlaces engine that renders a skybox when submerged in a liquid with r_wateralpha < 1."

No it isn't. ;) 
i'm not even sure why any engine would fail to draw the skybox when underwater, unless they specifically added code to do it. Otherwise you'd think that "if sky polygons are visible, draw skybox" is the most obvious logic. Or even the more dumb and simple "always draw the skybox" approach. 
User Error 
I had underwater fog on and didn't make the connection between that and the traditional fog. Skyboxes are viewed as infinitely far away. JoeQuake, Qrack, FuhQuake, ezQuake just draw the underwater fog.

And I believe none of the above even draw the skybox with any fog setting.

Bad post on my part! 
True Tho 
Yeah, fog needs tweaking for an infinitely distant skybox, and at the very least the fog end value needs tweaking also even without an infinitely distant one. Haven't looked at FQ's skybox code yet but I wouldn't be too surprised if it did something like double the fog end value when drawing the sky. 
Some FQ 0.85 Bugs 
In TexMgr_LoadImage8 you have "if (glt->flags & TEXPREF_ALPHA && !(glt->flags & TEXPREF_CONCHARS))" (also the same in a few other places) - "glt->flags & TEXPREF_ALPHA" needs parentheses. 
More Bugs 
The initial value of gl_max_anisotropy should be 1. This fixes the infinite loop in the cvar callback and is conformant with the spec (i.e. a value of 1 specifies normal isotropic filtering). 
fitzquake disabled gl_fog and just does a fixed-opacity blend over the sky, unless gl_skyfog is 1 (fully fogged) and then it just draws solid-colored, textureless sky polys.

As for the other bugs, thanks... i'll have to check those out. 
Just learned that there's a 256 frame limit which seems to be an engine side cap.

Going to make changes to have the thing fixed on our end, but thought I'd ask - is there any reason not to fix it? Apart from the obvious 'hardly anyone wants 256+ frames of animation'. 
That limit was raised in protocol 666, and the frames seem to always be passed as 32-bit ints internally, so i'm not sure what the problem would be. Is it crashing? 
Without a warning and only when I add more than 256 frames. I thought I remembered something about it being mentioned in documentation but couldn't find it again.

In any case the model is going on a diet - there are some unnecessary frames in there that can be pruned. Just thought I'd mention it. 
Frame Reduction 
One trick you can use to get rid of frames is to create framegroups from some animations. The safest candidate is the stand animation, since there's no action the monster performs which needs to be synced with the frames. Anything more complicated than that would almost always cause difficulties, but that one should be safe enough. If you're only 8 or 10 over the limit, that might just get you back.

Once you know that trick, you can also make longer idle animations, knowing that they will only cost you one frame. I've not done it yet, but it's one of those ideas that's been knocking about... 
That's a cool idea - although there are actions that need to be run like idle sounds, and we've got some idle tic stands as well.

Having said that there's some stuff that can use it such as the simpler trap style entities like wasps, spikemines and maggots. 
okay, i'll look into it. Thanks for the report. 
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? 
This post was flagged as spam. 
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. 
Post A Reply:
Website copyright © 2002-2017 John Fitzgibbons. All posts are copyright their respective authors.