News | Forum | People | FAQ | Links | Search | Register | Log in
Fitzquake Mark V
I wasn't planning on doing this mini-project, it started as an effort to address some Fitzquake issues, fix them the right way up to Fitzquake standards (i.e. do it right, once and properly versus continual releases) and donate it back.

FitzQuake Mark V Download:

Short version: Eliminated most issues in FitzQuake thread, most issues I can even remember hearing of ever and marked every single one clearly with a very minimal implementation.

It may be the case that only metlslime and Quakespasm and engine coders may find this engine upgrade of interest.

Features: 5 button mouse support, single pass video mode, external mdl textures, alpha textures (like RMQ), record demo at any time, rotation support, video capture (bind "capturevideo toggle"), console to clipboard, screenshot to clipboard, entities to clipboard, tool_texturepointer, tool_inspector (change weapons to see different info), clock fix, contrast support, fov does not affect gun, gun displays onscreen, Quakespasm wrong content protection, external ent support, session-to-session history and .. (see readme).
First | Previous | Next | Last
October 10th Build 
Windows version:

* Nehahra Support (game nehahra -nehahra in console). fmod.dll is optional --- it must be in the nehahra folder as the engine will not honor an fmod.dll in the Quake folder because several different versions of fmod.dll exist.
* Direct3D Renderer version
* MP3 remap capability
* Bullet-proof automatic water transparency
* WinQuake renderer, it plays Nehahra too and does BSP2 like Tronyn's Something Wicked.
* Maps menu, under single player
* Demos menu, under multiplayer
* WinQuake renderer loads skyboxes
* GLQuake External texture support for sprites, all 2D graphics (in addition to , models. WinQuake renderer has sprite32 support.
* PNG screenshots
* All BSP2 fixes and the Quakespasm flickering entity fix.
* Protocol 15 serving compatibility. FitzQuake 0.85 can't actually serve a protocol 15 game.
* Supports BPJ protocol 10002, so can play the Warpspasm demos
* Fixes for Windows 8.
* External music can be turned off or resume in real time.
* Switching to a gamedir will detect the correct map for the mod if possible and doing "Single Player->New Game" will run that map. For example, if you play lunsp1, it will run lunsp1.bsp doing Single Player->New Game. Or if the mod has a map named something like "warpstart" it will load that map.

Might have APSP1 func_train fix. I'll have to dig up the source code and upload the Mac version tomorrow and likely post a couple of screenshots and update the upload .exe as I believe there is a more current stable version with additional features.

The above feature list is incomplete, but I have to dig up a feature list. It might play dz demos if dzip.exe is in the Quake folder.

[I hope I uploaded a fairly polished version, there is a chance I didn't. Mark V supports libcurl downloads but does not require the DLL and doesn't actually use it for anything because I never fully completed the Quaddicted installer I was working on :(.] 
[Uploaded version doesn't support playing .dz demos. Tomorrow I'll find right version. Mac suports playing dz demos too.] 
3x Post 
Here is a Nehahra screenshot. This is actually the WinQuake renderer version:

Other features I am remembering: autodemos and autosaves during game if cheats are not being used (and probably if frames per second is 72 = standard SDA Quake rule). Auto-saves appear in the bottom 3 slots in the load game menu, autodemos would obviously appear in the demo menu. cl_autodemo 0 turns off autodemo. Autodemo and autosave will keep no more than 3 saves at any time.

Another feature: Mark V will never load a config saved by another engine and fall back to a backup copy.

Mark V *should* be totally immune to the Zerstorer and Nehahra config meddling as it uses a method similar to FTE latched cvars to revert cvars to their correct values after cutscenes and/or QuakeC or demo-playback meddling. However, since I'm not sure of the features of the version I uploaded or what I was doing with the source code at the time, can't be 100% sure.

Other features: r_lavaalpha and r_slimealpha cvars since Quakespasm was pushing for that (but doesn't seem to have the cvars in Quakespasm itself?) 
Damn ... Unfortunate 4x Post 
Enhanced coop capabilities:

Ping scoreboard, per player scores in coop.

If Mark V is hosting a coop game and teamplay 1 is set, the engine will ensure that all connecting players have the pants color of server host to prevent self-damage.

Feature can be disabled with sv_coop_enhancements 0. 
That Feature List Looks Huge 
I had some questions though:

* Protocol 15 serving compatibility. FitzQuake 0.85 can't actually serve a protocol 15 game.

Is this true? what does fitzquake do wrong?

* Switching to a gamedir will detect the correct map for the mod if possible and doing "Single Player->New Game" will run that map. For example, if you play lunsp1, it will run lunsp1.bsp doing Single Player->New Game. Or if the mod has a map named something like "warpstart" it will load that map.

How do you detect this? Are you scanning the entities lump to find "trigger_changelevel" and looking for what map points to the other maps? Or is it like, find the map with the fewest monsters? 
I May Be The Only One... 
In response to some of the posts above, but I think the RMQ engine was, and still is a fantastic engine, it was what is now Quakespasm. But I like it over Quakespasm for a few minor reasons, and it is my engine of choice for most things. Sure it has some flaws but what engine doesn't? I'm just curious as to why there is such a strong dislike for RMQ.

I don't mean to shift the conversation from Mark V, which is what this thread is about. I applaud you Baker for releasing a big update to the engine, I intend on playing around a lot with it. 
I am so impressed by your persistence and skill. You went from (seemingly) zero to being a full on engine developer. That's awesome!

Quaddicted installer
Oh that would be too great! Some day, some day. :) 
Texture Filtering Modes 
I have tried the new builds a bit. The Winquake version doesn't run for some reason for me at all, crashes during startup (Win 8.1 x64, Intel Core i7-4770K @ 3.5 GHz, 16GB RAM, nvidia GF 770).
The DX8 build seems fine, but when using gl_texturemode "gl_nearest_mipmap_linear", it seems that floor/wall/ceiling and some model textures (e.g. health packs) keep bilinear/trilinear filtering. Does it require additional settings now or is something broken here? 
Auto-detect Start Map 
How do you detect this? Are you scanning the entities lump to find "trigger_changelevel" and looking for what map points to the other maps? Or is it like, find the map with the fewest monsters?

I would assume something like "is the map name the same as the gamedir name?" is a good first test to make. From there I'd move to something like "is there only one map in the gamedir?", from there maybe look for a map with "start" in it's name, then finally return "start".

This is a cool idea but what I'd really also like to see is, if the start map isn't called "start", then assume that it has no skill selection halls and pop up a skill menu before loading it.

That "Levels" menu is also cool, well done Baker! 
Possibly nice feature: highlight (in a subtle way) all maps (files) exclusive to the specified mod directory when using the maps (dir) command..

Possibly nice feature #2 (half-joking): enable the engine to display the mod's/map's readme, so the player can look up things like the start map himself (because there's only so much auto-detection it can do). 
During sign-on, FitzQuake sends a message larger than protocol 15 can handle and preventing it gets to be very complicated (client scenario, server scenario, client and server, per protocol situations). There were 2 instances in one of the net_*.c source files that weren't being handled because those functions used sizeof on the buffer. Fixing that requires a global variable. 
@mh/metslime --- start.bsp --> *start*.bsp <gamedir>.bsp which catch the overwhelming majority of single player releases to the point that I can't name a release this doesn't work for offhand.

@negke "highlight (in a subtle way) all maps (files) exclusive to the specified mod directory" The maps menu in this Mark V does exactly that.

@mh - if the start map isn't called "start", then assume that it has no skill selection halls and pop up a skill menu before loading it. Although not in this build, I rolled the bsp compiler into the engine and was going to have to do things like that, including constructing an "Undergate" like map in real time and devised a mechanism to take screenshots using intermission camera spots that could occur in the background.

I never finished it, though.

The bsp sources were kept in a separate folder to ensure proper separation, but rolled into the engine to ensure availability. 
The DX8 build seems fine, but when using gl_texturemode "gl_nearest_mipmap_linear", it seems that floor/wall/ceiling and some model textures (e.g. health packs) keep bilinear/trilinear filtering

Not sure, I remember testing mostly only for the default settings and having to rewrite a few chunks of the MH Direct3D wrapper. It has a few (very few) weaknesses that the OpenGL version doesn't, apparently. I didn't notice that one it seems.

The DX8 version is runs on almost anything including really old Windows PCs with no Open GL drivers or a current one with bad Open GL drivers.

The Winquake version doesn't run for some reason for me at all, crashes during startup That is strange, I will attempt to see why that would be the case. 
MP3 Remap (id1/music/setmusic.cfg) 
Note: This is pretty much a literal implementation of what metslime's suggested back several months ago.

Mark V will run music/setmusic.cfg on startup. If Quake wants to play track 04, the remap will instead play sometrack.mp3 as indicated below.

This allows a single player release to have packaged mp3 music remapped and should be robust and flexible enough to be a standard.

Just include a setmusic.cfg in the music folder of the release.

Example contents:
setmusic 00 track1.mp3
setmusic 01 mytrack2.mp3
setmusic 02 somethingelse.mp3
setmusic 03 anothertrack.mp3
setmusic 04 sometrack.mp3 
Docs: Server Protocol 15 Compat, Intermission Fix 
1) Intermission Fix. Like ericw, I don't know exactly how or why the intermission fix works. Ben Jardrup's Enhanced GLQuake uses it. It works perfectly.

Mark V uses it.

2) I documented the protocol 15 server compatibility. Coincidentally, this happened to be modelled after Enhanced GLQuake. The solution is essentially simple, but unfortunately requires numerous changes to the source code.

In some ways, this fix doesn't matter as few people use a standard Quake engine. But for full backwards compatibility it is nice to have. 
@Baker, you should consider just using 'cd remap' instead of your 'setmusic' command, that is if you want consistancy with DP+FTE too. 
In FTE/DP would "cd remap 04 sometrack.mp3" be the equivalent of what I posted above? 
About Texture Filtering In DX8 Build 
Apparently a similar issue as the one described above (#519) happened during development of Quakespasm 0.90. According to bogworth, it was related to anisotropic filtering.

Quote bogworth:
"The combination of GL_TEXTURE_MAX_ANISOTROPY_EXT with values greater than 1 and GL_NEAREST appears to have vendor-specific behaviour - in my case, GL_NEAREST is ignored." and
"The problem appears for textures that are mipmapped (eg, not models), when gl_texture_anisotropy is greater than 1 and gl_texturemode is 1, 2 or 3."

I dunno if all of this applies (probably not, as I also had models with filtering changes being ignored), but maybe it helps with detecting and eliminating the problem.

Would be great if this got fixed since the DX build seems to be the only one properly working on my system right now (Winquake crashes and the vs2008 build shows weird texture issues). 
aye, in FTE, if its numeric then it goes and plays track%03i.mp3, otherwise it goes and plays the named path (with the same optional prefixes as other fake-tracks).
the same as 'cd play' and 'cd loop' commands.
the only catch is that you can only remap numbered tracks, not named ones.
I'm not entirely sure on which paths that DP assumes it might be in (if any), but the rest is the same as far as I am aware (for supported file formats).

what annoys me, is that world.sounds is a float. I'm tempted to add a hack and specially parse the entity lump to read it as a string, and update the server's svc_cdtrack generation to just play that string instead somehow. numbered tracks are so old fashioned!
plus, they get in the way of map compilations.
of course, this assumes mappers would use it. 
Ok, the text vs. numeric. I was thinking that would be required and you validated that. Well, the better compatibility with existing engines ...

Numbered tracks are what Quake expects and built into the pipeline. I think working with them sucks. I'd almost suggest a wordspawn key, but I fear a drastic proliferation of them. 
Well, I am glad the Direct X version is working for you.

Does current Quakespasm work properly for you?
What about a previous Mark V or Fitz 0.85? I'm trying to determine issue.

The current Open GL Mark V uses non-power of 2 (July 2014), uses stencil operations more (this one), varies from Fitz 0.85 by using the texture matrix instead of the mesh alterations (been that way since 2013).

The Direct X version of Mark V uses neither the texture matrix nor the Fitz 0.85 meshing alterations so the model textures will look like --- well --- JoeQuake/GLQuake/Requiem --- which are stretched and not crisp like FitzQuake.

It is done like that to support external textures for models in a straightforward way.

I had intended to revisit it in the Direct X version, but that time won't be coming soon. I don't think, at least.

I'm trying to mentally picture whether or not non-power of 2 would solve that and if the Direct3D 8 wrapper supports that. 
@NightFright, @Baker 
Would be great if this got fixed

It can't be fixed because D3D doersn't support it.

What D3D offers for filter modes is one of three options (for each of min/mip/mag):

- Point
- Linear
- Anisotropic

Various combinations of Point and Linear then correspond to the GL filter mode names, but the important thing here is that Anisotropic is also it's own filter mode, and anisotropic filtering is only enabled if you select that filter mode.

So in other words you can't combine point filtering (what GL calls nearest) with any form of anisotropic filtering.

This restriction still exists in D3D11 where the options (excluding shadow map comparison states) are:


Again you'll see that most of these modes correspond to the GL modes (D3D11 has a few extra ones) but that D3D11_FILTER_ANISOTROPIC is it's own mode and can't be combined with point/nearest filtering.

This isn't the kind of engine bug that you can fix in code, it's a limitation of the D3D specification. That's a difference between GL and D3D - GL keeps things loose and floppy and allows implementation-specific wriggle-room, D3D doesn't.

I'm trying to mentally picture whether or not non-power of 2 would solve that and if the Direct3D 8 wrapper supports that.

Non-power-of-two is the ideal solution but I don't remember if the wrapper supports it. D3D8 does support non-power-of-two textures so it would be easy enough to add a pseudo-extension check and code up the loader (be careful when reducing miplevels for non-power-of-two textures though). 
Thanks MH. I think npot solves the problem in a way that won't interfere with external textures, when I rebuild I'll tell the wrapper to say it has npot texture support. 
(be careful when reducing miplevels for non-power-of-two textures though).

Whoa ... what's this? Is there a size limitation of the mip textures of some sort? 
What Works (for Me) 
I had been using Mk V r15 before on the same machine without problems. Quakespasm 0.90 also works.

Strangely enough, the WinQuake build works on my Samsung NP-NC10 netbook (Intel Atom N270, 1.6 GHz, 2GB RAM).

The sad thing is that right now, I am stuck with DX8 since the OpenGL build (vs2008, I assume) doesn't work, either. When I load the start map for example, huge chunks of textures are missing. In the "Welcome to Quake" hall with the three skill selection gateways, it cuts away pretty much half of the screen. Never had any problem like this. 
Whoa ... what's this? Is there a size limitation of the mip textures of some sort?

No, no limit. You just need to be aware that the standard for both GL and D3D specifies round-down (so for a dimension of, say, 63, the next miplevel would become 31, not 32).

A simple way is to check "if ((width & 1) || (height & 1))" for a miplevel, then send it through GL_ResampleTexture instead of GL_MipMap. IIRC the stock Fitz code does some funky stuff with miplevel reduction (reducing each dimension separately) so you'll have some fun there.

I believe that the latest Quakespasm has non-power-of-two support so it'll probably be useful to cross-check with that.

For D3D9 the check is "if (!(d3d_DeviceCaps.TextureCaps & D3DPTEXTURECAPS_NONPOW2CONDITIONAL) && !(d3d_DeviceCaps.TextureCaps & D3DPTEXTURECAPS_POW2))" for full non-conditional support, and if memory serves it's the same in 8, so you can report that GL_ARB_texture_non_power_of_two is supported if they're met (everything else is done outside of the wrapper).

Conditional support means that the address mode must be clamp and you can't use mipmaps which is broadly equivalent to GL_ARB_texture_rectangle (although the GL extension is weird in that it uses integer texcoords). You'll want full non-conditional support in the general case, although conditional might be OK for MDLs (provided you're still doing the Fitz thing of not mipmapping them).

D3D should also not suffer from crap like "we'll say we support non-power-of-two textures but will emulate everything in software if you try to actually use them". 
OpenGL Issue 
Here is a screenshot of what the game looks like for me with the vs2008 build. Skyboxes, liquids and teleport surfaces are totally screwed. 
That gives me something useful to work with.

I use a stencil operation to draw the sky. All my computers even my Mac are ATI/Intel, apparently Nvidia does not like. 
Why not just draw the sky, clear the depth buffer, and move on? I understand it's probably an optimization thing, but ... 
r_mirroralpha support. Has to draw the sky twice. 
Also sky needs to draw on top of other things depending on the map 
Like Jam2_mfx.. 
In Mark V r15, what happens if you do r_shadows 1 (do the shadows look right?)? Mark V uses the stencil for shadows and has since 2013.

Although stencil operations seem the prime suspect to the Open GL compatibility, it might not be the case. 
R_shadows 1 In Mk V R15 
I was using r15 just before I switched to the new builds of yours. No problems there at all.

Proof (screen taken with r15): 
That's helpful. I'm sure I'll figure it out, I see from my sky drawing function I had some varying opinions about the drawing, which since it worked fine on my graphics card I have since forgotten ...

Maybe if I reflect on this a bit, I can come up with a resolution.

void Sky_Stencil_Draw (void)
int i;
msurface_t *s;
texture_t *t;

// Baker: Direct3D doesn't have stencil at this time
if (!renderer.gl_stencilbits || vid.direct3d)

// Baker: No sky to draw
if (! /*|| !frame.has_sky*/)

// Baker: Where drawn (doesn't z-fail), replace with 1
// in the stencil buffer.
eglStencilFunc (GL_ALWAYS, 1, ~0 );
eglEnable (GL_STENCIL_TEST);

// Baker: A no draw pass of the sky brushes, does not even
// write to depth buffer (maybe it should?) that writes
// our stencil overlay.

eglColorMask (0,0,0,0);
// eglDepthMask (0); // Don't write depth to buffer
eglDisable (GL_TEXTURE_2D);
for (i=0 ; i<cl.worldmodel->numtextures ; i++)
t = cl.worldmodel->textures[i];

if (!t || !t->texturechain || !(t->texturechain->flags & SURF_DRAWSKY))

for (s = t->texturechain; s; s = s->texturechain)
// if (!s->culled)
DrawGLPoly (s->polys, 0); // Not here.
eglEnable (GL_TEXTURE_2D);
eglColorMask (1,1,1,1);
// eglDepthMask (1);

// Baker: Keep any pixels where stencil wasn't drawn
// for this drawing pass.
eglStencilOp( GL_KEEP, GL_KEEP, GL_KEEP );
eglStencilFunc( GL_EQUAL, 1, ~0 );

// Baker: Now draw the stencil
Sky_DrawSky ();

// Turn it off
eglDisable (GL_STENCIL_TEST);
Transparent textures on worldbrushes arent handled correct. This screenshot is not what it looks like ingame, there you actually see the pink color.

When doing this with func_illu/wall whatever, all is good. 
Transparent textures on worldbrushes arent handled correct. This screenshot is not what it looks like ingame, there you actually see the pink color.

When doing this with func_illu/wall whatever, all is good. 
This Screenshot 
I�m So Stupid 
ignore me as usual.. 
QS 0.90 draws this "correct" 
Will fix.

I was going to remove alpha masked (fence) texture support on world brushes because it is technically wrong and leads to mapper newbie pain (a mapping newbie guy always says "I see void").

Then you guys made a map using it and then Quakespasm copied the Mark V implementation.

So now my "correction" becomes "bug".

Anyway, when I revisit I will "re-add" that back in. 
Its all cool Baker, i was trying to not overuse func_illusionaries for performance reasons, but yeah, its wrong to do it like this i know..
Thanks for your precious work anyway, it is very appreciated! 
I would just make them func_wall/func_illusionary on new maps, and consider the fences-as-world-geometry support in qs deprecated / not recommended for future use.

arguably I shouldn't have added that to qs 0.90, because you'll get HOMs/a view in to the void if the brush touches the rest of the world, plus vis might cull stuff behind the fence texture because it thinks they are opaque. 
Oops, Redundant Post 
Anyways, sorry for this Baker, I take responsibility for spreading the mis-feature :P

mfx, it should be safe to go crazy with a lot of func_illusionary, unless you're measuring a performance hit.

In glquake/fitzquake the brushmodel drawing does a bunch of setup per-poly of the model, so you want to avoid a single very complex func_wall (this is fixed in qs 0.90 though, and probably engines with more advanced renderers). But on the other hand, I'd expect drawing a lot of simple func_walls/illusionaries should be fairly fast on all engines. They're vis-culled too, so even having several hundred spread around the map should be fine. (famous last words.. ) 
the visculling is another thing that prevents this usage. My nooby brains was thinking "when i keep this brushes small and "freefloating" and use them like decals for wall deco and such, that would be cool for blending textures..." 
An option - if you want to have better performance but still let people go nuts on them - is to merge them into the world model.

As a general rule this is safe to do. Inline brush models only appear once each, are already in the worldmodel surfaces/textures/etc lumps, and if they have the same animation frame as the world, and origin and angles of {0|0|0}, you can add them to the world model texture chains quite safely.

For id1 maps there is no measurable performance gain, but for cases where using lots of them is a bottleneck, it works well. The only cost you'll pay is in overdraw, but you can set up the chains so that the inlines are drawn first and then you'll get early-Z rejection on the world polys.

The exception of course is when someone post-processes a compiled BSP to allow sharing of surfaces between inlines and inlines, or inlines and the world. But that would be evil and we'll assume nobody does that, right?

(As an aside: the way stock Fitz handles texture chains doesn't permit this optimization. I can't remember right now if it also sorts it's chains back-to-front (like stock GLQuake does) rather than front-to-back (which would also run faster).) 
Another Opinion(ated) Mapper 
If the user wants to make bad content with a feature, let them. No engine coder ever blocked the use of, say, fog 1.

Protecting the newbs seems like a strange reason to limit the feature as well. Why not disable map hacks while you're about it, just in case.

mh's solution sounds good, basically handling the process better. Just disabling stuff seems like prohibition.

Yes, my last map did have a couple of wafter thin parts of void clipping caused by this issue, but it was my fault :) 
thanks for the tips, will play with the merging brush models into the world sometime.

Fitz walks through the surfaces in the order of the cl.worldmodel->nodes array - there's no R_RecursiveWorldNode - then reverses the order per-texture from the chaining. Not sure if cl.worldmodel->nodes has any meaningful order to it.

ijed, that's a good point. 
the idea was that iterating a list is much better on CPU than walking a tree, and the order wasn't that important. This idea was taken from darkplaces at the time.

I have no idea if it's the correct tradeoff with current hardware. If GPU bound I guess front to back would be best. 
Fitz Walks Through The Surfaces... 
Fitz walks through the surfaces in the order of the cl.worldmodel->nodes array

The big problem is that it only regenerates texture chains when the PVS changes. Merging brush models really requires texture chains to be regenerated each frame.

It's actually quite trivial to write a GL renderer that runs twice as fast as Fitz on ID1 maps (much more on big maps), but much of that is down to batching rather than BSP tree traversal (this isn't including dynamic lighting which is it's own separate problem).

So adding some good batching and accepting the CPU overhead of building the chains each frame is a reasonable tradeoff that you're going to come out on the good side of on any hardware (unless you're totally fillrate or ROP bound, which the original 1996 hardware was, and therefore none of this was a problem back then), and then you get the ability to merge as a bonus. 
Happy New Bump 
Any progress on fixing the vs2008/OpenGL build of the latest snapshot? I'd hate going back to r15 after all the improvements which have been applied since then. 
any chance you can post the source for that last snapshot Baker? (no rush, just curious to have a look at it) 
@ericw -- of course! I'm deep in the middle of possibly finally handling some frustrating math calculations that have been owning me all week at the moment, will upload first opportunity tomorrow.

@nightfright -- Don't want to promise a timeframe at the moment. At same time, I do want to get a revision out. 
@eric w -- source 
Also: There needs to be an SDK folder above the source code with this. Contains DirectX, Curl, a very heavily modified "FDFramework" (the Mac build was derived from Fruitz of Dojo), some headers and some things moved out of the engine folder.

(More complex than I prefer ...) 
Crash On Quickload F9 
Getting Quake Error
R_Renderview: NULL worldmodel
When pressing F9 to quickload after previously saving with F6.
Fitzquake mark V 0.94 
try again without any mods 
Fitz With .mp3 Files Etc 
Any idea how to get this to work?
I just can't it working in FQ, but it seems to work fine in quakespasm. 
Quickload Crash 
Can't work out why this is happening. Workaround: put the following in autoexec.cfg:

bind "F6" "echo Quicksave...; wait; save s0 "
bind "F9" "menu_load "

So the top save slot is the quicksave one. 
can you try this:
in the console, type load quick.sav

the 'load' command can load any save by filename and quicksave just saves to a quick.sav file. There should be no difference between loading a normal save and loading a quicksave via quickload. A crash there would indicate something up with quickload code? Or the order in which things are done with quickload vs load?? 
Happens With V0.94 For Me Too 
but it seems to be fixed in v0.99, maybe try that version?

necros: "load quick" in the console causes the same crash. For some reason loading via the menu works. 
Maybe it disconnects first. 
Thanks, 0.99 vs2008 version works. The winquake version wouldn't start. (Win7 Pro x64 i7-4770 integrated graphics) 
If I have an autoexec.cfg then the sky is drawn over the world. Anyone else having this issue?

I thought it was a setting in the file but it seems that any entry will cause the problem. 
I tried to get around this by having a file called 1.cfg (the only setting being r_shadows 1), I typed exec 1.cfg and I get the same sky drawing error. 
Ignore Me 
I just went back and re-read the thread and realised there's a bug with shadows in the latest build...

What a weird coincidence that this was the only setting I decided to keep. Losing my marbles. 
The Nehahra Fog doesn't work in Mark V. I remember Directq used to have a problem with this. 
Nehahra Fog ... 
Nehahra is an interesting thing, especially the fog. Here is what I did ...

1) DPNehahra is the official engine for Nehahra.
2) Because dpnehahra is the official engine, I view how dpnehahra displays a map as correct and only way it should be displayed.

Load up the map in question in dpnehahra:

A) If dpnehahra shows fog on the map, I have a bug.
B) If dpnehahra does NOT show fog, I am complying to the official presentation.

JoeQuake and derivatives present the maps in a different way than DPNehahra.

But JoeQuake didn't exist when Nehahra was released and I view any differences in map presentation between JoeQuake and DPNehahra to be JoeQuake presenting the maps wrong.

Case in point, there is a DP Nehahra expansion map with a skybox and non-standard fog keys.

1) If I load up the map in DPNehahra, I see the sky but no fog.
2) If I load up the map in JoeQuake, I see fog but no sky.

I had to pick which way to do it, I picked the DPNehahra way. 
Who Needs A Fog Anyway? 
the fog is a lesser issue 
But DPnehehra has the fog in Neh2m5, but Mark V does not 
Since you are playing Nehahra, if you happen to know where any of the smoke emitters are, let me know. I spent a lot of time trying to get the sprite 32 support perfect and such, but the maps are so large and I couldn't find a smoke emitter. 
Fullbright Brushes (_glow Or _luma) And Translucency 
Does Mark V support external fullbright maps for brushes, like Darkplaces do? What do I have to do? I already have some xxx.tga and xxx_glow.tga in my ID1/textures directory. Mark V reads the texture, but the _glow thing doesn't seem to work. How do I fullbright a brush surface?

Also, is there support for alpha translucency? How do I do it? 
Fitzquake supports glow textures, so i would assume it also works in Mark V, but maybe there's something that changed. 
Here is a hideous screenshot demonstrating _glow textures against a test folder:

It uses the following 2 textures that happen to be .pcx format 
Alpha translucency is not a texture feature in any Quake engine except DarkPlaces because it is a recipe for cheating (FTE ... ezQuake ... any NQ engine etc do not support them.). Somewhere earlier in this thread there is a discussion involving Spike, Sock and myself and others on that topic.

In fact, if you having trouble with textures I would recommend removing the alpha channels.

I think the alpha channels are ignored in FitzQuake (not a common topic, so from memory I can't recall.)

If you want things like glass in a map, you have to set the entity alpha of the brush (for instance alpha 0.5.

Both Mark V and Quakespasm support alpha masked (a pure mask like a fence where each pixel is either fully transparent or fully opaque -- there is no translucency) and the texture in the map must begin with a { and Quake color #255 is the mask color.) 
The current Mark V beta, unlike Quakespasm, only supports alpha masked { fence-like textures on entities. Quakespasm supports them on the world model, but this shows void (areas outside the map) but Rubicon Rumble needed that because of a visibility issue that has since been resolved (i.e. masked textures really should not be on anything except entities). 
Looks like we're double-posting here and at QuakeOne. My bad :( Hope it's all useful.

Anyway, I just downloaded the two textures you posted to ID1/textures folder. Here is another hideous screenshot for you:

It's your texture pointer showing Mark V is loading sfloor4_2.pcx, but not sfloor4_2_glow.pcx.

Are you sure we're running the same version? Mine is 05:49:41 Jul 13 2014 
And here is the fence-like alpha blended working like a charm (on the background, sfloor4_2 fullbright not working): 
Alpha Transparent 
The screenshot above is a world brush, not an entity. So your engine alpha blends world geometry as well.

It's showing void where the brush touches the floor, wich makes perfect sense: the world brush subdivided the floor and the surface it hides was removed by the bsp compiler. Thing is, you can see thru this world brush, so you can see the hole the removed surface left.

I just tied the brush to a func_wall entity and recompiled the map. No void showing anymore. I'm gonna use it! 
I'm using the October 10 beta build which is known to have issues with drawing the sky on Nvidia cards due to a stencil operation and may have a couple of other things like that (which is why it was marked as a beta). The download is buried in the thread.

Words: It is unfortunate that work alpha gets used for everything but I do want to point out that no blending is occurring for "fence textures". Blending means it is combining 2 colors, fence textures are an alpha mask and isn't blending. 
sorry if I've it's been mentioned and I haven't noticed - is there any support (or planned support ;) )for Alpha masks on external textures?

Thanks for all your work on this so far, it's awesome. 
I don't remember if there is external texture support for the masked textures.

I would guess "no", but I can't remember because normally this is something I would do.

I think a roadblock was external textures for masked textures and the possibility of the masked texture having a fullbright component.

That is a complicated scenario to draw for external textures because fullbright is an additive blend but should only affect the masked area.

Which is quite a headache to devise the drawing for when almost no one even uses external textures, let alone masked textures. 
for alpha masked fence textures and fullbrights, you could process it at load time:

for the main texture, keep track of which pixels are < 0.666 alpha. On the glow map, set those pixels to pure black. This way the glowmap won't be visible on any screen pixels where the main texture is masked out.

I'm not sure if this will still cause tiny bleed overs where the glow slightly overhangs the hard edge of the mask, but it could be tweaked, maybe by raising the alpha threshold or something.

But at least this doesn't affect render code at all. 
External Alpha Mask 
In that screenshot I posted above, that transparent wall with yellow balls is a brush with an external TGA type 2 with an alpha channel, where white makes a pixel visible and anything else makes it invisible. So I would say yes, Mark V seem to support external alpha masked textures.

Tried the three EXE of the October beta. The WinQuake version wouldn't show external stuff anyway. The other two don't even have the r_texprefix_fence cvar :o

Please Baker, don't rip the transparency off the engine, I need it! Didn't follow the discussion, but a security solution can't be to cripple the engine. 
r_texprefix_fence cvar is gone because since Quakespasm adopted fence textures ported from Mark V with exclusively the prefix "{", it is no longer an option to pick a prefix. This is consistent with Half-Life and The Remake Quake engine and FTEQW. [Yeah, the WinQuake build doesn't seem to work]. 
@metslime. No doubt that work and I likely devised something like it.

I think the situation that was aggravating is the possibility of the regular texture and the glow texture replacement not being the same size and factoring in possible rescaling in the (rare) absence of power of 2 textures.

With normal _glow textures, this isn't a factor since there isn't a dependent relationship between the regular texture and the _glow one. 
baker: good point about the different resolutions. While it's still solvable, it's clearly more work to correctly sample one texture and lookup the correct alpha value for the other one. 
fullbrights have the same issues that lightmaps have in a single-tmu environment.
you need to use glDepthFunc(GL_EQUAL) for both your lightmap and your fullbrights, which prevents either additional pass from breaking anything.

with multitexture you just have to ensure your fullbrights don't harm the fragment alpha, so that your alphatest can still discard the fragment correctly.

if you're doing glsl-less bumpmapping and need to use the fragment alpha for some dotproduct values, you can just use glColorMask and specify the masked depth as an initial pass. this of course means that the fence and diffusemap don't have to have any correlation to each other whatsoever, if you're doing weird effects or whatever.

alpha-test has a specfic cut-off point somewhere between 1 and 0. this means that even internal fullbrights can bleed if you don't handle them properly (half-life didn't do fullbrights at all).

if it was blended then you'd have a point, along with other quirks.
there are still problems with coplanar surfaces, of course, but there's nothing you can really do about those. 
GL_EQUAL sounds like a good solution for multipass rendering.

And alpha shouldn't be an issue with fullbrights as fitzquake uses additive blending starting in 0.85. 
Tested The October 2014 Build 
Just to keep track, I posted my test with October 2014 build at Quakeone. No fullbrights showing. Here is the test: 

Assume the problem is solved for the moment.

I have been procrastinating on polishing up the Mark V beta mostly because there are 4 or 5 tedious issues that are unrewarding to work through.

But I think I've waiting long enough.

Within a week, there will be a polished Mark V non-beta I will ensure this inconsistency is gone. 
I'm of the opinion that the equivalent of glBlendEquation (GL_MAX) and glBlendFunc (GL_ONE, GL_ONE) is the most appropriate way of handling fullbrights.

The reason why is that there are areas in maps where (diffuse * light * 2) is actually brighter than the fullbright on it's own. This shouldn't be too hard to conceptualize; it's going to happen if the light is brighter than 0.5 (or 128 on a 0 to 255 scale).

The result is that you get a weird transition between normally lit texels and fullbright texels (and the brighter the light the weirder the transition).

This is easily visible on e.g the right-hand lit arrow leading into the e1 entrance in the Start map, and while using a GL_MAX blend doesn't replicate software Quake with precise fidelity, it is much more visually pleasing. (Other examples of the same concept include some lights in Quake which saturate even with 2x overbrighting, particularly if you add dynamics (although some even rarer areas don't even need that); not such a big problem for FQ as it doesn't create coloured dynamics, but very observable if you add them to it).

As a bonus you don't have to remove the fullbright texels from the source image using this method.

Unfortunately neither GL_COMBINE modes nor D3D SetTextureStageState support a maximum blend, so the only ways to do it are to multipass it or do it in a shader. 
I asked you so many questions and forgot to thank you for this awesome work. Hope I could help someway.

Here is another one: does Mark V load external sky textures? There is a sky_mb1.pcx (already tried TGA and PNG as well) in my textures folder, but the engine goes on loading the internal BSP texture. How can I make it load the external one? 
Just skybox support.

None of the FitzQuake/Quakespasm family of engines loads actual replacements for the 256x128 scrolling sky textures. DarkPlaces is the only engine I know offering the ability to replace the scrolling sky with a hi-res version.

[FitzQuake/Quakespasm don't + won't support PNG, just like Q3 doesn't support PNG.] 
Extra info: PNG serves no purpose for replacement textures because when the set is compressed into a .zip file, it gets compressed. The only thing PNG does is require the engine to increase map load times by decompressing the textures every single time. 
TGA already have alpha channel, so screw PNG :)
Your skybox works neat, just tested it. So, screw iD's moving PCX. 
Regarding My Issue (posts #514/533) 
I checked the vs2008 build in the 20141010 package again and noticed that liquids look fine again on my nvidia card if you use r_oldwater "1".

Dunno if that helps with solving the problem - still waiting and hoping for a fixed release. 
Interesting, thanks for info. Could be involved in this somehow. 
Mark V Beta 2 
Anyone with sky issue (NVidia only) will still have sky issue. Still working on that as I do not have a Nvidia card available. And does not yet have the DX improvements.

This is a much nicer release than the previous one, but more to go.

The WinQuake version should work and these are proper builds. The glow textures should work.

New feature: Select text using SHIFT in the console and copy, cut and paste with CTRL+X, CTRL+V, CTRL+C, SHIFT+INS, SHIFT+DEL

More versions will follow as I eliminate the known issues. Next one might not be until Monday or Tuesday. 
@NightFright Re:nvidia 
How does the sky look with r_oldwater 0 and r_oldwater 1?

Does the sky look correct with r_oldwater 1?
Does the sky look wrong with r_oldwater 0? 
also do you get any issues with "r_oldwater 0" with Fiitzquake 0.85 or Quakespasm? 
@ericw -- any oldwater problems in Mark V wouldn't be inherited from Fitz, but something I introduced.

r_oldwater 0 as you no doubt know requires a bit of hand-holding (in the code) because it is ingenious evil render-to-texture trick. Likely, video mode change isn't updating it or I'm clearing (or not clearing) a buffer at the wrong time or not updating the texture at the right time.

Probably a simple oversight on my part.

Source for Beta 2 which is easy to build (compiles out of the box with a key press) for Visual Studio 2008 or CodeBlocks (or Visual Studio 6 with service packs). The WinQuake build does use assembly language for speed and the project files compile those easy.

(The structure of the source is a bit more complex than I prefer, partially due to Nehahra support and Direct3D support.) 
@ericw -- any oldwater problems in Mark V wouldn't be inherited from Fitz, but something I introduced.

r_oldwater 0 as you no doubt know requires a bit of hand-holding (in the code) because it is ingenious evil render-to-texture trick. Likely, video mode change isn't updating it or I'm clearing (or not clearing) a buffer at the wrong time or not updating the texture at the right time.

Probably a simple oversight on my part.

Source for Beta 2 which is easy to build (compiles out of the box with a key press) for Visual Studio 2008 or CodeBlocks (or Visual Studio 6 with service packs). The WinQuake build does use assembly language for speed and the project files compile those easy.

(The structure of the source is a bit more complex than I prefer, partially due to Nehahra support and Direct3D support.) 
Nvidia GF GTX 770 And New Build 
With the new build (using mark_v.exe), behavior is exactly the same as with the previous version.

Using r_oldwater "1" only fixes liquids and teleporters, but NOT skies. Setting the variable to 0 breaks liquids, too (white surfaces).

Nothing has changed about my hardware setup since post #514, just using newer nvidia driver (v347.52). I have another system with an older nvidia card running on Windows 7 x64 (4GB RAM) which doesn't have show any issues at all, btw. 
Config.cfg File 
If it helps, here is my current config.cfg. Maybe there is another variable in it which I might try changing.

Config.cfg (3KB) 
I'd bet the farm on this being the graphics driver.

And since you provided the version #, maybe I have a shot in addressing it.

(I've seen DarkPlaces users mention certain driver #s being bad several times. I didn't expect this kind of thing to enter my world of "classic Quake appearance engines" but if this driver # can cause the problem, maybe I can target it. Nvidia used to have the reputation of providing stability and ATI was the shoddy/incompatible vendor. I don't claim to know much about graphics card drivers but things I have read makes it sound like they traded places.) 
In the gl version, type gl_clear 1

Does this fix the sky issue?

[The r_oldwater 0 issue is separate deal, I have plan to fix.] 
Setting this through console unfortunately doesn't have any visible effect, sky on start map still looks like in post #533.

My driver settings in nvidia control panel:

Anisotropic Filtering: Application-controlled
Antialiasing - FXAA: Off
Antialiasing - Setting: Application-controlled
Antialiasiang - Gamma correction: On
Antialiasing Mode: Application-controlled
Antialiasing Transparency: Off
Refresh Rate: Application-controlled
DSR Factors: Off
DSR Smoothing: Off
Triple Buffering: Off
Energy Saving Mode: Adaptive
Max amount of prerendered frames: Use settings of 3D application
Shader cache: On
Texture Filtering: Anisotropic Pattern Optimization: Off
Texture Filtering - Negative LOD Bias: Allow
Texture Filtering Quality: High Quality
Texture Filtering - Trilinear Optimization: On
Threaded Optimization: Auto
Vertical Sync: Use settings of 3D application
Prerendered VR frames: 1

My monitor refresh rate is at 120 Hz, if that matters at all. 
Mark V Beta 3

r_oldwater 0 issue gone. Was trying to resize warp image buffer before valid screen width/height determined. 
One Problem Less! 
Fix confirmed, works. ^^ Now all that's left to do is looking up to the sky!

Btw, before you release the final version, is there any chance to add a menu toggle between gl_nearest_mipmap_linear ("classic") and gl_linear_mipmap_linear ("smooth") texture filtering? Currently, you still need to put this into autoexec.cfg if you prefer the "pixel look". 
My pc is saying it's a virus. :D 
I just turned off the virus protection to download it. When I turned the virus protection on again the files were deleted.

Windows 8 doesn't like your program there Baker! 
If It's A Virus, Then A Good One :P 
I think that's rather an issue with your AV. :P I am using Panda Free AV on Win 8.1 here without issues.

The DX8 version (but not the GL version and not the WinQuake version)) somehow triggers Microsoft (and only Microsoft's) malware detection as some old Trojan from 2006.

61 other virus scanners say the dx8 version is not malware.

Go figure ... 
No silly virus warnings.

Looks like the skybox problem (drawing the sky in front of geometry) and the external mp3's not playing bugs are both still not fixed.

Also, had to start from a clean install as something in my config is crashing the program back to desktop... 
Water is working now with "r_oldwater 0". I still can't reproduce any problem with the sky. Also tried the config.cfg NightFright posted.

Here is my gl_info:
GL_VERSION: 4.5.0 NVIDIA 347.52

We have the same driver version, so it could be a 6xx series card vs 7xx issue. 
external mp3s not playing ... please provide more information.

Note: Mark V doesn't support mp3s playing from inside a pak. 
@ericw I see the driver # is same as NightFright's --- so isn't the driver. Hmmm. GeForce 7 series. 
Reupdated contents of Beta 3 zip with a interpolation bug fixed for the WinQuake build. 
My guess is also that it must be something with the graphics card model. As I wrote above, these builds work fine on an older system with an nvidia card running on the same driver. I doubt it has anything to do with the OS. Also as a reminder: Mark V before 20141010 is still running fine with the Geforce 700 series. So whatever got changed in the meantime is something those cards apparently don't like. 
Baker, No More Information To Give On Mp3's 
sorry, but mp3's don't play. They're not inside of a pak. I'm sure they used to work once upon a time. To be honest it has been broke in a lot of builds for me, I know I'm not the only person because I talked to Sock about it (it's one of the reasons he uses quakespasm over fitz)

I still use fitz regardless of this but it'd be nice to hear music again. 
map start;
r_shadows 1; wait; r_shadows 0

sky is now b0rked, despite switching r_shadows back to 0. 
It Requires A Reset To Fix 
You can't just switch it off...

You could try vid_reset though? 
in GL_DrawAliasShadow, change the arguments of the following functions to match the values given here:

sky bug now fixed.

actually, that clearstencil call becomes redundant as 0 is the default anyway and nothing else changes it.
also, consider only clearing the stencil buffer once per frame for entity shadows, so that you don't get tripple-whammys with gibs etc.
using ~0 instead of 2 means that the shadows don't glitch until you have (typically) 256 overlaps, rather than merely 3. which is important if you're doing what I just recommended. 
Excellent, thanks Spike. 
I should have another revision sometime this evening. @fifth -- I'll see if I can reproduce that on a Windows 8 machine. 
Just for the record: I don't have issues with MP3 playback on Win 8.1. My issues are purely about graphics. Curious to see if next build will be fully usable for me. 
Could Be A Driver Issue On My Side... 
I have never updated them myself... for the record quakespasm uses .ogg files which work fine. 
@fifth Re: Music 
I'm not sure why music isn't working for you, but I'll give the old college try to fix, and I have feeling it's gonna get solved.

Re: ogg and stuff

My understanding is that Quakespasm uses software rendering for MP3 music playback rendering.

It should be very reliable, but software rendering is slow and is quite a CPU hit. Mark V uses API that provide hardware acceleration.

An my opinion on music works like this: there is MP3 and nothing else and here's why:

1) The MP3 patents are expiring
2) Hardware API on every platform from Windwos to Mac to mobile platforms is optimized for MP3.
3) ogg is "free software" and I support free software, but the last decoding patent for MP3 expires in September 2015.

I think ogg was a great idea, but I don't think ogg has a rational use this in world in the year 2015.

Spirit and I used to have debates over video codecs and I favored free codecs while he supported the ones that worked well (H.264). Spirit won!

I see no place in this world for ogg.

/One opinion and I'm often wrong about these kinds of things. 
Oh, either I did not post a lot about how much I tried to prefer free video codecs or you forgot. I just gave up at some point. Maybe we talked after that. I can even spell Ptalarbvorm...

Ogg beats MP3 quality-wise. Opus would be even better. There should be nice libraries for all the Xiph stuff, including FLAC. 
Mp3 Vs Ogg 
I'm glad to see you're gonna tinker and hopefully fix mp3 support. As for the debate I don't know too much about the differences in the file format, although I did assume that .ogg was better quality even though the file sizes were often bigger (I doubt that matters too much these days). 
Every Time I'm Trying To Run That Newest Build 
it crashes

so i've just deleted my cfg files and started from scratch
i've noticed that my name is 'player' now
ok. i've changed that back to spy and the game has crashed
what gives?
and now changing the 'name' gives me a crush
typing the 'color' command and trying to switch it gives me a crush too

the latest stable version that i run without a troubles was the build from 07.13.14 
2015 April 13 Beta 
Windows OpenGL | WinQuake
Mac OS X OpenGL | WinQuake

Mac version runs on my Mac which has Mavericks. I imagine it will run on 10.8 and Yosemite, maybe 10.7 as well.

1) Should have sky glitch fixed which appears on certain graphics cards. Million thanks to Spike! But need confirmation it is fixed as I don't have right video card to experience issue.

2) Should render alpha masked textures with lightmaps correctly whether world model or brush models (aka Rubicon Rumble). Thanks ericw/Quakespasm for little tweaks in their source!

3) Spy's issue should be fixed ;-) I was hoping to get this update out before that little gremlin got noticed.

4) The levels menu having a couple of blank spots at end sometimes = fixed.

Getting far closer to a properly polished build, but more work to do ... thanks for feedbacks! 
Not Sure If This Related 
i'm running the mod(frogbot) that uses the crazy numbers from 'samelevel' cvar. Something like samelevel 627085, you know.

The new build(s) somehow borked that 'samelevel' cvar.
as it shows like
"samelevel" is "9.0112e+006" in the console 
That's how C represents the value of a large floating point number.

The value should be ok.

But I sure don't want it to display like that, isn't very human friendly. 
@spy: Fixed the display of large floating-point cvars. Above Windows download updated. 
Manual Saves 
I will test this tonight with my GF 770. On an nvidia GF 9500 GT, it's OK already, but as I said earlier, there haven't been any issues with that one before.

Noticed one thing with savegames, not sure if it's an error from my side or not. When I save a game (not quicksave, regular save through menu option), the savegame won't appear in the list when trying to load it. Quickload with F9 works, though. 
Everything Fixed (for Me) 
Game looks fine now on my Geforce GTX 770, also savegames work as intended with the latest build.

Good job and thanks a lot, Baker and Spike! ^^ 
Still Crashes To Me
theres my autoexec.cfg and config.cfg 
Most Issues Fixed For Me 
barring music of course.

Looking to see what audio driver is the most up-to-date for my surface pro is turning into a nightmare. 
Raw thoughts: the special characters in your name show as Russian or Greek or something in pastebin to me.

In the age of Unicode and UTF-8, if you manually did that in a text editor (as opposed to Quake writing the file) the text editor maybe have done strange things to your name and converted it to UTF-8 --- characters above 127 converted to escape sequences and such.

In that case, pasting the file to pastebin doesn't actually convey what the binary contents of your config really are.

You'd probably need to upload your config.cfg and autoexec.cfg to Quaketastic to get it to me as it really is in binary form on your hard drive.

Meanwhile, I'll play with the rest of the contents and try to imagine what could be causing the problem. 
Yay! I get the crash using your autoexec.cfg! 
tried updating my sound drivers to get the music to work... quake stopped working for a bit so I rolled back. Good times. 
No MP3 Music 
for me at least, mp3 not playing seems to be caused by not having a CD drive. If I move the "if (!enabled) return;" from the top of CDAudio_Update to after the if (using_directshow) bit, the mp3s play. 
If I remove the "map start" in the middle of the autoexec.cfg, I no longer have the problem.

However, obviously there is no reason why you shouldn't be able to change the map in the middle of the autoexec.cfg so I'll see what is up with that. 
ericw --- that makes sense! Great catch, thanks! 
fifth -- hopefully ericw's observation will allow me to get the mp3 going for you. 
I Wonder... 
I have a surface pro but it doesn't have a cd drive. 
@Baker - Almost There 
markv_dx8.exe "_glow" external mask works!

markv.exe ... doesn't

What's up with the GL version? 
+mlook Crashes 
Strangely enough, +mlook on console crashes both GL and DX versions. 
I'm Gonna Stop Now, Promise 

mark_v.exe --> renders "{" external texture transparency;

mark_v_dx8.exe --> renders external texture fullbright mask;

Each executable has one feature, none has both. 
+mlook shouldn't crash in the most recent upload.

If it still does, let me know.

@Baker - Almost There

Tell me about it! 2 operating systems, 3 renderers, 4 programming environments, 25 new features --- and I'm about 8 small issues away from surviving the tale.

(+1 exceptional deed from Spike, and ericw saving me from over-thinking Fifth's mp3 issue)

Well, I'll get those glow textures working in the GL build.

Tomorrow may have most of the remaining issues cleaned up. 
thanks for your response.

Strangely enough, +mlook on console crashes both GL and DX versions.
It seems you have find the bug!

i've removed +mlook string from my autoexec.cfg file and now i can launch Quake properly w/o a crush 
Opinion About Upcoming Release 
The only two features I am still missing now are:
- Music playback from within PAKs
- Menu toggle for texture filtering (see #617)

Both are totally optional, though (especially the first one - mostly cosmetic to get rid of all the MP3s in subdirs).

What impresses me most about this new version is the capability to run Nehahra - finally, we have a one-in-all solution that can launch pretty much everything. Once this is finalized, it'll hopefully last for a while before updates are needed again.

One way or the other, Mk V remains my favorite Quake port, and Baker's recent efforts just made sure it'll stay like that. 
thanks a lot for your efforts, will try the new version soon. 
Nop... +mlook still crashes, no fullbrights...

Did you run the sfloor4_2 test and saw these fullbrights? Is it working on your system? 
Praise Satan. 
Mark V Beta 6 
Windows OpenGL | WinQuake | DX8

1) Should have _glow textures working right in both GL and DX8 builds. Alpha masked textures are "functional" in the DX8 build, but not as nice as the GL build (due to the DX8 wrapper not supporting texture combine).
2) MP3 should work on machines without a CD drive.
3) +command issue (like +mlook) should be resolved once and for all.

New feature: Auto-complete from nothing by pressing CTRL+space. Sometimes you don't even know the first letter of map or something you want to auto-complete.

1) Type "bind " and then press CTRL + space.
2) Type "map " and then press CTRL + space.
3) Type "gl_texturemode " then press CTRL + space. (*)

Mostly thought of this for NightFright ... who asked for gl_texturemode to be added to a menu somewhere, and I while I don't think obscure stuff belongs in a menu, it sure is nicer if you can more easily complete it in the console even without knowing any of the possible values.

The CTRL + SPACE thing is, of course, in addition to the support for CTRL+X/CTRL+V/CTRL+C/SHIFT+INS/SHIFT+DEL and using shift to select in the console.

If you find a bug, please let me know!

I can't think of any offhand aside from a WinQuake build skybox bug reported @ inside3d by mk and I can't reproduce it to fix it. 
Finetuning Suggestions 
That thing with gl_texturemode is a compromise I can probably live with, thanks a lot for this. ^^

Other remaining things I noticed - dunno if you changed that in the more recent beta builds again or not:

- r_shadows now needs to be in autoexec.cfg in order to be used permanently. Was nicer when it was stored in the config file (as a permanent toggle). If people play with shadows, my bet is they wanna keep them.

- Would be nice if cl_autodemo was set to 0 by default. I am sure not everybody wants to record demos out of the box.

- Is there a way to toggle autosaves? While it's a really nice feature, it'd be nice to let users decide whether they want it or not.

None of these are bugs, rather feature requests for your consideration. 
I tried to make autosaves and autodemos subtle, however they aren't subtle enough and "get in the way" more than I find acceptable.

The need for autosave is a bit dubious, but spawned from the frustration of playing one of the map jam maps from last year about 2/3 way through and dying without saving.

Both features only ever maintain a history of 3 and use about no resources.

That being said, I need to put them in the "background" more. No one wants a pointless autosave of the start map in the save menu, for example.

Demos: Autodemos are more important than autosave. Demos are the one thing everyone wishes they recorded, but never do. But like autosaves, no one wants to see 3 random autodemos heading the demos menu.

I'm about as conservative about features as they come, so you know if I'm complaining about a feature I coded, I intend to remedy.

Only one kind of polished engine exists: the one that does things you want but keeps it out of your face and let's you focus on playing the game. ;-)


Shadows are a tricky topic and so is what should save to config.

I haven't thought too much recently about what saves to config, but I'm leaning towards everything except server vars (temp1, samelevel, deathmatch, coop, noexit + friends).

I also have a plan to make it so Mark V will tranparently interact with a non-Mark V config.cfg as to not wipe, for instance, DarkPlaces settings. Of course, likewise this plan doesn't have any need of other engines behaving similarly.

You can already see part of this plan in action. The WinQuake version of Mark V has all the standard WinQuake stuff and the OpenGL Mark V has all the GL stuff. Yet, you can run each engine back-to-back and change stuff and never be the worse for wear and no settings ever get lost. 
Got One 
Just noticed: In your latest build, the save bug is back. You cannot see saved games in the load game list. 
Quickload Without Quicksave 
Something else:
If you press F9 for quickload when there is no quicksave present in the game/mod folder, game freezes (should rather give some error like "no quicksave available"). 
Music Still Doesn't Work For Me 

The implementation in both Dark Places and QuakeSpasm work though. 
map autocomplete should always be able to autocomplete from the id1 directory IMO regardless of which game directory you're in. 
_glow GL Version 
No, the 2015-04-14 mark_v.exe doesn't render the _glow fullbrights. Only dx8_mark_v.exe does. Not here at work, not at home, not in my notebook. This time I tried other gl_texturemode settings to see if anything changes. Nothing. It's a mistery. 
"Not here at work, not at home, not in my notebook"

Bug reports by Dr Seuss?? 
Yes, I know I should be working instead of using my workstation to test Mark V. Just trying to make sure it's not my system. Or maybe it is, some configuration Baker is using and I'm not. 
Feature Request 
Support for the RRP maps would be cool. I wrote some notes on the required limits here:

Looks like the remaining ones to raise in MarkV are just:

I did a quick test, and the maps all load with those three raised.

Bug: entering "v_cshift" in the console with less than four arguments crashes the engine.

Also if you do RRP support, make sure to get the AllocBlock change in my linked post above, it's a 3-line change and telefragged.bsp goes from loading in about 10s to 1s. 
@nightfright --- excellent catch there about the behavior of trying to load missing save game file. It never told the map loading sequence to go away! Fixed!

1) When the mp3 music doesn't play, what does it say in the console? Usually it says something like "Track: music/track02.mp3 not found" or "Current music track: music/track04.mp3". And does it say "external music ON" when you go to the Options menu?

I want to verify those aren't problems.

What I will do is add some very precise messages for the mp3 startup sequence to indicate exactly why it will not start into the next build so I can get this working for you.

2) Could you do the following:
a) load your map that should have the _glow texture working
b) type "textures" in the console
c) type "copy"

And paste the whole log in the thread at QuakeOne you made:

@fifth re: map autocomplete ... I agree about the map auto-completing from id1 even if gamedir.

@nightfrightre: saves not in load game menu. What are the names of saves not showing the load game menu? Type "folder" and there should be saves like s0.sav and s1.sav sitting around? 
Baker... Mp3 Stuff 
It *does* recognise that a file is there (even in the older versions) as it does say "Current music track: music/track04.mp3"...

I thought it was a driver issue and now the sound on my pc is broke (only will play sounds if headphones are plugged in!) 
Also External Music Is On 
I tried both off and on to see if that fixes it, no dice. 
Can you zip up your textures and the map and upload the thing? There could be something non-obvious going on here like an alpha channel or the lack of one, or even the draw order. I still need to log so I can see what your machine has. 
ericw's vcshift observation fixed --- --- I rewired the command buffer to be more precise and to support multiple command buffers. Clearly, I need to completely mimick id1 with that and set missing arg pointers to an empty string or something.

@ericw -- thanks for the reminder and pointing out the limits. I had eyed the alloc block enhancement in Quakespasm a few times, but hadn't thought about it lately. 
Manual Saves 
Trying with your very latest build on my PC at home, there seem to be no issues with manual saves after all. I will verify this with the machine I use at work (where I had this glitch) tomorrow.

I intend to intensify testing this build with a complete Nehahra playthrough next to see if there are any major issues. I've been waiting for a long time for being able to play this addon with an up-to-date port. 
@fifth -- what is your volume and bgmvolume cvars set to?

In Mark V, if you turn down the volume, it also turns down the background music volume.

So if you have volume 0, the background music won't be making any noise.

I'm trying to emulate a no cd-drive scenario and the MP3 music is still playing. 
There is a link to my test here:

Just unzip it somewhere and replace the execs with your latest ones.

I posted my console right below, at QuakeOne.

@Baker - Haaa! 
dx8_mark_v.exe is loading the glow:

128 x 128 maps/dm3.bsp:tech05_1
16 x 128 maps/dm3.bsp:tech04_3
128 x 128 textures/sfloor4_2_glow (R)
128 x 128 textures/sfloor4_2 (R)
64 x 64 maps/dm3.bsp:sfloor1_2

mark_v.exe is not:

128 x 128 maps/dm3.bsp:tech05_1
16 x 128 maps/dm3.bsp:tech04_3
128 x 128 textures/sfloor4_2 (R)
64 x 64 maps/dm3.bsp:sfloor1_2

Check the filename ...

The current download,, has the names are mark_v_c.exe and dx8_mark_v_c.exe

I want to be sure we are working with the right version. 
Something weird, though.

As I look through your texture list you posted at QuakeOne, I see this:

64 x 64 maps/dm3.bsp:sfloor4_4_glow
64 x 64 maps/dm3.bsp:sfloor4_4
64 x 64 maps/dm3.bsp:comp1_7
64 x 64 maps/dm3.bsp:comp1_3
64 x 64 maps/dm3.bsp:comp1_6_glow

Now the sfloor4_2_glow isn't there.

But I notice the other _glow textures are there.

I'm trying to think what circumstance could cause that particular texture to not load, but all the other _glow textures would load.

This is very inconsistent. 
However, only textures with an (R) next to them have been replaced with an external texture. 
Check to ensure that the exe name is, in fact, mark_v_c.exe and dx8_mark_v_c.exe. 
Here is pretty much the same zip you gave me but which only the current Mark V gl executable in it but includes the other needed files.

Download that, unzip and double click the mark_v_c.exe and type "map dm3" in the console. 
It works!

Sorry, I was running the Beta 6 from #667, not this latest. Both GL and DX versions are showing transparency and fullbrights.

Actually, DX version darkens the transparent parts of a "{" texture a little. But GL version is perfect and it's enough for me.

About what you say at #688, the glows are inside dm3.bsp, not external at the /textures folder:

64 x 64 maps/dm3.bsp:sfloor4_4_glow

Don't know how they got there, though, since iD doesn't _glow their textures. Maybe it's a texture generated in memory by your code to fullbright iD's stock textures.

Anyway, thanks for the attention and congrats for this engine. You have some great software here. 
I'm happy to see it is working for you now, that's the important part!

Now, if I can get MP3 working on Fifth's computer, all the known true "bugs" are resolved.

And then I can focus on tidy-ups like observations above about autosaves, map completion and such and rounding out the feature set for Rubicon Rumble support. 
Here's a bug report with the latest bundle of stuff. I didn't notice any issues with mark_v_c.exe, but mark_v_winquake_c.exe crashes and raises the "Mark V has stopped working" dialog if I set it to fullscreen 1080p (my monitor native resolution). Fullscreen 720p works though.

Let me know if you want any info or other tests from me. 
Interesting. Looks like one of the hard limits of vertical resolution built into the software renderer is being hit.

The crash is easy enough to reproduce. 
So Far So Good 
Savegames definitely fixed. Looks like it was an issue with the April 13 build only, then.

Regarding raising limits to play most recent custom map releases: I am definitely supporting the idea that it should be possible to play any map currently available (hopefully also future ones) without requiring additional launch parameters. That's something that should definitely be in the final release.

Since everything works fine for me now, I'll stress-test the latest build with a few old and very recent mods to see if there is any odd behavior. I am almost finished with a full playthrough of all the vanilla Quake episodes and found no reason to complain so far. 
Transparent Water 
When viewing teleporter surfaces through transparent water, the teleporters appear unfiltered, i.e. without the water layer effect.

To illustrate the effect, check this screenshot.

Using latest Mk V snapshot with following water settings:
gl_subdivide_size 16
r_oldwater 0
r_lavaalpha 0.8
r_slimealpha 0.7
r_wateralpha 0.6
r_waterquality 32
r_waterripple 3
r_waterwarp 1

Using .vis files to achieve water transparency (inside a PAK file). 
That looks more like bad depth sorting for alpha surfaces than anything else. 
new build and its predecessors -condebug is not working (qconsole.log) it remains empty

when i'm typing developer 1 the game crashes

can't run the travail pak. But it run just fine on my working PC

it seems the show_clock command doesnt work either (at least wnen DM mode is enable) it shows everytime despite enable/disable state
personally i don't like the position of the clock too. The only two(off four) of the scoreboard leaders are visible. 
Beta 7 - Windows Open GL | DX 8 | WinQuake

1) Changed scr_clock to allow never drawing the clock even in deathmatch as an option. scr_clock 0 (never), scr_clock -1 (dm only, default), scr_clock 1 (always). If the clock is off in DM, will draw all 4 player slots. If the clock is on in DM will draw 2 player slots.

2) -condebug and -condebug + developer 1 are fixed. Thanks to spy for pointing this out.

3) Rewired the command buffer system to handle unexpected or uncoded arguments in the classic way that Quake handled them. My original plan was to audit every command in Quake, but I don't see an effective way to do that.

4) Increased 3 remaining limits for Rubicon Rumble that ericw says will make it playable. Have not implemented lightmap loading speed up. MAX_ENT_LEAFS was already 32 and already handles brushes in tons of visleafs about the same as Quakespasm (per MH from several months ago)

5) sv_autosave defaults off and doesn't save to config. Obviously needs 1 engine restart to clear. 
@nightfright Re: Water + Tele 
FitzQuake 0.85 draws all "liquid" surfaces in a single pass.

But I guess now that some "liquids" like water might be transparent and some "liquids" like teleporters or lava might not be ... the rendering needs a slight tweak.

Adjusted liquids to draw in 2 passes:
1) 1st pass: solid pass like teleporters
2) 2nd pass: alpha pass like r_wateralpha 0.5

Should render like how you would expect it.

Update: Teleporter + water rendering improved - Windows version
Source (may be 5-10 mins before I have it uploaded) 
can confirm all of the RRP maps load with the latest build 
@ericw -- do you happen to know the names of any of those "bad lightmap" 64-bit maps from last year? I want to experience one of those first hand.

(I can't do this with my Win32 build. But I'm hoping it crops up on the Mac build which is 64-bit.) 
jam2_mfx is a good one, just turn right from the start position and check for diagonal stripes to the right of the arch, there should be none. I posted some screenshots of that one and the fix as well on i3d:

Another is mfxsp17, just go straight ahead from the start position and check the wall panel behind the crate. It shouldn't have a black triangle in the upper left corner, here is a screenshot with the bug: 
Both of the above mfx maps are fixed with the change in CalcSurfaceExtents.

This is another bug on jam3_ericw:

I didn't do the best job explaining it, but in the "reference rendering" (winquake.exe from id, fitzquake085.exe) the zombie is solid black.

unmodified 64-bit builds will change that particular zombie to be lit up. With the change I gave in RecursiveLightPoint, rendering will be corrected back to black again. 
Some Pending Checks From My Side 
Rendering issue with transparent liquids fixed (using build from post #701).

Some minor stuff I noticed:
- On PNG screenshots (NOT ingame), the statusbar gets screwed (kinda white) if you change its transparency (scr_sbaralpha).
- Centered messages (such as the ones you get when you are about to enter one of the vanilla Quake episode selection chambers) sometimes have weird copper arrows/triangles at the end of each line. Will provide screenshot later, currently dunno how to reliably reproduce.

Played through the first Nehahra episode without any problems until now. Will keep you updated about my progress. (BTW, forgot how hard that addon is, even with nomonsters 1.)

Back in February/March 2014, I also had a Mk V playthrough with several mods and encountered some problems there. Will check if they still exist with a recent build:

Freezes in "Castle Rapture", but managed to continue by ignoring the knights at the beginning

Soul of Evil
In the "Morbid Manse" (soe2m5), Mk V crashed many times after obtaining the gold key and approaching the fitting door. Continuation possible by skipping the problematic area with noclip.

The Altar of Storms
Game crashed whenever a succubus tried to resurrect a corpse. Only workaround: Kill any succubus before engaging any other enemy 
Beta 8 
Windows OpenGL | DX8 | WinQuake

Changes: GL version wasn't polyblending powerup shift rights. Shadows tweak targeting Warpspasm. Aesthetic auto-complete and startdemos changes. Demo rewind visual oddity with weapon fixed. 

Your post made me think and he's what I did: I reenabled autosaves but they do not show in the save game menu ever.

If you get a crash in any map for any mod, grab all the auto-saves and the most recent autodemo and zip them ;-)

The nice thing about autosaves is they are available when you least expect to need them!

Mark V cycles auto-saves in a rather logical fashion so they should be spaced out a couple of minutes apart. 
re: PNG shots and alpha channel

I reupdated the upload for beta 8 and it strips out the alpha channel. Let me know if that fixes the png shots. 
Centered Messages 
Here is the thing with the "copper arrows" I have been talking about earlier.

No clue where these are coming from, but I know they don't belong there... :P 
Zip up a demo of it -- or the autodemo. I tried to recreate it. I'm very curious. I should be able to reproduce it by watching the demo. 
Why is your HUD so misshapen? 
Demos And Savegames For "arrow Issue" 
Fair enough, here are some demo files and savegames:

Mk V centered msg issue (120 KB)

I just recorded the part after my last quicksave, right before the message appears. Mind that I updated the Mk V a few times while playing this episode and kept saving over it. However, I also had this issue already right after starting a new game.

Regarding my HUD:
I see nothing wrong with it. I made it transparent and rescaled it a bit. ^^ 
Ha! Loading the save game makes it happen. And it displays in the demo.

This is the best weird bug report ever because I can reproduce it.

And what a nicely formatted bug. It conscientiously displays the arrows in a very considerate way that is pleasing and flows well with the text.

I'll have time to examine probably this evening sometime (small chance I won't be able to do this this evening). But this will be fun to unravel.

My best guess: something about the saving and loading of the save game files. But we will find out! 
Like I said, it can be you reach this spot in E4M7 and you don't encounter any issue like this at all. Then again, it's possible that the episode selection messages on the start map already look like this. Well, at least you seem to have fun with it. xD

Other than this, my full Quake playthrough turned out completely fine with the latest build(s). Now on to some of the mods I listed above. 
It appears a fix I may have acquired from another engine (not any of the ones discussed these days) in the load game procedure may be the origin.

Save games is fine. Load games with newlines within quotes adds a "bronze arrow". 
The strength of that modification was that it would be resistant to special characters in the save game files doing screwy things.

One possibility is there is another piece to this modification I missed and failed to implement it. (Another possibility is that the other engine had this weakness, but I have difficulty believing that.) 
Ne_ruins Crash 
Altar of Storms (ne_ruins):
Game STILL crashes when a succubus resurrects any mob. Additionally, game only runs if you use -heapsize command (I used -heapsize 512000, and even then it still gives you some console errors).

Demo and savegame for ne_ruins crash (46.5 MB)

"Castle Rapture" map checks out fine on test playthrough.

Soul of Evil:
soe2m5 doesn't cash when approaching Gold Key door with the key.

Hope I'm not giving you too many headaches, but I really love Mk V and hope to contribute to a flawless release. 
that bronze arrow wouldn't happen to be a \r would it?

"message" "first line\r
hurrah for dos-format text files.
(quake's \r support is non-standard anyway)

its stuff like this that annoys me:
"wad" "foo.wad;c:\noonar\"
kaboom. :s
typically coupled with:
"message" "my wonderful map\nsorry about the bugs"
nrnnrnagh! now my hud is going to bug out.
"message" "and now mr bond
you die"
AWERUIWEHWEHF!!! you just totally screwed up my parsing! DIE YOU RETARDED BUGGY MAP/SAVED GAME!

there's no way to cope with this properly, you can only use hacks and assumptions. 
It's An \n 
Sound Playback 
Another issue: sound.

Got this while playing the first mission of "Scourge of Armagon".

Needless to say, I am not using any sound mods. 
Hope I'm not giving you too many headaches

Not at all! I want Mark V to work great.

I added sounded warnings from another engine and apparently the sound warnings. Apparently those should be for developer 1 only.

re: newlines

I'll just use the same assumptions that Fitz 0.85 uses and if someone has special characters in the save, that's just too bad.

ne_ruins is known to have unusual resource requirements. 
Beta 9 
Beta 9 - Windows Open GL | DX 8 | WinQuake

1) Extra .wav warning messages only print if developer 1.
2) New lines are saved in same games the same way as FitzQuake 0.85 instead of writing binary. Stops the "bronze arrows". 
Sound Issue 
I think I should have elaborated on the sound problem a bit more. The thing is that those sounds are actually not played back. And that is bad because it affects stuff like weapons, e.g. the laser gun. The gun remains silent when fired. Among other sound sources. That sucks, so I guess more needs to be done than hiding the messages... :P 
I play Hipnotic and those sounds play for me and they do so without error or anything.

Where did you get your hipnotic from? CD? Steam?

I'm trying to think of how you could be having this problem and I'm not?

Cross checking against FitzQuake 0.85, it looks like those warnings print in Fitz 0.85 and the sounds shouldn't play.

What does FitzQuake 0.85 do?

I want to get this solved! 
Hipnotic Source 
I never owned Quake or any of its mission packs on Steam. My PAK comes straight from an original disk dating back to 1997. However, I dunno if the Steam version used a different .wav format. I don't remember having that issue with Mk V r15.

Regarding ne_ruins:
I am OK with adding parameters, but the reproducable crash with succubi resurrections sucks. 
Nice to see this engine still being actively worked on, I think you've added a ton of useful features. I did come across some possible bugs though. OS is Win 7 64 bit, GPU is AMD 6870, driver version 4.12.

1. Demo rewind/fast-forward controls don't appear to work with any of the recent builds from the last few days. Thought it might be something with my PC or config, so I tested an old build I had from July 31 2012, and the controls worked fine. This was tested when using the playdemo command as suggested in post 84 of this thread.

2. 'Give' commands used multiple times as part of an alias or chained together with semi-colon separators don't seem to work. For example, the following alias -

alias giveall "impulse 9; wait; wait; wait; wait; give h 999; give a 999; give c 999; give s 999; give n 999; give r 999"

- will only perform the impulse 9 function and nothing beyond it. This alias works in most other engines I tested. I tried using "give 3; give 4; give 5" etc instead, but that didn't work either, even when entered in the console rather than executed via an alias. Other commands and cvars chained with semi-colons did work; eg 'sensitivity 99; volume 0.8; r_drawviewmodel 0' or 'unbind enter; toggleconsole'.

3. Another weird behaviour was what happened when using the 'give q1' etc commands for runes. Try the following in order:

a) impulse 9
b) give q1 (or any rune)
c) impulse 9

On my PC, the 'give q1' command results in all weapons except the one currently active being stripped, and using impulse 9 again will only give back the rocket launcher and lightning gun.

4. Not sure if it's a bug or intended behaviour, but the gamma and contrast cvars operate within a more limited range than other engines. Usually I'd use a gamma value of 1.3, but unlike FitzQuake and Quakespasm, Mark V doesn't seem to permit gamma exceeding a value of 1, leaving the game looking excessively bright on my monitor.

Also, is it intended behaviour that vid_hardwaregamma 1 permits use of both gamma and contrast cvars, whereas a value of 0 only permits access to contrast?

5. I can confirm the presence of the WinQuake crash when switching to 1920x1080.

I hope you don't mind if I make a few feature requests as well, though I know you're currently working on polishing up what you currently have rather than adding anything new.

1. The text editing features in-console are terrific and this is something I always miss when using non-Source engine games, but would it be possible to add the common ctrl shortcuts such as ctrl+left/rightarrow, ctrl+z, ctrl+a, ctrl+shift+left/rightarrow?

2. The 'apropos' command from DarkPlaces and FTE that lets you search for any console commands containing the specified string, perhaps renamed to something more intuitive like 'find'. I think this would fit in nicely with the kind of usability features Mark V specialises in.

3. Again from Darkplaces and FTE, a 'true lightning' cvar, that stops the lightning gun's beam from becoming detached from the gun when looking or moving around.

4. From DirectQuake and FTE, separate cvars for each of the screen tinting effects (pickup flash, damage flash, quad damage etc).

I have a few others but that's probably enough for now. Let me know if you need more info about my PC or config when investigating those bugs. 
@nightfright --- I'm committed to getting your problems with hipnotic and ne_ruins solved. I'll do some thinking and investigation.


1) Demo rewind. Works, uses arrows keys now instead of pgup/pgdn. A Macbook Pro doesn't have PGUP or PGDN and since both Qrack and JoeQuake use the arrow keys for those functions, I decided to reluctantly change those keys to be more multi-platform friendly.

2) vid_hardwaregamma 0 --- I don't currently have gamma implemented for that, only contrast.

3) WinQuake vertical resolution > 900 = crash. Yeah, hard limit of renderer. Will work in future versions via scaling.

4) would it be possible to add the common ctrl shortcuts such as ctrl+left/rightarrow, ctrl+z, ctrl+a, ctrl+shift+left/rightarrow? Sounds reasonable ;-)

5) Give stuff. Will investigate and fix if needed. 
About SoA Sound Issue 
Baker, please disregard my report about broken SoA sounds. I checked again and realized I had a custom PAK in my MP1 folder with resampled sound files after all.

It has nothing to do with your port - after removing that file, everything works fine. My apologies for the confusion! 
PNG Screenshots / Nehahra 
Unfortunately, transparent statusbars still cause visual glitches on PNG screenshots.

That screen was taken in the level "Sacred Trinity" of Nehahra. It seems that none of the three keys there you have to collect to open the exit gate are textured. I don't remember if it was like that from the beginning or it's a glitch with the renderer.

So far, Nehahra playthrough progresses well. I can live without the fog effects. Unfortunately, the game only works properly with music if you place the files within a "nehahra" subdir inside of the Quake folder. I usually have all my mods in an "addons" folder, so the links are normally like "-game addons/nehahra". That works with launchers like MiniQL, but looks like Mk V won't find fmod.dll if you don't have the Nehahra folder where it expects it to be. Game crashes if you try anything else.
You also need to have the music files separately in the nehahra/mods folder (inside a PAK won't work, guess it's the same as with MP3s), but that's OK.

Curious what will happen once I reach Nehahra. JoeQuake crashed pretty badly after defeating the boss when running out of edicts or something with all the gibs flying all over the place... 
Thank You Baker 
the latest build is running like charm
and the mention issues have gone, thats nice 
Probably a false alarm, but FWIW Baker, MSE claims that the Beta 9 zip is infested with "TrojanDropper:Win32/SpamThru.gen!A". 
Beta 10 
Windows OpenGL + WinQuake

(didn't include the DirectX 8 build because because it flags Microsoft's malware detection for some reason ...)

1) Fixed "give bug" pointed out by therailmccoy.
2) Fine tuned timedemo, playdemo and start demos transition handling (zzzzzz, but I want it to be "right").
3) Change to how warp textures and console scaling changes take effect. Not very interesting but laying the groundwork for adding scaling to the WinQuake version.
4) Some other fine tuning.

Next update is likely to have:
a) Scaling solution for WinQuake vertical resolution > 900 +/-.
b) The extra keys therailmccoy likes that are in Source engines (ctrl + a, etc.)
c) Rework to give especially for the things that only Mark V lets you give yourself like keys and runes. Now that I have auto-complete cryptic names like Q1 for sigils and KS for silver key need to go. Will have names like "give silverkey" and you can either auto-complete from the 'S' or press CTRL+SPACE to see the valid ones. And somehow letting user know they can remove the silverkey/goldkey/rune1-4 using same command.
d) Attempt to solve PNG screenshot too white with sbar alpha for NightFright.
e) Mark V does play DZip demos. You have to have dzip.exe in your Quake folder. Next update is likely to not require dzip.exe at all and just be built-in. The SpeedDemosArchive has 1000s of speedruns in .dz format.
f) Maybe cut/paste/shift select for all text fields in the game.
g) Quakespasm allocblock lightmap speedmap.
h) Quakespasm lightmap precision refinements, but I want to try to have the problem first. 
Cool Stuff 
Regarding h), it should be easy to reproduce on the Mac build, I was able to with the recent Mac build you posted.

Also, if you want, you should be able to reproduce the issue in Visual Studio as well with the "/arch:sse2" flag. IIRC this will still make a 32-bit exe, but will require a Pentium 4 or better. Info on that flag: 
I was able to with the recent Mac build you posted Sounds like when I boot up that Mac that'll be easy then (most of past attempts failed because the screenshots of the issue had no name and I looked at a few mapjams and didn't see issue ... was frustrating). The BSP compiler actually does the calcs using doubles so your fix is a natural extension of what Q engines should be doing already.

General note: When I was looking at Quakespasm's render adjustments, something bumped my memory of MH's expression "DrawSequentialPoly must die" (from a few year's back) ... and I find it a bit onerous to have to maintain 2 copies of the drawing code (one for world, one for brush models) when they are essentially the same aside from .alpha.

JoeQuake and FuhQuake (predecessor to ezQuake), for instance have had DrawSequentialPoly gone for a long, long time.

Note #2: I wish I knew an easy way to have WinQuake use vid_vsync. That uses a wgl function on Windows. I could make WinQuake use OpenGL only for buffer swapping, but then exposes WinQuake on Windows to bad OpenGL driver issues. 
ditch mgl so that you can use directdraw directly.
use directdraw's vsync stuff, then you won't need to copy textures twice nor suffer from missing gl drivers. 
I wasn't aware DirectDraw had vsync somewhere in the API, although I'm not using mgl nor DirectDraw but rather just BitBlt/StretchBlt.

[I copy the buffer using BitBlt on Windows derived from what initially started as MH's pure API WinQuake and still has some of that left. The Mac WinQuake renders to texture in OpenGL via proxy texture and draws the texture to the entire window.] 
The link above for the updated package should be 
The impetus for getting rid of DrawSequentialPoly in qs was ijed's RRP map telefragged.bsp... The first main room, after you leave the entrance room and go through a corridor, has several large brush models in the PVS (a train outside, and moving bridges, inside). I was getting something like 17 fps on my laptop (while not a gaming laptop, high-end enough that it should breeze through anything quake. i.e. i7 quad, geforce 650gt).

Profiling showed 90% of rendering time in that room was in DrawSequentialPoly, and most of that is doing gl state changes, because the brush model surfaces aren't sorted by texture. So if the brush model uses several textures, and has a couple hundred faces, you end up doing: "bind texture A, draw surf, bind B, draw surf, bind A, draw, bind B,.. Etc.."

In fitzquake's renderer it's a little more awkward to merge brush model and world drawing than in plain GLQuake, because of how fitz sorts the world surfaces by texture when the PVS changes, but that sorting persists across several frames. So initially I tried to have each brush model clear the texture chains, then chain each surface in the brush model, but this broke the world drawing, because the world wasn't re-chained every frame.

What I ended up doing is making two sets of texture chains, one for the world that can persist across several frames, and one for the brush models that's cleared every time a brush model is drawn. It's a bit convoluted, but it works well, and is simple than maintaining two copies of the drawing code (and faster!). (Side note: I've thought of reverting QS to use a GLQuake style R_DrawRecursiveWorld that regenerates the world texture chains every frame. Based on some comments from mh it may be a bit faster because surfaces are sorted front-to-back, and it would remove the complexity of two sets of texture chains. However the current method works fine so it's not a high priority.)

The other nice thing is, that refactoring paved the way to using a VBO to store the world and brush model (which is isolated to just one drawing function), but it's certainly not necessary to use VBO's to get a good performance boost from eliminating DrawSequentialPoly, at least in cases like ijed's map that make heavy use of brush models. 
Nehahra Crash 
Unfortunately, Mk V currently fails at the very same spot as JoeQuake does when playing Nehahra:

In "Nehahra's Den", after you kill Nehahra and all the gibs start flying with the exit lift descending, game crashes with following error:

1032 byte packet exceeds standard limit of 1024
host_error: ed_alloc: no free edicts (max_edicts: 512)

Here are some savegames to check (no autodemo this time, sorry). The quicksave will bring you to the time right before Nehahra goes down, just keep shooting at it and see what happens. 
I'll take a look at that and resolve. 
Pleased to hear the additional text editing shortcuts might make it in soon. =)

It's an excellent idea to have more intuitive names for give-able items along with autocomplete; might it be worth adding every possible item, so Biosuit, Ring of Shadows etc? Possibly Nehahra/Quoth items too if running those mods.

Btw, the 'give' issue is indeed fixed for commands chained with semi-colons, but giving runes still has the problems I described before.

I also noticed that 'pak help' and 'zip help' commands will result in a crash. 
Gamma range

Extended to the limits that Windows hardware gamma will accept for the next version so your higher level gamma will work. I had limited them to attempt to keep them in the valid range, but the high range for gamma corresponded to the menu limit not the hardware limit.

Give - more items, quoth, nehahra, etc.

Not sure. I've already made the names user-friendly. Many of those things are likely to be impulses which are mod specific behaviors outside the engine. One example, the "give" command cannot give you "Quad".

Extra editing keys

Those are in the next one.

I also noticed that 'pak help' and 'zip help' commands

Hehe, 'pak' and 'zip' exist just to expose those for testing. I don't expect them to be there in the end, and didn't expect them to be noticed ;-) 
Items like quad are given by impulse commands, but Quoth does implement named aliases for these commands, for example "quadcheat" in the console performs impulse 255 and gives you the quad. These should autocomplete when the engine supports it - as fitz085 does I'm sure Mark V would as well... 
Nehahra And Limits 
I am actually wondering why that Nehahra crash happened. Didn't you raise the limits for RRP already, including edicts? That should have avoided this issue. Was using the April 19 snapshot after all. Anyway, maybe Nehahra is handled differently.

I am pretty sure it's the only problem with the mod, though. Until that point, everything worked flawlessly (and I don't expect it to screw up in the last level when you got to fight Max).

Side note: Is there actually any chance you are able to add the missing fog effects or is that something Mk V simply cannot pull off? 
Not Nehahra's fault, engine's fault. Reason is long-winded and technical. I'll try to explain.

Mark V guesses the number of server edicts needed. ne_ruins and end of nehahra, because they spawn lots of entities tricks this and over-runs the limit.

I wanted to avoid dynamic allocation of entities because then it requires a client to dynamically allocate them. I'm not interested in Mark V as a server being incompatible with FitzQuake 0.85 or Quakespasm as a client, I view that unacceptable incompatibility.

Hence, the guessing (mostly to avoid the max_edicts cvar)--- and guessing wrong in this case.

But I think I have an alternative, but need to think more.

For now, setting host_max_edicts to, say, 8192 should make anything run. Mark V will honor the cvar if it isn't set to 0.


I can't remember the specifics. I know I had the fog enabled at one point. Then I had cause to disable it and I believe it was for a good reason, but I don't remember it right now.

I like fog so it had to be a good reason, but I can't recall --- it could have been something like ...

A) Perhaps FitzQuake fog and Nehahra don't mix right. Maybe it totally obscured the skyboxes. Maybe it was something else.
B) Maybe the fog keys in the maps were wildly inconsistent?
C) Maybe I compared DPNehahra vs. JoeQuake there was a serious difference?

Like I said, there was a reason. Now, I need to remember why ... 
Max Edicts 
Having the client dynamically allocate entities is easy. Having the server dynamically allocate them is hard, because the QC interpreter does a lot of pointer offset trickery to access edict fields. It's even valid for the interpreter to try to access a field in a different edict to the current one. I'm not sure why you'd even want to, but I've tripped up on that assumption in the past.

Static entities and efrags have absolutely no reason to have hard-coded limits and can be just pulled from Hunk memory as required. At a guess I'd say that the hard-coded limits in the original were there because Quake had to run on an 8mb MS-DOS machine (a lot of the weirdness in Quake's memory system comes from that and the fact that DOS had no virtual memory, and it's notable that id threw it all out when they moved away from DOS). There's no reason to preserve that in a modern source port. 
better the client disconnects than the server crashes.

fog is different in almost every engine. it would be nice if someone actually documented the formulas engines use in an attempt to create some standard that all engines could then use...

the _only_ reason for weird fields is weird ens - ie: qccx hacks (there's no other way to easily generate those dodgy fields). imho, nuke them from orbit, but I guess baker doesn't have that luxuary due to his proquake stuff.
fte+dp use regular indexes for ents instead of offsets (screw qccx), and in doing so, they can dynamically allocate more memory. the catch is that you can't free it again mid-map. 
Fog isn't just different on every engine, it's also potentially different on different hardware, drivers and even APIs.

Fixed pipeline fog (i.e the various glFog commands) is allowed to be evaluated per-vertex or per-fragment. AFAIK OpenGL doesn't specify this, but D3D also allows more explicit control of range-based (versus simple depth-based) fog and even table-based fog.

You're completely at the mercy of what your 3D card and driver gives you for this, so it's pointless specifying a standard. The best anyone can do is implement something that looks good enough to pass, but even so it may look completely different (even with the very same code) on somebody else's PC.

Fixed pipeline fog doesn't even work at all under D3D with Shader Model 3 or better hardware. You must write your own fog in a shader.

Fixed pipeline fog quality in OpenGL is controlled by a hint and the documentation for glHint explicitly states that "the interpretation of the hints depends on the implementation". It's perfectly legal for you to request GL_NICEST but for the driver to give you low-quality instead.

Shader-based fog can use any formula at all, and can likewise be calculated per-vertex or per-fragment. The end result can look much higher quality than fixed pipeline fog (you can even experiment with crazy things like moving fog) but the higher quality may be interpreted as different or non-standard by comparison to what a player is otherwise used to.

Quake 3 and Doom 3 avoid all of this mess by doing their own fog as an extra pass over all surfaces, which obviously comes at the cost of extra geometry submission and processing. Depending on the scene, this could cut framerate in half.

It's also possible to implement fog by drawing the depth buffer as a full-screen quad over the scene and deriving a fog formula from the values stored in it, but that of course will fail for anything that's not written to the depth buffer (particles, translucent water, etc won't be fogged). 
Finishing Nehahra 
Well, putting max_edicts "8192" into autoexec.cfg enabled me to get past "Nehahra's Den" with existing savegames. The problem is that while Nehahra's gibs are flying around, the exit elevator breaks through the ceiling, and with all the glass shards and debris raining down while gibs are still visible, it's just too much with low edicts settings.

I noticed a small detail with episode ending text screens. Looks like the last line(s) of text are cut off. Thought it may be because I use scr_menuscale 3, but reducing the value didn't reveal the missing lines (they were complete when checking it on console, though).

Summary of Nehahra playthrough:
- "Nehahra's Den" crash fix needed
- Possible issue with ending texts (may be general issue or not)
- Adding missing fog would be nice, but optional
- Otherwise, flawless gameplay. Music plays (if set up properly), cutscenes work, all maps completable etc

Keeping the "resurrection crash issue" with ne_ruins in mind, I will continue my Mk V testing queue with:
- Quake mission packs (SoA almost done already)
- Travail
- Honey
- Rubicon Rumble Pack

Possibly more after that, provided my free time allows it. 
@nightfright .. I appreciate the testing. I can't work on this and play a ton of mods at the same time ;-) 
Did you say that earlier you had max_edicts at 512? Because that's lower than dosquake which allowed 600 edicts, which might explain why it caused crashing. There's an argument here that allowing people to reduce the memory footprint below what was considered acceptable 19 years ago is unnecessary today. This argument would continue that engines should prevent people shooting themselves in the foot by enforcing a minimum max_edicts of 600. 
Edict size in ID1 is 876 bytes. This can be variable because mods can add their own edict fields which are tagged on at the end of the struct, accessible normally through QC but only accessible through C code by means of some pointer jiggery-pokery.

Say 1k as a good working size and because it makes subsequent calculations easier.

So if max_edicts is 8192 that's 8mb of memory. If it's 32768 it's 32mb of memory. Neither is a huge figure today, nor would it be considered huge on a PC from 10 years ago.

Most of that memory is going to be unused though, and there's also the fact that a lot of engine developers like to have their engines run on the same (or at least similar) class of machine that the original ran on.

One solution under Windows would be to VirtualAlloc a largeish pool of memory - say 64mb (for headroom) - with MEM_RESERVE. This won't count towards memory used, it just marks pages as reserved for subsequent use. Then as edicts are assigned from that pool, another VirtualAlloc with MEM_COMMIT for each new edict will actually use the memory, and only the memory, required for however many edicts a map might need.

I'm sure Linux and other POSIX systems have APIs that allow a similar scheme, but I'm not familiar with them. Either way, this setup allows the max_edicts cvar to go away.

IMO this is a good thing. I get that max_edicts is well-meant, but a major weakness of it is that it puts the obligation on the player to do the right thing. And the player must be aware that it exists, know that it may be needed, know what the appropriate value to set it to is, and know to set it before loading the map.

That just seems appallingly player-unfriendly to me. OK, I also understand that newer mods come with their own quake.rc that sets it accordingly, but it's still broken under older mods and it's something that with a bit of thought doesn't even need to exist.

In the end I just don't see an acceptable middle-ground for players. Either set a hard max_edicts and design mods around it, or make there be no practical maximum. But putting the burden on the player to do the right thing is eventually just going to blow up in your face. 
512 sounds low, but it was a machine picking the limit because the map probably had like 150 entities.

Dynamic ents will fix.

Dynamic ents doesn't solve any issues except this one. By the time you hit 5000 server edicts you are going to have all kinds of problems with the networking limits for stock Quake.

If it isn't one thing, its another. 
Beta 11 
Windows OpenGL | WinQuake

1) PNG screenshots might be fixed. Need NightFright to check since I don't experience issue. Changed download from GL_RGBA to old style GL_RGB before saving to PNG.

2) WinQuake large resolutions should be fine, but scaled (because WinQuake renderer can only do so many vertical lines). I don't have a 1080p monitor, so need verification as well.

3) Added Ctrl+Left+Arrow, CTRL-A, CTRL-Z (undo), CTRL-SHIFT-Z (redo) to console.

[I was going to do one level of undo. Then I thought, I'm not going to bother with undo. So of course, it has an unlimited undo buffer that compacts to words.]

4) Fixed drawing chat text if the console width was too narrow to display the whole line.

I have another batch of changes, but wanted to hit a check a "checkpoint" because I made heavy revisions to the console for auto-complete, console drawing and for undo. The auto-complete function in previous versions worked fine, but the code was embarassing cobbled together spaghetti caked on layer after layer that happened to work. 
Actual Download ... 
Music Is Fixed Now 
I dunno what you did between this release and the last one but music suddenly works!

Developer 1 And Sound 
I noticed that with developer 1 active the console gets spammed with messages about sound volume - 
I'm really happy your music works now! 
Cheers. This has replaced all my other engines now. I will still be using dark places too but only to make sure dark places is compatible.

Any reason why gl_texturemode settings don't save? It resets each load unless you set it in an autoexec.cfg 
It isn't a cvar. Fitz 0.85 it was a command.

[Quakespasm made it a cvar and has it save. I don't see that as something someone generally would touch except as curiousity and if they do, they wouldn't know the default value easily to restore it.] 
PNG Screenshots 
I can confirm that latest snapshot fixes screenshots with transparent statusbar for me.

Something else on my wishlist for quite a while is a sound resampler - especially useful if you set sndspeed 44100. I picture something like in ZDoom with its snd_resampler variable, letting you choose between "NoInterp", "Linear", "Cubic" and "Spline" modes.
Currently, I try to compensate the most annoying upsampling side-effects with converted sounds, but as we know, that's not a very elegant solution. 
the nice thing about MarkV using DirectX to play back the music is, the sfx and music are mixed together by the OS, not by MarkV. By using the default sndspeed 11025, you'll get very high quality upsampling provided by Windows, better than "Cubic" or "Spline" I'd guess.

In stock id quake, the lightning gun crackle is one of the only 22050Hz sounds, and I think everyone's used to hearing it downsampled to 11025. the need for a good resampler only comes into play if you want mix 11025 and 22050 sounds (in a mod, say), or mix 11025 with 44100 music in-engine (quakespasm does this). 
Good start. Now 2 of 3 known issues that I don't or can't experience are gone.

If someone with a 1080p monitor can see how the WinQuake version reacts to setting a screen resolution like 1920 x 1080.

I have another update with maxedicts gone (client always has 8192 edicts available, server will use 8192 edicts unless protocol is 15 (standard Quake) and in that case will use 600 for backwards compatibility), ericw's allocblock and double precision adjustments for lightmaps (even in the WinQuake version for the lightmap adjustments) and a few other things like fifth being annoying with developer 1 and changing mp3 volume printed.

I have dzip for .dz demos integrated in the current released build, but I don't have it doing anything yet.

I need to tweak the Nehahra handling a little and see if there is anything else I've missed. 
Really good advice with sndspeed 11050, thanks a lot! Didn't know that it actually sounds better with default setting. As you said, some sounds (not only in vanilla Quake, but also addons) have different sampling rates, but I guess this is a fair compromise.

I am about to finish my Travail tests. So far no issues. 
Winquake 1080p 
I can select the mode for 1080p, it seems to work in that respect but I can't tell if it's truly setting that as the resolution. I thought taking a screenshot would show the true res but the resolution of the .png file was 960x540 
Yep same here. I'd guess that's intended since Baker was talking about handling the problem thru scaling. It's funny that you get "fewer pixels" at 1080p than at 720p here, but if for whatever reason the renderer can't handle 1080p then pixel-doubling could be better than having to interpolate.

Is this what other SW renderers do at high resolutions? 
I loaded up Half Life and went to options->video and selected the software renderer, but my vertical resolution is 768 and it won't let me try higher.

Don't have Quake 2 installed at the moment to try that either.

[I did try to adjust by a percent initially instead of dividing by an integer, but the status bar was imperfect at some resolutions showing a line (WinQuake doesn't always draw the status bar, so it isn't quite a single surface.). So I went with the integer multiplication method because of that and the results should always be very predictable and I don't have to worry about stretching and such possibly looking bad at some resolutions, so it will look clean cut.] 
r_shared.h, change #define MAXHEIGHT 1024 to 1080.
1920x1080 works fine now, though it's pretty slow 
Touching that definition introduces a chain reaction that filters into the assembly language definitions and numerous things in the software renderer files.

That's way outside the scope of this project for me. 
Ah Sorry 
didn't realize you were doing scaling.
The latest markv winquake build works well here @ 1920x1080. 
Haha, you know what ... 1080 vs. 1024, that's a mere 56 pixels. A quick look and I dug up some Engoo/QBism/Makaqu threads and it appears that isn't going to explode anything. 
Beta 12 
Beta 12 - Windows GL | WinQuake

1) mp3 status events don't print for developer 1
2) Increased the maximum vertical resolution for WinQuake to 1080 (in theory -- can't directly test).
3) ericw's lightmap precision changes + alloc block speed up from Quakespasm implemented.
4) Max edicts is gone. As a client it always uses 8192. As a server it uses 8192 if running FitzQuake protocol 666 (the usual) and standard Quake's limit of 600 if serving a protocol 15 game.

Later on, I'll upload the Mac version and updated source.

Thanks for all the help in testing all of this! 
Interesting , because protocol 15 can handle up to 8192 edicts correctly 
that's a subjective statement. while the protocol might be able to cope with up to 32k ents, the implementations of that protocol may only support 600.

seeing as vanilla nq will safely handle its limitation, I would personally say that the server should just use 8192 even with protocol 15, because its better to soft-crash outdated clients than the server.
fte filters entities over the assumed client's limit because invisible entities is probably better than soft-crashing anything. if the client supports the proquake 16bit angles thing, you can generally assume the limit is higher. heuristics can always be wrong, of course.
of course, fte is crazy, and filtering reliably is a whole load of work that I can understand not bothering with (svc_setview! oh noes!), in which case imho your server not crashing is more important than your clients not crashing. 
For protocol 15:

FitzQuake 0.80, if I recall bumped the max edicts from 600 to 1024. JoeQuake uses 2048 if I remember correctly. WinQuake and GLQuake use 600.

My thoughts were if someone was going to run in protocol 15 mode as a server, they would probably want to ensure anything original Quake could connect and play. 
Nehara And Latest Build 
No crash in "Nehahra's Den" any more with max_edicts limitation gone. So much for the good news.

Unfortunately, the game now crashes to desktop a bit later when entering the next/last map (nehend). This also happens when you directly try to go that level via menu or with +map nehend, so it's not related to the previous boss fight.

Nehahra savegames and autodemo (932 KB) to demonstrate the problem

At the end of that level (nehahra), mp3 music from id1 dir is played during the level statistics and the following episode ending screen. This interferes with the actual background music, maybe it can be fixed still even though it is a minimal issue? 
Nehahra Crash Details 
To be more precise, the following Nehahra levels now crash directly to desktop when loading them:

neh1m9 "To the Death"
neh2m6 "Your Last Cup of Sorrow"
nehend "Quintessence"

Also, ID1 music generally plays in all the levels, except for when the game searches for tracks 00 and 01, but cannot find them in the music folder within the id1 directory. 
Could you check a timerefresh command. I think it's broken. 
timerefresh is broken in pretty much any modern engine, isn't it? If not, it is completely useless on any modern hardware anyways. Use timedemo. 
@ NightFright ...

1) music + crashes

Nehahra isn't supposed to use the mp3 music or cdtracks, just the .xm tracks with fmod. I need to check the behavior there, but I bet if you temporarily remove your music tracks it won't crash. Clearly, I need to fix that so it doesn't try to play both.

2) Nehahra finale text --- interesting. Apparently Nehahra draws too many lines to display for the finale text (i.e. isn't backwards compatible to Quake minimum resolution of 320 x 200, which the menu is based on). I'll figure out how to address.

@spy ... I'll fix timerefresh. Thanks for finding that. There really is no reason why that shouldn't work. 
Testing Report 
Really odd thing: I checked Nehahra again at home on my other PC, and neither do I have crashes there nor does it play MP3s and XM tracks at the same time. Hard to figure out the differences of the PC setups. Ofc the hardware isn't exactly the same. Hmmm... I am running the game in windowed mode in the other place. Will look into that. Still, it cannot hurt to make sure Nehahra will never use MP3 music from the ID1 folder.

So far, I have tested Mk V with:
- Quake + both mission packs (MP2 50% done) --> OK
- Travail --> OK
- Nehahra --> Intermission text length, missing fog
- ne_ruins --> Succubus resurrection crash

I also remember that the commercial TCs Shrak and Malice had some issues with Mk V at least one year ago (Shrak: crashed for me when using rocket launcher sometimes, Malice: crashes in pre-final level when killing Vasquez). Will look into those again as well, even though I am not sure you'd be willing to check this if I find anything. Those addons are not very common, and at least Shrak isn't the most popular, either. 
Does Succubus resurrection still crash ne_ruins? 
Succubus crash still happens, though not right after the first resurrection any more. Can take 2-3 now before you are going back to desktop.

I also still see quite some error messages, e.g.
302 models exceeds standard limit of 256
291 sounds exceeds standard limit of 256
111 lightmaps exceeds standard limit of 64
605 edicts exceeds standard limit of 600

Not sure if these still have any meaning, though. I play with -heapsize 524288 parameter. 
Demo and autosave please. Please, please. 
Ne_ruins Demo 
Here we go again:
ne_ruins autodemo/savegames (335 KB)

You can ignore the manual save(s). The quicksave will bring you straight to the situation with the succubus and the knights as seen in the short autodemo. God mode is activated.

Regarding the text length issue:
Actually, MP2 is also affected (e.g. at the end of episode 1). Maybe either use a second screen if texts are too long or simply make the game show all the text in any situation. I doubt that anybody still players in 320x200 these days, anyway. 
I've tried 15 ways to get it to crash, had tons of monsters resurrected, played your save game, watched your demo.

Also played ne_ruins for who knows how long (45 minutes?) couldn't get it to crash.

Does it just crash to desktop or does it say Host_Error or something? 
It's a straight crash to desktop without any error (besides the standard Windows thing "Program doesn't work any more"). Maybe it's again a hardware-specific issue (e.g. I have nvidia cards in both PCs I use).

In my autoexec.cfg, I have
gl_texturemode "gl_nearest_mipmap_linear"
r_shadows "1"
r_waterquality "32"

Here's the config.cfg from my ne_ruins folder.

I tried to more things which didn't change anything:
- Switch to fullscreen mode
- Move "ne_ruins" folder from "addons" subdir to Quake root dir (i.e. Quake/ne_ruins instead of Quake/addons/ne_ruins) and run it from there 
The good news: your config completely crashes me. 
The "exceeds standard limit" messages are warnings, not errors. I always get confused about that too. It means the engine warns you that engines without raised limits won't be able to load it or show errors. It's the "developers 1 for content creators output". 
It may be one of the settings applied through the config, then. But even with a default config file (wiping my customized one from ID1 folder and creating a new one from scratch when running ne_ruins afterwards), it doesn't fix the problem. 

I don't have an exact answer for why it is crashing for you. (It isn't for me, although I run out of memory without using a massive -heapsize 512000 because of your use of gl_subdivide_size which does look incredible with r_waterripple).

I think the use of several aggressive settings like gl_subdivide_size 16, a huge memory allocation, possibly mp3 music (and maybe model/sound replacements?) on the bunker-busting ne_ruins in aggregate is causing an unusual stress point somehow.

I notice you are using gl_texture_anisotropy 16.

gl_subdivide_size 16 is using ridiculous amounts of memory on ne_ruins.

Maybe you created the perfect storm and doing it with ne_ruins is piece of straw that breaks the camel's back. 
In my ID1 folder, I have the following additional PAKs:

- pak2.pak (.lit/.vis files for ID1 maps)
- pak3.pak (OriOn's fixed MDLs)
- pak4.pak (improved models by capnbubs/Lunaran)
- pak5.pak (E2M6.bsp with Romero's enhanced entrace included, .vis and .lit file)

Download the PAKs above here (11.3 MB) and put them into ID1 if you wish to try. However, since you said the config file is already enough for you to get the crashes as well, I hardly believe those files are to blame for it. 
@nightfright Pt2 
But if you upload your id1 folder + your ne_ruins folder somewhere I'll try to see the nature of the problem. 
Ah, you just posted. I'll try your packs. 
Or nightfright could start from a clean installation himself and work step by step to find the culprit. Don't burn out, baker! 
I'm able to recreate the crash and really quickly. 
@spirit ... I'm not gonna burn out ;-)

I'm in this deep with this problem, I can get it to crash now. 
It looks like some sort of stack corruption. It goes to draw a model, sets the pointer to a texture. And the pointer to the texture is fine.

Then at the end of the function, it isn't fine and points somewhere crazy.

I tend to use vc6 because it is fast, quick to compile and stays out of my way. I guess I'll use vs 2008 to compile the ones for distribution. 
I have tried resetting following variables to their defaults (as written below):

gl_subdivide_size "128"
gl_texture_anisotropy "1"
r_lavaalpha "1"
r_oldwater "1"
r_slimealpha "1"
r_wateralpha "1"
r_waterripple "0"
r_waterquality "8"
r_shadows "0"

Even if that frees up memory as you say, the effect would still occur, even if I start a new game (not using the savegames I posted above). 
Played it a fair bit, so here's some feedback and bug reports.

No issues so far with the text editing shortcuts, seems to work fine. Really love this and hopefully various other non-Quake id open source engines devs adopt it for their own engines.

- WinQuake at 1080p seems to be mainly ok, but I noticed one or two minor issues. First, something I noticed is that the WinQuake version starts to feel more 'choppy' and with seemingly worse input latency as you dial up the resolution, even with equal framerate. So 1920x1080 @ 72 fps feels worse than 1600x900 @ 72 which in turn feels worse than 1024x768 @ 72. This is with vid_vsync 0. Maybe this is just some quirk deep in the engine that would be hard to fix, but just thought I'd mention it.

- Also in WinQuake, is it intended behaviour for water/slime/lava to each produce identical results when their respective r_*alpha value is set to anything below 1? Ie, there is no visual difference between 0.1 and 0.9. Also, at least to me, lava tends to look a little strange with a value below 1 -

- Moving on to the OpenGL version, I noticed this strange blue pixel that appears on the shotgun (circled in red) - - which doesn't appear in other engines (apologies for png, but it shows up better with this image format).

- If gamma and contrast cvars have been adjusted and the engine crashes, it results in Windows desktop displaying as excessively bright. Tried to take a screenshot of this, but Windows always produces normal colours in the screenshot.

- Not necessarily a bug, but gamma has a much broader range of possible values than contrast. Not a problem on my monitor, but might be for some people.

- Regarding the ne_ruins crashes - are you using -zone 2048 -heapsize 192000 as instructed in the ne_ruins readme, NightFright? I was getting a crash frequently at a particular location - - and it always happened without setting those values. When I did set them, it happened much less frequently. Demo and save game if you want to take a look, Baker -

- You probably know, but runes weapon stripping stuff and 'pak/zip help' issues still there. 
ne_ruins crash conclusively solved. Incorrect handling of entities with alpha = 0. The End.

So that's what was up with that. 
1. WinQuake slow @ big resolutions.

WinQuake is software renderer. Big resolution = slow. Low resolution = fast. Even though 1080p "works".

However, no one makes you do 1920x1080 full screen, you could pick another full-screen resolution like 800x600 or something with less pixels and it would be faster.

2. Stipple alpha on|off doesn't recognize differences

The stipple alpha I put in WinQuake isn't fancy. It draws every other pixel if r_wateralpha < 1, so it is sort of yes or no.

3. "I noticed this strange blue pixel".

I noticed that myself months ago. If you open up id1/pak0.pak ... progs/v_shot.mdl you'll discover the background is blue!! Look a shot gun box in DarkPlaces and you'll see other fun stuff. FitzQuake engines and, say, ezQuake have a "fix the shotgun shell texture" fix in them, DarkPlaces is purist in that regard and does not correct content.

So rack that up as one of the weird things in Quake. If you do enough poking around, you'll find little weird things in Quake.

4. gamma has a much broader range of possible values than contrast.

Not sure what to say. The range is the acceptable range that Windows accepts for hardware gamma for contrast. The gamma cvar will accept all possible values for gamma that Windows will accept, but as I noted before the slider bar corresponds to the WinQuake menu.

5. If gamma and contrast cvars have been adjusted and the engine crashes, it results in Windows desktop displaying as excessively bright.

Which is why I don't like using hardware gamma.

Hardware gamma is the worst. Except for all the other ways of doing it :( Hardware gamma is free, other ways either are an FPS hit or imprecise which is why there is the vid_hardwaregamma cvar and maybe at some point I'll try to implement a sneaky tactic of shoving gamma+contrast into the textures (and hope it looks right). But that's for the future.

6. ne_ruins

As of like 20 minutes ago, the mysterious ne_ruins crash is solved once and for all --- in the next release.

I think more people have discovered ne_ruins seeing it cause Mark V grief in this thread than from any other source ;-) 
Sounds cool. I am curious whether this might actually even fix my issues with Shrak and Malice, as the crashes there were quite similar. Will playtest till it breaks (well, hopefully not) once you have an updated build. Great that you found something after all - admirable dedication you show there!

I experienced the same issues regarding texture seams on HUD weapons. To counter the effect, I have released OriOn's fixed weapons with edited skins over at With these, the texture seams should disappear (my edits of the original model pack was aiming especially for that). 
I wasn't able to compile this on Linux 64-bit. Has it been ported over? 
Ah yeh, looks like the ne_ruins glitch was identified just before I posted.

With WinQuake, it's not like it's slow in terms of fps, as i said 1080p holds steady at 72 fps just fine, it just feels choppy. But yeh, not like I really expect wonders from a near 20 year old software renderer, it's frankly just nice to have a modern working one at all. =P

Regarding gamma/contrast, I was really just drawing attention to the somewhat narrow range of contrast values available, rather than anything gamma related. For example, DirectQuake allows you to go from a value of 0 (exceptionally low contrast) to a value of (I think) 7 (exceptionally high contrast), whereas Mark V seems to go from 1 (low-medium contrast) to 2 (medium-high contrast).

NightFright - thanks for the link. Installed it and had a look, and I do quite like some of the fixes in it, though some weapons seem to show up even more blue pixels than the id originals. =) 
DirectQ applied gamma by running a pixel shader over the entire screen as a post-process effect, so it wasn't bound by the range of standard hardware gamma, but of course it wasn't a free effect either. 
Tonight, I will take a closer look at some more recent addons and see how Mk V is doing there.

I have updated the OriOn model pack once more. Now all weapon skins have their blue background colors replaced by black. Maybe that will fix the issue for you once and for all. 
@saindd - there isn't a Linux port of Mark V. Quakeforge and ezQuake may have software renderers available for Linux. 
Beta 14 - Windows OpenGL | WinQuake

ne_ruins fix (entities with alpha = 0). Other minor things (fixed a demo pause oddity, clear undo buffer when exiting console, zzzzz ...) and changed compiler options slightly to improve speed slightly. 
runes weapon stripping stuff

Ironically, giving yourself a rune doesn't do anything except cause the item to show in inventory.

In QuakeC, this isn't how runes work. So whether or not it shows in the status bar is all psychological. If you use that give yourself runes and changelevel to the start map, nothing special happens because the game logic keeps track of things differently.

So I'll give removing the "give yourself a rune" command.

It does nothing of substance :( 
Give Runes 
Actually if you impulse 11 4 times then changelevel start the entrance to Shub Niggurath's pit will be open, and the episode gates closed. A single rune does nothing. 
a single rune should block the entrance to the specific episode where that rune lives. 
That is somewhat inconvenient in this sense.

You can't actually type "impulse 11" in the console 4 times in single player.

You have to type "impulse 11", close the console so that game isn't paused and the server will take a command.

Then open the console and repeat 3 more times.

Even typing "wait" between won't help because frames still happen when the console is open so waiting for the next frame doesn't mean anything.

Who wants to open and shut the console 4 times.

Then after all of that, do a changelevel.

However, the circumstances are rare enough I'll just add a little extra text in typing the give command without parameters. Or something. 
Is that bug where runes disappear fixed in fmv? Otherwise people do need that workaround. 
Runes Bug 
Personally I find it more useful to changelevel to the last map in the episode for which a rune is missing, then do a quick god/notarget/noclip ride to the rune area, then changelevel back to start.

It seems like more effort but it works if you're playing the episodes out of order. 
Ne_ruins Fixed! 
I confirm that the succubus resurrection crash in ne_ruins is gone for good. I went to the problematic scene in the level again and had the succubus resurrect mobs for more than one minute without any issues. Before that, Mk V would crash after 1-3 resurrects at the very latest. Excellent job, Baker! (I'll still play the whole addon from beginning to the end to make sure it's 100% completable.)

I have already tested "Honey" last night and it's flawless. Never had any issues with it though, so didn't expect it to be any different now.

Next on my list are packs like RRP, The Horde of Zendar and some high-end maps for Quoth (e.g. Conference of the Shamblers) or Drake. Definitely on my list is a test for Shrak/Malice compatibility still. Shrak especially since its hub system caused trouble with some ports for me in the past, plus some random crashes when using rocket launcher (or facing a certain emeny, not sure what was the real problem). Latest update possibly fixed this, so we'll see. ^^ 
For runes, after some poking around I can just directly add them because the progs.dat serverflags is available in the engine

// sigil is 1, 2, 4 8 (1 = Rune 1, 2 = Rune 2, ..)
SV_ClientPrintf ("may require 'changelevel start' or equivalent for intended effect.n");
pr_global_struct->serverflags = (int)pr_global_struct->serverflags ^ sigil;

So the give rune1, give rune2, .. instead of being removed will actually give the rune (as opposed to simply make it show in the inventory). 
I haven't tested this myself yet, nor even given it much thought, but I'm going to have a go at making a PR_ExecuteProgram call to handle this and see how I get on. 
Ne_ruins Again... 
Found a new interesting reproducable bug in ne_ruins:

If you have the new double-barrelled shotgun equipped (not the regular one) and you use "previous weapon" (impulse 12), game freezes and eventually crashes to desktop. I have impulse 12 bound to MWHEELDOWN. "Next weapon" (impulse 10) doesn't do that (bound to MWHEELUP for me). 
Do: sv_fix_no_impulse12 0

That's the feature from Requiem that tries to add "impulse 12" to mods that are missing it.

Apparently, it detects ne_ruins doesn't have "impulse 12" and tries to improvise and causes a crash. 
Impulse 12 
While we are at it: There are addons which use impulse 12 already for other stuff. I am currently testing Malice, and there it is used for weapon reload. That means you cannot use previous weapon function in such mods. 
I think we'll find Requiem's "impulse 12" helper works well with nearly all Func_Msgboard style single player releases and the kind of stuff available at Quaddicted.

And may be often be an interference with heavier stuff like Malice or like most of the stuff listed here or QuakeC modder progs and such. 
Shrak And Malice 
Continuing my testing with latest Mk V build, I have checked out some more exotic addons: Shrak and Malice.

It seems some fixes applied during the last year (possibly the latest for ne_ruins) have solved my issue with crashes when using rocket launcher or killing certain enemies. Hub also works fine, you can complete the whole addon without any showstopper.
The only thing that's left is a skin issue with some gibs. I think several models are affected, but one that's always screwed is the head of the brown shotgun mob, called "Zed". In Shrak's pak0.pak, the mdl is called h_zed.mdl or something, I believe. My guess is either the model or the skin has something Mk V doesn't like. It may be worth investigating as I have also encountered this in some other addons, e.g. Soul of Evil (which I will also check out later still). Here is a Shrak autodemo (437 KB) if you want to see the problem in action.

I still need to finish the last two levels, but I think I can already name the most imminent issue(s):
- Small crates cannot be pushed
- Statusbar is visible during cutscenes
- Crash in "Stayin' Alive" when killing Vasquez sisters more than once

The first two issues may be tolerable (even though not being able to push those small brown crates can prevent you from reaching certain areas in some levels), but the third one kinda sucks.
In that level, you basically encounter three chicks which respawn endlessly whenever you kill them, trying to prevent you from reaching the exit. The thing seems to be: You can kill each of them exactly once. Any additional kill will make Mk V crash to desktop inevitably. This bug is not totally critical as you don't necessarily have to kill the sisters to complete the level. Still may be worth investigating.

Malice autodemo and savegames (238 KB)
(Quicksave should get you directly to the encounter)

In case you don't have Shrak or Malice, you can get them from Quaddicted archives. (For Shrak, use Shrak2.7z.) 
Beta 15 - Windows OpenGL | WinQuake

* Extra room for finale text exceeding FitzQuake menu canvas (320x200) so Nehahra and other longer finale text will display.
* Timerefresh works.
* Dzip demos play with no external dependencies and won't leave potential 'extras' in your Quake folder like JoeQuake and variants (like readmes that were in the .dz). Making dzip be internal to the engine also made in the inside of the engine supporting .dz demos way cleaner.

.dz demos: Speed Demos Archive | Example .dz

* A few other minor touchups: autocompletion got a bit confused by quotes, ability to load a DarkPlaces save game file, don't draw the clock if viewsize is 120, draw intermission plaque + center print + finale text even when console is up or game is paused.

* Give rune1 to rune4 is fully and correctly functional. Tells user they may need to 'changelevel start' or equivalent to get desired effect. 
@nightfright ...

Malice - Small crates cannot be pushed
Malice - Crash in "Stayin' Alive" when killing Vasquez sisters more than once

Does this work right in, say, FitzQuake 0.85 or JoeQuake or some other traditional and very original Quake-like engine?

The Shrak skin thing with the gibs might be because of how GLQuake or even FitzQuake handles skins slightly differently than WinQuake (I think there was a discussion about that in the Quakespasm thread) but next week I'll look at these issues (the ones potentially involving QuakeC like the Malice crates --- if it doesn't work with any open source Quake engine I'm not sure it is actionable.) 
Malice On Other Ports 
FitzQuake 0.85:
- Small crates can be moved
- Vasquez crash (map d13) still happens

JoeQuake 0.15 build 3798:
- Small crates can be moved
- Vasquez crash (map d13) not occurring

In JoeQuake, moving small crates is a bit more difficult as it depends more on viewing angle etc., but it's still possible.

The Vasquez crash seems to be inherited from original FitzQuake, it seems. 
Hm, the malice map d13 crash (happens when you kill one of the enemies in the first group) is from an out-of-range skin number. I saw values of 50, 53, 54, and in the server in SV_WriteEntitiesToClient the skin number is actually a fraction (53.41...).

At first glance I think Fitz is just missing something like the following in the mdl rendering code, this is in Winquake:

if ((skinnum >= pmdl->numskins) || (skinnum < 0))
Con_DPrintf ("R_AliasSetupSkin: no such skin # %dn", skinnum);
skinnum = 0;
fitzquake is supposed to display a blue checker texture for missing skins, which is why it doesn't set the skin to 0. However it appears some mods rely on that behavior?

I can't explain the crash, though. 
Ah I See 
I didn't know about the checkerboard feature.
The crash was coming from these lines in r_alias.c:

tx = paliashdr->gltextures[e->skinnum][anim];
fb = paliashdr->fbtextures[e->skinnum][anim];

The size of the first index of the gltextures and fbtextures arrays is MAX_SKINS (32), so if e->skinnum is < 0 or >= 32, it'll probably crash.

This does the trick:

if ((e->skinnum >= paliashdr->numskins) || (e->skinnum < 0))
Con_DPrintf ("R_DrawAliasModel: no such skin # %dn", e->skinnum);
tx = NULL; // NULL will give the checkerboard texture
fb = NULL;
tx = paliashdr->gltextures[e->skinnum][anim];
fb = paliashdr->fbtextures[e->skinnum][anim];
Malice does kind of rely on skin 0 showing up for invalid skin numbers; when you kill an enemy, they do a teleport animation and the invalid skin is used briefly. So it's a toss up whether to go with strict winquake compatibility (show skin 0) or fitzquake (show checkerboard) 
your fix makes sense. My only suggestion is finding a way not to spam that console message every frame. Like maybe, only do it when the skin is different from the previous frame. (which probably requires moving the test to the client parsing code) 
May 2 Build 
Windows Download Mac OS X 10.7+ Source Code

OpenGL and WinQuake builds for each platform.

ericw's skin fix. Hordes of dedicated server features no one is likely all that interested in but include things like sv_filter_gibs (has a sv_filter_gibs_list to control what that is), sv_full_invisibility (eyes.mdl entity doesn't get sent to anyone), ability to specify console log name -condebug <logname> and several chat limitation options, ability to have condebug log be "dequaked" (chars > 127 converted down 128).

Also edited the probably unnoticed "name maker" (options->multiplayer->setup->name) to not permit carriage returns and such.

The Mac version obviously has both an OpenGL build and a WinQuake build. And like the Windows version can play dzip demos and has all the same selection, copy, paste and undo keys enabled in the console and auto-complete via CTRL-SPACE, etc. It might have an option to unpak pak files in the menu, I forgot to test it this time. Like the Windows version, it can play Nehahra and supports mp3 tracks. 
NightFright - thanks for the updated models, using them permanently now. The only small bit of feedback I'd give is that the original super-nailgun model looks slightly better than the replacement due to the highlight on top being narrower and thus better selling the illusion of a rounded barrel.

Original -
Replacement -

Baker - only thing I noticed so far is that autocomplete seems to require minimum 2 characters to function. Ie - 'q->tab' results in no response, but 'qu->tab' will show the autocomplete possibilities. 
Thanks for the heads up on the auto-complete thing. Quality bug reports make all the difference and you've pointed out some very insightful ones (so has spy, fifth and very obviously nightfright). Not many people would play with the 'give' command, for instance, to notice the runes wiped away the weapons.

The source code link is bad, it should be this
I will still finish my pending tests even though I don't expect to find more.

Dunno if the skin problem in Shrak and Malice crates can still be solved, but it's rather minor things compared to the crashes that were fixed. Considered that the Malice crash was in FitzQuake pretty much since it exists, it's quite an accomplishment to get it solved after all this time. 
Nehahra Cutscene 
A few posts ago was told that the cutscenes of Nehahra work correctly, however when I go play they are not displayed, simply goes from "nehstart" to "neh1m1" without displaying them. I appreciate if anyone knows how to solve it. 
Do you have the correct pak0.pak? The one that comes with the Quaddicted release is only a placeholder. 
It will only get you a file "Readme" inside. 
If it's only with a readme inside, it's the dummy file. Pak0.pak with the 20min intro movie is inside a package called "Seal of Nehahra". Google it, download the zip and overwrite your pak with the bigger one. 
Man, the problem is not in PAK0 ran the mod with the 'glquake' that comes in the zip and cutscenes worked (did not put the PAK0 the seal of nehahra), tested with Darkplaces and also worked, alendo more than the cutscenes that appear within the game are in PAK3. 
NP, Baker, glad to help; after all we all benefit from engines being in active development and bug-free. =)

Something else I noticed was that the numpad responds in an unexpected way. Numpad keys are displayed when the 'keys' command is issued, suggesting they are valid for use, but when attempting to bind them through console or config, they do not function.

It is possible to bind them by using the controls menu and they then behave as expected, but a command attached to say, kp_end, will be described as being bound to '1', kp_leftarrow as '4' etc. So taking the latter case as an example, pressing either the standard '4' key or 'kp_leftarrow' will produce the same result. Perhaps this is intended behaviour, but if it is, it may be worth removing the kp_ keys from being listed in the 'keys' command.

For reference, FitzQuake and Quakespasm do allow binding to numpad separately from standards numbers; ie you can have two separate functions bound to '4' and 'kp_leftarrow', for instance. 
Nehahra has 3 issues I need to address:
1) Demos between levels on Windows only. Right now, the demos in between levels don't play on Windows.
2) Reviewing the fmod code and the mp3 playback code and cd code ensuring only fmod is used.
3) Fog. I'll probably see if I can make it use the FitzQuake fog system.

@nightfright ... I intend to fix the Malice crates. And I will look at the Shrak skin. Probably in a week, they are on my list. From what you have told me about the malice crates, it looks like it should be fixable.

@THERAILMCCOY - I'll look at the keypad and resolve. 
Nehara Music/fog 
I still had the impression that during my Nehahra playthrough, fmod music didn't play all the time when it was supposed to. However, since I don't remember when exactly music needs to be played (some levels are silent on purpose), I cannot say for sure something is wrong.

Restoring fog support would be essential since the few levels in which the effect is used profit considerably regarding their atmosphere. 
Episode Finale Text Length 
Other thing:

Unfortunately, the fix for finale text length from build 15 still isn't enough for some addons.

I picked Rapture for testing since it has extremely long texts, and there the text is still cut off as you can see here. On this screenshot, 5 lines are not shown. I dunno if you can push this fix any further, but maybe if it doesn't fit on the screen you could try shrinking the font size automatically or something.

Other than that, I checked Malice map d13 once more and the crash with respawning Vasquez sisters is definitely gone. Thumbs up! 
Good Catch On Rapture 
The text is cut off in fitz085. This is rainend.bsp.
winquake is OK:

I don't know the code that draws these but my suggestion is:
- check the buffer size winquake uses
- calculate the actual height of the full message, so it can be centered on screen properly. 
It is far better to find out about all these edge cases now so they can be addressed while the iron is hot. 
Something else to think about in the meantime: Checking RRP, I get a crash to console in "Telefragged".

It happens like this:
After picking up the yellow keycard, I go around the corner and approach the yellow keycard door. Game crashes to console with a message like:

call0 2303(multi_trigger)multi_trigger()
... <-- couple of lines with subs.qc/triggers.qc etc here
(no function)
stack overflow
host_error: program error

Try if you can reproduce it with these savegames and autodemo (1.07 MB). Quicksave gets you right after picking up the keycard. Go around the corner and watch the game crash (probably). Autodemo shows the whole procedure. 
that is a known bug in telefragged.bsp on easy skill, not an engine issue 
I did a rough calculation of the text length and it comes out at ~900 chars. Now, Quake copies the centerprint text to a 1024 char buffer (in SCR_CenterPrint), so it's possible that this particular text is exceeding the buffer size and being chopped. That's possibility one.

Quake also counts the lines of text (stored to scr_center_lines) and I make it 29 lines, or 232 pixels high. Now, FitzQuake implements a GL_SetCanvas mechanism for laying out the 2D GUI elements, and centerprints use CANVAS_MENU, which is constrained to a 320x200 viewport (via a glViewport call), so anything outside of that viewport gets discarded by the driver. Add in the "Congratulations" banner and you can easily see why the text gets chopped. That's possibility two.

Possibility one is unlikely but it is nonetheless something that you should try to fix.

Possibility two is definitely what's going on here; the text is just too large for a 320x200 viewport.

Unfortunately this is a case where the mod author was careless: the same problem would occur on any engine running at a sufficiently low resolution. It doesn't occur on non-Fitz-based engines at higher resolutions simply because they don't use the same constrained viewport.

I'd chalk this one down to "bad content", of a similar class to textures containing fullbright texels, but it's up to you whether or not you think engines should support bad content like this. 
Windows GL | WinQuake - Probably fixes the Rapture end text for Open GL by expanding the canvas height to 480 or the largest it can do for the screen resolution being used while keeping the completion plaque or congratulations plaque in the same place.

@mh - Well, I'm sort of the mindset that 320x200 should be supported but also if original Quake does it then it can't really be a bug.

I am particularly interested in coop and I'm hoping to acquire ZQuake into the engine this week. In previous times, I wouldn't have had the right kind of knowledge to make this happen. It is possible I may discover I still don't. Finding out is half the fun. 
End Text With Latest Build 
With the new build, now the "Congratulations" panel shows in 5:4 modes, but text remains cut off. In 16:9 however, the panel isn't visible while the text is displayed completely.

I was trying this with scr_menuscale 1 and higher, wouldn't make any difference. 
Malice Boss Fight 
So I played the last two levels of Malice. While I didn't expect anything to go wrong there any more, it unfortunately did.

In d15 (boss map), the game seems to change your FOV, I guess as a side effect of the boss attack when he pulls you towards him or something. This effect should only be temporary and restore your original FOV afterwards, of course. However, sooner or later this causes a crash to console with this message:

host_error: bad fov: 180.000000

I had my FOV set to 105 in config.cfg before this happened, and when I checked after the crash, it was 170. it also happened when setting my initial FOV to 90, so this doesn't seem to be causing it.

Check autodemo and savegames here (136 KB)
(Last savegame and quicksave are relevant - I recommend activating godmode immediately.)

This should be the last issue with Malice.

At least, it seems pushing small crates works after all. No idea if it was something with latest builds that fixed it or I just didn't try pushing at the right angle. Main thing is you can push these crates, so I believe there is no need to look into it after all. 
Yeah sorry about that, complete oversight on my part - nobody tested in easy :[ 
RRP Telefragged 
Is there a fix anywhere for this map? Or would it be possible to make one? It's not the first time it has been requested. :P 
Ok ... I'm glad you can push the Malice crates --- that was #1 on my least favorite thing to examine because it shouldn't be related to the engine and would involve QuakeC.

Not that I wouldn't have been able to figure out a game plan, but that it would be very time consuming, especially because I'm sure Malice's QuakeC isn't open source.

Text-cutoff: Thanks for info. 
I'll Try And Make Some Time For It 
If I can't then I'll let you know. 
It's still possible to complete the map even with the bug. I just opened the yellow key door by walking backwards into it. And afterwards you have to be careful when returning to that room, ofc.
(As a general advice: Don't include stuff like resolution settings in quake.rc - folks don't like when their default config gets changed.)

Other than that, Mk V doesn't seem to have any issues with RRP. Plays smoothly. Still need to get through Mfx's map to complete the pack, though. 
Level Ending Screen 
Something else I noticed with level completion screens: It always displays "current music track" in the upper left corner when starting to play the level stats music. I think that can vanish. 
bad quake.rc files are nothing new.

I don't know that anyone, even with the best of intentions is qualified to make a quake.rc file, most of them are toxic to some extent.

Which is why I've always preferred to type -game <gamedir> in the console.

The mods that really need a quake.rc file are the highly exotic ones and it is not very helpful since you usually do not know that "R" has the reload gun bind key or "K" is use items.

quake.rc files are just basically entirely useless unless they indicate something like the preferred r_wateralpha value. 
Other than that, Mk V doesn't seem to have any issues with RRP. Plays smoothly. Still need to get through Mfx's map to complete the pack, though.

Mark V doesn't say anything 'cause there's lots of builds that may work different if you don't update every time. I still haven't played RRP 'cause it crashes on the build of mark V I tried it back then. I need to check if new version works fine with it. 
I know Baker just added the ability to load RRP maps in the last few weeks, so only the bleeding edge builds in the last few pages of this thread would support it 
RRP definitely works fine with latest Mk V snapshots. Just be careful about Telefragged on easy. 
Telefragged Patch 
I'll see if I can do this on the weekend, as well as fix a few other problems with the level, like the long drop secret and make that retarded pipe progression easier to spot. 
Experimental Features 
Windows GL | WinQuake | Source

Improved ability to handle very large finale text ("Congratulations! ...") like the Rapture.

Experimental feature for use at your own risk --- and this means if you aren't interested in beta testing and not very Quake savvy this one isn't for you. That zlib1.dll file is required because libcurl needs it and I don't have anything checking to make sure it is there.

* Ability to install mods (or uninstall) via console.

install travail (will try Quaddicted)
install (direct from any web address provided it is a standard .zip file)
uninstall travail (removes quake/travail but keeps the
uninstall travail full (removes quake/travail and removes the

The downloaded .zip files live in quake/id1/_library

This is a beta and it prints a bit more than it should when installing and so far handles things rather intelligently and in a user-friendly manner.

But I have more to do like don't be playing travail and type "uninstall travail". I also want to require the .zip file to uninstall a mod and use the .zip file to only remove files that came with the .zip. 
Just installed it... it crashes to desktop when attempting the install command 
Also New Thing 
Playing with the music a bit -

If you do cd play 2 it will play track002, you can keep doing this and it will play the tracks but without stopping the previous one. The funny thing is that cd stop only works once so you can only disable one of the tracks, the others keep playing. 
Awesome! Someone Please Port It To Linux 
someone please port it to linux
someone please port it to linux
someone please port it to linux
someone please port it to linux

Default directory for downloads is qdir/Downloads/ in the Injector I think, would be great if we synchronise.

I'd suggest "purge" instead of "uninstall NAME full" or maybe at least the other order "uninstall full NAME" or "uninstall purge NAME". That would be more normal. 
Some notes:

And I know this would be rather difficult for the Quake Injector to do but here goes:

1) I have all installed files as lower case no matter what.
2) Take an archive like It should install to warpspasm not warp. You shouldn't have zip files that need a gamedir other than the archive name. And this unarchives that way instead of honoring the \warp directory in the .zip.
3) I agree with synchronization, but I don't want the Downloads folder obviously exposed to the user.
4) I plan that in coop, a server can just transmit over the archive to the client and live install. Mark V as a server already stuffs in a hint to the client that tells another Mark V client to change to directory like -game warpspasm -quoth.
5) I also plan to try to disallow any external archive having the same name as a Quaddicted known archive and refusing to install it.

I have plenty more hammering to do.

@fifth --- at the moment, I don't have another computer available so this really hasn't been run on anything except my hard drive. Thanks for the heads up on the cd play command. 
Rapture Texts 
Latest build definitely fixes Rapture episode ending texts (and with that most likely also Nehahra or any other addon with the same issue). In some video modes, it requires even the very last line available, but all characters remain visible. I only checked with rainend, but I doubt any text is longer than there.

Currently still on my wishlist (unless I find more):
- Shrak texture issues
- Malice d15 fov crash 
Had a quick go at using the install feature.

-'install' then hitting enter is fine, normal command/cvar explanation is printed.

-'install modname', where modname is the name of a mod present on Quaddicted, results in a crash.

-'install' or any URL I've tried so far results in a crash.

In fact entering anything after 'install' seems to result in a crash.

-'uninstall' then enter is fine.

-'uninstall modname' seems to work fine.

-'uninstall modname full' removes the mod directory, but not the zip in id1/_library. Since install wasn't working, _library was obviously manually created and a zip manually placed there to test, so perhaps that's an artificial way to test it. 
When you are already starting with zipfile stuff, why not also provide support for loading zip/pk3 files in general? For me at least, that would make things easier when adding mods. Always opening Pakscape to group stuff together sucks. And additionally, maybe music files inside PAK/zips could finally be recognized. :P

And I forgot one thing in my "wishlist":
- Music track playing msg when exiting level to be removed 
1) I have to be honest that I don't fully understand that log now but if I closed it I guess it is not a crossplatform solution to lowercase everything.

2) You know the pain of my Quake life... I need a time machine to get back to the 90s, take over idgames2 and have it prosper with my nazi standards.

Do you support HTTPS or are you using the QI user agent as workaround? I'd need to add a comment to my config so I don't lock the engine out once QI gets a new release. 
Overengineering Is Fun 
a few things regarding this install command:

why not get the engine to directly load the paks etc from the zip file? (especially good when you consider downloads from servers).

(@NightFright: compression within (most) pk3s means that you need to rewrite half the engine to use calls that can either read from a memory buffer or decompress the file on demand. pak files have no compression and are typically opened simply by re-opening the pak and seeking to an offset. I suppose that decompressing to a temporary file that will be automatically deleted would also work. Either way, it isn't a bolt-on feature and can be quite daunting, at least if you want to do it properly.)

how do you update when a new version is available? 'uninstall foo full;install foo'? you'll lose your configs/saves/etc
(this is also incredibly relevant when considering random quake servers running different versions of a mod)

never trust the filename in a url. some examples: (evil huh, note that nvidia drivers will obligingly attempt to load a whole load of dlls from the working directory)

use the user's home directory instead of the quake dir for the Downloads path. Noone will ever find it there!

stuffcmd(self, "uninstall id1 full\n");
also, aliases.
nuff said.

console commands have almost no discoverability. if I don't know the name of a package, I have no way to install it. eg the install command needs a way to list all packages with 'rubicon' or something in the filename or description (apropos style or something).
also, needs a menu so you can easily delete everything.

replacement/generic content like texture packages shouldn't need a -game

map packages will often have a dependancy upon an existing mod, and should be installed in that mod's gamedir instead.

I did consider doing something similar myself, but I ended up overengineering it to be too weird for anything but standalone mods. oh, and I didn't bother with an uninstall option (partly because of the problems with multiple versions of a mod needing to be installed in order to cope with servers running different versions of the mod, as well as mods potentially requiring generic/shared stuff like texture packages).
hence fte's .fmf thing. 
@spirit --- I'm using the QI user-agent like you told me about.


utilities.c in the source is loaded with several common sense sanity checks and I mention above having a "todo" where the uninstall only uninstalls via the source zip to see what files came with the mod, leaving user content to the user.

There isn't anything new here, the Quake Injector has done this for ages, here is its xml database.

Someone wanting to do things the old fashioned way isn't prevented from doing that.

The "install" command merely intelligently unzips a file the way you or I could without reading the readme.

- If it sees a .pak or a progs.dat it goes to it's own gamedir.
- If it just contains .bsp files, should go in the maps folder.

Installing an unknown zip into place is relable, but the game parameters and other settings remain unknown. Someone may still need to read the readme to get an unknown mod running.

Having the engine read Quaddicted's database will help it with the rest for known mods. And soon enough it will auto-complete from Quaddicted's database.

Unknown mod? Wrong version? You can install by hand the way you do it today.

I agree with the replacement content shouldn't be a -game but some separate layer.

But ... Most important thing is to get another update out after testing on another computer. I suspect I have a dependency in my Windows $PATH that didn't make it into the .zip 
@spike part 2

Searching by word. Agree. Quake Injector lets you do this.


Probably an update tomorrow after I test on a few machines and do a revision. 
Experimental Build #2 
Windows GL | WinQuake

Experimental build #2 with ability to install directly from Quaddicted or a web address.

I've run this on (2) Windows 8 machines as verification in addition to my Windows 7 laptop that the download function works. (No longer uses libcurl for downloading the archives, so no external .dll files needed.)

Also fixed: cd play bug reported by fifth and a couple of things railmccoy pointed out when he simulated installation.

To install something from Quaddicted or a web address, type something like:

] install rapture (Will try quaddicted)
] install (direct from web address)

Also can uninstall and likewise this is experimental.

] uninstall rapture (removes quake/rapture gamedir contents and folder, but leaves available)
] uninstall rapture full (removes the as well)

More refinements need to be done ... 
I'm going to figure out a way to make content replacement easy for you.

I don't know the exact method, and it maybe a couple of weeks before I sort that out.

But it would be nice to make conservative classic Quake replacement content available to more people and do it easily. 
Level Ending Msg 
Take your time with that. Main thing right now is to fix any remaining issues (or those which may still be found).

I am still wondering why that "Current music track" message pops up on the level ending screen, and it's always track03. Even if no music is played, regardless which addon. Weird. 
Played around with install a bit more and encountered no bugs, other than a crash that occurs when you input an https URL.

I have a few general feedback points as well. Firstly, while not really a bug, it seems strange that it gives you the impression of downloading something if you feed it the name of a file that doesn't exist; eg 'install sthashahaeg'. Would probably be better if it just informed you that such a file doesn't exist.

It also seems inconsistent that the feature allows you to install certain types of files (eg maps as opposed to mods) but doesn't let you uninstall them, just the archive. Related to this is the absence of autocomplete for the zips. Maybe an uninstall_zip command?

I suppose there are arguments both ways - for keeping the simplicity of confining it to just 2 commands, install and uninstall, and keeping it to just folders rather than all kinds of loose files versus giving more complexity but greater consistency and a fuller feature set.

The other thing I noticed is how much good feedback it gives you, with clear descriptions of the features when using them, and useful notices when you use it incorrectly. It would be nice to see this extended to all cvars and commands in the engine, similar to the level of info DP and FTE give you when using the console.

Also, as Spike says, autocomplete and apropos/find for the Quaddicted archive seem like essentials, and this would then seem an opportune time to extend that kind of discoverability to all cvars and commands. 
Quaddicted needs an API. Any programmers here? 
Is It Just Me 
but it seems FMv has turn the wrong direction.

Why in the world the engine has to install the mods instead of you?

i don't get it. What's next, the engine that playing the game instead of you're?

there's more and more similarities between this engine and DP (no double penetrate confused) 
I could add a command line parameter that disables those 2 commands.

The main purpose is to allow the Quake server in a LAN coop game to share the archive to other computers.

Instead of downloading each map, model, sound.

Which doesn't work for single player releases because:
1) Skyboxes. QuakeC doesn't know about these.
2) .lit files. QuakeC doesn't know about them.
3) Other misc files that are part of a single player experience that is a .mdl, .spr, .bsp or .wav

I know most people don't care about coop, but it is a major interest of mine. 
This is actually a Very Good feature.

For the likes of you and me it's unnecessary. For the casual player or newcomer to Quake it's absolutely essential. Installing mods, making sure you get the right files into the right directories, setting up dependencies - these are all huge barriers and while you may think they're basic enough, you'd be surprised at how much difficulty the non-technical end user can have in getting them done. Even something as simple as getting the engine executable into the correct directory is something I've personally witnessed people having trouble with. 
Install Command Now Seems To Work 
Pretty nifty feature, not entirely sure if I will use it really since you have to know what you're looking for beforehand. If there was a way to browse before you install.

Could be worth having a list feature, maybe "install list"? While we're on the subject of lists, I can't remember which engine had the feature but it'd be cool if there was a way of having things in the console have rows/columns rather than say 1 item per line. (like if you remember in DOS you could put /p /w and it would fill the screen so you didn't have to scroll so much). 
i'm really sorry for my expression. 
For the casual player or newcomer to Quake it's absolutely essential.

Actually i'm not sure the newcomer that never installed the mod in a "proper way", would install the mod via console command using the engine. 
A feature that definitely IS for newcomers is the "Levels" menu option. I absolutely love it since it makes level packs that come without start map (e.g. one of the Retro Jam releases) very easy to use. You can choose any map without using the console at all.

The bottom line is: If you really want the feature to be accessible, it may need to work via the game menu. 
How many newcomers does Quake 1 get these days? 
More than usual, just judging from this thread.

I don't really agree that a menu option is top priority, though. 
Kind of interesting to reflect on what you'd want to do to make a perfectly accessible engine for a newcomer to Quake; say someone who took up gaming in the last 5 years and only has experience of Steam.

You'd probably want to ensure that they never have any interaction with the directory structure, the command-line, configs or the console. That's basically how Steam functions, even if you're playing a game with mods. You just launch the game through the Steam UI, and if you want mods, you just double click stuff on the Workshop and it all installs automatically, never leaving the Steam interface.

So for Quake, you'd want the source port to come packaged in an installer (a single exe in a single exe sounds absurd, but as mh said, putting the engine in the right place isn't necessarily obvious to a newcomer to Quake) which the user just double clicks and it detects where Quake is and puts the exe in the right place, then creates a shortcut on the desktop. Maybe it could come packaged with Quake Injector too, as a means of ensuring that downloading and installing mods is all menu driven, rather than fiddling with rars and zips and the directory structure, with the Injector also creating its own desktop shortcut.

Afaik Quake Injector doesn't have any means to set up the correct command-line switches automatically though, so that would be an issue. I know some engines - FodQuake for sure - do away with the command-line entirely, so instead of having -heapsize etc, it just allocates memory correctly on the fly. That would probably solve a large percentage of command-lines required by mods.

Another interesting idea would be to actually get all that on to Steam through Greenlight. There are various old HL and HL2 mods up there now which you download directly through Steam servers, and Valve's long term plan is to allow basically any kind of software on Steam, so it'd be an interesting first to see if a source port could end up on there. =)

That way people who have Quake on Steam would likely find themselves directed through Steam's recommendation system to any custom Quake engine available on Steam, rather than being stuck with broken glQuake or having to trawl round the web searching for engines which they won't know how to install.

If something like that was in place, you could play Quake and any mod without ever touching anything other than desktop shortcuts/Steam UI and in-game menus, which would certainly make Quake future proof and more accessible to a wider audience. 
Finished Tests 
I see that some silence has returned to this thread. :P

Well, just dropped in to say that I am finished with my basic Mk V testing sessions.

I checked these:
- Quake + mission packs
- Nehahra
- Travail
- Shrak
- Malice
- Abyss of Pandemonium
- Beyond Belief
- Honey
- Rubicon Rumble Pack
- ne_ruins
- Rapture
- Soul of Evil
- Soul of Evil: Indian Summer
- In the Shadows
- Retro Jam 1-3
- Func Map Jam 1+2

Good news: No problems with any of these actually - besides the remaining issues with Shrak (white skin textures) and Malice (fov crash in map d15).

I will check some Quoth and Drake missions, but I am confident Mk V will do fine here, too. :) 
I'm glad to hear it!

Haven't had much to talk about because I've been working away on the to-do list and items in this thread.

But I'm only about 70% done, so late next week is likely when the next version will be out. 
How do I load from the autosave? I press F9 and it loads from the manual quicksave. 
Type load and the press a and then TAB.

You'll see a0.sav, a1.sav and a2.sav

(I need to give them better names but initially I didn't call them auto_save because some single player releases with autosave tend to use a name like auto_save.) 
a0 = newest, a1 a few minutes older, 2 a few minutes older than that. 
should probably load the latest autosave... Or the last autosave should show up in the load menu. Either/or will do. 
MarkV Vs Quakespasm 
The last Quakespasm update at Quaddicted says Baker ported a MarkV feature into Quakespasm. I know he's involved in both projects. So, what are the differences between them? 
MarkV Vs Quakespasm 
I am sure Baker can tell you all the differences instantly. For me, the most important difference is actually that Mk V can run Nehahra. And that's amazing.

Hoping that Baker eventually gets back to working on the new version. Still waiting for the Shrak/Malice fixes. ^^ 
Yah , Nehara is good.

MarkV is a windows project, with more experimental/fancy features. QS is multiplatform and, perhaps, more solid. 
Is the fog problem in Neh2m5 fixed? 
Is there any way to limit the game fps to 72 without syncing to the monitor refresh rate? My monitor only does 60 Hz. Also, with vsync on, there's some weird lag going on.

DirectQ has this feature, but unfortunately, it also has an annoying issue where the player will start sinking into the floor after some time of playing. 
Host_maxfps should do it 
Thanks, that's it! Still unplayable with it set to 72 though; quite jerky. I guess I won't be playing e3m2 with this engine. Everything else seems fine though! 
WinQuake Mark V 
The software stuff is really exciting because it's the only software port besides super8 that can load big maps and it's much more faithful than super8. Do you plan on adding the interface scaling from regular Mark V/QuakeSpasm? The HUD is unreadable at 1920x1080.

Come to think of it, if you could implement colored lighting, interface scaling, and fog into the WinQuake Mark V executable, it would instantly make super8 obsolete and it would make me very happy indeed. 
Any news about a new build, btw? I am still waiting for those Shrak/Malice fixes (see #826 and #855). :P 
Weapon Model And (colored) Lights 
How does the engine define the intensity and color for weapon model to apply? It seems to me that is checks the light value only without checking delay or wait values of the light entity. So if I have a light source with high light value but with delay and wait adjusted so that it's bright only near the source my weapon shines although the walls are dark.
This screenshot shows the problem: there's a orange light source with 800 light value underneath (the floor is func_door, so it doesn't block the lighting) but delay and wait (and other) values make it barely noticeable at this distance. While my weapon model thinks that there's a light with plain light 800 that affects it.

Is it possible to fix this? 
I think that's the just Quake's simplistic lighting for mdl's. AFAIK, the engine traces a line downward from the entity until it hits a floor surface in the world model, then it samples the lightmap on that surface. So the engine doesn't ever look at the light entities or their light/delay/wait values, just what's baked into the lightmap. 
from what I see light value affects mdl lighting. Here's the screenshot of the same place but with 300 light value:
weapon doesn't shine that bright.

That's why I think it might be possible to fix.

btw that's surface light. 
quake uses the light on the (worldmodel) floor straight downwards from the model to determine lighting -- even if that floor is quite far below the model. if the floor below you is bright red, that explains it. 
that makes sense. any brush entity floor breaks it =( 
That screenshot makes me want to add a lightgrid to .lit2, and to revive .lit2... 
Ironically, I had a "fix" for that that was in very early Mark V versions, which I removed.

But that would be a lighting change and I'm sure random obscure map X, Y or Z might have a spot where the lighting would be different than expected. 
I wonder if it is possible to make it switchable via console command. So the default value is classic light behaviour but a mapper can add a note in readme that recommended settings for his map are the following (including this new command). Or he can place it in quake.rc 
Your problem is caused by what metlslime says.

You have the opposite of the "black scrags against a bright sky" error, where people place scrags out at a distance but do not light the floor below them because it isn't visible to the player.

The scrags appear solid black even though the sky is full bright and the area up where they are may be well lit. This is because the floor far below is in darkness.

Any floor which is an entity, such as func_wall or door/plat, is not used for lighting models. The engine keeps going down until it finds solid geometry. 
adding lightgrid (or something like it) to lit2 seems like a good idea, because any fix that uses the normal bsp or lit lighting will break expected behavior of old maps. But no old maps use lit2, so it's a fresh start. 
I guess but I couldn't promise a time to do that.

To change the light point, I had to change the entire lighting collision section so that it would also collide with brush models.

It's very messy having 2 different ways in the code, especially for collisions.

I bet DarkPlaces does the collision with the brush models as the normal way to do things.

As an alternative, you could poke around and maybe one of these has it: 
Yeah, changing the lighting --- even a subtle change like that one --- can make scrags in the shadows bright --- or make scrags that you are supposed to see obscured in darkness.

Probably doesn't happen on id maps often as they didn't do anything crazy, but custom maps like void maps and such .... 
Can't Believe It! 
I don't know how I managed to miss the last couple of builds!

The WinQuake Mark V is virtually perfect. Being able to play Nehahra on a modern engine in software with MP3 and controller (after a couple of tweaks) support is just brilliant. My netbook says thank you!

Now, when are you going to add 5.1 surround sound? :P 
Interesting to know the joystick support works.

I re-added it, but have no joystick to test.

Now, when are you going to add 5.1 surround sound?

Probably never. Honest question, honest answer. 
Mp3 Music 
doesn't work for me. MP3s are placed in id1/music, external music is on but no music, no warnings. what did I miss? 
Oh well. Thanks for being honest. :)

Yeah, I've got a DualShock 4 running under DS4Windows as an X-Input device. It works great. Two of the axes are switched from WinQuake and, of course, the z axis triggers aren't recognised but other than that it's fine.

Should I upload my config for other? Can I do that here? 
You could paste relevant portion here. At some future point I could investigate. I don't see Mark V being updated for a while. 
It should say something like "Playing id1/music/track001.mp3" or "Track id1/music/track01.mp3" not found.

Which does it say? If it says "Playing ..." and it isn't working, check both the music volume slider and the volume slider. If it still isn't playing, then I don't know --- Fifth had some issue like that and then he did something and it worked. 
It should say something like "Playing id1/music/track001.mp3" or "Track id1/music/track01.mp3" not found.

That's the problem. I searched for my problem through this thread and everyone mentioned that it should had been a warning about that. While I don't get any warnings at all. Is there any console command to switch on/off music or anything else I have missed? External music is enabled in options, sound and music volume sliders don't make any changes.
I'm confused. 
Music has worked for me since one of the newer builds. I just assumed that you had figured out the issue and fixed it... directory structure and file naming is
1. I created a new folder "Quake"
2. I created a Quake\id1 folder
3. and copied pak0.pak and pak1.pak in there.
4. I created a Quake\id1\music
5. Copied an mp3 as Quake\id1\track04.mp3

Using this latest Mark V beta for Windows (download)

I have no config and there is no command line. I start Mark V and do single player new game so I am on the Introduction and it says

Using protocol 666
Current music track: music/track04.mp3"

And the music plays.

So no config, no command line, current .exe that's what it says with a valid mp3 in Quake\id1\music\track04.mp3 on the "start" map. For me. 
correction ---> quake\id1\music\track04.mp3

(I typed it wrong the first time) 
I repeated all these steps with new quake folder etc (btw I've discovered that I've been using previous build (from 20150426) while having the latest one downloaded).

After all I got:

Using protocol 666"

And no music.

That's with clean quake and the latest mark v. 
Are you using a command line that has something like -nocd or -nocdaudio or -nosound or something?

It either prints that ...
A) it found the track
B) it didn't find the track

It seems you have the music disabled somehow. 
Missing/incompatible DLL/codec Perhaps? 
It doesn't say something like "ERROR - Could not initialize COM library" if you scroll up in the console does it? (Seems unlikely)

Also: Type "developer 1" in the console and then type "map start" and it will print out "too much detail" but might give you a clue and will print music messages like if it found the file.

About all I can say. 
I'm Having A Similar Problem With Music In Mark V 
and the tracks play just fine in quakespasm. In mark v, the message about "current music track" displays for me as well, but no mp3 is playing. 
Controller Config 
To anyone who's interested here's the controller configuration I use.

Just copy the text below and paste it into a new text file. Save it as "controller.cfg".

Then just add the line: "exec controller.cfg" to your autoexec.cfg in your "Quake\id1" folder.

Copy text from here:

joystick 1

joyname "Controller"

joyadvanced 1

joyadvaxisx 2
joyadvaxisy 1
joyadvaxisr 4
joyadvaxisu 3

joyforwardsensitivity -1.0
joysidesensitivity 1.0
joypitchsensitivity 1.0
joyyawsensitivity -1.0

joyforwardthreshold 0.15
joysidethreshold 0.15
joyyawthreshold 0.15
joypitchthreshold 0.15



// JOY1 = "A" Button
bind joy1 "+speed"
// JOY2 = "B" Button
bind joy2 "impulse 1"

// JOY3 = "X" Button
bind joy3 "impulse 12"
// JOY4 = "Y" Button
bind joy4 "impulse 10"

// AUX5 = "Left Shoulder" Button
bind aux5 "+jump"
// AUX6 = "Right Shoulder" Button
bind aux6 "+attack"

// AUX7 = "Back" Button
bind aux7 "+showscores"
// AUX8 = "Start" Button
bind aux8 "pause"

// AUX9 = "Middle Left Stick" Button
bind aux9 ""
// AUX10 = "Middle Right Stick" Button
bind aux10 ""

// AUX29 = D-Pad Up
bind aux29 ""
// AUX30 = D-Dad Right
bind aux30 ""

// AUX31 = D-Pad Down
bind aux31 ""
// AUX32 = D-Pad Left
bind aux32 ""

To the line above!

PS: I realise most of you will know what to do with the above text. I just thought it prudent to add some simple instructions for those not familiar with such things. :) 
Consistent Crash In Abyss Of Pandemonium? 
The game loads fine but crashes every time I pick up and shoot the incendiary grenade launcher at the Death Knight as found in the first secret area in the first map.

I'm using the latest build from above (20150508) on Windows 7 Pro 64 bit. 
Mark V uses DirectShow to play MP3 using hardware acceleration. Because DirectShow is part of Windows, there are buried settings in the control panel audio settings or even sometimes Windows Media Player (volume per file type) that might affect it.

Your Abyss of Pandemonium issue might be related to Shrak invalid skin bug. Whenever in the future I do an update to Mark V I'll take a look at it. 
Shot In The Dark.. 
Given that it's DirectShow, it might be worth running that DirectX Web installer (from Microsoft.. don't have a link handy.)

A while ago, I was getting a missing d3dx DLL error when running DirectQ on a fresh Windows 10 install, and running that web installer fixed it. 
AoP Follow Up 
I tried AoP with the OGL version of Mark V and it works fine. It only happens in the WinQuake build.

I tried Erics suggestion in the hope that it was indeed just a glitch in the matrix but the issue's still there.

Anyway, just thought I'd let you know. :) 
In developer 1 mode I get this (map start):

Using protocol 666
CDaudio: Bad track number 4"

I get a feeling that it doesn't even try to find mp3s.

I've inserted an audio cd and checked. With external music off I get no "CDaudio: Bad track number n" warning but cd music doesn't play either. Though that cd plays well in windows media player.

I need to investigate in on my pc at work. 
Since I've very much enjoyed some of your past maps like Menk, I tried to think of some solutions outside the box.

But the problem you are having is "outlier".

(i.e. the particulars of the problem you are having don't match anything anyone else has had in a thread over 3 years old.)

So I don't know and I can't think of any helpful advice. 
Well, hold on ----

In Mark V, a CD track > mp3

It assumes if you have a CD in the player, you intend to use it.

CD supercedes MP3.

Answer: Don't have a CD in. 
That makes sense. I think the cause of the problem is that I have a virtual drive, that has a letter prior to the physical cd drive. So Mark V thinks that I always have a cd in my drive.

Music plays fine on my pc on work where I don't have any virtual cds.

Thanks for such investigation. 
Then what does "external music" option do? Description says that you can choose what to play, cd music or mp3, while actually CD always supercedes MP3. 
external_music 1 or 0. Determines if a music track (CD or MP3) will attempt to play. 
The info that the your AOP problem is specific to the software renderer (WinQuake) is helpful information.

WinQuake and GLQuake have different little problems with non-conforming maps, models, textures.

There is some map Madfox made with Q3 skeletons and on the bridge there are some non-conforming textures, for instance, that look ok in Open GL but break the Quake texture spec so bad that in WinQuake they are totally wrong. Nehahra on the 3rd, 4th or 5th map has a BSP with a severe bsp/sky texture irregularity that affects both WinQuake and GLQuake and somehow not DarkPlaces. Probably used what would be considered by Func_Msgboard a very non-compliant map compiler.

Fortunately, these problems are very rare. 
It Works! 
I changed the letter of the virtual drive so that physical cd drive is the first one and mark v started to play music after this.

Thanks for guiding me towards the right direction. 
Sock Tries Mark V WinQuake 
Sock tries Mark V WinQuake. Mind blown!

"OMG! WinQuake how could I forget you! MarkV Winquake from Baker, #quake pixel heaven!"


Sock, if you read this, I used Zendar and Metal Monstrocity as the primary testing targets for the WinQuake version of Mark V. 
Sock has taste. But I knew that already. 
@Sleepwalker/Mac Version Re:Twitter Link 
Sleepwalker: I just wish it ran on Mac...

There is Mac version of Mark V WinQuake.

Mark V GL | WinQuake Mac

And both of them play Nehahra --- on the Mac.

(I've just never had the time to wrap up Mark V to get to where I want it to be a for 1.00 release. NightFright pointed out an obscure bug in Shrak for Quake and I have some other Q and A I wanted to do ... who knows when I'll have the time though ...) 
dooooo iiiiiiit 
Lunix would be a Lunaran distro? 
There is a Linux build on my hard drive but just of the GL build.

I wanted to convert over the software renderer version too, wasn't sure of a right approach to do it fast, and somewhere around that time, I didn't have the time to work on it any longer. 
I Can't Seem To Get Mark V Winquake To Work. 
It just crashes on startup. Is there something I'm missing? 
check vid_width / vid_height in your config.cfg, maybe they're set too high for winquake? try a clean config maybe 
Quick Question 
Are fence textures on .mdl possible? 
I suspect you probably could make palette entry 255 a mask.

I assume this would come with its own problems, you can see through the other side of the model completely (as it wouldnt have a back-face) and would limit what you can do with it. Some models might use this colour as its a skin-toned colour. My guess is that the flame textures use it. So you'd probably have to redo some of the textures for certain models.

Maybe the engine would be able to recognise models that should be masked, perhaps using some kind of naming convention on the model? Is it possible that external textures could be compatible with models? You could create a number effects this way. 
No luck, still crashes on startup, I've got quakespasm already installed, do I need to download Mark V from the link on the OP? 
I'm thinking vegetation.

Imagine a modelled tree with branches, and a bunch of quads plastered on it with "fence" leafy bits and whatnot.

Also cross-quad grass billboards. That sort of bojangles. 
sounds like what you're actually looking for is lit sprites.

can we have lit sprites? only problem with that one is that most sprites are supposed to be fullbright, but sprites used for foliage and such need to be identified in some way to let the engine know to apply lighting levels to them. 
sounds like what you're actually looking for is lit sprites.

no, not really.

I'd rather have one entity to represent a big bush (hehehe) made of many quads all in one .mdl, than add 50 separate sprite entities - one for each quad. 
oh ok, when you said billboard, i figured you were just going to create a bunch of 2 tri models with a transparent texture on it. :P

but yeah, now that max edicts is 32k... doing leaves with sprites is doable.

whether or not it should be done is another question, but it might be work trying?

you could use qc to generate the leaves on certain parts of the model; would make it so trees look slightly different? 
It's an interesting idea but even if it is technically possible given a high enough max_edicts, the sheer principle of using one edict per vegetation quad makes my eye twitch. It just seems like we should be looking at more sensible/efficient ways of doing it.

Doing it with unlit sprites would suck anyway. 
actually, while we're dreaming... if we could get a bump up on the max number of static entities, we could make each foliage static and make it not use edicts at all! 
I guess to be fair the only way these sorts of feature requests get any traction is if there's already a bunch of well-made assets ready to go that a lot of people would use.

Making a bunch of quakesque vegetation models has been on my list for a while, so I might as well just start making them and then bully the engine coders into supporting alpha on them afterwards :} 
if we could get a bump up on the max number of static entities

It's actually quite silly for an engine to have a fixed-size maximum for these in 2016. Static entities can be just allocated on the hunk until memory runs out; don't need to come from a separate array at all. Likewise with efrags. 
Alpha-tested Models 
hexen2 supports it. There's some model flag you can set that enables it (but tools may not provide you with that option, and might necessitate using some hex-editor).
afaik FTE is the only quake engine that supports it at this point in time, although if you're targetting DP, you can use shaders with some 'alphatest gt128' line or something, along with an external texture (iiuc an external texture alone will enable alpha blending, which will look a little ugly if they overlap).

#define MFH2_HOLEY (1u<<14) // Solid model with color 0
so byte 0x4E should be set to 0x40, assuming I counted correctly.

clientside limits on static entities are kinda silly (and implies wasted memory).
serverside limits on them due to the signon buffer size are harder to remove, although not impossible. 
Trying deleting your config.cfg. Are you using an old version of Windows like XP or something?

I made a couple of tough choices in very recent version that may affect old, old Windows versions. 
@Kinn - I think your ideas are interesting but at least for 2016 ericw/Quakespasm are where your best chances lie.

That being said,

Check this out:

That modified FitzQuake engine already has that feature, it's color 255. 
@Kinn: It's the trees with alpha masked textures.

Mod screenshot 
@Kinn - 3 Of 3 
Kinn I guess what I'm saying: If you make a model with alpha masked textures and it works in that FitzKurok engine that I posted (you should be able to play with the model in that engine), ...

My recollection is the modification is not that difficult, but in the engine code for that model, the alpha masked model names are HARDCODED. i.e. look through the game data pak file and find the alpha model name (is it bush.mdl? tree.mdl? but whatever it is, use that name and there may be several).

The key thing is I would obviously not have the model name be hardcoded, so how to indicate a alpha masked texture? The quick and dirty version would be something similar to r_noshadow_list, r_nolerp_list or whatever those cvars are called and make a r_alphamaskedmodels_list or whatever would be a good name. 
a bunch of well-made assets ready to go that a lot of people would use

Sock has some really nice ones: 
Baker - thanks very much for that! Looks interesting, I'll have a play with that :)

adib - sock's foliage assets are great for Q3, but I would want to be making stuff that fits in with quake's established chunky-pixel aesthetic. 
@Baker: I'm Using Windows 7 
I might try deleting the config. 
Checking to see changes involved:

Engine modification requires:
1) Creating a color table for alpha masked textures (probably already exists since QS/Mark V both support this for the .bsp)
2) A method for specifying if a model's texture should be an alpha masked. (Sadly, since some rare models do use color 255 in them ...). Options cvar list var, external file, model name, somehow adding more model flags to a .mdl (like blood trail). Default option is probably creating a cvar with model names like the existing r_nolerp_list.
3) Checking such a model's texture for actual palette index 255 alpha masking, and if not disabling it.
4) Turning on alpha test during draw for specified models, then turning it off. Since GLQuake model lighting and FitzQuake overbrighting is just a color modification, no other drawing consequences.
5) Permitting external textures to have an alpha channel for models where alpha masking is indicated. 
Cheers, sounds reasonably doable ;}

2) I guess a list cvar fits in with the existing list stuff. To ensure that everyone gets the list in my mod even if quake.rc doesn't run (e.g. if someone loads the mod from the console), would it work if I did a stuffcmd from the QuakeC? 
I'd rather Spike suggest a better solution than the cvar list thing. ;-)

I hate the cvar list thing. Consider it an ugly placeholder until someone comes up with a better idea or a standard.

So consider the cvar list as a temporary placeholder until someone comes up with a great idea. 
Spike says something about a model flag that Hexen 2 uses above. Hmmm. 
I'd personally be down for using a new flag (like blood trail).

However that requires tools that would support it. It personally doesn't bother me in the slightest as I bang out .mdls from blender using a script that I can easily edit. 
For existing tools (QME) to conveniently work, I would personally opt for checking BOTH a rocket trail and grenade trail (selecting multiple trails is non-sensical in the engine, it only uses the first trail flag).

In model.c in model load, engine authors can just add a

if (model->flags & (EF_ROCKET | EF_GRENADE) == EF_ROCKET | EF_GRENADE ) model->flags ~= EF_ROCKET | EF_GRENADE, model->flags |= EF_ALPHA_MASKED;

A non-supported engine it's going to render horribly wrong anyway with pink everywhere.

This would allow QME to be able to edit the flag, instead of putting terrible burdens on mappers.

/One thought ... Spike said only FTE has a mechanism currently. 
QME lets you set any flag I think, not just the ones in use...

So, using an unused flag might be ok, even for people who for some masochistic reason use QME to make mdls. 
Awesome, did not know that!

Methinks Spike may not have known that, I didn't like the "must use Hex Editor idea". 
Looking Through Spike's Source Code 
and reading his above comment,

looks like 0x4000 (16384 decimal) is the flag that would be most compatible with FTE. 
Sometime in the next 24 hours I'll grab bush1.mdl and palmleav.mdl (a palm tree) from Kurok, edit the model flag in QME and post a Windows OpenGL .exe Mark V with the implementation. 
Holy Mother Of 
I'd better get my modelling trousers on 
Another possible way to specify that the model should be alpha masked is making the skin name start with "{". Hexen2's TEX_HOLEY model flag (16384) seems OK though. Are hexen 2 and quake mdl's the same format, aside from extra flags used by h2?

I was reading the uhexen2 source, it looks like both palette index 0 and 255 are transparent for TEX_HOLEY, at least in uhexen2. But we would just use 255 since that's what is used elsewhere in quake.

Last thing: it might be worth comparing this with a different approach: trying obj2map's new UV/texturing import feature, and then either compile the foliage maps to bsp (disadvantage: lighting would be static) or even try using itendswithtens's new map instance inserter tool to automate pasting prefabs in your map (?). My light tool can even raytrace through the fence textures properly, giving natural shadows under trees. This route is likely more of a pain to set up, but it would have the advantage of working in all the engines that already support "{" textures. 
Quake loads up a hexen2 .mdl fine. Other than that, I don't know how the formats differ.

I'm thinking of making the foliage move in some cases, so bsp wouldn't be great for that.

Also I just don't think bsp feels right for the sort of geometry I have in mind.

Also: plant monsters. 
killer hedges / vines.. looking forward to seeing this! 
Alphamasked MDL texture support has existed in Makaqu for ages, and Super8 inherited it.

I've also implemented it in the x86 ASM version of the MDL drawing code, for fast performance. 
So far, I've deleted the Config, and It still crashes on startup. Is it not compatible with Windows 7? 
@kinn - Alpha Models Build 
Experimental Windows GL Build with alpha texture support for models (with changed source files)

Palette 255 is transparent color, model must have flag 0x4000 set in the .mdl QME 3.1.

A test mod is supplied. Type in console:
"game alphamaskmodeltexture; map start" and watch the lavaball in the HARD hallway which has been replaced with palm leave .mdl.

And looks like this:

@ Breezeep_ 
I develop on Windows 7. I don't know why you are having the problem, somewhere around 100 ppl have used Mark V WinQuake.

If you are committed to helping me identify the nature of the problem, I might be able to get it running for you if you are willing to post logs and such. I think in another thread Skiffy said he had a problem like yours.

Let me know. 
@ericw, @mk 
@ericw - agreed, heh.

@mk - that's awesome that Makaqu has that feature already. Even more awesome that you have asm for it. 
Wow, that's perfect. Thanks so much for this!

I'm going to be making a lot of assets that showcase this in my mod. Might even be ready for the 20th anniversary expo! 
ok, i'm sold. that looks terrific! 
@necros -- updated the above download raising max static entities from 512 to 8192.

Client-side entities are very small and just keep track a couple of dozen numbers/positions/times and the static limit was just an array of client-side entities and nothing more.

(MH and Spike point out other limiting factors.) 
@necros -- updated the above download raising max static entities from 512 to 8192.

One would hope that at some point you'll drop the array and just Hunk_Alloc each entity_t as each static entity comes in. 
I know how to do it, but until classic-like Quake engines implement "add static entities at any time" for dead monsters and gibs and the like, static entities is basically just a fixed array that happens during connection to the map.

Compounded by: what if a monster died on a lift or temporary floor -- since static entities don't move? And then if you fix that, you break standard Quake physics.

And the entity_t struct stores a ton of lerp data and other things that don't apply to static entities --- which never move. I killed the grunt on the opening bridge in Metal Monstrocity and then shot the bridge release and then was slightly distressed that his body just floated in the air, but in DarkPlaces he'd fall into the pit when the bridge is gone.

Optimization and Quake can be a paradox or at best a rabbit-hole with no known end. Proof that Quake was made by an HP Lovecraft monster and somewhere Cthulu is laughing ... 
wait, what? monsters don't get made static when they die.
monster corpses float in the air only because the fl_onground flag doesn't get cleared so the engine ignores it when doing physics updates. Darkplaces probably just fixes that behaviour. 
actually wait... if a corpse floats in the air when a lift goes down, that's some kind of bug because corpses DO go down with lifts and such. maybe a corner was on the ledge? 
Monsters don't get made static when they die.

I was arguing that in some ways, they should.

If standard QuakeC exposed the ability to make create new static entities at any time like DarkPlaces permits.

Then QuakeC doesn't waste time performing physics or sending network traffic on dead monster bodies.

(Then I mention the problem with this is that if you make dead monster bodies static entities --- they don't experience physics and some places they should). 
attachments could be used on static ents so that corpses could move with the platform.
which would work fine until the platform is killtargetted and then spawned as something else... yay corpses riding your nails!...
might be fun. 
...until classic-like Quake engines implement "add static entities at any time" for dead monsters and gibs and the like, static entities is basically just a fixed array that happens during connection to the map

Hmmm - I'm not sure how this is potentially a blocker.

To be clear, the suggestion to just Hunk_Alloc each static ent as it comes in is nothing to do with being able to makestatic at any time.

It's to do with (1) removing the limit on static entities so you don't get in an arms race with mods, and (2) saving memory while doing so.

Both of which are IMO useful and essential things to have in any engine, irrespective of presence or absence of other features. 
sizeof(entity_t) = 336 bytes on 32-bit (pretty small size). 336 bytes x 8192 statics = 2.7 MB.

You are correct in engine design and philosophy.

But if I rewired it to do as you suggest, Mr. end user won't know even know he saved around 2.7 MB in RAM on all but the most unusual maps.

I mean, I raised the default zone allocation to 8 MB. That's probably 6 MB more than the most rare situation would actually need.

And both Mark V and Quakespasm default to 256 MB -heapsize. Which is about double the memory any map actually requires.

/At least those are my thoughts 
What's the drive to optimize for memory usage in Quake engines these days?

Is it programmer pride, or is there a solid tech reason? 
MH wrote DirectQ and RMQ engine (first BSP2 engine, MH designed BSP2) --- it has some slick memory management. FTE and DarkPlaces do as well, but I've only ever really looked at MH's stuff in relation to the memory management.

(Because MH writes really great code. Time permitting, I try to code in his clean style.)

Almost acquired the entirety of RMQ's dynamic memory management into Mark V in 2014.

I have unusually ambitious backwards compatibility goals because of another engine called ProQuake and realized that if I implemented full dynamic that non-dynamic memory engines (ProQuake, Qrack, Quakespasm, WinQuake, FitzQuake, etc.) wouldn't reliably be able to either connect (coop or over the internet) or playback demos with certainty.

To address that, would have to have a mechanism to set a hard limit. Ends up being a lot of work to be back where you started.

[So both Mark V and Quakespasm use 8192 entities as the limit by default.] 
I Think That Means 
'Why make maps better than id1?' :>

I think the other reason is the megamap format. Some things just don't work very well, like flickering lights. 
What's the drive to optimize for memory usage

"so modders/mappers can push the engine more" would be my initial thought, although I don't know much about engine coding. 
"'Why make maps better than id1?' :> "

No, no ... it means, "My machine has a kojillian gigs of RAM in it. Why stress about a few hundred bytes?"

Why stress about a few hundred bytes?

Because it's not. 
I think it would be daft to take a bloatware approach to engine mods to a 1996 game, even if computers in 2016 can handle it. A lot of people will want to run this on older PCs. The original was coded efficiently and there's no reason not continue in the same philosophy. 
What's the drive to optimize for memory usage
Dynamic limits for stuff means that it'll not crash due to the limit being too low (note: you typically still need a sanity limit).
Fixed limits are a constant battle between sanity and actual use. Any time anyone makes a slightly bigger map, the engine needs twice as much memory. Essentually, the program eventually ends up allocating memory right up to the edge of sanity. Which then causes it to crash because its BSS section clogs its virtual memory pool.
Okay, maybe I'm exagurating a little, while 1 fixed limit can be ignored, by the time you have enough such limits things do start to hit the fan. Its just good to make all limits dynamic early, before it gets too problematic.

Baker, so you want MarkV to have limited static entity counts because someone *might* record a demo and then play that demo in an even more crippled engine?
Really you're just ensuring that maps won't work in either engine, spreading the crippleware. 
"The original was coded efficiently and there's no reason not continue in the same philosophy."

Well, it would eliminate the now routine conversation that takes place when any new mod or large map gets released about which engine it works in, which limits need to be raised, etc.

And there's nothing inefficient about a dynamic array. Software around the world uses them every day. :) 
Playing Quake 
Well, it'd be nice if Quake was more accessible to people who don't know what the console is, or simply don't want to mess around with heapsize and the like.

But the onus there is on the mappers to set up their rc or autoexec properly.

Which engine is more difficult, although Quakespasm has become the standardised engine of choice for many. 
Well, it'd be nice if Quake was more accessible to people who don't know what the console is

Absolutely. I dream of an engine where a noob can just start it, and load a mod/map through an ingame menu and literally not need to worry about anything else. 
I think the ideal situation is dynamic arrays when possible, with some sanity check hard limit, and also "xxx exceeds standard limit of yyy" messages when "developer 1" is set.

- still runs as well on old computers / vanilla maps as an engine with vanilla limits would
- mappers can check how high over vanilla limits they are.
- eliminates frustration for players running huge maps

In practice there can be challenges doing this for each different limit.

Looks like QS and MarkV both MAX_STATIC_ENTITIES at 512. Hunk_Allocing the static entities as they arrive sounds like a good solution, as long you can be sure things added to the hunk during CL_ParseServerMessage will stay around until the client is restarted. 
map viewer

Mark V has a map browser already... maybe it could do with a mod browser. To be honest is it necessary? Most maps come with a readme txt with instructions. 
To be honest is it necessary? Most maps come with a readme txt with instructions

I once tried getting some people at work into Quake. The short answer? Yes. 
Doesn't something like QuakeInjector solve the noob issue? 
I didn't know about that thing. I guess I'm the noob :} 
The original was coded efficiently and there's no reason not continue in the same philosophy.

It actually wasn't. The original was coded for an 8 MB MS-DOS machine with no multitasking and no virtual memory, so (1) it could freely grab all of the memory in a machine without worrying about having to play nice with other programs, and (2) if it ran out of physical memory it would explode.

There's vestiges of this all through the original memory management system. Zone memory is one example; the whole LRU/MRU/flush/evict thing in cache memory is another.

When doing any analysis of Quake's memory subsystem you absolutely have to bear in mind that it was coded for an OS and for constraints that no longer exist.

And of course, with specific reference to static entities (and a few other things), there is always this: 
The quake engine was coded for efficiency in the use of memory and stability. For one, the so-called modern engines typically have bugs which are not detectable because of the slack memory handling in a modern OS, whereas the popular DOS extenders were strict. This enables detection of memory related bugs and stable code.

The majority of modified winquake engines seem to be enthusiast projects to show off the latest visual feature. This is worthwhile for working on experimental features, but much less so for the mappers and gamers. They should have to debug the maps and OS issues and not have a common source of bugs in the engine, too. This is why quakespasm is favored, even though it is missing the original software engine. 
Perhaps what you have to say would be more interesting if you provided some specific examples with some specific engine names.

Everyone likes a good rant, but that's muddy as hell with no specifics. 
They should have to debug the maps and OS issues and not have a common source of bugs in the engine, too. This is why quakespasm is favored, even though it is missing the original software engine.

It's not that simple. Quakespasm, FitzQuake and so on are also favored because they operate in 32-bit color. They have 32-bit colored lights, 32-bit colored fog, 32-bit alpha blending, 32-bit color skyboxes and so on.

Software renderers can't compete with that. Even less so if 32-bit color filtering for 8-bit textures is also taken into account. There's no way to make a 24-bit software renderer fast enough to do all those true color effects at a playable speed. No way.

I was happy enough to figure out how to do color-corrected 8-bit alpha blending in real time, because the alternative color system I was developing would be slower and overcomplicated. It's hard to create precomputed 16-bit or 24-bit color transformation tables that fits in the CPU caches and are fast (using a single access for each RGB color instead of doing the R, G & B transformations separately).

The smooth, smooth colors of hardware rendering are something that really sets both worlds apart, even if texture filtering is disabled. Software rendering feels just poor in comparison.

That's why there's no market for it. Texture filtering gets disabled because it distorts the texture resolution, and software rendering is not used because it distorts the texture's colors.

Any software renderer with 8-bit colored lights, 8-bit colored fog, 8-bit alpha blending, 8-bit color skyboxes and so on is doomed to be just a trifle, just a novelty. There's no reason for anyone to put them above what the hardware renderers can do.

All this may sound weird coming from me, but I'm just thinking objectively. 
Looks like QS and MarkV both MAX_STATIC_ENTITIES at 512. Hunk_Allocing the static entities as they arrive sounds like a good solution, as long you can be sure things added to the hunk during CL_ParseServerMessage will stay around until the client is restarted.

We can be absolutely certain this is the case for static entities.

The client-side code (where the Hunk_Alloc would be done) adds efrags as the last part of setting up a static entity, and efrags depend on the world existing. The world is loaded into the hunk. Therefore the hunk must be valid otherwise the world itself wouldn't be valid.

Server-side static entities depend on the progs.dat to have been loaded first, and the progs.dat is also loaded into the hunk. So the same applies - if the hunk were somehow invalid then the progs.dat would also be invalid.

So both client-side and server-side we can conclusively prove that there are absolutely no circumstances in which it's not valid to use the hunk by the time static entities are loaded. 
Quake 1 and its artwork was designed around 8-bit color and the software renderer. By comparison, the opengl renderer has a "washed out" appearance as described earlier by the Winquake community and in a summary of Quake engine differences at Quaddicted. I agree that the opengl engine is superior in maps specifically designed for that engine, however, the remakes of Quake maps (ExMx) look better to me in the software renderer. These maps aren't designed around high resolution skyboxes and transparent textures.

I agree that the software renderer can't compete with the opengl renderer where it performs best. However, the software renderer has its strengths, such as portability (and performance) on non-gl systems, suitability to represent the original artwork and derivatives, (and better compatibility with past mods in the case of Winquake projects).

If there was a Winquake client with Quakespasm like software development practices, then it would be easier for developers to offer secondary compatibility to the software renderer, such as Sock and others have done. 
Maybe someone should code a very conservative WinQuake client that doesn't focus on effects and instead is essentially a WinQuake clone of FitzQuake/Quakespasm.

Would you agree with that statement? 
Fine! Next update I'll change static ents to array of pointers. And in cl_parse.c

Change this to Hunk_Alloc size(entity_y) ent = &cl.static_entities[i];

I guess it's a 2 liner anyway. 
3 liner. I'll have to zero fill the pointer array on CL_NewMap. 
Next update I'll change static ents to array of pointers. And in cl_parse.c

Nope, that's not what we're talking about.

What we're talking about is getting rid of MAX_STATIC_ENTITIES, getting rid of cl_static_entities and getting rid of cl.num_statics - delete them, altogether.

Then the code in cl_parse.c gets rid of this block:

i = cl.num_statics;
Host_Error ("Too many static entities");
ent = &cl_static_entities[i];

And replaces it all with this:

ent = Hunk_Alloc (sizeof (entity_t));

The thing is - there is atually no need to track static entities in an array; whether that be an array of entity_t or of entity_t * is irrelevant; it's not needed and can be gotten rid of. 
No Limit Static Entities 
Beta Windows GL Build - Feb 4 2016

* no limit to static entities
* alpha masked models (0x4000 flag in QME 3.1)
* (with changed source files provided) 
Although obviously I didn't read your post since it was literally 3 seconds before I clicked submit, I did remove the array.

However, I do keep the count for the compatibility warning vs. original Quake. ;-) 
I dunno, wasn't the original Unreal software renderer 32-bit? 24 at least... And it ran pretty well. 
Maybe I'm wrong ... it's too early in the morning. 
I think you're actually making two arguments here, one of which is valid but the other of which is bogus, and unfortunately you're using the valid argument as justification for the bogus one.

The valid argument is that there is a pixel-art aesthetic in Quake, with lots of pixel-level detail in it's textures that the default linear filtering used by GLQuake ruins.

However, that should not be extended to try argue that a lot of the rest of Quake's original grunginess is either deliberate, or finely crafted, or efficiently coded, or whatever.

You see, the evidence is there in the code itself, in comments in the code, in sources like interviews, .plan files, Michael Abrash's Black Book, the Masters of Doom book, and so on. The thing is: id Software were very open about discussing Quake and it's development and none of this is a secret.

Take Quake's colormap for example; you absolutely positively cannot try to argue that it's in any way finely crafted, because it's not, and we have the proof. It's just a brute-force nearest-colour match:

Likewise .MDL files: you cannot claim that the reduction of position vertices to 8-bit is anything other than a crude scale and bias, with type conversion, because once again the evidence is there in the modelgen.c source code.

If you look at the code and other sources you'll see lots of "fixme" comments, you'll see Carmack's "I hate our model format!" remark, and more. It's a matter of public record that Quake's development was one year of experimentation followed by 6 months of an insane rush to get it finished and released. So please don't try to claim that there's much in the way of deliberate craft there.

The majority of modified winquake engines seem to be enthusiast projects to show off the latest visual feature. This is worthwhile for working on experimental features, but much less so for the mappers and gamers.

If you were talking about Quake clients back in 2002 or 2003, you'd be right because that's the way the majority of Quake clients actually were developed back then. I was there, I remember it. Making such a claim about an engine such as Fitzquake, which has an explicit goal of remedying the areas where GLQuake is inferior to software Quake, just shows that you haven't been paying attention. 
I Was Saying Boo-urns 
I am one of the people who loves the look of software quake, because of the hue shifts in different light levels, which imo gives it a more appealing and painterly look. If this is not intentional, as mh implies, it doesn't matter to me, I still like the way it looks. I also love the way the light is banded and not smooth. It's a proper retro look and has its own charm.

You lose the subtle shift of hues with GL engines, but obviously you get better preservation of the texture art, coloured lighting, fog and all the other cool stuff. 
The UT renderer is 16-bit, IIRC. However, it doesn't feature all the effects of its hardware counterpart, so it still fits my description. Combining all of those different effects together requires a lot of work.

I was going to use a 16-bit indexed color palette, with textures using only 256 colors from that, so most color transformations could be done with a single ( (texel << 16) | pixel) operation. But all tables together would consume lots of memory, and reducing their sizes to fit into the L3 cache would kill the smoothness I was trying to achieve. I even thought of an approach using a special texture format, but that would require creating special tools and extra work steps for the asset creation, not to mention that Quake compatibility would go out of the window. 
Ahh OK ... I love software rendering. It just has a character that hardware doesn't seem to retain. 
mh, thanks for the explanation of safety of Hunk_Alloc'ing static ents, helps me visualize things :) 
A 10 minute experiment on Mark V WinQuake. Some success ... but spans must be clipping each other so incomplete.

WinQuake screenshot:

Attempt 2 
2nd - 10 minute experiment .. WinQuake alpha masked models. Part 2.



It works! Rather surprised in a way, nothing is ever easy with the internals of the software renderer. But this particular time, not so hard. 
Which method did you use? Doing a whole pass for each surface is easy, but not optimal. 
It was a 2 liner. Here's how it worked:


if ((lzi >> 16) >= *lpz)
byte bsrc = ((byte *)acolormap)[*lptex + (llight & 0xFF00)];

if (bsrc != 255) { // Baker: masked theory.
*lpdest = bsrc;
*lpz = lzi >> 16;

I feel like a complete jerk as result. 
Oh, that's a MDL. I thought it was a BSP. 
wow baker, this is great! thanks for taking a chance on the alpha textures on models! 
Surely it should be "if (*lptex != 255)" - I don't know if palette index 255 can ever come out of the lighting calculation, but that aside, alpha should come from the base texture anyway. 
You are right. I only spent a few minutes, tried a quick experiment and it worked. I think the above happens to work because 255 is a fullbright. 
Feb 7 2016 - Beta Build 
Windows Open GL + WinQuake | Windows Direct X Version

* Alpha masked models support (set .mdl's QME 3.1 0x4000 flag)
* Alpha masked models for WinQuake version too
* No limit static entities
* RCON remote console support (ProQuake compatible) + full NAT fix.
* sv_map_rotation "dm3 dm6 dm4 dm6" --- map rotation via cvar - repeated names fine, it won't get confused.
* May have (all?) obscure mod bug-fixes that NightFright pointed out.
* Install from Quaddicted. Type "install travail" for instance. Type "uninstall travail" to uninstall.
* No dependencies at all. Just single .exe

Source. Maybe next time will update Mac build. 
will this play orl's new map set? 
ericw did a very kind thing by making a scrappy custom Quakespasm executable with "protocol 999" support for orl's map so more people might try it.

As I understand it, it isn't true protocol 999 and wouldn't be able to play, for instance, RemakeQuake like the RemakeQuake Engine can screenshot.

So it's not a real protocol -- it's just something kind that ericw did for ORL. 
Protocol 999 
It's been a while but IIRC protocol 999 was deliberately designed to be modular; if I've got this right, a standard protocol 666 data flow is also a valid protocol 999 data flow with the exception of the protocol version number and an extra int which is used to specify what optional features are used.

Again working from memory, clients and servers then use that extra int to negotiate what set of these optional features they both have in common, and from there features are enabled or disabled.

So in theory even a "scrappy protocol 999" is therefore also a valid protocol 999.

But like I said, this is all from memory. The last released version (which was not supposed to be final) may or may not support all of this, but what I've just described is certainly what the intention was. 
This interests me. It's one of the goals of my protocol experiments.

Got more detailed info on this? 
scrappy = perfectly adequete.

possible host_errors is better than unconditional host_errors, imho.
partial is better than none.

unless baker wishes to propose a different solution for large maps or jerky rotations? :P 
// protocol flags
#define PRFL_SHORTANGLE (1 << 1)
#define PRFL_FLOATANGLE (1 << 2)
#define PRFL_24BITCOORD (1 << 3)
#define PRFL_FLOATCOORD (1 << 4)
#define PRFL_EDICTSCALE (1 << 5)
#define PRFL_ALPHASANITY (1 << 6) // cleanup insanity with alpha
#define PRFL_INT32COORD (1 << 7)
#define PRFL_MOREFLAGS (1 << 31) // to do - support this...

if its protocol 999, then read a 32bit integer interpreted as the above flags. those flags define how it differs from 666.
If there's a bit set that you don't understand, error out or something.

there is no handshake/negotiation in rmqe, the server dictates and clients are expected to fall in line.

fte uses PRFL_FLOATCOORD| PRFL_SHORTANGLE (which matches dpp5+ and fte clients, as well as avoids extra inprecision...).

ericw missed te 255 apparently (but so does fte, so whatever).
He also missed U_SCALE (which might come back to bite him with illegible server messages on rmqe servers).
QS should probably also warn if any protocol flags are set that his client doesn't support, again to avoid any bewildering illegible server messages.

personally I'd recommend against having the client distinguish between 666 and 999 other than to parse the flags. its simpler to treat them identically except with 666 having flags 0, but that's just my opinion because I hate lots of OR expressions all over the place. 
Obviously I want smooth rotation. Would ideas behind this protocol permit the following to evolve in it:

1) Prediction
2) Baseline compression/ack frames.
3) EF_FOLLOW, EF_NODRAW and other flags like DarkPlaces, view weapons
4) Possibly connectionless connections.
5) Team scores in multiplayer? 
"alpha insanity" -- that appears several times in the RMQ engine source code. Could you explain what that means? Is that how .alpha in FitzQuake 0.85 if 0 for a new entity should actually be --- I think 255 is full alpha, but I haven't looked. 
It's slightly, and amusingly, ironic that one aspect of Quake that RMQ very successfully recreated was the somewhat fucked-up development.

personally I'd recommend against having the client distinguish between 666 and 999 other than to parse the flags. its simpler to treat them identically except with 666 having flags 0, but that's just my opinion because I hate lots of OR expressions all over the place.

I'd agree with this recommendation; I can't remember what way I did it originally, but like I said - the intention was for 999 to be identical to 666 but for the flags, so this approach would work and be cleanest.

Got more detailed info on this?

There's not really much more to say aside from what Spike and myself have said. Protocol 999 was designed in a rush to meet a very specific requirement (a large map going beyond regular bounds) and was left unfinished. Despite that the intention was for it to be easily adoptable and extensible, so bit of forethought was put into how to achieve that. Hence the fact that you'll see that there's a "moreflags" bit already reserved, which signals to send another int (and IIRC the intention was also that bit 31 of this other int would in turn signify even more flags, and so on, so it should in theory be infinitely extensible).

"alpha insanity" -- that appears several times in the RMQ engine source code. Could you explain what that means?

I think this is in reference to the FitzQuake standard of having an alpha of 0 signifying full opaque. I understand why this was done (so a memset-0 would set a good default) but I remember being annoyed by it at the time. Probably unnecessarily annoyed too, I must add: juggling multiple things, 75% of which aren't even working and all of which are needed now for content does tend to stress one out a little. 
Kinn managed to get me excited about alpha textures on .mdl --- resulting in a couple of updates. I couldn't resist!

I guess I'll be meditating on the protocol 999 thing. My destination of choice is full, no compromises coop support in a way that would meet Spike's approval.

If protocol 999 is a pitstop on that road or not, I still can't tell although perhaps Spike can tell me.

re: the alpha insanity, I hear you ;-)

(I think I'll use the Pitfall logo for this post, I don't think I ever used that one before ... heh) 
in fitzquake, 0 means wateralpha for turb surfaces. other values ignore wateralpha entirely, thus it does make a distinction between 0 and 255.

the problem with extending protocol 999 is a case of who defines the flags.
my own extensions have a chained style, ultimately terminating in the protocol version that they're meant to be extending.
note that fte also has a handshake mechanism (but falls back to stuffcmds for nq).
my personal fear is that everyone defines their own extensions and then I end up feeling like I have to implement 5 different variations of the same extension, each with a different svc or different order of flags etc. each subtly different that I can't share code despite them all fundamentally doing the same damn thing.
unfortunately there is no real authority when it comes to extensions. 
in fitzquake, 0 means wateralpha for turb surfaces. other values ignore wateralpha entirely, thus it does make a distinction between 0 and 255.

I was thinking more in terms of entity alpha and FitzQuake's ENTALPHA_* macros, with the memset-0 happening in ED_ClearEdict. 
My most ideal thing would be split-screen support with controller support. No idea how that would work but I would be overjoyed with that. 
baker, I don't really do approval, ever...
not sure why you're looking at me specifically about coop.

all I can really say is that coop without some easy way to punch holes through NATs is somewhat futile nowadays, from a usability perspective.
my xmpp thing used an XMPP server for ICE stuff, but needing people to create accounts etc is a significant issue, and even using existing acounts like gmail addresses is filled with far too many nightmares.
I keep meaning to use an irc server or something for it, but I can never find the motivation to try.
You could also run your own specialised server for it, but gah, infrastructure. 
I mean your "school of thought" on the efficiency of a network protocol. No I don't mean your explicit approval, per se.

(And maybe with luck I may have a real block of time later this year. Otherwise it's 2017 -- and such is the way of things in this world ...) 
Thanks for the code review :) Mankrip: here is the diff to QS. I was meaning to test it more, like test connecting between my implementation and FTE/DirectQ/RMQEngine and demo compatibility, but didn't get around to it yet.

I will look at implementing PRFL_EDICTSCALE.

One thing I need to look more closely at is the "roughround" flag in RMQEngine, in MSG_WriteShortAngle:

// -1 and -2 are legal values with special meaning so handle them
// the same way as ID Quake did; other values can use rounding
if ((f == -1 || f == -2) && roughround)
// encode to byte, decode back to float to get the same behaviour as ID Quake
sang = (int) (f * 256.0 / 360.0) & 255;
f = (float) sang * (360.0 / 256);

I'm not sure what the purpose of that is.

Also, I am tempted to switch QS to use the 24-bit position to save space. I noticed that with 32-bit positions, QS overflows the signon buffer when loading telefragged.bsp (this map requires something like 48KB with protocol 666..)

My thought on the protocol flags: it's useful if a demo recorded with protocol 999 is playable in any engine that supports 999. This implies freezing the set of flags, because otherwise an old 999 client won't be able to play a demo (or connect to a server) running a new 999 version with new flags.

General thoughts: I'm still sort of meditating on this as well, and it's not merged into the main QS repo. Larger than +-4096 map support only really happens for users/mappers if 999 is enabled by default, you can't expect users to know whether a map requires >+-4096 support and set the sv_protocol cvar accordingly. I even forgot to set it myself while testing oms3_2.bsp and had to restart the level, lol. 
My to do list --- whenever the time comes and it does not feel soon ---

1) ipv6 + what I have been discussion above + automatic background high-speed LAN/non-LAN propogation of current mod running for coop via TCP.
2) Enhanced graphical integration with Quaddicted.
3) Mirrors + security cameras.
4) Linux software renderer build and polish up unreleased OpenGL version which regretably uses SDL because X Windows is a cluster-mess and seems like it was designed by a basement nerd who never used an operating system with a decent GUI --- and even then SDL doesn't cover all the bases, but hats off the SDL guys because it does cover 90% of the way and SDL 2.0 is exceptionally nice and forward thinking.
5) Inter-map travel with single file saves.
6) Absorb remaining ProQuake features. Absorb 1 or 2 remaining JoeQuake features. Mark V already plays .dz demos on any platform with no dependencies, the Mac build for instance. ProQuake will then become just a different build of Mark V.
7) sv_gameplay_fix_qrally_is_a_crappy_mod_dot_com 1
8) Probably add rotation back in.
9) I think I needed to touch up Nehahra in 2 places.
10) Possibly multiplayer save games.
11) Take another look at WinQuake and what I wanted to do but didn't. It wasn't too much, but I can think of a 2-3 things.
12) Would need to check list, I'm sure something else is on there. 
@ericw +1 
re: not knowing if a map requires large map coordinates. 
I'm not sure what the purpose of that is.

All discussed here:

Basically the game uses an angle of -1 or -2 to signify special behaviour rather than rotation. With the default rounding these are transmitted to the client as 0 and the entity draws correctly. Using Q_rint (Fitz & a few others) they transmit as non-zero and the entity is incorrectly rotated. So in certain cases it's necessary to revert to the original engine rounding: the linked thread gives one test map and I remember reliably reproing this bug in a number of engines. 
Quakec resets the yaw to 0 after detecting angle -1 or -2 in the spawn function for those entities that support the special values.

The bug occurs when -1/-2 is added to classes that don't support those special values, such as func_train. In that case, the spawn function doesn't reset yaw to 0.

In maps that have this error, it is invisible to players in stock engines by the way those engines do rounding. (at least -1 is invisible, -2 might still show up as a bug) 
Cheers, I suspected my explanation was incomplete.

So it comes down to "do you want to support buggy content" then. 
i wonder if it's possible to fix the -1 and -2 yaw values without screwing up other entities that are simply spinning in place, like fans. Do func_rotate objects always have a positive yaw? And what about monsters and players that rotate? Do they ever have negative yaws? 
I believe this is something that Sock tried to fix in AD in the progs but it broke a bunch of func_doors... found that bug fairly quick. 
Negative Campaigning 
Sometimes for a func_rotate_train you might have a negative angle, if e.g. a waypoint has a destination angle of 270 degrees, and you want the train to perform two full rotations on the way there, you could set the starting angle to -450.

Of course, you could easily redesign so that all the angles in that set-up were positive, there's never a necessity to have negative angles. The problem is 1) insisting on positive angles is changing the rules after the game's started and 2) the bug we're fighting is introduced unwittingly by mappers, so giving them more to think about won't really help.

In an ideal world, I'd introduce a very targeted fix. I don't think you need to deal with -2, because that angle should be visible in normal engines and fixed in testing. What I'd want is for the engine to detect when an entity has received a yaw of -1 from the map file, and render that entity as if it has yaw 0 until its angle next changes. It would still have yaw -1 from the QC's point of view, there would just be a temporary disconnect between the visible angle and the QC.

I thought you could just get away with this by sending a fake angle update over the network at the start of the map, then you wouldn't need to a) monitor whether the angle had changed at all or b) keep a flag to remember if the -1 had come from the map load or not. When I thought about it more I realised that you need to send this message each time the object comes into vision, so that wouldn't work. Is there a way to hack this into the protocol? 
Mark V has "sv_fix_func_train_angles" to strip negative angles off a train. Defaults on for APSP1.

(Yeah, yeah, Preach and the theoretical train.)

With true rotation, negative angles never happen, the angles are wrapped 0-359.99999 
As It Stands 
Just as a reminder that I am still checking here, still hoping for a fix for the Nehahra bug in the final boss map at least. Solving the Shrak issue would also be nice, because then all the official and inofficial addons would work with this port, which is still pretty much the best out there if you are aiming for vanilla Quake gameplay with a few nice enhancements. 
According the source code, the Shrak invalid skin number issue should be fixed. Could you confirm whether or not this is still an issue? 
Testing with the build from May 8, 2015 (if that is the latest one), it seems I can no longer reproduce the issue, at least not when playing the first few Shrak levels and gibbing mobs like crazy with the rocket launcher. We can consider this one fixed, then.

What remains on my personal list is the Malice issue from #855, the game messing around with FOV until it crashes. 
Update On Malice Issue With Latest Mk V Build 
I just saw there is a build from Feb 8, 2016. Used that one and tried Malice d16 again. Unfortunately, the Host_error: Bad fov: 180.000000 problem still occurs when the boss pulls you towards him. Also tried by loading the map directly, skipping usage of savegames from earlier builds. 
Possibly fixed for Malice.

Mark V with Malice FOV fix

Let me know if that fixes the issue. 
Pause Problem With Playing Demos 
Latest mark v seems to have problem with playing demo with pauses. If the client pauses the demo ingame while recording, it doesn't seem to unpause anymore when playing it. It can be seen in Vondur's demo of my latest map. Quakespasm plays it without problems (unpauses right after pause). 
Mk V Feb 16 Build Feedback 
Baker, your latest build fixed the FOV issue in Malice... kinda. Good news is the crash doesn't occur any longer. That's already a huge progress!

However, if I (quick)save during the fight and (quick)load, the FOV would be totally warped. Checking the config.cfg, I see that the game (still) changes fov to 170. That needs to be prevented.

Then there are two other issues regarding demos/cutscenes, one of them may be related to PuLSaR`s finding above. Cutscenes don't play any more when they are inside of PAK files. I get an error like this at the end of d15 after entering the exit portal:

Playing demo from cut8.dem.
ERROR: couldn't open

If I extract the file from the PAK, it works. Same with any other cutscene, e.g. from the beginning of the game.

The other thing is rather minor: The HUD remains visible during the cutscenes. I don't know if that can be changed, though. 
Crashes On Laptop 
Hi, for me the last build still crashes on my toshiba laptop with win xp sp3 and trident blade xp integrated video. The directx build runs fine and both original fitzquake and quakespasm, the latter very slow though. 
Thanks for the info. I don't expect to have time to do further updates for a while (next year probably). But I read all the feedback and always use it when the time comes. 
According to this that card doesn't support OpenGL, so QS is probably using the windows software renderer.

If you don't mind, try launching QS with "-condebug +gl_info", then quit, and upload the qconsole.log file from quake directory. Possibly MarkV crashes when only the windows software renderer is available? (the software OpenGL implementation in Windows is unusably slow, anyway) 
Interesting. Well, at least there is the Direct 3D API for him to use. 
Thanks. The card had opengl 1.2 support and could run even quake 3 engine games. Mark V changes video mode, 640x480, and then back to desktop resolution and exits cleanly. 
Mark V changes video mode, 640x480, and then back to desktop resolution and exits cleanly

That sounds like an error that happens at some stage during video startup. I would also suggest that you try running it with -window. This is just to test it's behaviour, as it may be able to pop up an actual meaningful error message if the failure occurs in windowed mode. 
I've tried windowed mode and still no error message, a black window appears and then dissapears. I'm running from a network drive with write access but i don't think that matters. Here's the condebug output:

UDP Initialized:
Exe: 19:58:01 Feb 7 2016
256.0 megabyte heap
FOUND: ARB_multitexture
Warning: texture_env_combine not supported
Warning: texture_env_add not supported
Warning: texture_non_power_of_two not supported
Warning: texture_filter_anisotropic not supported
Warning: Swap control not available
Hardware gamma enabled
joystick not found -- no valid joysticks (a5)
Input initialized 
Even if you did get it work, it looks like you have virtually no opengl extensions and it wouldn't be very nice at all.

I coded and tested assuming the worst possible hardware was an old Intel GMA and if it ran fine on that well --- that's the baseline and a very low bar.

You have something with Open GL drivers that doesn't even meet the very low bar of old Intel GMA.

Even if it did run, it would terrible and probably not render correctly in all circumstances.

The Direct X version does virtually everything the OpenGL version does. 
FOUND: ARB_multitexture

Does Mark V have -nomtex? IIRC the Direct3D versions doesn't have multitexture, so it might be worth testing with -nomtex to see if that's your problem.

Otherwise I suspect that the best way to figure what's happening would be to single-step video startup in a debugger on the hardware in question. 
Ok but i've tried with both gldirect and the software opengl driver and the same thing happens. Moreover original fitzquake only runs in 640x400x16: if i select another resolution it starts at 640x400x16, goes to desktop and then i get a black screen with sound when it goes back into the game. That's why i was interested in Mark V, may be it's the 32 bit rendering why it doesn't run? The card supports 32 bits however. 
@MH -- my Direct3D version has up to 8x multi-texture because I made some changes/enhancements.

Otherwise I suspect that the best way to figure what's happening would be to single-step video startup in a debugger

Well, I have no absolutely no intention --- I mean 0.00000000000 -- of trying to support a 2002 era oddball graphics card.

I'm not into that. 
Very well could be. Mark V does 32 bit color. Doesn't even have the option for 16 bit color since even the most worst/terrible/horrible computer I could find for testing would do 32 bit color just fine. 
Things that can help performance on old cards with fitz-style engines:

+gl_flashblend 1
+r_oldwater 1
+r_dynamic 0

Those defaults change from original FitzQuake to QuakeSpasm/MarkV (I think) to better-quality options, which could explain why QS is slower than FitzQuake for you. QS has a "-bpp 16" command line option as well, though from a brief look MarkV always uses 24bpp. 
For $6.50 + free shipping, the graphics card could be upgraded to 16 million colors ... 
toshiba laptop

It's worse than that, he's dead Jim. 
I made the Direct3D version so people with oddball video cards with terrible opengl drivers could enjoy a nice recent engine.

And the Direct3D version runs with flying colors with 99.9% features on even some very horrible machines that no one else's engine will run on.

/And does it with style and a robust feature set and stability 
True, but my point was that a graphics card upgrade is not an option in this case, because it's a laptop and the Trident is an integrated part. 
Usually I am telling that to Spike or someone else in a conversation.

How did I end up on this side of the argument?

Somewhere, someone screwed up this conversation and made it work out weird.

Probably ericw's fault since his username has a extra consonant appended to his name, which is very distracting at times --- especially because a "w" can sometimes be considered a conosant and other times it can be a vowel. 
Any News... 
... about the issues I had reported in #1085? 
Mark V isn't going to see an update until sometime in 2017. 
Well.... That's Crashy 
I'm just updating my Mark V after a long time (in preparation for some FvF :P), and I find all these new versions crash directly after the console says "3 demos in loop."

(the newer winquake versions worked fine though)

Yeah, I am on an older netbook running WinXP... because that's what I had Quake installed on.

I went back and kept trying older versions to see which is the last one that works (in case this might apply to anyone else), and it is:


But at least I can tell that the MP3-playing bug that I had in my previous old versions of Fitzquake has been fixed (i.e., it wouldn't play MP3 tracks unless it detected a real or virtual CD drive) -- I can hear the music playing now with no problem.

I guess it wouldn't do much good for me to report any bugs I find in this old version of Mark V.... I might at some point move Quake over to my Win7 device.

Baker, you really really need some kind of actual project page with just the downloads and notes about the versions, heh. It's difficult scrolling through all this discussion (though I eventually just went to the index of the files). 
Hey Gunter. 
It's difficult scrolling through all this discussion

It's supposed to be difficult to find the right download and keep up with the thread. ;-)

It deters uninterested parties from using the engine. What little development time I may end up having has to be catered towards experienced and knowledgeable beta-testers (like yourself).

The casual player should be using Quakespasm.

NightFright, Pulsar, spy, Fifth and others have provided the feedback I need through extensive testing. It's almost completely polished but there are some things I'd like to improve and features I want to complete.

I just don't have the time to do any more work on it right now --- and sometimes I wonder when or even "if" that time may come.

The current best version is: 
But It Looks Good 
This old version is looking good though....

I'm pleased that you decided to revert to Quake Defaults for most things, with menu options to change them.

Some of the previous minor issues I had seem to have been fixed.

Arrgh, Always So Close.... 
It's always just out of reach, but so close to begin just right.... And Baker never has time to work on it, heh.

I do wish I could use the most recent Mark V, but like I said, everything past mark_v_e just crashes (with one of those Microsoft error reports, if you would like all that mass of information....).

I can use the winquake version of the newest mark v, but of course winquake looks like butt :D (Arrgh, and it's got RCON in it... I so wish the old version that I can use did too!).

It does seem a lot of the old bugs were fixed, but I'm also seeing new issues that didn't exists in my previous old old version, r15.

For example (these issues also exist in the new winquake version):

No particle trail on vore balls. What happened to them?

The FPS display is in the top right... but if you size the screen area down, it does not stay in the top-right -- it just vanishes (or is not being drawn, or is hidden behind the "brown screen border").

Why did the HUD move to the center (single-player style) instead of moving to the left edge (deathmatch/proquake style) like it used to, so you can also display some player names in the extra space....

In the winquake versions only, if I set the screen to an 800 x 600 window (my netbook screen is 1024 x 600) then the HUD gets cut off at the bottom of the screen (pushed down too far, really -- looks like the full-screen console is the same way), by about the same amount of space that the title bar takes up at the top of the screen, maybe.... You might be able to replicate this by setting a window height to the same resolution height of your screen?

Eh, there are other bugs, but it looks like they have been fixed in the newest version (judging by the winquake one).

What are the chances that the GL version will ever be fixed so that it will work on my WinXP Quake netbook again? ... I suppose that's moot, since Baker has no time to work on it anyway, heh....

I tried Quakespasm. Oh my gosh, it runs like ass. I don't know what it is, but some effect it's creating causes the frame rate to be like 10 FPS on my netbook, in the entry area of the Start map, unless I turn and face a wall. Seems like the colored lights or something; it depends on where I'm looking. I promptly deleted it, and will continue to use the old version of Mark V.


Well, it's still better than any other client for me, but it's always just SO CLOSE to just right! D: 
Does the Direct 3D version run?

(Voreball trail is probably a mistake in a last beta build which involved a change regarding model flags, easily fixed. If the DirectX version runs for you, I'll fix bug and post an update.)

I don't normally include the Direct X version because Microsoft --- and only Microsoft out of 53 anti-virus providers --- says it is a trojan or something crazy. 
Well, Microsoft ended support for WinXP, so I had to uninstall MS Security Essentials, so I definitely won't be getting a security warning! Hey, my netbook still makes a find Quake device! :D

Yep, that DX version works, and looks nice. At first I thought it would not be usable, because I was getting only 10 FPS, but then I switched to full-screen mode and it works fine! I guess DX doesn't like running in a window. I generally prefer to run Quake in a window so I can easily switch around to other things while I'm playing, so I can look at config files and make notes about bugs I find in Fitzquake ;) but I will definitely use this, even if I gotta go full-screen now!

Thanks very much for that!

While you're fixing the voreball particles, here's my quick wishlist for three ProQuake-type features that you might consider adding in (because these should be pretty easy additions), listed in order of assumed simplicity:

Colors 14/15 (just a simple option that gives players more choice)

Proquake style Centerprints -- they appear near the top of the screen (just below the chat area) instead of blocking the view directly in the center of the screen. FvF does use a good amount of centerprints....

Bring back the deathmatch-style HUD... the way it used to be in Fitzquake (and ProQuake), over on the left (with extra player names on the right), instead of centered at the bottom single-player style (with no extra player info), as it is now....

I have another issue that is FvF-related (not really that important, but I will report it). FvF does not allow blank names, and will automatically assign a default name if someone tries to name themselves "". Well, during a game if I go to Multiplayer -> Setup, and try to erase my name to change it to something else, as soon as I erase the final letter of my name, that means my name is "" and FvF instantly assigns me a default name, heh, so I can never fully delete my name in order to change it to something else. I don't think the name should be "set" until the player is done editing everything and "accepts changes." (This didn't happen in old old versions of Fitzquake mark v.)

Anyway, thanks again for the DX version!
Best Quake Client so far, for my needs! 
I tried Quakespasm. Oh my gosh, it runs like ass.
Only if you're interested,... it would be nice to know why that is the case. If MarkV GL runs well, it's 99% likely just a configuration difference causing the slowdown, since QS may have different defaults(?).

I guess I should add this to an FAQ for QS, the settings to try for a low end laptop: (try each setting in sequence, checking if it increases FPS in start.bsp)
- use fullscreen
- r_oldwater 1
- gl_flashblend 1
- r_dynamic 0

Less likely to help: launch with command-line args:
-bpp 16

Also what is your gfx card / and which driver is reported by "gl_info"?
Sorry for the spam, Baker 
scr_sbarcentered 0 
@ericw --- if someone says GL version low fps or problems and then says the words like Netbook or Windows XP or even hints at "old computer", it's always Open GL drivers.

I just say "DirectX version" and then they say "Works fine. 200 fps. Thanks!" It's 100% problem solver in that department. 
Agreed, I just thought he mentioned that GL markv was running reasonably while QS was giving super low fps. 
yeah, or they could scrape the internet looking for the right opengl drivers, find lots of 404s, and the resign themselves to buying something that is actually still supported!... stupid laptop manufacturers that refuse to allow the chipset manufacturers to provide generic drivers...
or yeah, they can use d3d.

FTE has a d3d renderer too... :) 
Would you be willing to try Ericw's list of settings in Quakespasm to see if it works --- I bet the -bpp 16 may make a bit difference.

And then do a review of Quakespasm from the perspective of someone who runs a standard ProQuake Quake server (GLQuake compatible, Quake protocol) and plays online? 
Another cvar to try: r_flatlightstyles 1 -- it removes styled lights without sacrificing dlights the way r_dynamic/gl_flashblend would. 
Ah, thanks, Baker. scr_sbarcentered 0 is just what I wanted.

ericw, r_oldwater was the culprit. As soon as I turned that off, the FPS smoothed out DRAMATICALLY (running in an 800x600 window, it went from 6 FPS to just over 60, standing in the Start map, looking at the 3 teleporters and lava -- all water surfaces). Oddly, running full screen seems to give me about a 10 FPS decrease....

And gl_info returns:

intel 945GM
1.4.0 - Build 
Choppy Fog 
Oh, and this probably can't be helped (I skimmed over mh's post about fog, above), but the fog in DX Mark V is rather unsmooth compared to the OpenGL Mark V.

It's hard to get a good still image of the effect, but you can tell the lower image is much more "line-y" even in areas that aren't so dark on the wall. It's really noticeable when walking around, because you see the fog lines moving across the walls.... The OpenGL version had a much more subtle effect, and seemed smoother and much less noticeable on most surfaces.

I guess this is just a result of DX not doing fog as well or something? Probably not a setting to smooth that out.... Too bad; I like a little fog. Give a nice sense of depth. 
Are you interested in doing a review of Quakespasm from your perspective?

Most of the feedback Quakespasm receives is from single-player only types.

Diversity of feedback is what makes an engine better and helps developers have a broader point of view.

(re: fog --- Yeah, I have no control over Direct3D differences in fog rendering. Probably midday tomorrow, I'll try to rebuild fixing missing voreball trail. I probably stripped the flag.) 
that fog banding is interesting, because both shots have the same number of bands, but somehow on the lower shot it's more noticable.

If you look at the darkest parts of the image, like the wood pillar on the left side, it's clear that the lighting ramp is different -- top shot appears more blown out (slightly) -- i wonder if that's why the banding is more noticable in the bottom image, because the lighting is darker so the fog grey color has more higher contrast to the black walls.

Anyway both shots look bad, and this is a good example of why fog is difficult to make look good. You need to avoid solid colored patches of the scene, (such as a pitch black wall) since only the noise of textures and lighting can hide the banding that will always occur. 
ericw, r_oldwater was the culprit. As soon as I turned that off, the FPS smoothed out DRAMATICALLY (running in an 800x600 window, it went from 6 FPS to just over 60, standing in the Start map, looking at the 3 teleporters and lava -- all water surfaces).

Thanks! Glad that worked. 
I guess this is just a result of DX not doing fog as well or something?

GL or DX don't actually "do fog" at all - your GPU does. All that GL or DX do is provide your program with a means of saying "draw this polygon with fog", but your GPU does all the actual drawing.

With everything else being equal, there should be no difference whatsoever between images produced by one API versus images produced by the other, because it's the same GPU that's doing the drawing; all that the API does is send commands to the GPU.

On the other hand, DX does provide a handful of extra fog quality/performance options whereas GL hides them all behind a single glHint (GL_FASTEST/GL_NICEST), and allows the actual result to be implementation-dependent.

One possibility is that one of those extra options, if configured, would resolve it.

Another possibility is that the projection matrix isn't configured correctly in the DX version, causing loss of some depth precision, causing the extra banding. 
Baker, I'm afraid I just find Quakespasm off-putting for various reasons, but I will try to give it a test drive, since you asked....

So, it seems that now DX Mark V is running fine in a window... I'm not sure what changed (I often delete config files when testing), but most likely it was just me rebooting my netbook after testing no-telling-what last night.... In any case, the DX version is now running just as smoothly as the older OpenGL one, even in a window.

But here come some bug reports! heh

Your default lava color is incorrect!!!!!

Haha, yeah, this is a minor niggle, but your r_lavacolor is "255 80 50 150" and the Quake default should be "255 80 0 150" (search for "lava" here to see )

It does alter the color a bit... Of course, the lava intensity needs to be dropped to about 100 for my tastes; in standard Quake, if you were in lava you were dead, so it didn't matter that it was blinding in there. But in Runequake and FvF, there are ways to be in lava and not be dead, so you need to be able to see a little bit... 100 looks good to me (it's still lava, after all!). Normally I'm for keeping the defaults, but in this case, it would benefit from a slight change. Though I'm afraid I don't like the "light" blends in Mark V though -- way too transparent. But as long as it defaults to the defaults, that's fine. And Mark V provides the ability to change them to tastes, so that's fine too.

All other blends look good to me at Quake default, though for some reason the Ring blend looks a bit heavy. Maybe I'm just used to all the Quake clients that made it too light, but is there a variable to adjust the Ring blend? Hm, it does look like the cshift_powerup stuff for invisibility is the highest % on that page I just linked. I guess it's supposed to be that way.

Speaking of invisibility... I really liked that "always draw weapon when invisible" option in the old OpenGL version of Mark V that I was using... It made my weapon transparent. I like little tweaks like that which enhance things without really drastically changing the default Quake feel.

However, in the new DX version, the weapon just stays completely solid, and in the Winquake version, the weapon is completely invisible again... (of course I can't test the newest OpenGL version...). I wouldn't expect the Winquake version to do good transparency, but it seems the option, in that case, should leave the weapon completely solid. Which I actually don't like (laugh)! 
Ok, so, I find this interesting too, though I am clueless as to the internal stuff.

I cranked the gamma and contrast up to max (for the sliders) and made some more screenshots.

OpenGL (older version of Mark V) is on top, and the newest Mark V DX version is on bottom....

You can see the ugly square of fog over the close wall in the bottom image.... Though it turns out, in the top (OpenGL) image, the fog is actually extending farther toward the "me" in the image -- that's why the left edge of the first image looks lighter. The OpenGL fog still somehow looks better/smoother (even in this forced setup). I'm not changing any other settings -- just switching which client I run.

Here the same angle with fog off, and they are pretty much identical:

You can only tell them apart because of the odd lighter shadow under the grenade launcher in the OpenGL one -- I don't notice that in game, but the screenshot seems to capture it, same as the first image I posted upthread. Uhh... for some reason, imgur may resize the view so the odd lighter shadow is not visible o_O But trust me, it's there in the original image, heh.

Ok, now the most interesting image.... I changed my position to emphasize the fog distance difference:

Now look at that!

The fog does get closer to "me" in OpenGL, but also the bands on the wall are not all straight and parallel, which actually helps them not seem so ugly/uniform/bandy/unnatural.... And especially in the lit areas of the wall, the GL fog looks much better than the DX. This is what is pretty noticeable in play, under more typical lighting conditions.

There's also some difference in the interaction of the fog and the teleport texture. 
Image 3 settles it - there's a different fog range calculation being used depending on the API.

That's going to require a code change and a whole bunch of testing to fix up though. 
While testing Quakespasm, I looked at the fog (looks good - identical to the OpenGL images above), and I noticed what is causing the difference.

The fog is BEHAVING differently... and this would be hard to capture in a non-animated image, and it may be difficult to describe. But you should be able to replicate this yourself if you wanna see it in action. Just ramp up your brightness and contrast in Quake, and go to the entry room for E4M8 and look at the black wall opposite the portal while walking forward very slowly, or even looking left and right a bit. Oh, I also use a very light fog setting 0.03

The GL fog is JUMPING along the wall, in small sections at a time. That's why the bands in the GL screenshot are not perfectly straight lines -- one section of the line will jump forward, then another section. This actually makes it less noticeable on the walls when you are moving around, because you don't see any "movement" -- a line doesn't move across the wall, it just suddenly is there or isn't there, and that's really hard to notice when you're moving around, especially with the lines being not perfectly straight due to them jumping unevenly.

The DX fog is MOVING very smoothly along the wall, in perfectly straight lines. It looks bad because you easily see the movement of straight lines smoothly scrolling across the walls.... 
Animated Fog 
Ok... animated images... Keep in mind the colors will be extra ugly for being compressed to a GIF.

Just barely creeping forward you can see how the GL fog jumps in small sections, instantly. There are no missing frames in the fog's positions:

In DX, moving forward a big faster, the fog evenly scrolls across the wall. There are lots of missing frames of fog position in the animation.... I'd describe it as similar to interpolated movement, if that makes sense, because it moves very smoothly across the wall.

Is there any point to doing/discussing this?
Who knows!
I just do the testing. It's up to other people to do anything about it ;) 
Windows Build

Vore trail fixed, "submersion in lava" color slight typo fixed.

/Took a quick look at the DX transparent model with invisibility ring. Oddly discovered it doesn't look like FitzQuake 0.85 ever had a pathway to use model transparency if the driver doesn't support combine (the Direct3D wrapper does not support combine) --- so may not even be possible (didn't expect that). The non-combine rendering pathway does a series of operations that already use blending but it isn't alpha blending -- so that's probably one reason FitzQuake uses combine in the first place. A bit annoying.

I don't have time to do anything of substance on the engine, but the above 2 things were 2 minute fixes.

But in the future when the day comes that I have that time, I always read all the notes. 
That's interesting, i don't remember whether i added that support or not (but i would have assumed i did.) There is this comment in the readme:

- fullbrights now use additive blending instead of alpha blending. This allows me to support external glowmaps, and entity transparency with fullbrights/glowmaps. In some cases, additive fullbrights are rendered using multitexture, but only if GL_EXT_texture_env_add is available. The command line option -nocombine will disable the use of GL_EXT_texture_env_add.

This implies that without combine, models with fullbright masks are rendered in two passes. It doesn't say that they are rendered correctly with alpha though... hmm. 
It is probably a virtually non-existent situation.

I've not seen an instance of someone using .alpha on an alias model in a single player release. And there probably aren't any Open GL drivers that don't support combine.

It's just that the Direct3D wrapper doesn't have combine ability written in the code and that Mark V offers a "gun with transparency" option when invisible, instead of Quake not drawing the gun at all.

/But the brush models don't suffer this problem in the Direct 3D + no combine scenario (I tested against back2forwards which uses .alpha for glass). So at some future date when I have time to chart out the rendering, I should be able to rewire something --- assuming I would do that instead of maybe taking a shot at adding combine to the Direct3D wrapper. 
(Actually, thinking about that --- Nehahra does .alpha on wraiths and Mark V runs Nehahra.) 
the sparks in rubicon2 fade out using alpha (they are models) 
Hehehe, never noticed that. I only noticed the laser barrier bars and such used .alpha. 
Torch flames in sock's maps usually (always?) have alpha as well. Any maps using Preach's smoke model. 
Animated Fog 
I did proper animated fog once. It used world position and a function of time to do a lookup in a 3D noise texture which was then used to adjust the opacity. It looked beautiful but the performance hit was just on the wrong side of what I considered acceptable.

Totally irrelevant to the ongoing fog discussion, of course, but it was fun. 
Low-Lying Fog 
While we're mentioning fog, faint transparent water with a more subtle texture could make for neat looking fog, especially if combined with mankrip's shore fading. 
Contract Revoked used this trick, IIRC. 
Contract Revoked 
Didn't have fog. 
dwere was probably talking about this. I didn't adjust the translucency and soft depth levels to match Qmaster's suggestion, though. 
Quakespasm, Pt. 1 
Ok, you asked for it Baker, so here is my review of Quakespasm. Much of this will be personal preference, and other stuff will be comparisons to Mark V.

I mentioned that Quakespasm is off-putting to me. This starts with the website (I talked about that long ago, way upthread). I do note the addition of a clear "readme" link on the site, and that's a definite improvement, because when I go to try and download something like this, I want specific information rather than the vague artsy presentation which just gets in the way....

The second off-putting thing to me was all the files Quakespasm wants to drop into my Quake directory.... My goodness, that's a lot of files. 12 DLLs, a PAK file, 3 TXT files and an HTML... along with the 2 EXEs. What a lot of clutter.

The third major hurdle was that r_oldwater defaulting to 0, which caused my frame rate to be like 5-10 on the Start map.

Finally, there's the difficulty in finding what settings are available, such as all the various console variables, like the one above -- there's no good documentation. I would have never known to try that to fix my issue.

So yeah, with all those issues, I was like, "Forget this..." and I'd move on to something else.

But I will say, once past all that, Quakespasm is a really nice engine. It may even run a bit smoother in places as compared to Mark V. Well, I am stuck with the DX version of Mark V now, since the newer GL ones just crash for me... so... that may make a difference. The fog certainly looks better in Quakespasm as compared to DX Mark V (but that's also true of GL Mark V vs DX).

My first point of feedback would be that the r_oldwater setting should really default to 1... since it seems to be such a power-hungry effect to have active (in my case any way). I tried enabling it in Mark V, and got the same result -- baaaaaad FPS. But Mark V has r_oldwater 1 by default.

In the menu, I really like the "Scale" slider. Very nice. I had to set up keys in Mark V to achieve the same effect by altering 3 different console variables. The nice slider seems to adjust everything at once (that's definitely something Mark V should add).

The "instant Quit" upon selecting Quit from the menu. Hm, not sure how I feel abut that. I don't love it but I don't hate it. The new Console background is the same type of thing -- not sure if I like it or not, but FvF has its own console replacement anyway, which still looks close to the original Quake one, so it doesn't matter much.

Hey, the "Always Run" menu option is a definite improvement in the way it functions. In most Quake clients (like Mark V), having "Always Run" on seems to place more emphasis on your forward movement, causing the side-stepping movement to be way too slow (when you gotta side-step to get out of the way of a rocket, you want to sidestep FAST!). The way Quakespasm implemented it seems to instead function just like a run key (+speed), which places emphasis on your side-stepping speed while only slowing your forward speed down a little (there's still an overall speed limit you can't pass when moving "diagonally"). Even better, when "Always Run" is enabled, your usual +speed key acts to slow you back to normal walking speed. That's a nice touch (Baker, Mark V needs all of this! :D ).

Uh, where's the clock ? The usual clock in DM mode is MIA. Is there a console variable to enable it? But watch out that it doesn't overlay the "player squares" that appear where the clock would normally be -- just limit the number of those "squares" that appear there.

Also, there are no pings by the scoreboard when you press tab while playing online. That's a pretty common feature, and pretty much expected these days.

Speaking of the scoreboard (and all other things that are printed in the center of the screen, like centerprints and "loading" images), the ProQuake method of positioning all these things near the top of the screen is the best way to go. Then they don't block your view in the middle of the screen. Every modern Quake client should be imitating Proquake in this respect. EVERY MODERN QUAKE CLIENT, Baker :D

(continued below, because maximum character count is only 5000, haha) 
Quakespasm Pt. 2 
Wow, MP3s load fast! I guess some of those DLLs are doing their job. The MP3s seem to load with no delay at all. My gosh, Mark V takes like 10 seconds to load an MP3 track (all the while your game is frozen). Can we get this in Mark V? Like, seriously. I won't even complain if it will require some extra DLLs!
Though it seems the menu option to enable/disable external sounds does not take effect until level change (Mark V enables/disables the music right away. Well, after the loading delay, that is).

Speaking of those DLLs, I don't suppose they would go into the PAK file to make them more tidy? Probably not, eh? Well, the next best option would be to move all the Quakespasm-related files (DLLs and PAK) into a Quakespasm folder within the Quake folder (this is like how Qrack does it).... Quakespasm would still know where to find them, and they would be out of the way. I think this would be a significant improvement.

Is there a way to toggle high-quality textures on and off? Mark V has external_textures to toggle.... I like to be able to turn them on and off in game, to make comparisons and to test loading time. There doesn't seem to be a way to turn them off at all in Quakespasm?

And... how do I get high-quality monster textures to work? I tried them in Qrack format (png), I tried them in Mark V format (tga), I tried them in various locations (progs folder or textures folder), but they don't show up. Documentation, please!

I do note that the high-quality wall textures load correctly in my modified dm6 (it's got some small extra areas added to the standard DM6 map). For some reason, Mark V does not load the custom textures in it, and reverts back to the standard textures for the map.

Speaking of my modified DM6 and Mark V (and this is really a Mark V bug report, but I'm on a roll), for some weird reason, when I run FvF and go to start a new Single Player game, I am dropped into my DM6 at a DM spawn point (I did add SP spawn points to the map) instead of the Start map! What's up with that? No other engine does that (including Quakespasm or older Fitzquake Mark V or Proquake....). Some weird interaction of Mark V and FvF, or the modified DM6? It's not really important, because FvF doesn't actually have a single player mode... It's just weird.

gl_overbright_models does not look good for me. Makes the Quake solder way too washed out when he's standing in a bright area, especially if he's wearing white. Same in Mark V. I just disable it.

I like that r_wateralpha controls all the liquids by default. In recent Mark V, it seems each setting must be made separately (like r_lavaalpha). This appears to be a result of Quakespasm using defaults of 0 for like r_lavaalpha, and also allowing the r_wateralpha to affect all liquids. That's a much better way of handling it, which still allows fine-tuning of separate liquids if desired. Mark V could benefit from this.

Hey, the "under lava" blend looks perfect, right out of the box in Quakespasm. Has the intensity of it been changed? Quakespasm doesn't seem to have the ability to alter it manually.... Good thing it looks perfect as-is! But I'm curious as to why it does, when it looks so blinding in Mark V at the default Quake values.

Models with missing skins come up as white in Quakespasm. This is old GLquake behavior, but it should really be handled like Winquake does, by using the default texture. For example, if a monster or projectile has multiple skins for a mod (FvF does this a lot), but the client does not have those skins installed -- so the like mod is assigning skin_1 or skin_2 to a model, but if the client doesn't have them he should just see the default skin_0 for that model. Mark V does show the default skin in these cases.

Hm, scr_showfps doesn't stay set for the next time you start Quakespasm.... That seems to be standard behavior for Quake clients, but this seems like one of the settings that should be stuck in the cfg file and saved.

Quakespasm Pt. 3 
Keeping in mind I'm running on a netbook with a resolution of 1280x600,
If I set Quakespasm to a 800x600 window, the actual space inside the window (game area) is 600 tall, but the title bar and border extend farther.
In Mark V (and Proquake, etc), the entire window (including title bar and border), is 600 tall.
This means that in Quakespam, there would be a tiny portion of the screen cut off at the bottom of my actual screen, because I can't move the top of the window all the way off the top of the screen.
I'm not really saying one way is more correct (though the standard, I think, is that the 800x600 defines the dimensions of the entire window, including borders).
So I end up setting my window to a weird size so it all fits my screen, 750x550 (I've used this with Mark V and Proquake sometimes too), but when I do that, Quakespasm's color depth is locked at 16 bpp and can't be changed in the menu.
If I go back to an 800x600 window, the color depth is again changeable in Quakespasm's settings, though I really can't tell any difference at all in the graphics when I change it (in full-screen or window). My desktop is set at 32 bit color. I don't have any real issues with any of this -- I'm just reporting my findings, heh.

I do have a slight issue that the Contrast slider does not do anything for me (no matter the BPP or full-screen/window settings)... so the Brightness slider is my only option for adjusting things, and that tends to make colors less vibrant. Mark V's Contrast slider works fine for me.

The weapon model is too low. I guess that's the Fitzquake default.... Mark V allows (and defaults to) the Proquake way of showing the weapon, which makes it less hidden at the bottom. Well, normally Quakespasm hides the weapon behind the transparent HUD anyway, but I like to set my HUD to opaque. And I like to see more of my gun.

While on that topic, the Mark V "transparent weapon when invisible" is a nice option Quakespasm could use.

Demos don't load at all upon startup? Is there an option for that?

The r_noshadow_list has same problems as Fitzquake: There is no bolt1.mdl in Quake. That should be bolt.mdl. Baker did add bolt.mdl to Mark V, but he forgot to remove the bolt1.mdl. Also, k_spike.mdl (the Death Knight fireball attack) and lavaball.mdl really should be added to the list, as they are glowing things that should not be casting shadows.

Hm, I miss the stain maps from Mark V....

And I would suggest adding Proquake's RCON function to Quakespasm (as Baker did for Mark V -- thanks!!). It is extremely useful to be able to admin a Proquake server while I'm connected and playing. This is a pretty big criteria for me when selecting a Quake client, though it may not matter at all for most people.

And of course I always suggest adding support for Colors 14/15. Heh, They are in Quake... it's just that the client doesn't allow them to be selected. I think it's an easy thing to modify (later versions of ProQuake have it).

I guess in the end Quakespasm and Mark V are pretty close, with each having pros and cons compared to the other.... 
In most Quake clients (like Mark V), having "Always Run" on seems to place more emphasis on your forward movement, causing the side-stepping movement to be way too slow (when you gotta side-step to get out of the way of a rocket, you want to sidestep FAST!).

Apparently, your mod uses a slow default for cl_sidespeed.

The actual Quake default was always somewhere around the max speed, making strafing very fast regardless of autorun. I don't know why they set it up like this, but my guess is it was an attempt to assist keyboard-only players in dodging.

The result is that the autorun toggler in the menu most likely just ignores cl_sidespeed and only affects cl_forwardspeed and cl_backspeed. 
re: mp3 loading speed slower in Mark V

Quakespasm uses a software library for media playback, Mark V uses Windows hardware accelerated playback. On the computers I have tried Mark V on (probably around 20), it typically loads instantly. I think it stop/pause/restart instantly, but Quakespasm can't.

The software library Quakespasm uses is more reliable because it isn't subject to Windows settings or Windows .dlls, but uses more CPU.

/Mark V is a "pure client", it doesn't use 3rd libraries (that's why doesn't need .dlls). Quakespasm uses SDL2. Spike statically linked Quakespasm-Spike, so it doesn't need dlls and the library instructions are rolled into the .exe.

Quakespasm contrast not working

Quakespasm contrast not working is probably the result of one the command line options required to make Quakespasm run on your netbook. Try removing one of those command line options and see if it runs.

Quakespasm it uses a shader for brightness/contrast, it only affects the Quake window --- not the entire desktop.

Mark V by default uses the Windows API, but it affects the fullscreen so in windowed mode the rest of the desktop screen is affected by your brightness settings --- but it has no effect on frames per second or cpu usage (it's free).

r_lavaalpha etc

Hehe, ericw/Quakespasm did a push to get different transparent level for different liquids. Hence the feature in Mark V.

Quake defaults

AFAIK, Mark V uses 100% Quake defaults and 100% Quake behaviors with minor exceptions (mouse look defaults on).

I don't like all the defaults, I think ring of shadows hue is too dark.

You might not like how standard Quake "always run" is less than perfect, but I'm seeking to exactly mirror GLQuake/WinQuake/FitzQuake in behavior.

External textures

You must use the DarkPlaces texture naming convention. They must be in .tga format.

Mark V recognizes
(1) one format --- it's TGA
(2) one folder for things to go -- the DarkPlaces location
(3) one naming format -- the DarkPlaces one

DarkPlaces Examples:

progs/armor.mdl_0.tga // green skin
progs/armor.mdl_1.tga // yellow skin
progs/armor.mdl_2.tga // red skin

I don't care about the Qrack place/name --- DarkPlaces is the engine that people make skins for. Everyone should use the DarkPlaces name/format *and* only the DarkPlaces name/format. The naming convention Qrack uses for skins comes from the FuhQuake Quakeworld client, which provides no naming convention for sprites. The Qrack naming conventon is flawed. 
Context On The External Textures 
The FuhQuake texture naming convention not only has a bad naming convention, it stuff like specific folder names for different models. Qrack uses the same, as does ezQuake.

It's insane.

Poor FTE (Spike's engine obv) obviously caters to people familiar with ezQuake and he has check for textures in like 16 different places in some cases. It's slowish and can add to load time (think of a map with 160 textures) and then multiply by supported graphics formats and then how a file can be in a pak or not.

So the rogue FuhQuake/ezQuake/Qrack naming convention is not only slow -- and not only confusing to users --- but the code looks like spaghetti.

The other problem is if you are a user, how are you going to find the texture if it could be in so many different places.

It's crazy

/Mini-rant, but DarkPlaces naming convention injects 2 forms of minimalistic sanity! 
Side Stepping 
No, there's definitely some different behavior when using +speed vs using "Always Run" in default Quake. Try it in most any Quake client, such as Proquake or Mark V.

Default cl_forwardspeed is 200
cl_sidespeed is 350

Setting "Always Run" just sets the cl_forwardspeed to 400, leaving cl_sidespeed at 350

But using this setting, try going to the Easy hall on the Start map. Back up into the corner of the wall and the step (so the health box is behind you), and press Forward + Right. You will barely make it to the "corner" of the wall and the metallic column thing at the end of the hall, before you hit the right wall.

Now disable Always Run and either set +speed in the console, or assign a Run button like Shift, and hold that down.

Repeat the exercise above.... You will easily make it to the right wall in half the time, and if you quickly reverse direction to the Left, you will even hit the left wall before leaving the hall area.

I believe I understand why this happens now!

When you use +speed, all your speeds are doubled, so the values are effectively changed to:

cl_forwardspeed 400
cl_sidespeed 700

Now, 700 is obviously faster than the speed limit, so you expect it to be stopped at 400 by the server, and that's true.

However, that 700 number places EMPHASIS or priority on your side speed over the forward speed -- maybe the server calculates where you WOULD be if you were moving by those values, but only allows you to move a max of 400 toward that point.

Now, if you use "Always Run" that only sets your cl_forwardspeed to 400, leaving cl_sidspeed at 350... which would produce a completely different calculation for where you WOULD be if you could moved at those values.... Further, if you then press the +speed button, it will not affect where you end up because both the numbers would be doubled, to 800 and 700, which would be the same comparative amount of movement in each direction.

However, if you go in and manually set cl_sidespeed to 700, then you're back to moving just like +speed, with fast side movement, even with "Always Run" enabled.

So in short, "Always Run" de-emphasizes your sidestepping speed by not doubling, while +speed increases your sidestepping speed by the same proportion as your forward speed, allowing your sidestepping to remain nice and fast.

The fix: Make "Always Run" also set cl_sidespeed to 700 along with setting cl_forwardspeed (and cl_backspeed) to 400.

Then the movement ratio stays the same. 
Spike statically linked Quakespasm-Spike
No, I didn't. I just didn't include any dlls - the target audience will have them already.
I meant for it to be a patch rather than a fork, so I didn't see the point in making the zip huge.

FTE's texture loading code looks like spagetti because its designed to act like it, and by that I mean it supports both threads and filesystem caching.
This makes it _much_ faster to load stuff than DP.
And that's despite it trying about 125 different paths (ignoring the multiple extra gamedirs) for each individual texure last time I checked (that count doesn't include lumas/gloss/normals/bumps).
But yes, DP is consistent yet strict. Its a good choice as the favoured path to try first - unless of course the texturs in that path were completely flat with the expectation of bumpmaps providing all the depth, in which case they'll look terrible without rtlights.
So yeah, hurrah for fuhquake's naming convention! 
The above reply was to dwere ^

In regard to what Baker said about it, I don't have a problem with sticking to Quake's default behavior for "Always Run," however in that case you should stick to Quake's default behavior and leave "Always Run" DISABLED by default. Of course, I dislike it and won't use it (for the reasons mentioned above), and can set up my config in an alternate way, but with it defaulted to ON, when I'm setting up new configs, it requires toggling the menu option to disable it -- there's no console command to disable it, right? 
Gunter, I agree intellectually with what you say.

But I do things from the perspective of the standard existing behavior so the users gets what they expect and have always known.

(1) Power users like you know how to edit your config.
(2) Some users who just want to play they game and it be like what they've always known.

They aren't necessarily power users and if you change things on them, they get confused.

@spike -- Interesting stuff. I thought you statically linked it like what imagine do with FTE. I know SDL2 can be statically linked in MinGW. 
Of course, I dislike it and won't use it (for the reasons mentioned above), and can set up my config in an alternate way, but with it defaulted to ON, when I'm setting up new configs, it requires toggling the menu option to disable it -- there's no console command to disable it, right?

There's no single console command, but a bunch of variables. You can set them however you want, and safely ignore what's written in the menu. The engine wasn't taught to detect your custom settings, so it just assumes one of the two conditions (autorun on/off) based on some of these variables (most likely just one of them).

The variables are:

cl_upspeed (swimming/flying up and down)
cl_movespeedkey (multiplies the above speeds when +speed) 
"Always Run" 
Hm, considering it more, I really think this is an error or oversight in the original Quake code that has gone unfixed for a long time (actually, Quakespasm has fixed it!), and it really should be fixed in modern clients.

An illustration:

Default diagonal walking speed has you to move 2 steps forward and 3.5 steps to the side (200 and 350 are the actual settings).

So imagine a line starting at the lower . and ending at the top right .
Just go ahead and draw a line on your monitor with a marker to connect the dots :D


That shows your line of motion -- the direction you will be traveling.

If you "run" using a Run key (+speed), those steps are both doubled, so you will be trying to take 4 steps forward and 7 steps to the side.
Imagine your line of moment now starting at the lower . and ending at the 7

You can see it is the same line of movement -- it just travels twice as far. Of course, you won't make it that whole distance, because there is an absolute speed limit, but you will still be traveling along the exact same line in the same direction as before until you hit the speed limit.

Now with "Always Run" ONLY modifying your forward speed, you will be taking 4 steps forward and 3.5 steps to the side, which greatly alters your line of travel. Now you are traveling from the lower . to the upper . again


Completely different line of movement, and your sidestep speed suffers greatly.

The total distance you end up moving will be the same (the absolute speed limit) but your position will be different because you are moving along a different line in each case....

I believe the first line of movement is the correct intention for Quake, since it applies to the default walking or running methods.

I think with the "Always Run" menu option, they simply overlooked that it was supposed to also apply to the sidestep speed, which IS supposed to be doubled along with the other speeds when running. 
(1) A menu is to satisfy the basic needs of the average user.

(2) A config is to satisfy specialized needs, preferences or interests. 
Getting back to other bug reports, Joystick support seems to be broken in the latest Mark V, though it seems to work fine in my older version mark_v_e.

It says Joystick detected, and joystick 1 is set in the console, but no input is detected. 
Quakespasm has game controller support, you might check that out.

In the future when the day comes that I can work on the engine more, I expect to try to get the joystick control working perfectly. PFL earlier in the thread posted joystick settings that he used. (My response was I'm glad it worked, since I don't have a joystick at the present time). 
"Quakespasm contrast not working is probably the result of one the command line options required to make Quakespasm run on your netbook. Try removing one of those command line options and see if it runs. "

I'm not using any command line switches (other than setting resolution). I can run Quakespasm just by itself and still no Contrast adjustment (same with the Quakespasm-sdl2.exe). I tried adding the -fitz switch, and that didn't help either (although then the demos play, when they normally don't in Quakespasm).

"I think ring of shadows hue is too dark. "

Yes, I agree. How about a console variable to adjust that?

I cannot get monster skins to work in Quakespasm.... They work fine in Mark V, and all other textures work in Quakespasm, such as walls, items, and weapons. Just not the monsters, no matter where I put the textures, like:


And I even tried the Qrack format ogre_0.png in various locations, just to be sure.

But the ogre stays ugly. Well, I mean... low-resolution ugly as opposed to high-resolution ugly. *shrug* I don't care enough to keep trying to make it work in Quakespasm. 
And... how do I get high-quality monster textures to work? I tried them in Qrack format (png), I tried them in Mark V format (tga), I tried them in various locations (progs folder or textures folder), but they don't show up. Documentation, please!

Some of legacy GLQuake code in Quakespasm interferes with modern operating systems, preventing users from applying external skins to MDL files. To fix this, you need to go into your C:/Windows directory and delete system32. 
Quakespasm doesn't have external texture support for models. Just maps.

In preferences there is an option to lighten the view blends, the ring of shadows falls in that category. Otherwise you have to play with gl_polyblend or r_polyblend or whatever the name is. 
The reason the contrast slider wasn't working is it requres GL2.0+, which the intel 945 doesn't support.
Thanks for all the feedback! 
I didn't adjust the translucency and soft depth levels to match Qmaster's suggestion, though.

It should look even better with translucency, because it's multi-layered. 
Ah, gl_polyblend is something I can mess with, though I really would like to be able to adjust only the ring blend, and not ALL the blends, because I think the others are ok. If I turn the ringblend down to where I think it looks good, then all the other blends look way too light. I guess I will settle for just toning it down a hair to 0.9, which doesn't lighten anything else too much....

I've also noticed that Mark V allows standard chat behavior during the "level end" scoreboard (i.e., you can still see the chat lines on the screen, and additionally if you are typing as the level transitions, it stays on screen too). Nice touch. This is an old old Quake bug that I hadn't seen anyone else deal with. And we do like to continue chatting in FvF while we dance at the end of a level ;)

On the bad side, I seem to be experiencing a few crashes on level transition both online and offline.... That's gonna be hard to debug on my end unless Mark V can generate error logs. But it seems like it possibly happens more often on certain maps. I'll keep notes on this....

Also, sometimes, when lots of stuff is flying around (especially lightning), I get "warning: 150 tempentities exceeds standard limit of 64." I don't think there's a need for users to see that warning, is there? It's fine as a debug message, but not something the end user needs to see.

And the shadows in DX Mark V are... uh... well, they look like ProQuake shadows where it's like you can see the folds inside the model casting varying intensity shadows -- the shadows don't look solid. In the older GL versions of Mark V, the shadows were a uniform color/transparency.

And just an interesting thing to note: I found out what was causing DX Mark V to run really badly in a window when I first tried it (but fine in fullscreen). I have a little program running that sits in the corner of my screen and shows the network traffic. It's called BitMeter 2. When that is on my screen and DX Mark V is running in a window, my FPS goet to like 6. As soon as I hide the little BitMeter display, my FPS smoooths out dramatically.... It doesn't effect the GL Quake clients I've used, though I have had videos get unsmooth when I try to watch them full screen if I had BitMeter displaying as well.... *shrug* 
baker: i finally got a chance to look at the fitzquake 085 code, it appears that without texture_env_combine, you still can get alpha blending but what you lose is overbright lighting. 
Retroquad doesn't support overdraw between surfaces with the same kind of liquid in the same entity, because in most cases that would be just a waste of framerate. In maps with molten mapping enabled and compiled with lit liquids, that would be a framerate killer.

But I agree that multiple layers of translucent surfaces may give a better fog impression. The lava in some AD maps (playing with QuakeSpasm, as my engine can't run it) looks more like plasma to me due to this.

(Sorry for the off-topic, Baker.) 
@gunter: By the way, in Mark V...

* You can paste text into what you type in a "say" message (messagemode2).
* You can paste text anywhere text input is accepted. In fact, if you hold down shift and select text in the console, you can press CTRL-C and copy text.
* You can also type "copy" in the console and copy the contents of the console to the clipboard.

DX wrapper doesn't have stencil, so can't do stencil shadows. Those smooth shadows are stencil shadows. But even those shadows don't clip. DarkPlaces is the only engine that renders player shadows properly on multiple surfaces that clip.

Warnings. Standard FitzQuake 0.85 printing warnings. But I've seen it confuse more than 1 person. Quakespasm made those only print with developer 1.

Its to help mappers know they are making a map that isn't standard Quake compatible (it won't be playable in Quakeworld like ezQuake, nor playable in GLQuake, etc.)

The DOPA release by Machine Games a couple of months ago is an example of a episode that is actually all-Quake compatible.

@metlslime: Didn't have enough time to check the .bsp code to see what alpha brushes rendered ok. Sounds like you are saying that I would have discovered no overbrighting on those when combine isn't available when I did look. In the future, I probably mimic that path for models with translucency to resolve lack of transparent gun rendering in DX version.

(@mk - it's not off-topic at all. Software renderers matter too!) 
More Bugs And Suggestions 
Hm, so if you can't make stencil shadows in DX, how about making the shadows completely black? Perhaps the r_shadows variable could work like wateralpha, and set the transparency level of the shadow. 0.5 might be the standard setting, but a setting of 1 would be a solid black shadow, which would look better than the weird shadows of varying thickness in DX.

I found that setting "noclip 1" caused the HUD area to turn grey. It sometimes flashes back to the HID when other effects are happening.

I tried playing a demo that someone recorded (I believe in Qrack) and it was constantly spamming the console with everyone's pings. I played the same demo in Proquake and it didn't do that. I played my autodemos from Mark V, and they also did not do that in Mark V. So I tried recording a couple demos in Qrack myself (not sure what version of Qrack I have), and they wouldn't play at all in Mark V, and one of them caused Mark V to crash. I tried the same demos in ProQuake, and it also crashed, but it popped up an error message first, "sv_lightstyle > MAX_LIGHTSTYLES"

A possible suggestion: how about overlaying the standard Quake sky over the skyboxes using the skyalpha to make it mostly transparent? Then you'd still have transparent moving clouds in front of the skybox.... Maybe just the first layer of clouds, and make the second layer completely invisible or something. 
I'd be curious to see how Gunter's multi-layered sky would look. 
That would be neat! Best of both worlds. Vanilla skies lack realism and skyboxes are pretty but completely static. Both are slightly annoying in their own way, but if we could mix them... w00t! 
Transparent Weapon Model 

I reported before, the "Invisibility - Draw Weapon" option that makes your weapon model transparent did not seem to work in DX Mark V, leaving the weapon fully solid.

But I just found that if "external_textures 1" is set, it DOES work, and my weapon model is transparent! 
Qrack questions, really you should ask R00k about his engine.

mh calls shadows in a Quake a hack. Go stand on the slime bridge in E1M1 with shadows on ... where is your shadow? Try any non-DarkPlace engine, the shadows aren't there when you walk on an entity. DarkPlaces has nice shadows.

Skybox clouds. I might put that on the list of things to see what it looks like, whenever in the future I have the opportunity to work on the engine again.

Noclip + DX + HUD. Looks like you found a bug with a certain combination of settings in the DX version. 
Setting gl_clear 1 may fix your HUD drawing issue in the DirectX version.

Interesting that activating external textures would cause the alpha transparency to work --- must kick it through a slightly different rendering codepath. 
Planar shadows in Quake also poke over edges. You can stand under a bridge that a monster is walking on and see the underside of it's shadow poking over the edge of the bridge.

After 20 years of Quake, how the fuck do people still not notice this kind of stuff? Because once you do see it, you can't un-see it, and no shadows are better than that. 
Lighting made of hacks and approximations will always have its artifacts. Lightmaps included.

It's just a matter of what's easier for you to ignore. In this case - the lack of character shadows, or their unnatural properties. 
Shadows in Quake are pretty bad

quick screenshot 
Quake disappearing shadows 
*Shadows* hang over edges?
Big deal!
Look at this! :p

Heh, everybody knows Quake ain't pretty!
We don't play it for it's cutting-edge, hyper-realistic graphics....
Hacky shadows look fine most of the time.

"gl_clear 1" did fix the grey HUD issue above.

I mentioned long ago that the bubble sprite doesn't load in Fitzquake when a high-quality textures is in ID1\progs\s_bubble.spr_0.tga (and the spr_1 animation frame too). If those are in place, and high-quality textures are enabled, the bubble is simply invisible in the game.

However, in Quakespasm with the same setup, it does show the original low-res bubble sprite instead of the hi-res one... Either there's some issue imported from Fitzquake, or maybe there's something wrong with my high-res bubble sprite, and Quakespasm knows that, so defaults to the original bubble ?

But the s_light.spr_0.tga in the same location works fine.... 
Replacing a bubble texture with a red one works for me.

Something is likely wrong with your texture.

Quakespasm only supports replacement textures for maps surfaces (technically .bsp surfaces, like ammo boxes, healthboxes too).

I thought gl_clear would solve the issue, I'm glad it fixed it. 
Projection shadow method follows slopes and breaks over edges. quake2vr solved some of the remaining problems on sharp corners.

history per q2vr readme-
beefquake --> kmquake2 --> quake2vr

IIRC qfusion and/or warsow may have also have this. 
Ah, that's right; I forgot Quakespasm doesn't re-texture anything but maps.

Well. my bubble sprite textures are from the Quake Retexturing Project, "Item textures v.0.73" pack.

Opening them in an image editor, I do see a difference between the bubble sprites and the light sprite; the Alpha mask of the light sprite appears to have it fully opaque, but the Alpha mask of the bubble sprites look like they're trying to make it partially transparent....

So is it a similar issue with partial transparency, maybe? And it's making the bubbles completely transparent and invisible....

Ah, yep... after tinkering around with the alpha channel in the tga, it seems that with a sprite textures, Mark V makes areas fully transparent (invisible) if they are less than 50% visible, and anything over that threshold becomes fully opaque... I think. So that's why my bubbles were fully invisible -- the Quake Retextuing Project has the bubble sprites at about only 25% visibility (75% transparent) or so....

I think Mark V needs a much higher threshold before it makes things completely transparent...
It's better to have the bubbles fully visible.

Assuming Mark V won't be able to correctly make it partially transparent, anyway.... 
Lighting made of hacks and approximations will always have its artifacts

Shadows in GLQuake are *not* part of it's lighting model. 
In the real world shadows are related to light. Hence the generalization. 
The MP3 Loading 
"Quakespasm uses a software library for media playback, Mark V uses Windows hardware accelerated playback. On the computers I have tried Mark V on (probably around 20), it typically loads instantly.
The software library Quakespasm uses is more reliable because it isn't subject to Windows settings or Windows .dlls,
Mark V is a "pure client", it doesn't use 3rd libraries (that's why doesn't need .dlls"

Is there any way I can troubleshoot this? The delay I'm getting is really awful. If I go to the Start map and toggle the External Music ON in the menu, my game completely freezes for 17 seconds while the MP3 loads (track04.mp3, 3.78 meg).

If I then toggle the External Music OFF and instantly toggle it ON again, my game completely freezes for 17 seconds while the MP3 loads....

Is there any certain Windows setting or dll I should be looking at as the culprit?

I can't remember any other software having such a delay when I'm loading MP3s.... 
Sounds like you don't have enough memory. The Windows API probably precaches the whole mp3 (I'm just guessing), Quakespasm's library feeds it to the sound system in chunks.

Either way, I know almost nothing about Windows settings and such, I never change mine. People at or Tom's Hardware might know such things. 
quakespasm includes mp3 decoders.
mp3 patents technically violate the gpl and/or patent law.
(another reason for me to not include dependancies with my quakespasm patch).
using the system's mp3 decoders is one way around that issue (avoids distributing it, and system component avoid gpl issues).

markv uses directshow, which is a system component...
but directshow is poo...
that said, even 17 seconds is excessive even for directshow. wth?

the third way is to use windows' 'acm' api, which can provide stream-based mp3 decoding, which is the method that fte uses. this doesn't do anything silly like scanning the entire file, and isn't even aware of the file. yay pk3s.
markv already uses this api! but the other way around (encoding mp3 for avis).
and with it decoding to memory, it can also be used for sound effects too! yay!..
but yeah, directshow sucks. 
According to Google;

the last MP3 decoding patent expired September 2015. (Decoding = playback)

the last MP3 encoding patent expires April, 2017. (Encoding = recording)

Mark V still can play the music from the CD, so you can always put the Quake cd in the CD drive.

Mark V's mp3 playback is plenty fast on the computers I have tried it on and I've not seen anyone else in this thread (1100+ posts) report that it is slow. But I remember Fifth having problems to get it to work on his Surface Pro, then he did a driver update or something and it worked fine. 
I might add that DirectQ always used DirectShow (AFAIK) for mp3 playblack, and I never recalled seeing a "mp3 is slow" thing in a DirectQ thread -- DirectQ got tons of usage too when MH was developing it.

But yeah, I don't know much about Windows settings and drivers and such --- I never change any settings.

You could try playing music from the CD since Mark V still supports that. 
Was it a driver update? I can't remember now, I thought you had fixed it because I moaned incessantly ;) 
I was going to ask you what you did to fix it.

You posted something like "I reinstalled <XYZ> and now my music is working!" 
try uninstalling+reinstalling windows media player. that'll probably reset whatever is screwed. that or it'll fail completely, but hey, there's always ffmpeg+vlc, right? 
I wasn't aware that the ACM library -- which Mark V already uses for other purposes -- could do mp3 playback, which sounds like unlike DirectShow isn't subject to Windows Media Player settings.

So at some point in the future, I may look through FTE and rewire Mark V to do what Spike does, which is more robust.

/But since I have no time for engine coding, that'd be sometime in 2017 
Mixing the music and quake sfx in-engine is somewhat tricky (if you want the final result to match vanilla quake running at -sndspeed 11025 + a CD playing / an external music player).

You need to duplicate what happens in the OS mixer, so running the 11025Hz output of the quake mixer through a high-quality resampler to get 44100Hz, then mixing in the music, taking care to reduce the volume of the resampled sfx a bit to avoid clipping. Resampling after sfx mixing is key to keeping it sounding like vanilla quake.

(the above doesn't apply if for those who play with -sndspeed 44100 which I find ear-grating :P) 
@ericw, Small Rant 
most modern (cheap) sound cards favour 48khz(dvd quality).
apis like wasapi (that thing that directsound is now a wrapper around) tend to favour floating-point audio too (which incidentilly makes clipping MUCH easier to deal with, also, hurrah for sse).
resampling 11khz to 44khz, crapping over it a bit, then resampling to 48khz via directsound is kinda crazy.
especially when that first resample step *STILL* uses nearest sampling...
so yes, I'm not surprised at you finding it ear-grating.

back in the dos days, the lack of os-level mixing meant that taking actual control of the hardware output rate made sense. with quake spitting out 11khz audio and the sound card outputting analog audio smoothly at the same rate, the hardware would then do linear sampling for you. obviously this varies based upon sound chips.
Or in other words, just fix ResampleSfx to use linear resampling instead of nearest, and have quake output to the OS's native mixer rate, and you'll have audio that sounds as close to vanilla quake as you can realistically get.
There is imho no point in lowpass filters etc, unless you're trying to get underwater effects or whatever... which isn't vanilla quake.

and yes, mp3s played at 11khz sound terrible. so don't do that.

side note: it was recently reported to me that the existing method to get FTE to play internet radio stations sucks.
While I was of course aware of this, I really cba to change anything. We have OSS4 now, the dude should just use a real player, they generally have hotkeys anyway. 
Hypothesis: Could the weird delay be caused by Windows Media Player searching for covers and metadata through the Internet?

Does the MP3 delay also happen in windowed mode? Does any icon activity or notification message pop up in the Windows taskbar during that time?

Maybe Windows is showing up one of those system pop-up windows asking for you to confirm something before x seconds, but since you're in fullscreen you can't see it and the game has to wait for the background pop-up window countdown to end before playing the track. 
Re: Just Use A Real Player 
Real Player? Is that still around?

Oh wait. The dead one is WinAmp ... the one that -- It Really Whips the Llama's Ass. 
My engine instincts are a bit slow and rusty .. but my reinterpretation would be that ACM provides a mp3 decoder and based on what you said --- and I haven't looked at FTE's code --- it throws it into Quake sound mixer's buffer.

I know with SDL2 you have to use a callback for the sound buffer, but AFAIK not another thread ... but Spike may use another thread.

Hence I used the word "maybe". ;-)

When I use the word "maybe", my spidersense has told me there are 2 or 3 wildcards that once I witness I may not feel like is worth the effort, haha.

@mankrip --- he may be on to something! Even for an old computer, 17 seconds sounds weird. 
"I might add that DirectQ always used DirectShow (AFAIK) for mp3 playblack"

I gave DirectQ a try... and I get the exact same result: very close to a 17 second delay to load the MP3 on the Start map.

I do run Quake in a window, and there are no Windows notifications happening. I disabled all the "download media info" stuff in Windows Media Player.

I tried uninstalling (rather, rolling back to version 9 is what it does) my Windows Media Player 11, but running either version seems to make no difference, so I re-installed version 11 again.

I tried running on my much older WinXP laptop, and (although it may have other issues running smoothly) the MP3 loading did not experience much of a delay at all....

So I guess it's just my netbook that's the problem, though I've never had a similar issue with MP3s. I mean, yeah, it's a WinXP netbook, but it should certainly be good enough to play Quake and MP3s (ASUS EeePC, Intel Atom CPU N270 @ 1.60 GHz, 0.99 GB RAM).

Let me do some re-encoding of the MP3 and see what results I get....

Using Track04.mp3 (8:20 length) for Start map, I originally ripped it as stereo, 63 kbps, 22050 Hz. With that I get the pretty consistent 17 second delay when I switch on external music.

Well, now I'm using Audacity to convert the MP3 to different formats, and getting significant results.

Simply re-encoding the file at the same 64 kbps, 22050 Hz, the loading delay drops to about 7 seconds.

I believe I used CDex to rip the tracks from the Quake CD a few years back... maybe it used some weird encoder? Or was 63 kbps a weird rate? Actually, Windows reports the original MP3 is 63 kbps, but VLC says it's 64....

If I drop the quality way down to to 16 kbps, 11025 Hz, it drops the loading time to 2 seconds.

Going up to 128 kbps, 44100 Hz, the load delay goes up to about 14 seconds, which is still better than before.

I guess I just need to decide what quality I want to sacrifice for a decent load time. 5-7 seconds is tolerable, especially compared to that 17.

I guess the issue was some weird combination of my WinXP netbook and the encoding of the MP3s.... Though I will still have a delay, but it will be much less.

Anyway, thanks, everyone, for the information and attempted help.

Hm, oddly, it seems that sometimes encoding at the same parameters will produce different results (like a 10 second delay instead of the usual 6-7), which are consistent with that MP3 until I encode again.... Eh, I'll just have to tinker around with it.

Er, just loading my original MP3 in Winamp and stripping out the ID3v2 tag (which only contained "genre: unknown, track: 4") drops the loading time from the 17 to only 10 seconds.... Doing the same thing with the Audacity re-encoded file (that still held the tag info) makes no difference at all in the loading time.

Eh. Computers are weird!

If anyone else would like to try my weird MP3 file to see if you get any weird delay (you probably won't...) here, have at it! 
You might not like this thought but something that occurred to me ...

Windows Media Player might be trying to connect to a long dead web site (for reasons unknown) and it takes 15 seconds for the load to fail.

If you had some sort of network traffic utility that could identify the theoretical dead web site, you might be able to use Google for a similar problem or uses the hosts file to block the DNS and at least make it fail faster.

One thought, possibly wrong ... sorry you have a pointless stupid problem ... 
There's a simpler way to test that � just unplug the network cable and turn off the Wi-Fi device.

After doing so, disabling the antivirus may also help � some antivirus programs does scan any files accessed by supposedly unusual means before allowing the programs to access them.

And lastly, see if there's any music scrobbler (such as Last.FM) installed.

The antivirus is a strong candidate, since encoding methods can make the file harder to go through deep analysis, and antivirus programs usually does some special analysis on ID3 tags to prevent some kinds of exploits (I vaguely remember reading something about security issues with ID3 tags).

Also, players like Winamp and Windows Media Player are likely to be in a list of trusted media players for the antivirus to ignore. Custom Quake engines aren't. 
If this has anything to do with the problem, appears thats Windows Media Player may be trying to find missing meta data using the internet (which probably tries to contact a long dead site ...) 
Audio Nerd Tangent.. 
re: resampling algorithms: nearest-neighbour is terrible for audio, but so are linear and cubic. Upsampling 11kHz audio is unforgiving because with the nyquist frequency at 5.5kHz, the distortion let through above 5.5kHz by a poor resampler is right in the sensitive area of human hearing (an ideal upsampler for 11kHz audio is a brickwall lowpass filter at ~5.5kHz).

You got me curious about what kind of filtering vintage cards had, and I turned up this thread:
The SB16 is pretty impressive, it's certainly not just using linear interpolation based on those measurements.

So IMHO something like libspeex-resample (windowed-sinc FIR filter) should be used for any audio resampling unless you specifically want the distortion of a bad resampler.

About fixing ResampleSfx.. I did try making a version using libspeex-resample, and still ran into 2 problems:
- When the mixer is running at 11kHz, quake can get away with cutting off and restarting sounds without fading in/out. The upsampling smooths out the discontinuities, and limits the glitching to be below 5.5kHz which prevents it from being too annoying. If the mixer is running at 44 or 48kHz you lose this safety net. Particularly: holding down fire with the nailgun creates really annoying high-frequency glitches when the nail firing sample is cut off midway through and restarted. This distracts me whenever I use DarkPlaces..

- The other related problem is Quake sfx tends to clip like crazy, especially if there is a lot of action happening. Like the previous point, clipping at 11kHz is no big deal because the upsampling limits the damage to below 5.5kHz, so you almost get a limiter/softclipper for free. Whereas at 44/48kHz clipping sounds awful and must be avoided at all costs.

I tried working around both of those, by making the mixer fade in/out when interrupting samples, and adding a limiter/softclipper, but couldn't get something I was happy with. So, for QS, ended up with a 11kHz->44kHz resampler (FIR filter) after the sfx mixer, before mixing in music.
Upgrading to a resampler that can do 48kHz, supporting float output, and moving to floats internally would be nice improvements for sure. 
idea: try installing ffdshow, this should add support for many other codecs to DirectShow. It might replace the mp3 decoder and magically fix your issue. Not sure if MarkV will play other formats like OGG/flac if DirectShow is capable of it, but that could be worth a try too. 
Thanks, those are some good troubleshooting ideas, but...

I disabled the Wifi adapter, no change.
Installed ffdshow, no change.
I have no anti-virus running.

It seems to be an issue with the encoding/decoding.

And I'm getting some really strange results that I can't explain.

I'm using CDex 1.77 (just updated from a slightly older version) to rip directly from the Quake CD with various encoding options.

The default encoder is set to "Lame MP3 Encoder 1.32," and if I leave it on the default settings (a range of 128 - 320 kbps with auto sample rate), it outputs a 256 kbps 44100 Hz, 11 meg file.

Mark V loads that file in 7 seconds...

If I only alter the option to lock the rate to 64 or 56 kbps, the file size drops to about 3.8 meg, but the MP3 then takes 11 seconds to load in Mark V. What's up with that??

Locking the rate at 256 kbsp makes a 15 meg file that only takes 9 seconds to load....

If I allow a variable rate from 48-96, it encodes at 96, but it then takes 16 seconds to load....

If I alter the Hz down to 32000 sometimes I can get it back down to a 7 second load time with other altered settings....

Eh, I just can't come up with any one thing that's affecting it in a predictable way.

Well, I have better luck changing the encoder in CDex to "Windows MP3 Codec" which says it's "Fraunhofer IIS MPEG Layer-3 Codec." It is much more limited, offering a max of 56 kbps, 22050 Hz, but the MP3 comes out at around 3.32 meg and only takes about 4.5 seconds to load.

If I change some things around and encode with the same settings using Lame, the file seems virtually identical at 3.31 meg, but takes 7 seconds to load. There are some other options in the Lame encoder, like "VBR method" which I have no clue about....

I've tried making sure I don't include ID3 tags, and that seems to make no difference.

Well, I think I've hit a wall with my testing. The "Windows MP3 Codec" will have to do, and I don't think I'm going to get a better result without using a drastically lower audio quality.

It's just... weird. 
Did you check memory usage during the freeze, and whether any disk swapping is happening in Task Manager?

tbh I would just format/reinstall Windows at this point, but I have low patience for troubleshooting and it's not always practical 
Maybe one last idea ... is hardware acceleration on?

Almost all hardware has the ability to decode mp3 (mp3 is part of the MPEG-2 standard).

Even thought the option says "video", audio is part of video.

Worth a last try maybe ... 
I tried altering the hardware acceleration settings in WMP, but got no difference (I use the file that causes the 17 second delay for testing, because the delay is very close to 17 seconds every time, like clockwork, though I did also try my newly-encoded file that only causes a 4.5 second delay, but any difference in that one would probably be small).

Watching the tack manager, when I'm just sitting with Quake running in a window, it says Mark V's memory usage is right around 215,920 K. CPU usage hovers around 50% (I get around 0% just watching this web page without Quake running, though it can spike up to 50% when I'm dragging windows around a lot).

When I switch on External Sounds in Mark V, while I'm experiencing the 17-second delay, Mem Usage jumps up to 222,100 or so (and my second processor seems to show slightly less usage on the graph, probably because the video in Quake is frozen).

Then after the 17 seconds, when the music starts playing, the Men Usage goes to around 221,956 K.

Turning the music off again drops me back to the original 215,920 K.

These numbers are pretty consistent.

At any point in the process I can easily switch around to other windows, and it does not feel bogged down or like it's out of memory or anything.... The page file seems to stay pretty constant too. Right now it's around 437 MB while I'm not playing Quake. Running DX Mark V makes it go up to about 888. It goes to around 895 when I enable the music (during and after the 17 second freeze), and right back down to 889 when I disable the music.

Yeahhh, I'm not gonna try to re-install Windows, heh.

And again, only in Mark V do I get this bizarre delay (well, and in DirectQ, which I tried earlier). Using WMP or VLC or Winamp, the MP3 starts up instantly, after the program loads. *shrug* 
DirectShow mp3 playback in Quake engines is not new. Mark V was nowhere near the first engine to use it.

FitzQuake 0.85 + mp3 support --- November 11, 2009

ProQuake with mp3 playback --- July 2010

DirectQ - A post from 2012 where someone is asking about mp3 and MH states that DirectQ has had mp3 playback for "about 3 years".

Engine X - September 2010

Reckless (now known as Revelator) used DirectShow playback for his Realm engine (2010ish?)

And none of these engines were anywhere near the first to use it, probably an ancient MHQuake engine from 2003-2005 was. 
I'm pretty sure that I wrote the DirectShow code for DirectQ because I had this idea that I wanted to use DirectX components for everything. Older versions would have used the Windows Media Player SDK. You can also use MCI which is a little cleaner and more "C-like".

Unfortunately I'm in a similar situation to Baker and just don't have the time to put together experimental code to test all of this out. 
Well I tried Glpro438 just to be thorough, and the MP3 loading delay is the same.

On to other things, I saw the "smooth text" option in DirectQ, and that looked really nice. Mark V could benefit form that.

Also, r_waterripple is neat, but it moves too fast. If the "waves" moved much slower, it would look better.

Uhh, I was trying to make use of the Copy command today, but it failed me... I mean, for some reason, it did not copy the link someone had posted just prior to me issuing the "copy" in order to grab the link. Then I waited a moment and did "copy" again, and it still omitted the link (which was visible in my console), in addition to the thing that was said just prior to the "copy" command again (which was just some chat text).... I can't seem to reproduce it now. I'll mess with it when there are people on the server again....

Here's the section in question. There may have been other things happening in the console farther up, so I don't know if there were any weird characters or what...

Gunter: what the link again?
Sgt-PieFace: cobalt PMed you on the forum
Sgt-PieFace: for this server I think

Copied console to clipboard
Sgt-PieFace: wana stop by RN? me and cobalt are there


There was text in both the blank spaces in my console. I'll try to do more testing. 
1) "copy" copies the context of the console --- like "You've got nails" "Host Error" ... whatever.

Maybe I described what it does poorly.

But if you need some of the text in the console -- it copies the whole thing and you can paste it into notepad.

Fine tuning the copy ability further would be a PITA.

2) Smooth text.

Smooth text is for scenarios that would cause stretching and the make the console look terrible.

ProQuake uses it when the someone is using an odd combination of resolution + "2d resolution".

At some point Mark V will likely have smooth text.

Notice that ProQuake has the very superior "console width" option in the discrete "advanced settings" menu.

Well, that knocks the snot out of every other Quake engine because the
a) setting is easy to use
b) offers a few different choices easily
c) and the text looks good every time

(* DirectQ might have had a similar feature, I can't recall. Even if it did, I wrote my mine first ;) Haha )

But yeah, Mark V doesn't have that option -- solely because there were bigger fish to catch.

3) r_waterripple is neat. I forgot about that feature. It probably is a bit too fast and lacks customization. Mark V has a few experimental things like that which are defaulted off which are like that. 
For this kind of thing I always prefer to see it controlled by a fractional value of the cvar rather than adding an extra cvar. So maybe r_waterripple 0.5 for half speed, or would that make more sense for height of the ripple?

r_waterripple really depends on water surfaces being subdivided too (and is sensitive to the value of gl_subdividesize). 
I don't know if you have seen this, but as someone who maintains a QuakeC code base, you may find this interesting ...

Type "tool_inspector" in the console. Type impulse 9 to give all weapons.

Change the information seen by selecting a different gun.

Examining map issues or QuakeC problems under some circumstances becomes far more convenient. 
And one last thought since you do coop,

Mark V has a per player coop scoreboard if Mark V is the server. Defaults on. It's one of the sv_ options. 
Yeah, I understand how the Copy command works -- I was fine with copying the entire console to be able to also grab the link. The problem was, the Copy command left blank spaces in what it copied, and I didn't get the link....

In regard to that "console width" slider in Proquake, Quakespasm does it better with that nice "scale" slider. It seems to adjust all the things that I am setting manually in Mark V:

scr_sbarscale 1.55
scr_conscale 1.55
scr_menuscale 1.55

But yeah, that tends to make the text a bit jaggedy.

I think we already get the full scoreboard like that in FvF, because it runs in kind of a hybrid Deathmatch+Coop mode (it's kind of like team Deatmatch against the monsters). Well, FvF can be voted into regular Deathmatch mode, but people seem to prefer the Quest mode.

Wow! I like that undocumented tool_inspector thing. I think I will definitely have use for that. 
i would recommend scale values that are whole numbers like 1,2,3, etc. Much clearer looking text. 
@gunter - A one-factor master scale cannot adequately address a four-factor scaling problem.

It'll just offer a lot of different ways for most of the possible settings to get jaggy text and scrunched 2D graphics.

LordHavoc and R00k were both on a server one time talking about engine development topics and got into a long conversation about 2D scaling challenges. I didn't even know how compile a Quake engine at the time, and stopped playing to listen to their fascinating engine conversations.

The 2D scaling conversation was the conversation that really drew me in -- at one point in the future I took what LordHavoc and R00k said the problems were and drafted up a blueprint to address each bullet point in ProQuake -- I had to rewrite all of the 2D rendering mechanics in ProQuake, the text renders smoothly with any setting.


Co-op scoreboard. I meant for use with things like releases like Travail or Quoth or Arcane Dimensions or the Mission Packs and such.

Coop-oriented mods like FvF or RQuake already have that taken care of. ;-) 
Back On Fog 
Hmm, I have another interesting note about the fog in the DX version. If I turn gl_overbight off, I seem to get 2X the number of fog bands on lighted areas of the wall. This makes it look better because it's a smoother gradient... but it's weird that it does not show up on unlit areas of the wall. He's a screen comparison, again with gamma ramped way up and in an area that makes the fog look extra ugly:

In (my older version of) GL Mark V, I do not see the same thing happen when toggling the setting. Ah hah! That's one reason why the GL version fog looks better -- it ALWAYS has those extra bands on the lit areas of the wall. They are just really hard to see because they make a much smoother gradient... but I see them now that I'm looking for them.

In summary:

GL version has 2X the number of fog bands on lit areas of the wall, always.

DX version only has 2X the number of fog bands on lit areas of the wall if gl_overbright 0.
gl_overbright 1 removes the extra bands and makes the fog extra ugly due to a less gradual gradient. 
Copy Command 
Confirmed that it's the weird Quake characters that cause blank places in the COPY'ed text.

Didn't test all the various characters, but if you use the one that kind of looks like the left side of a bar, like this for your name (imagine the (= =) are the weird characters):


Then anything appearing on that line after the S would be blank in the COPY'ed text. 
+1 ... Great bug report. Shouldn't happen.

Using this can you hover your mouse over the appropriate character and tell me the number.

I need to know the character code. My caveman-like brain can't quite imagine which specific one you refer to. 
128 is the character in question which will blank the rest of the line after it appears.

Additionally (you didn't think I would neglect to test everything else, did you? heh), the following characters will insert a newline in the COPY text:


Also, when you get around to fixing that, please stop it from actually committing the name change every time you change one character, because my console looks like this just from using backspace and typing characters in the name field:

Gunter's name12 renamed to Gunter's name1
Gunter's name1 renamed to Gunter's name
Gunter's name renamed to Gunter's nam
Gunter's nam renamed to Gunter's na
Gunter's na renamed to Gunter's n
Gunter's n renamed to Gunter's
Gunter's renamed to Gunter's 1
Gunter's 1 renamed to Gunter's 12
Gunter's 12 renamed to Gunter's 12n
Gunter's 12n renamed to Gunter's 12na
Gunter's 12na renamed to Gunter's 12nam
Gunter's 12nam renamed to Gunter's 12name
I did say you were a quality beta-tester. ;-)

At some point in the future I will refine the namemaker to commit the change "all at once", but it is better than the old system of committing the name "all at once" and having to choose "Accept" and accidentally hitting ESC and losing the name you spent a few minutes making. It's always been on the todo list to make that less spammy. 
I don't suppose you could give me some kind of test build that would spit out some error messages when it crashes (or save it to a file)? Because it crashes a lot! Well, tonight it seemed that way.... But sometimes it goes for quite a while without crashing, seeming to run just fine. It seems to like to crash right when a map first loads, after exiting the previous map. Perhaps some maps seem to trigger it more than others, like e3m2 seems mighty prone to crashing.

Sometimes it just exits, and other times I'll get a Windows error box asking if I want to report it... and I can check more details about that, but it's mostly incomprehensible gobbeldygook.

It'd also be nice to figure out why the GL version crashes right away too... 
Well, we have back to the old catch-22.

I don't have time to commit to engine development now (engine development is extremely time consuming), nor will I have that kind of time in the near future either.

Maybe some time in the 2nd half of 2017 I will.

This engine is in beta, and is not being actively developed at the present time.

It's not the first big gap of non-development of the engine either.

Quakespasm is a stable release. There's also Qrack and such as options.

You might try FTE, it's pretty damn nice.

You can tell Spike that "nqconnect" isn't working in this build I linked :(

On 2nd thought, nevermind. I forgot you have an Intel 845, FTE is pretty big on the shaders and such, althought it does have a Direct3D version too.

What would Spike say? "Your mileage may vary" ;-) 
Kinda Offtopic 
You can tell Spike that "nqconnect" isn't working in this build I linked :(
What would Spike say? "Your mileage may vary" ;-)
I would also say 'works for me'...
(I actually bothered to test that just now!)

(also, you can drop the 'nq' from 'nqconnect' if you want to explicitly specify the port, hurrah for nq+qw using different default ports! or just use the server browser, but whatever)
(also that first build contains both gl+d3d9 renderers, you can switch between them in the menus, and yes with basic settings it should still work without glsl, but certain features obviously will not). 
See -- Spike Is On The Ball! 
Sorry, I have 10 copies of FTE in my Quake folder. I blew it, the "fteqw.exe" in my folder is out of date and quite old.

@gunter: FTE supports external textures and if you like options, compared to FTE, Qrack doesn't even have any options.

The number of features FTE has is off the charts.

And should have almost every possible feature you have ever seen. 
Oh my... yes, FTE certainly does seem to have a ton of options. And the GL version runs just fine for me.

At the "nice" preset, I get 70 FPS, but at the "real-time" one I get like 4 FPS -- it may be one of the effects like that oldwater thing like in Quakespasm, but I don't know the setting to toggle it in FTE.

Is there lots of documentation about all the console variables so I can test stuff? Or I guess I'll have to go in and see what all the menu settings do....

The MP3 music seems to start up without delay... though it doesn't seem like it's playing the same tracks. hmm.

I will play around with this and see if I can get it set up how I like. I could sure use some exhaustive documentation! *searches around FTE site* 
There's a wiki for it that has some information. 
Setting my Contrast really high makes most things look really good -- the colors are vibrant and the walls aren't all bland. And it allows me to use a lower Gamma setting.

However, any fullbright textures become completely crunched and actually lose their contrast -- they just appear as one (way too bright) color, mostly, except for in the most contrasting areas (for example, torches).

gl_fullbrights 0 fixes the problem, making the torches (and any other fulbrights) again look nice even with high contrast, but of course that turns off the neat fullbright effect.

I already have both gl_overbright settings at 0

So, to keep the fullbrights from looking nasty, I have to crank the Gamma up higher to make things bright enough, but that tends to make things look a bit washed out and bland...

I saw above you said, "at some point I'll try to implement a sneaky tactic of shoving gamma+contrast into the textures (and hope it looks right). But that's for the future. "

Was that implemented? If so, the easy fix would seem to be to NOT have contrast affect any fullbright textures. Then everything would look good. I don't know if it would otherwise be possible to have "contrast" not affect fullbright textures if contrast is being controlled by hardware....

Also, just a thought (for potential future fixing): sure, the shadows are a hack, but a tweak that would improve them is to make sure they are not drawn at all if the distance to the model is greater than a certain amount. This would stop them from dancing around on surfaces way below where the model is actually standing (this is one of the common issues with the hacked shadows). 
I'll keep that in mind for future consideration.

Spike has caused the need for a Mark V update with ipv6 and (likely) ProQuake with ipv6, by making the code easily available and saving me a lot of time.

It'll need tested and one main concern I have is Windows XP.

Not sure when it will happen, but I expect it to be soon.

Because metlslime pointed out a quick way to solve your DirectX + model transparency thing, seems likely I can put that in there.

And if I am lucky, your clipboard interfering evil characters fix/scrub because that should be a 2 minute fix (probably a char codes 128-160 dequaked (-128) to control chars issues).

Can't say exactly when. I don't really have any time, but I've been sizing it up. 
Ipv6 Maybe Sooner Than I Thought 
Maybe sooner than I thought.

I just used Mark V to connect to "Quakespasm Spiked" R4 via ipv4 and then ipv6. 
ipv6 ain't hard to support, its just a different/bigger sockaddr structure with corresponding different address family value.
name resolution is a little more involved (in part because colons are used in ipv6 numeric addresses, which necessitates square-brackets where ports were normally specified with colons).
operating systems have annoying hybrid socket support defaults, so you need to be explicit about that in order to not conflict with ipv4 sockets (and xp doesn't support hybrid sockets at all, so I went with dual sockets with qss).
broadcast doesn't work with ipv6, its all multicast, so instead of flagging a socket as able to send broadcasts, you have to flag a socket as willing to receive multicast packets to various addresses.
that's about it, really. the rest is just datatypes and glue.

really though, right now ipv6 only gets you support for public addresses when servers are behind ipv4 cgnats (but with their own globally routable ipv6 address).
mobile phone versions of quake may need ipv6 (iiuc, apple mandate that ios apps support ipv6).
other than that, no non-mobile isp would dream of skipping ipv4 yet, making ipv6 support nice but in no way necessary.
single-socket-servers on the other hand... 
360 Controller Support 
was added to quakespasm and it is a very good implementation, could this also be added to mark_v? 
360 Controller Is Dead 
Anything is possible in the 2nd half of 2017, but Mark V is not SDL based like Quakespasm, it isn't like it could use the existing code in any shape or form.

re: 360 controller

They don't make those anymore -- the xbox 360 controller died when the xbox 360 died.

They'll never manufacture them again. 
I'm sure you can get a second hand one. Personally when I need a gamepad on PC, I use a Dual Shock 2 with a Madrics Superbox 3 Pro - yeah, fancy name for a little plastic thing. Works good and I prefer the shape of PlayStation pads. 
360 Controller 
Just another way of saying xinput support. That's the standard controller library that's replaced directinput on windows for the past few years, you'd be hard pressed to find a PC-compatible gamepad that didn't use it. Supporting the 360 pad is supporting gamepads in general, at least on Windows. 
Biased Opinion 
90% of the work in implementing QS's controller support was stuff that is independent of the SDL2 gamepad api - Subjective stuff like deadzones, easing functions, choosing good defaults and playtesting them. Also making the menus usable with the controller. So this code could still be useful if you like how I did it.

SDL2's gamepad API was, I believe, largely a clone of whatever the modern windows API for gamepads is (Xinput?)

re: 360 controllers dead
true but I don't think this affects software much if at all. 
It would be great if you could include some kind of error logging in a new release, so that we could get some idea of why the GL version crashes instantly as soon as I try to load a map (it runs fine up top that point... in the console and menus).

And maybe also see why the DX version crashes intermittently....

Quakespasm, FTE, Qrack, etc., all work fine in GL for me. I really hope Mark V can be fixed to work in GL for me too. 
Xbox 360 Controller 
They have them at Newegg. I was just looking at it the other day. It's on sale for $30 with "free shipping". 
@ericw - I think your code is pretty tight and well written. Mark V doesn't do DirectInput or XInput, so would be hella lot of work for Mark V support. Definitely not part of a group of 4 small updates, each that don't take too much time.

@gunter - I don't have much time, we'll see. I private suspect your graphics card can't do anything except 16-bit color, are you actually able to use, say, Qrack or Quakespasm in 32 bit mode?

@others - All I am saying is that my interest in a discontinued controller limited to pawn shops, ebay, second hand sales is "meh".

If someone knows of a worthy controller that actually has a future ... 
xinput is the future (for now). The specific type/brand of controller using xinput shouldn't matter much. 
Strange Vitriol For A Pad 
I don't understand, seems like un-needed hostility? Maybe I'm misinterpreting your tone though.

You can still get 360 pads brand new here in Europe, they're marketed as a 360/PC controller.

They're pretty much THE standard controller for playing games on PC, even more than the xbone, PS4 or any number of PC-Specific pad.

You could have just said "it's too much work, sorry" or "it's not a priority". 
Supporting xinput, as far as I know, will allow you to support basically every logitech controller for the past few years, the Xbox One controllers, and the generally established hacks for the DS4. So, basically all the controllers.

Speaking of hacks; aside from the tricks people are pulling to get the DS4 to work on PC, there are also plenty of wrappers out there that will make a DirectInput controller work like an xinput one for most purposes, so there's not much need to support an (actually dead) second system of controller.

Honestly though... how necessary is controller support? Does anyone here, or anyone that someone here knows, actually use it in QS? I certainly don't, and I can't say I see the appeal either... 
Not Discontinued 
Isn't it pretty much the standard for PC controllers because of support built into Windows? 
The only Quake engine that seems to report the BPP in the console is Quakespasm, and it tells me "24-bit" when I try set it to 32 bpp (either in the menu or by command line).

Of course it reports "16-bit" when I change to that....

How would I verify that any other engine is running in any certain bpp?

Well, I can do more than 16 bpp in any case... (what is it, the stone age? :) 
I Sometimes Play With A Pad 
when I just want to sit in front of the TV playing games I whack on some Quake.

I know KB+M is the best way to play but I originally used to play the game keyboard only when I first got the game... :P 
@gunter - that clears up possible causes of the issue.

@fifth/@rick - I'm not against gamepad support.

As long as the controller support code works with current/future devices (@johhny). 
It Does/will 
I don't claim to keep up with consoles ...

Does the Quakespasm controller support work with an XBox One Controller? 
According to this reddit post the xbox one controller should work with any game that uses XInput, which SDL2 is wrapping, so it should work in QS. I don't know if anyone has tested it though.

Anything listed here should work out of the box with qs, there is also a community mapping file for more support. 
Ok, that clears up things quite a bit -- it supports a wide array of devices.

When I hear "xbox 360 controller" immediately I think "But the XBox One came out back in 2013?" 
@gunter -- you may discover the Dopa maps surprising automatically download now for supporting clients.


/Inside joke, gunter will understand. 
Uhhh... does that mean Polarite updated the server so it will do that now? Hm, yesterday Trans did say he thought he saw Darkplaces download something.... Neat. We'll have to test this more.

We do indeed have the DOPA maps installed on and they work (almost*) perfectly for FvF Quest mode. So everyone should come give it a try! You can use the VOTE menu to activate the custom maps.

* One thing mappers often neglect to do is add Co-op spawn points. DOPA has this oversight... so all the players try to spawn on the one Single-Player spawn point, resulting in undesirable things happening, like people getting pushed into the floor. That can be really bad when there's a lava pit below the floor, heh.

Another "gotcha" you gotta watch out for are trap rooms that lock behind someone when they enter, and if the person dies in there, there's no way for anyone else to get in, so progress is blocked on the map. DOPA contains 2 areas like this, but I work around them with QuakeC code by actually relocating buttons and altering properties of doors on the map, so that the roadblock is moved out of the way or opened from the outside.

But yeah, everyone should come play FvF. The server is almost always in Quest (co-op) mode, so it's newb-friendly.

(Heck, while I'm self-promoting, here is also a link to find out about my Pogo Piggle games for Android, which everyone should also play :D ) 
Hm, well... we tested today and maps did not automatically download to Darkplaces.

I guess you may be talking about something that has not yet been implemented...?

*scratches head* 
All the old methods of stopping Demos from playing at start up no longer work

It's in the menu so anyone can do that. The cvar is host_startdemos 0 (default 1). 
Wow, that's a really old issue I reported back in 2014, Baker, heh. I think that's been fixed for a long time.... I did find that menu option (that's probably the newer addition). It's very handy.

Probably my main hope for a soon release would be Proquake-positioned Centerprint and "Rankings" scoreboard, so they don't obscure your view right in the middle of the screen.

Actually, I'm not sure exactly how ProQuake's Centerprint positioning works... It seems like if your centerprint message has more than 3 lines or so, it is placed up high, well out of the way of your view. But if your Centerprint message only has 1 or 2 or 3 lines (using \n) it places it down lower near the center of the screen... but still not right in the middle of your view. Maybe it checks to avoid that specifically rather than just moving EVERYTHING up to a certain point (though even the menus are positioned higher). In any case, it's much preferable to having stuff printed right over your crosshair position. 
Can you do a screenshot demonstrating the centerprint issue you are having? My imagination isn't working. 
(Small screenshots just to illustrate the positioning of Centerprints)

First comparison is the standard FvF Vote Menu. You can see Proquake keeps it up high, not blocking the center of the player's view. Obviously most players aren't going to be running around shooting things with the Vote menu up, but there are other centerprints that happen in the game which have the same issue -- notably, all the FvF splash text stuff when a level first starts... and sometimes there are monster attacking you when the level first starts, so you need to be able to aim :D

Second comparison is me pressing the TAB key to show the scoreboard while the vote menu is still active. I just noticed that Mark V hides any centerprints when you are viewing the scoreboard.... I'm not sure I like that behavior (is there a setting?). A player might miss a centerprint message when doing that.... Well, Proquake shows both things at the same time; yeah, that can end up with overlapping stuff, but a player can easily release TAB when he sees a centerprint pop up.
Anyway, you can see that again Proquake moves the scoreboard up near the top (probably a bit too far in this case, because that can block the second and lower chat line -- there's still room at the very top for one chat line). If there were 4 or 5 players in the server, the Mark V position (which is most likely the standard for Quake) would again block the center of the view, where the crosshair is.

The final comparison shows that the position remains the same when it's a short centerprint with only a few lines (the crosshair positioning may be off a bit, so the relative text position may be exactly the same... or it may be slightly different... not sure). Either way it doesn't block the view, so that's fine.
I'm not sure exactly how Proquake decides where to position stuff, but it seems like if there are 4 or more lines in a centerprint, it puts it way up at the top, but 3 or fewer lines are shown back at the standard location.

These issues become worse if the text size is increased by scr_conscale (I shrunk my text in Mark V to match Proquake, but I usually have it larger, so centerprints sometimes go well below crosshair level). 
The "Fine-Tuning" Problem 
@gunter -- re: centerprint position

I connected to your server and tried some of the menus. I thought it looked pretty good with the default settings in both Mark V and ProQuake. If I mess with settings in either engine, I can make it not look good in either of them.

Centerprint consistency has always sucked as tool available to the QuakeC modder, even with GLQuake. If you use a big resolution, the text stops being where it was supposed to be and might even be in annoying place.

If I loaded up Quake with the intended resolution of 320x240, your FVF centerprint will be all over the crosshair. "Gunter? Why u hate DOSQuake so much! Is only real QUAKE! Quake CD comes with DOSQuake, is no GLQuake on Quake CD! GLQuake is a lie!!"

Mark V centerprint starting position is pretty consistent across all video resolutions, but just like original GLQuake if you start changing settings or resolutions it affects the placement (but at least Mark V calculates it the same regardless of any settings/resolutions you can pick).

The centerprint position also relates to the finale printing. I worked long and hard with NightFright to get that all positioned properly and independently even for single player releases like The Rapture that prints incredible gobs of finale text (it's like a mini-thesis, it's that long) --- while also taking into consideration multiplayer mods.

That's called the "fine tuning problem". If you "fix it for one" (combination of settings) then you just "break it for another". 
@gunter - Re:scoreboard 
FitzQuake is pretty much geared to display the multiplayer scoreboard in the center of the screen, as you've noticed. Just like how the menu is very center of the screen in FitzQuake.

A ton of centerprint like a centerprint-based menu on, say, a RuneQuake server, clashes with the FitzQuake multiplayer scoreboard worse than original Quake.

Pretty much makes the scoreboard unreadable.

I tried the Qrack draw a background behind the scoreboard (didn't look Quakey) and a few other thoughts to avoid the problem before realizing no good answer was possible -- so not drawing the text was the only option.

But notice it still does print the chat messages with the scoreboard up! ;-)

I know those are important so I salvaged what I could. 
"Centerprint consistency has always sucked as tool available to the QuakeC modder"

Yep, that's pretty much it.

I can move centerprints DOWN out of the way by padding it with nnnn, but I have to be careful with that, because I could move it right off the bottom of the screen depending on resolution and text size settings of the client....

But there's no way to move it UP out of the way... which is why I greatly prefer them to be placed high on the screen by default, like Proquake does. There's no danger that they will be TOO HIGH, no matter what the client settings.

Since I can move things down but not up, I think it would be great if all centerprints were positioned like 4 text lines down from the top of the screen, no matter what (even for one-line centerprints). There's really no reason for them to be centered vertically anyway.... As I have said, it can block part of what you are trying to look at, leaving all that all that unused free space (resolution and text size permitting) near the top of the screen which could be used instead.

Of course, not all clients do it that way, but Proquake was "the standard" for many years, and that's how it works (I would suspect for the reason I mentioned, as Proquake is supposed to have enhancements for deathmatch play, and not having your view blocked by text is good when in deathmatches).

But yeah, not all clients do it like that....

All these variations in different clients is also a reason why I name Mark V as the "officially recommended" client for FvF -- if I get the majority of players using the same client to play FvF, then I know they are seeing the same thing that I see.

Anyway, my main point would be: There is really no reason centerprints need to be vertically centered. It has potential negative impact, whereas putting it higher on the screen (like at a set position of "4 text lines from the top") has no negative impact. 
There actually is a reason, it's in the Quake manual:

Certain messages appear inconveniently in the middle of your view. These are always important, and you do not want to ignore them! 
And ironically, the manual also states that messages that appear on the top of the screen are non-critical, ignore them if you please. That includes chat. 

*goes and finds Quake manual to check*

Well, I'll be damned... it does say those things.

Funny that id intentionally made centerprints "inconveniently" located to make sure the noobs read them, heh. But I think at this point they are no longer "always important," sooo.... they don't really need to be inconveniently in the middle of your view anymore :D 
I'm not certain that I agree with this way of thinking about it.

What you're basically doing is taking a default feature of Quake, using it for a purpose for which it's not intended, then asking for it's default behaviour to be changed in a way that would suit that unintended purpose but at the expense of it's actual intended purpose.

That's the kind of thinking that led to the horrific collections of hacks that polluted Quake engines and mods years ago, and which culminated in Nehahra. It would be a lot more productive to open a dialog about creating a new message type that would suit your requirement. It's 2016, we understand things better now, and we don't have to rely on ugly hacks to get stuff done any more. 
I'm Inclined To Agree With MH, 
not particularly for the reasons he mentioned, though they're perfectly valid, but because there are still Quake n00bs who might still need centerprints to pop up in their faces. Just a couple days ago there was this guy at QuakeOne asking how to open the megahealth door in the water section of E1M1... 
Even for non-noobs, don't underestimate the extent to which one's muscle memory can be trained.

I speak from bitter experience here: For every 1 person who thinks it's good there will be 10 who want it back the way it was. 
there will be 10 who want it back the way it was.
Good point. I know very well the flak Darkplaces or HD textures can get around here... because "it's not Quake, hurr". 
I think you should learn to properly parse people's arguments against the things you like, instead of simply disregarding them as "something stupid, hurr". 
I heard their arguments. I don't agree with them and I don't dismiss their tastes either, unlike the other way around. Anyway, that's not the point. The point is the Fitz family of engines is more geared towards conservative Quakers. Therefore, changing things too much might not be a good idea. 
I think you should learn to properly parse people's arguments against the things you like, instead of simply disregarding them as "something stupid, hurr".

Nope, way to miss the point.

Whether one likes it or not is irrelevant. I've been here before. You do a nice particle system and the first thing people will ask you is "how do I get the old one back?" You do a nice HUD and the first thing people will ask you is "how do I get the old one back?"

This is something that really does happen. 
Uh-huh, except in this particular case we were talking about a very specific conversation where people actually managed to make sound arguments when they weren't too busy throwing insults around. 
My discussion with Gunter wasn't a philosophical one. It's an aesthetic one. When I was looking to solve the centerprint issue, I experimented with several different ways and loaded up about every engine including DarkPlaces to assess options.

Centerprint in the ProQuake position makes it so ...

1) it looks really silly when you go to the menu and have white text sitting above the menu.
2) looks silly when you press TAB to see the multiplayer scoreboard and have white center print above the scoreboard.

So to avoid that I'd have to move ...
1) The menu
2) The scoreboard
3) Other stuff

And it would no longer look like FitzQuake. 
I am sympathetic to the issue of centerprinting positioning, by the way.

I've worked on mods that have used centerprinting (RQuake, xCTF, Team DM) and centerprinting positioning has always been a thorny thing.

And there are some classic single player mods that use a lot of centerprinting (see Quake Terminus mod list or Frika's Q-Pacman).

I went out of my way to get Mark V to handle centerprinting consistently and tested a lot of different stuff to make sure it looked great, even with mods that have centerprint menus.

But the ProQuake position for a FitzQuake engine is a case where the cure is worse than the disease.

/Maybe at some point some sort idea for a viable solution will emerge. 
Couldn't you solve the overlap issues by hiding centerprints when one of the conflicting menus is visible? They do show up in the console as well if I'm not mistaken so if a player missed one it wouldn't be the end of the world. 
Stock GLQuake doesn't draw centerprints if the menus are visible; look in SCR_CheckDrawCenterString for a check for (key_dest != key_game); engines that change this are also changing the behaviour from stock GLQuake.

So overlap issues are actually not something that occurs unless someone has explicitly modified the engine code to make them occur. 
Ah, so it's the other engines (rather than original GLquake) that do it differently in regard to hiding centerprints when menus are open. I'm mostly fine with that functionality; my only concern was that a centerprint may go unnoticed if someone is staring at the scoreboard. But still, I don't hate that behavior.

My main concern is the positioning of centerprint on the screen. So to address things people said in regard to that (assuming that's what they're talking about):

"What you're basically doing is taking a default feature of Quake, using it for a purpose for which it's not intended, "

What? The purpose of centerprint is to deliver information to the player. That's it. And that's what all Quake mods use it for.... Maybe the information is above and beyond what id originally thought of (like an underwater air meter, for example), but it's still just delivering information to the player. Indeed, centerprint is heavily used in every Quake mod I can think of to deliver information to the players (it's pretty much THE tool we have to do so -- console prints are very quickly swallowed up if a lot of things are happening). But it can have negative issues, as I've mentioned.

Yes, the original resolution of Quake was tiny, so there really was practically no choice but to have centerprints right in the middle of the screen, but now we can run Quake in all kinds of resolutions, and we have MUCH more screen space available, so there is no reason it still needs to be in an area that blocks potentially important areas of the view.

It's not as if text popping up closer the top of the screen is going to go unnoticed by noobs -- UNLESS they are in the middle of a battle, in which case, again, it it detrimental to have text blocking their view when they are trying to aim!

This has nothing to do with muscle memory (I guess you didn't mean that literally...), and it doesn't make any radical changes like a new HUD or particle system -- it's just more optimal positioning of text in the available screen space. Yes, if you make changes that cause things to "not look like Quake" then people will complain. However, I wager NOT A SINGLE PERSON has ever complained about ProQuake's better (IMO) centerprint positioning, and ProQuake was "the standard" for many years....

Perhaps the most ideal solution would be a setting that would control centerprint positioning -- placing it either centered in the screen, or just sticking it about 4 lines from the top of the screen. But I really doubt anyone would prefer to potentially have it blocking their aiming rather than up near the top, out of the way....

Again, I'm not sure everyone is talking about the same issue (hiding centerprints when the scoreboard is up is fine) -- I'm only referring to the vertical positioning of the centerprint text on the screen. This really does not reach the same level of new HUDs or particle systems that alter the look and feel of Quake substantially.

Of course, I do like "rounded" particles rather than the giant square pixels in old software Quake, heh. 
Hahaha... ok... REVELATIONS.

I decided to go and look for myself in the original (that's DOS Quake.exe 1.08 and original GlQuake whatever version it was) executables to see for myself....

So you can basically forget all my well-thought-out and valid arguments for why ProQuake's centerprint positioning should be used. My new argument is:

"You've changed Quake's default behavior!! I don't like it!! Change it back right now!! Too many changes are a bad thing!!!!!1"

Yep, that's right, original Quake's centerprint positioning is IDENTICAL to ProQuake's! you can see in this screenshot of original DOS Quake in all its pixely glory at maximum resolution of 800x600:

It's also identical in that if the centerprint is 3 lines or fewer, it starts more toward the center of the screen, but if it's more lines than that, it appears up near the top of the screen.

Also, you can see that the scoreboard is stuck up near the top of the screen, just like those ProQuake screenshots I provided earlier (and the centerprint text is still visible when scoreboard is up, but not when the Menu is up -- is that what people were talking about?)

Actually, again, I don't hate that centerprints are hidden when the scoreboard is up, but I don't love it either....

And don't actually forget all my previous arguments, heh; they are still completely valid! I still would prefer ALL centerprints, even those of 3 lines or fewer, to be positioned closer to the top of the screen... But I think I can perhaps force that to happen by padding the bottom with empty lines... hm, I'll have to test that.

But yeah, scoreboard and centerprint positions should be just like in ProQuake, which is just like in original Quake, because:

1. It is more optimal for all the reasons I have mentioned about obscuring the important part of the view,


2. OMG, you changed Quake's default behavir and I don't like it and youneed to fix it right nao!!!1!!

Has Gunter won the centerprint wars?
Tune in later to find out!
A new version is going to be out in the 24-48 hours. 15 changes. Includes DarkPlaces/FTE-like "apropos" ability, which every engine should have.

/Wish had time to fix NightFright's Malice "knockback effect" issue, since he did so much mod compatability testing/bug resolution verification. AAA+++ beta tester.

/So is Gunter/Fifth/Spy/OTP/Pulsar and so many others. Gunter may argue too hard at times, but he sure tests stuff great ;-) 
I argue hard, I bug-test hard!

Nice! New update.


What is "apropos" stuff?

Here's a quickie "bug" I just encountered. I was trying to type "%complete" and it came out as "100omplete" because apparently %c is a macro for my remaining Cells.... And I guess there are many more such macros. There should be a much more rare macro indicator, like %% instead of just %, perhaps.

I'm preparing a 50-page powerpoint presentation to support my position on this.... I'll post it later! 
Apropos Xxxxx 
is a console command that lists all cvars containing xxxxx.

ex: apropos particles 
I Lied 
Malice is fixed too. 
Apropos Apropos 
As some of you may know, I'm French and "� propos" means "about" in french. Why not have settled on an About command instead? I mean usually, all command names are in english... 
Hahaha, you're on to me. You are ruining everything! 
Hyar Hyar Hyar!! 
But seriously, it was a genuine question. Was someone French on the team of the first engine that implemented this command or something? 
I think Apropos is just one of those words that the Folks Across The Channel nicked off with a while back and started using for themselves.

Interestingly, Google's dictionary functionality suggests that Apropos doesn't really mean "About", at least not in English. It says "with reference to; concerning.", which is still appropriate to some degree but perhaps not the best choice of words. 
Ah, "find" looks like it could be useful.

Uh, it does appear that centerprints are being shown when the Menu is active. Standard Quake doesn't do that (and it does look bad).

Also, I think maybe %c% would be a better format for the macros. That ensures that they only occur when someone intentionally wants them to.

Bug. Try this: take any map, rename it dm6.bsp and put it in like quake\test\maps\dm6.bsp

Now run Mark V -game test

Go to start a new single player game through the menus.

It will dump you onto that "dm6" map instead of the Start map. I saw this happen with another test map too, which was named like fvf_hallo.bsp

Actually, I'm not sure the name of the map is important. It seems to do this no matter what the name.... I've seen (and mentioned) this happening before, but I haven't give it a thorough testing. But it should be reproducible.

But perhaps this may have something to do with the "autocomplete" feature that looks for map names automatically? 
Loc support -- Mark V has nothing to do with it nor how it works. Load up DarkPlaces, ProQuake, Qrack, FTE or ezQuake type "say %h" in the console and see what happens. As I understand it, id Software wrote the spec.

Automatic start map support -- if you use -game and that gamedir has maps, Mark V is going start those instead if you are using a gamedir when you do single player new game. Mark V is oriented towards single player releases. So if you have a gamedir and it has maps named ruinsstart.bsp, ruins1, ruin2 it is going to load ruinsstart.bsp. If it only finds 1 map, it will load that one. 
Automatic Start Map Support 
It's worth noting that this was discussed around the community some years ago, and the described behaviour was a community consensus decision. 
Hm, I see.

Well, "the community" was WRONG about this :D

Where did this discussion take place? Got a link? I'd like to read over it and see how this "consensus" was arrived at....

This is bad behavior, altered from standard Quake, and uncontrollable by the user (specifically, I don't WANT to go to a custom map when I go to start a new single-player game -- and if I do want to, I will change to the specific map myself). If I have several maps in my mod folder, it just picks one seemingly at random? Or does it work by alphabetical order? I don't know, but you can almost guarantee that it's not going to pick the specific custom map I might want to play, meaning that I'll have to change it manually anyway. In a folder full of maps, it's not likely to select the correct starting map for a custom episode either.

Testing that.... Yep. Looks like it's just grabbing the first map in alphabetical order... that is, unless there is any map that contains the word "start" in the name, in which case it prefers that. If you have 2 or more maps that contain the word "start" then it favors the one that's first alphabetically....

Of course, if there is a custom map named "start.bsp" for a custom episode (like with DOPA), then that will start automatically anyway.... that's standard Quake behavior.

All that this functionality does is ensure that one single map -- whichever has the preferred name in your folder full of maps -- will the the one that starts up every time you go to start a new single-player game. So unless the end user is wanting to play the same map every time, there is no benefit, because he'll still have to change maps manually after starting up.

The standard Start map is the starting map for various reasons, such as being small, without a lot of entities, so it loads up fast. This functionality could result in a larger map being selected as your single-player start map, which could take longer to load (ok, probably a barely noticeable delay in most cases, but still undesirable behavior).

If I'm going to have to rename maps so that the the one I want will load up, that's no different than the standard behavior of having a custom "start.bsp" in your maps folder.

Well, this isn't exactly a CRITICAL issue, but I will say that I absolutely hate it :D

And this isn't just "in theory" --

It has been happening to me for a while, every time I want to do some testing, when I start up a single-player game, and I had no idea why it was happening, and it forced me to have to manually switch back to the Start map....

Now let's hear from all the people who are actually making use of this feature often, without any issues of having to change maps manually anyway, because it selects the correct map they want to play every time :D

All I would really ask is an option to ENABLE this feature for those who might want it. Of course, I feel it should be DISABLED by default -- this is a pretty drastic change from standard Quake behavior. And it's a solution for a problem which doesn't exist -- you can already name a map start.bsp if you want that one to start by default.

And it further seems unneeded, because I see that you have added the really NICE functionality of the console command "maps" to see a list of your custom maps, and "map XXX[tab]" to auto-complete a map name. Now that's some fine, elegant, helpful, non-intrusive functionality right there. Love stuff like that. ;)

I suppose the ideal thing might be a map browser of some kind where you could scroll up and down the list and select the one you want.

And quickly checking my old Quake.exe... nope, no macros in original Quake or GlQuake (they print literally "%c" instead of your cells value), but it is in Proquake. So it's just one of those things someone came up with, and everyone imitated. But it could be more optimal in various ways.

Eh, not a major issue, but I don't care for it, since I don't use it. And the rare situation arises where it interferes with something I try to say. 
I find this particularly ironic.

You want a change from default Quake behaviour when that change suits you.

You hate a change from default Quake behaviour when that change doesn't suit you.

At this stage it's looking like you just want what suits you and to hell with anything else. 
loc support - How it works and how it was defined has nothing to do with me; is not subject to my whims. You used ProQuake for 10 years, it was always there. Nothing to discuss, move along ...

single player default map - This engine is oriented towards playing single player custom map releases just like func_msgboard! And it will be tomorrow and every day after that.

map browser - Actually already has one. single player --> levels. Voila! 
And it's a solution for a problem which doesn't exist -- you can already name a map start.bsp if you want that one to start by default.

Except many modders are weirdos who like to name the start map of their mapset anything but start.bsp, even though their mod has its own directory.

This feature is for players, not developers. It allows to launch such weird map packs without using the console. If you like to test on start.bsp - you're probably knowledgeable enough to organize it without using the new game menu. 
Dwere +5 
Yeah, Gunter please read dwere's comment. It is a real problem in single player. 
Except many modders are weirdos who like to name the start map of their mapset anything but start.bsp
Naming your start map "startsomething.bsp" is useful to avoid problems when you have a custom start.ent in \id1\maps. Otherwise you have to manually save the .ent file of the mod whose start map is simply named start.bsp 
A problem that DarkPlaces can have -- but neither Quakespasm nor Mark V can ever have that problem.

The Quakespasm content protection system prevents .ent files or .lit files from upstream directories being used on models in downstream directories.

id1 (start.ent) -> arcane dimensions (start.bsp)
^^ NO, that start.ent cannot know about model in gamedir

Once I urged LordHavoc to add that system (I call it the "Quakespasm content protection system") to DarkPlaces. He didn't think that was a good idea.

So DarkPlaces suffers greatly from that problem even today. 
mh, What specific issue are you talking about that I want to change from Quake's default behavior only because it suits me? That centerprint thing we were just discussing is a case where I WANT Quake's default behavior ;) And in that case it was you who was disagreeing when you thought it would be a change from Quake's default behavior, heh... soooo... aren't you doing the thing you accused me of?

What's ironic is that when people thought I was asking for a change to Quake's default, they seemed against it (ONLY for the reason that it was a "change"), but it turns out it was Quake's default all along (I only knew it was in ProQuake, which does stay pretty faithful to original Quake), and someone had changed it....

I'll quote Mugwump above, who said, "The point is the Fitz family of engines is more geared towards conservative Quakers. Therefore, changing things too much might not be a good idea."

That nails the point PRECISELY, and that's the position I approach from.

That doesn't mean NOTHING should be changed (certainly bugs should be fixed) -- and something like a more optimal positioning of centerprint is such an insignificant thing, and yeah, I would have advocated for that regardless of whether or not it was Quake's default. But I would NEVER push for something like, "centerprints should be in bright yellow text because I like it that way and it's more noticeable."

Do you see the difference there? One thing is just a minor optimization of text position which doesn't change the look or behavior of Quake, while the other thing is a major change from Quake's default look based on my own preference.

MINOR improvements and Behind-the-scenes-changes and options which CAN be enabled are great. FORCED changes from Quake's default, expected behavior are bad, especially when they cannot be disabled.

It's as simple as that.

And yeah, if you make a 4-sentence, pretty baseless attack on me, you get a multi-paragraph response fully describing my actual position ;)

By the way, what is your position on the centerprint thing now? It should use Quake's nice default instead of, as you said, "ugly hacks," right? :D

Come on people, don't be so serious. Then again, we're Quakers, and sometimes we just need to fire rocket launchers at each other ;) 
You Fire Rocket Launchers? 
I just fire rockets...

@Baker We should petition LH to implement that protection system into DP. Let's show him how unnecessary it is! 
I get that the engine is geared toward single-player maps, but this feature is not good toward that end, except in limited situations. Yes, mappers use weird names, but if it's an actual "mod has its own directory" then there will already be a progs to send you to the right map. If that's not the case, there's no guarantee the intended map will be correctly named for this to find it.

"Weird map names" is a reason this function will often fail to do as intended.

I'm not speaking hypothetically -- this is happening to me. I have the IIKKA and Terra map packs. They aren't "mods," just maps, so I have them all in the same folder, without their start maps (unneeded). I also have a modified DM6.

So when I go to start a Single Player game I get put on DM6 because that's first by alphabet. There is seriously no reason this should ever happen when I try to start a single player game...

Ok, so I don't have the IKstart or TerraStart maps, but even if I did, there would still be a problem -- I would always go to IKstart regardless of what I want, because it's first alphabetically and contains the word "start." I will never begin on the terra or orl start maps if I have those in there too, or any other map.

How does this help me if I want to play single-player map episodes other than IIKKA? How does it ever help me if I want to play a selection of standalone maps? It would only work if I put one map at a time into my maps folder, otherwise I'm always starting on the same map.

Seems most of the time this function is not helpful, unless you're using a lot of separate folders, and it even becomes a hindrance in some situations.
Sure, it will work as intended if you only have one map, or only one map pack, assuming their is an auspiciously-named start map included. But that's the end of it -- if you add other maps, it breaks down and you gain nothing.

What is the solution? It's already there! An excellent Map Browser! Now THAT is nice. I may have seen that before, but forgot about it.... But since we have that, and we can easily select whichever single map or starting map we actually want to play, why then do we even need an automatic forcing of a potentially unwanted map, especially if we are expecting a single-player game (of a mod) to put us on the standard Start map?

So yeah, Map Browser: Beautiful, non-intrusive, allowing full player control.

Forced Alphabetical Staring Map: Drastic change from Quake default behavior which is not controllable by the player.

Options in order of preference:

1. Remove it! Heh, It just seems more negative than positive, and the user-controlled (important!) Map Browser is the IDEAL way to do this. Seriously. Love that.

2. Disable it by default, as it is far removed from Quake's default behavior. Allow it to be turned on if someone really wants it...

3. Even if it's left on as the default (*shudder*), give me a setting to disable it. Then you won't hear me mention it again, because it will stop annoying me, heh.

4. Have it be more selective and ONLY function if there IS a map that contains the word "start." TerraStart, IIKKAstart, ORLstart, whatever. At least you KNOW those are actually meant as starting maps. This wouldn't fix the problems I mentioned above (with many maps in the same folder you'd still be starting on the same map every time, regardless of what you want), but it would stop it from happening for those who don't want it by allowing some user control -- just make sure to remove maps with "start" in the name from the maps folder, and it stops sending you to some map (like DM6!) just based on alphabet.

Heck, ya know what might be more useful than allowing the whims of the alphabet to select your starting map? Allow the user to select any map as the default starting map from within the map browser. "Press 'D' to set this as the default starting map."

Throw me a bone and give me SOMETHING to allow me to make it stop happening! :D

Don't get discouraged, Baker, heh. Even though I hate this feature, I still love the engine as a whole. But just because you CAN do something, and just because someone asks for it (... who asked for it anyway? was the idea really well-thought-out?) that doesn't necessarily mean it SHOULD be done. There should always be someone asking if there are truly good reasons to make changes, and pointing out the negative issues that can happen if those changes are implemented.

Yeah, that includes any changes I might ask for. But I support my suggestions with solid reasoning, with consequences fully considered, and you'll never see me asking for anything that changes the look, feel, or function of Quake in a drastic way.

It's the job of us modders to do that, not the engine coders ;)

I'm just happy that you're actually making some updates now instead of later in 2017 :D 
loc file support -- is this not a separate issue from the macro format? I mean, it's not as if your hands are tied when you import something from another engine (just checked -- original Fitzquake didn't have this). Sure, maybe ProQuake chose to use %c as the macro, but you could choose to make it something like %c% instead (I mean, you changed "apropos" to "find" ;) ) It's just a matter of the user formatting their binds for the engine to access the loc files. But I guess all the other custom engines are using the %c format, so that's what players expect.... And anyway, this is a very minor thing, as I mentioned, which I don't care all that much about. But there's no reason to not talk about ways it might be improved.... 
No no no no no.

The centerprint positioning you want is not more optimal in the general case.

It's more optimal for your mod. It's more optimal for what you want to do. And that's leading you to downplay the importance of it's actual intended purpose.

A useful rule of thumb in cases like this is to ask yourself "what if two mods did this?"

So please, try to look beyond your own requirement and think about what would happen if two mods had different centerprint positioning needs.

That's why we have defaults and that's why defaults sometimes don't suit individual mods.

There is a useful dialog to be had about making centerprint positioning more flexible - maybe keep the default but stuff some control characters to the start of the string to override. But right now you're being just as inflexible about it yourself. 
Next version: Coop players spawn partially transparent, get less transparent each second.

While transparent, they may walk through each other/cannot be telefragged.

Maps without coop spawn points will be drastically less annoying for coop. Pure engine modification. 
Also in next version, Nehahra support is perfected and polished.

Includes fog support (yhe1, I think kept bringing it up) via non-standard commands that Nehahra uses and full fmod support.

Mark V starts up fmod if you activate Nehahra, shuts it back down if you change the gamedir back to id1. Also during the fmod startup, it adds the Nehahra special commands in and then removes them on shutdown.

/It has been discussed before that Nehahra tries hard and heavy to screw with your settings (fov, wateralpha, crosshair, viewsize, and on and on and on ... sheesh). The engine lies to Nehahra, pretending those things happened. 
Hate To Triple Post ... 
Next version: The built-in install single player releases from Quaddicted via typing "install" in the console has been enhanced some.

The install command will autocompete 538 Quaddicted single player releases. It can install the ones that don't auto-complete, but I didn't want the lower rated releases to autocomplete.

And this subset is searchable similar to the "find" command, but I haven't been able to figure out a good name for it.

Misc stuff: the OpenGL build may be able to work for, say, Gunter or Jonathan with touchy OpenGL drivers. Added -nomultisample (<-- I think this is the villain) and -nostencil command line params, hopefully one of those will solve the issue, particular for Gunter who can run Quakespasm ok with r_oldwater 0. Also bind 3 three keys in menu in customize controls.

Shooting for a couple more things (and intentionally keeping something rather unusual a surprise) ... I've been wanting to get this engine completely polished up for over 2 years now.

Probably will have international keyboard support. I've procrastinated on that because of more serious issues, but modern ProQuake has had international keyboard support for ages and ages (I worked with Vegetous and rudl as beta testers back at the time.). Also want it to be able to be turned off on a whim, like ProQuake does. 
I'm a bit confused about this centerprint argument right now. Gunter wants it to be returned to how the original engines and some custom ones do it, mostly because it serves his needs better (the argument can be made that it's also good to be more like the "real deal" anyway...), but mh doesn't want that because it's considered worse for a lot of other mods/use cases.

If i've summed it up well enough, I can't see where this discussion can go from here. And I mean, it hasn't really been going anywhere regardless. 
Actually No 
There are two elements to it.

Part one is that the original engine suppressed centerprints when the menus were up. Some engines changed this behaviour to retain centerprints. This should be reverted.

Part one is not in dispute.

Part two is that the default positioning of centerprints should be changed to suit Gunter's mod and that the original intended purpose of centerprints is not as important as Gunter's mod.

Part two, and only part two, is in dispute. 
Now I don't know whether to use Mark V or QSS. I know it's too much to ask to make them a joint effort. This engine has x awesome feature and that engine has y awesome feature. And poor player doesn't know whether to get the camaro or the mustang, especially not when yall keep turbocharging them and adding cool features. To think I used my old beater WinQuake for so many years up until a couple years ago. Had to ditch DP since it didn't twist water right, plus it leaked oil all over my config file.

I'm tempted to compile a comparison chart so people can better pick the best engine. It'd be hard to keep up though. 
You have it right, Pritchard. mh is confused.... Maybe he didn't fully digest the post I made where I showed that the positioning I want is actually the default positioning of original Quake.

See for yourself. Start a single-player game in original Quake, GL, or Proquake (which uses the same positioning). As you walk through a hall you will get the one-line message about "this hall selects whatever skill." Note the position above your crosshair. Now enter the first episode area, and you get the 4-line message about the dimension of the doomed. Note that it still starts at the same place, but is still fully above your crosshair position (assuming you aren't in a tiny resolution). All good. Now enter the second episode area where there is a FIVE-line message about the realm of black magic... but look where it is positioned! It's way up near the top (again, resolution dependent)! Why? Probably for the same reasons I talk about: so that it doesn't actually start to extend to the crosshair area and block that important area of your view, when instead you can move it upward because you have all that extra screen space where it could go instead.

This is NOT a case where I want to change the positioning JUST to suit my mod -- this positioning would be better for ANY mod that uses centerprints, and even for original Quake. So yeah, it IS more optimal for the general case.

id, in all their wisdom, chose this positioning for good reasons. I, in all my wisdom, wanted this positioning too, for good reasons, before I actually realized it was the original positioning, haha. I didn't know at first that this positioning was from original Quake (I've been away from Quake for a couple years :p ) -- I just knew that it had changed from what I was used to in ProQuake, and the change had made things less optimal, and it ended up obscuring my view in an unpleasant way.

So it turns out you actually agree with me, right mh? You think the default Quake behavior should be used, correct? Good, glad we have that settled.

Or are you focusing too much on the idea that I am wanting to change the PURPOSE of centerprint messages, from when I said, "But I think at this point they are no longer 'always important,' sooo.... they don't really need to be inconveniently in the middle of your view anymore :D"

Much like id's original statement, I was not being completely serious. id's original statement was a small joke (I thought it was funny anyway) -- it's simply not true that every centerprint in Quake is 'always important,' and they aren't even always inconveniently in the middle of your view, as I demonstrated above.

Sure, I did talk about even changing it a bit beyond the original positioning, but that's the kind of ideas that should get thrown around in threads lie this. After some testing, I have found that I actually have a great deal of control with id's original centerprint positioning.

If I want it to appear closer to the center of the view, I just make it 4 lines or fewer (that is the actual limit, now that I've checked for sure).

If I want it to appear near the top (it's "7 lines" from the top), I just make sure to pad it with extra lines ("one line\\n\\n\\n\\n" will appear at the top).

I can even move it below the crosshair area if I stuff in a bunch of extra lines above what I want to print....

I have lost this level of control in Mark V, so yeah, I would like it reverted to Quake's default behavior.

And apparently you agree with me, right mh? You seem to pretty strongly advocate for using "defaults..." So we are in total agreement here!

Now let me consider some of these other juicy changes Baker is adding in.... 
Yeah that's difficult since a lot of stuff is not well-documented, plus there's an avalanche of little things that someone may or may not care about.

One could try to do a chart comparing engine support for widescreen, rendering API, palettized rendering output, texture filtering, QW multiplayer, QW listen server, singleplayer, colored lighting, soundtrack music files (and in what formats), bsp2, map texture replacement, model texture replacement, alpha-masked textures, various fog behaviors, .ent files, .loc files, QC extensions, clientside QC, XInput controllers ... you could really keep going and going and even then never get to things like "centerprint behavior" :-) or corrected weapon-viewmodel-height or whether the demos play on startup. Which some folks really care about!

It might be a good thing to try to set up as a shared Google-docs spreadsheet that a few engine experts/aficionados would be interested in keeping up-to-date. I dunno. There's a chance it would just get dozens of feature-columns added for minor things which only apply to one specific Quake engine. 
was replying to Qmaster there 
"Coop players spawn partially transparent ... cannot be telefragged"

Brilliant! We do have that problem in FvF! Unfortunately, I don't think this is going to help me, heh. That would be a server thing, right? Polarite runs some linux proquake for the server.... Further, FvF doesn't actually run in coop mode -- it runs in a special deathmatch mode (coop 0, deathmatch 3), so all the doors are already open and we don't have to go around collecting keys and things most of the time. We just get to killing the monsters.

But this certainly give me the idea to try this change in the mod, instead of the standard 3-second spawn protection pent (which prevents telefragging, but causes people to sometimes be pushed into the floor). Hm, but what happens if the players are standing on top of each other when they became fully opaque?

I'm hopeful about the gl issue workarounds.... 
That is pretty weird behaviour in WINQUAKE.EXE: set the res to 1024x768, walk up to the episode 2 entrance in start.bsp, and the 5-line message is near the top of the screen. The episode 4 message (4 lines) is just above the crosshair.

This feels like something where the code is fudged in a way that looks good at 320x240. (another is the weird left-aligned deathmatch hud) 
Episode Messages 
The episode ending messages use WriteString, not centerprint and that is why they are at the upper portion of the screen.

@Johnny Law: Might do...sounds tedious but I do like that sort of thing. 
Last night I was using chase_active 1 too look at some splashing water effect I'm trying, and I thought it would be nice if the crosshair was still accurate even in chase cam.

I used the autocomplete and found the chase_active setting which I had forgotten about, and toggled it on, and found that my crosshair was accurate in chase mode! Ok, that's nice.

However, chase_mode does not act in an intuitive manner -- I reported this as a bug in the past because I did not know what was happening. It seems that chase_mode cycles through 8 different modes (and most all of them are going to be completely non-useful, I think) without letting you know it's doing that. I did find that I can do "chase_mode 1" to specify I want that first mode with the accurate crosshair.

Perhaps the cycling of chase_mode should be followed by a notification, like "chase_mode is 4" or whatever.

And I guess this would throw everything off with crosshair accuracy, but it would really be nice if I could re-position the chase cam so that it was like right above my shoulder, as in many 3rd person shooter games (chase_right just doesn't work in chase_mode 1, etc).

Maybe one of the default chase_modes could be a view like that....

I can't tell what the difference is between chase_mode 1 and chase_mode 2. Chase_mode 3 and higher are rather crazy.

Quake has had chase cam for a long time; it's just never been that useful. Having an accurate crosshair even in chase mode is a big improvement. I just need to be able to move the cam to the right a bit so my guy isn't blocking my aim.... 
Chase_mode is a "for fun" feature.

Gives different camera perspectives, possibly for making a "movie"/.avi/Youtube video.

Games with sophisticated camera control have massive C++ libraries created by paid game professionals, sometimes involving camera hint entities and such in the maps.

Like shadows, chase_active 1 is just a hack. I gave some extra flexibility for making a Quake vid and ...

... gave it an MH tune up where MH made the chase camera collide with the wall far more accurately. Used to be something mh and I talked about a ton, haha.

But once I saw the massive C++ camera code in commericial class engines, yeah ... sadly it's a lost cause.

Won't be altering chase_mode for the foreseable future. Have more important issues.

I'm just one person. 
I'll probably be making at least some light documentation since it looks like the engine will finally be out of beta testing stage -- a place its been living due a lack of time. 
Window Switching Gamma 
I don't know how fixable this would be, but I'll mention it.

I have an altered gamma profile on my netbook, to brighten the screen a bit -- the default is too dark. It loads up automatically in windows once I set it in the graphics properties.

Mark V uses hardware gamma, as you have mentioned, and it looks good in the game.

If I run Mark V in a window, I can see that my other windows are even brighter than usual, but when I switch away from Mark V (or when I exit Mark V) it returns my netbook to the default setting instead of my altered gamma profile (switching back to Mark V changes it again to the gamma settings I made in Mark V -- of course, this all still applies when I run in fullscreen too; it's just easier to notice when I run in a window).

It's not a huge problem, since I have a taskbar icon I can use to set my gamma profile, but ideally it would return my gamma profile to what was selected before I started Mark V, rather than the default (which is "no adjustment"). 
You can do vid_hardwaregamma 0 in Mark V and only get contrast correction (no gamma). Only other option. 
Next version: Marcher is fully coopable; engine overrides bad keys behaviors in coop. 
I might add a texture gamma option into the (it won't be very flexible though) next one. I want to see what texture gamma would look like (it might look nice, it might look "wrong" -- only one way to find out).

Mark V already can apply gamma/contrast, it does it to screenshots when hardware gamma is used so the screenshots look like what you see on the screen -- I just don't have it setup to do that when loading textures. 
Ah. Well, as I reported a while back, the Contrast adjustment makes everything look really good, except fullbright textures, which it makes look pretty bad (really washed out, losing a lot of the variations in color). So I ended up turning contrast all the way down.

If there was a way to have contrast not affect fullbright things (like wall torches), that would be great.

Interestingly, when the Menu is up and the rest of the screen is kind of "darkened" then the fullbright textures look good again, and you can see the fine variations in color in them.

Also, I think I saw this in FTE, but it's really nice how, when you have selected gamma or contrast in the menu, that "darkened" effect goes away, so that you are actually seeing what the game is going to look like while you are adjusting the colors.

Here, visual aid:

I really like the way contrast makes everything else look (colors are vibrant, especially the screen text, which becomes much easier to read); it just crunches the heck out of fullbrights. 
Could something be done about the visual glitch commonly known as "z-fighting?"

It's what you see when two surfaces are at exactly the same location, and the engine seems to draw them both, producing really ugly, flickery/flashy results...

One of the best (worst?) examples of this is the large platform in the water on e2m2, which must be raised to get to the exit area. When it's lowered, it's at exactly the same level as the water surface, and it looks reaaaaly bad (this issue only occurs in 3D engines -- not software renderers such as Mark V Winquake).

And it's not always a z-axis issue -- the same thing can be seen on e4m5 where the secret door opens at the start.

I suppose the engine should favor drawing any map brushes over door entities to address this.

I use an ugly hack in FvF and move every door and wall entity on every map by a tiny amount (less than one unit) just so they never appear at exactly the same position as a brush! It eliminates the z-fighting (or x or y-fighting), but it causes tiny cracks to appear near many doors, if you look really closely, heh. But that's a much less ugly thing than the z-fighting. 
gl_zfix 1. It is off by default.

Z fix fighting fixes in engines are evil.

On some graphics cards due to different calculations, they will reveal secret doors.

On other graphics cards the z fighting calculation may not fix z fighting the same.

There is no such thing as a z fighting fix, just a way to try to cover up problems where the solution may yield different problems (hidden doors being exposed). 
The way I always understood it, z fighting was a mapping error. As in, don't let two valid surfaces occupy the same place, doors exactly the same thickness as the wall they slide into and that sort of thing. 
Ah, thanks. gl_zfix 1 is a definite improvement, but not perfect for me (as you said).

It works better the closer I am to a surface. If I'm right up on something, it looks fine, but the farther away I move, the more it z-fights. 
In a perfect world, an OpenGL engine could use what WinQuake uses which as I understand it, clips away at doors and platforms where they occupy the same space as the world. Would be complicated and probably CPU expensive.

A different alternative would be someone making external .ent files to correct maps by nudging the entities on a case-by-case basis. But this isn't always possible. Mark V does this for a couple of maps internally (E1M1, E1M2, ..). quakespasm.pak has a few .ent files using this process. Plenty of instances where that cannot fix the issue, though. 
@gunter ... yeah z-fighting fixes suffer from the "fine tuning" problem ...

"Hey, this looks right on this map, where I am currently standing, with my specific video card, at this angle, if I don't go around and look at any more entities in the current map, ..." 
(pesky stuff) in next one:
1) Zoom: One-size fits all solution that handles specific sensitivity, fov, r_viewmodel_fov values according. dwere brought this up.

2) scr_showspeed - On-screen speed indicator, so someone wanting to speedrun a map or see how fast they can strafe jump doesn't miss JoeQuake.

2) renamed warppos to setpos for consistency with Quakespasm

3) scr_showpos -- for consistency with Quakepsasm r_pos will suggest this command. This is an on-screen indicator, not a console print one.

4) skyfog, wateralpha, slimealpha (etc) worldspawn keys ericw proposed as a standard

5) Curb stomps a couple of things in default.cfg overriding certain horrible Quake default keys, using a WASD setup for the keyboard. Only does this for default.cfg in id1/pak0.pak, does not interfere with mods that override that. 
I wonder if anyone has made a list of all instances of z-fighting in standard Quake?

There aren't all that many "major" places where it happens. It's actually pretty easy fix in QuakeC, heh, just by giving the appropriate entity a different value for either start position or end position when the map is first loaded. It's certainly easier to do it that way than to edit all the maps (one modified progs.dat as opposed to a bunch of modified maps).... 
It's certainly easier to do it that way than to edit all the maps (one modified progs.dat as opposed to a bunch of modified maps)....

Depends on your tools. External .ent files doesn't need QuakeC, it's like doing -onlyents map recompile.

In Mark V do this:
1) "copy ents" ... copies the entire map entity string to the clipboard.
2) Save that as c:/quake/id1/maps/e3m3.ent
3) With the map in Mark V, type tool_inspector 1
4) Press 3 for the graphical display to show the edict #.
5) In the console type "edict 55" if the edict # is 55.

You can just find the map entity in the .ent and change numbers.

I'm only pointing out what you can do with tool_inspector in Mark V. 
Ah, that is pretty cool. Yeah, tool_inspector is a great feature -- I've found that very useful.

I didn't know about "copy ents," or really ent files in general. That seems like it would be a nice solution for engines that support it... but in practice it doesn't seem to work.

Looks like the ent information doesn't really contain ALL the information for the ent, and I can't seem to change an origin of a door using the ent file, even if I add a line for it. I know setting an origin can be tricky....

Hm, it looks like "copy ent" loads the information directly from the bsp (ignoring any changes I've made from the progs), and the ent file stuff is only applied if there's a difference between it and what's in the original bsp. And that happens after any progs changes have been applied (overriding any changes I make with QuakeC).

Also, having a blank ent file (as I first crated when testing) will prevent you from loading a level, heh, because "Host_Error: SV_ModelIndex: model progs/player.mdl not precached" 
An .ent file is just to replace the entity text in a .bsp (without recompiling the .bsp without doing -onlyents, which would replace that text).

Open a .bsp in a text editor, go to very near the bottom, that's the entity information.

It won't exactly match the output of the "edicts" or "edict x" command because some of the edict entity information is filled in at run-time.

An example is modelindex. The .bsp (the map) has no idea what that will be, because a map have idea what progs.dat will be running, etc., etc.

But some fields will be exactly the same much of the time, like "spawnflags". A monster's origin if stationary, door information, etc. 
Next will have:
1) Texture gamma option, change it on-the-fly. Uses no cpu/gpu. Should work on gunter's old video card. The no cpu usage/cpu usage thing was the appeal.

2) Gun positioning cvar r_viewmodel_scale. Similar to ezQuake/FuhQuake Can move the gun forward and more prominent.

3) Automatic 2D console/status bar scaling -- Small | Medium | Large or off and use the different FitzQuake cvars.

Change resolution and it will use the best non-jaggies combination of settings based on your preference. 
And "ProQuake" centerprint option --- which is just the same place that original Quake did centerprint. scr_winquake 1 to turn it on. Also sets the scoreboard at the top of the screen.

Mostly doing this because next update could be the last one for a very long time. 
Might add:

if (scr_center_lines <= 4)
..... y = vid.height * 0.35;
.. else
..... y = 48;

Is the original Quake code. And quite terrible, really.

So if less than 4 lines of text, sort of center it on the screen (sort of). If more than 4 lines, do it way up near the top.

So if the resolution gets really high, that discrepancy in positioning will get very large between the positioning of a 4-line centerprint vs. a 1-liner.

It is what it is.

I basically prefer the FitzQuake way provided the text is ensured to be above the crosshair.

/But then you have compatibility ... and I get that too. Hence, upcoming option I don't entirely like to begin with. 
What seems obvious is that the intention of that code is to fit a 320x200 display. Original releases of GLQuake scaled the menus, console, sbar, etc to 320x200 via glOrtho.

What seems deeply fucking odd is that the very same code survived through software Quake, GLQuake, QuakeWorld, Quake 2 and presumably Hexen 2 although I don't have a copy of it's source handy for cross-checking.

I stand by saying that the stated intention of centerprints is for important messages that the player needs to be pay attention to and that obstructing your view is the correct and desired behaviour.

Something like y = (vid.height * 0.35) - (scr_center_lines * 4) seems a better compromise to me. 
@mh - Mark V uses a formula not too different than that. 
It's really not as terrible as one might first think. It actually provides a great deal of control over the positioning of the centerprint (as I previously mentioned).

Also, it does seem worse when you use standard winquake or glquake (or proquake) in very large resolutions where the text gets teeny tiny, so the positioning is affected quite a bit, BUT this is not a problem with the centerprint positioning -- it's a problem with the text size, and Mark V lets us scale the text size up regardless of screen resolution, so the weirdness of positioning of teeny tiny text is really not an issue -- at least not for anyone who scales the text size up to something more reasonable/standard-looking.

Speaking of teeny-tiny text, I tried out the tool_texturepointer thing, and it does not scale the text up along with my other text, so it remains teeny tiny and hard to read in large resolutions.

Anyway, thanks so much for providing the option to use Quake's standard centerprint positioning. This ensures compatibility so that the text will appear as the modders intended (as they saw it in Quake), with pretty much every Quake mod (and standard Quake itself) -- assuming the user's text size is also scaled to a more "normal-looking" setting for Quake

Ya know, I don't think id designed Quake to only run in 320 x 200 -- that's just the minimum supported resolution. And text size is pretty unwieldy at that resolution (not to mention the console is too large); you can hardly tell the difference in the position of 4 or 5 line centerprints when in 320x200. I highly doubt they never tested it in the higher resolutions; they didn't just accidentally position the centerprints the way they did because they neglected to test in anything but 320x200.... 
I'm pretty certain that it wasn't exclusively designed around 320x200... Although conback.lmp is 320x200 so you sure can't make assumptions.....

Nonetheless, I'm also pretty sure that there are huge chunks of the engine that were designed around hardware constraints of the time. The whole zone/cache/hunk thing in the memory manager, for example, is so obviously designed around "must run in 8mb memory". 
Just found this on my hard drive. Dated 2 minutes ago. It is an interesting screen shot.

4-player split screen

Holy Snaps 
Need tbh. Gonna play some DM with my buddies!

Will it have multi pad support somehow? 
I don't at the moment have a plan for input, that's the hitch.

Maybe within the next week or two after thinking things over, I can come up with a plan for input. 
Boring stuff: next version will clear any aliases send via stuffcmd to the client upon disconnect.

Posting a 2nd screen shot of 4-player:

4-Player Shot #2 
cool stuff! did it require a lot of code changes? 
You could do like Blaster Disaster and support two people on the keyboard, one person on a multi-button mouse, and one person on a joystick/gamepad.

Downsides: keyboard players would be stuck with oldschool no mouselook. All players would probably only be able to change weapons via cycling up or down except for maybe one of the keyboard players. Mouse player might need to steel a couple keys for strafing (laptop users would definitely be crowded). 
Boring stuff: sv_gameplayfix_setmodelrealbox for Quake Rally or other old mods that need original Quake bugged setmodel.

I've got a video of the four-player uploading now. Sadly, the video is 1 GB and it says 1 hour, 17 minutes remaining on the YouTube upload.

@ericw -- I went full retard. Never go full retard. I literally posted the screenshot 2 minutes after I got the prototype working.

With any luck, the new version will out today or tomorrow. 
Just opened up ol Blaster Disaster and it let you have up to 8 players:3 keyboard, 1 mouse, 4 joysticks. 
@qmaster - I'll solve the input solution with some thought. Spike, R00k and myself have had numerous conversation about FTE split-screen in the past. 
Wow, that's pretty cool.

I think you will definitely need joystick/gamepad support for that to be usable.

Perhaps the simplest thing to get it working at first, may just be to have one joystick configuration (button 1 = jump, button 2 = fire, etc., however the user sets it up), and just copy that behavior for gamepad 1, 2, 3, and 4, with each gamepad sending its input to player 1, 2, 3, 4.

Otherwise each gamepad will need to be configured separately. Which would probably be ideal in the long run, but just having one configuration for joystick input may be easier just to get it working.

Keyboard input should probably always be for player 1 (the one in control of the computer, which would often be the "server," in effect). Hm, but I hope it be able to connect all the extra players to an online server too....

But I'm already imagining hooking my netbook to the large TV screen and playing couch-coop splitscreen Quake! I have plenty of PS3 gamepads (which are basically just USB gamepads in Windows). 
There's a video I posted in the General Abuse thread. Read the names of the players in the scoreboard. 
Hah, neat. Reposting that on the fvf forum....

Thinking more about gamepad input, due to the limited number of buttons on a gamepad as compared to a keyboard, you may need to implement a "shift" key functionality.

Pressing Button 1 alone causes you to attack.
Pressing Button 2 does nothing by itself, -- it's a "shift" key.
Pressing Button 1 while holding Button 2 causes some alternate action, like changing your gun.

That's how they did the Playstation port of Diablo.

This could be added into Mark V as a standard feature -- not just for gamepads.

Perhaps something like:

bind ctrl +attack
bind alt @shift
bind @ctrl +jump

Now the ctrl key can be used to attack, or to jump if you are holding down alt at the same time.

Yeah, it doesn't seem as useful when you could just use alt to jump, since there are plenty of other keys on the keyboard, but you could bind lots of other keys or mouse buttons to shift their behavior too, like:

bind mouse2 +moveup
bind @mouse2 +movedown
bind mouse3 (next weapon impulse)
bind @mouse3 (previous weapon impulse)


It would give more options, which would be more useful for a gamepad.

I suppose you could even add more than one "shift" key, so ctrl could be @shift and alt could be #shift or something.

Then you have even more overly-complcated things to bind!

bind ctrl @shift
bind alt #shift
bind mouse1 +attack
bind @mouse1 +jump
bind #mouse1 "say I can do 3 confusing things all with one mouse button!" 
Joypad Support In Quakespasm 
Is pretty damn near perfect btw. 
I have all the major console controllers to test with 
HUD Icons In Official Mission Packs 
Hello, first of all great job on the engine, it's definitely my favourite.
I'm playing Scourge of Armagon and Dissolution of Eternity for the first time and using the winquake executable of Mark V for the original look. I've noticed that in both expansion packs the hud icons for new weapons are not displayed properly. In Dissolution the weapon in use should have a "lava glow" and in Armagon there should be unique weapon icons. These effects are completely missing. I'm using the GOG version of the games.

Should these icons be working properly in Mark V? 
@ zbikey -- Theory ... make sure you started the command line right

cmdline: -game hipnotic -hipnotic
cmdline: -game rogue -rogue
(The -hipnotic activates the hipnotic HUD)

If you prefer to switch to the gamedir in the console instead, it is basically the same:

In console: game hipnotic -hipnotic
In console: game rogue -rogue

Let me know if that was the issue!

@fifth, when the time comes I'll definitely need your help with the gamepad support.

My first priority is getting out the new release, getting feedback on it to see if there are any outstanding issues to make sure Mark V can finally become non-beta for the first time in a few years.

Then I can confidently proceed to make split-screen a standardized feature and add controller support. 
That Did It 
Everything is working perfectly. Sorry, I should've looked for the solution myself, didn't think there would be a command line for this. Thanks so much! 
It's a common problem. 
It's a common problem.
The command line or the people who ask without looking first? 
Multiplayer Save Games Working. 
Multiplayer save games working.

/Never looked at either DarkPlaces or FTE. I think DarkPlaces might have feature; FTE is known to have feature. 
Darkplaces Does Have Saving For Coop 
Hm, this is a bit beyond the type of thing I usually ask for... but is it even possible to allow some kind mod-side support for drawing things transparently? Like, client-side (similar to the way you draw the viewmodel transparent when the player is invisible), even if the server isn't using a protocol that sends alpha information....

I guess the problem would be that the server doesn't send much information to each client other than like the model, location, and frame of another entity, right?

So, for example, you couldn't just draw something transparent based on a .field of an entity....

It would have to be something like a

r_transparentlist progs/wizard.mdl,progs/bolt.mdl,progs/laser.mdl

Or perhaps somehow allowing only certain frames to be transparent, like progs/wizard.mdl:5-7,

I guess that doesn't give much control with a mod, other than just stuffing the list to the clients when they connect....

What I was hoping to achieve would be transparent observers.... I suppose if I could make one certain frame of the player.mdl designated as transparent, I could just avoid using that frame during any other animation, and have observers only use that frame when they are flying around (that frame being 71, heh)....

Just brainstorming here..... 
It both can and cannot be done.

FitzQuake protocol 666 supports .alpha on entities.

Do this:
1) Start E1M1
2) Console type: copy ents
3) Open text editor, paste it. Save as c:quakeid1mapse1m1.ent
4) Add this at bottom of e1m1.ent text file, then save again.
"classname" "func_illusionary"
"model" "progs/player.mdl"
"origin" "430 574 24"
"alpha" "0.5"
5) Load E1M1. You will see what I am talking about.

So it can be done automatically with FitzQuake protocol 666.

FitzQuake 0.85 obv, Quakespasm, Mark V, Qrack, Super8, FTE all support FitzQuake 666 protocol.

DarkPlaces doesn't. ProQuake doesn't. Those clients would not be able to connect, but both of those are by far the 2 most likely clients someone connecting to your server would be using.

If you were to run FitzQuake 666 protocol, this would mean you would need to run something different as your server executable (couldn't be ProQuake, no .alpha support).

In addition, if you were to use something non-ProQuake as the server, if you use qccx hacks to mask ip addresses that stuff would have to be stripped out your QuakeC source because it depends on fixed memory structures/memory addresses that only an adamantly retro-compatible engine like ProQuake can possibly support. 
I guess that doesn't give much control with a mod, other than just stuffing the list to the clients when they connect....

Beware - this way lies madness. Or at least recreating Nehahra.

The problem with on-connect stuffing is that it doesn't survive save games. So you stuff every frame instead. And then you've recreated Nehahra.

Better options exist, such as saying "this requires an engine that supports .alpha", or forking PQ and modifying it to support protocol 666 (which, if sensibly implemented, could potentially end up being taken back into the main branch). 
.ent files -- could it be made so that having "missing" information in the .ent file would let it fall back to using the original ent information (from the bsp)? For example, what if I made an ent file for e1m1 that ONLY contained the above line add the func_illusionary, without having all the other ent info in there? I know currently it will just cause an error and fail to load the map, because of all the "missing" ent information.... It seems like it should fall back to the original ent info in that case -- only loading modified or additional stuff from the .ent file.

And that transparent func_illusionary doesn't seem to work right for me in DX Mark V (may be related to the previous thing I reported about the weapon model not being transparent UNLESS I have HQ textures enabled -- but in this case that doesn't help). It does make the fake player visible, but it's not transparent, and it's drawn strangely, like from back to front (or would that be front to back...); If I look at him from the front, I can see the gun strapped to his back.... If I set his alpha to "1" then it looks normal.

Ok, so what about having an r_transparentlist for the client to play with? It could just set certain things to always be drawn at 50% alpha.

There are quite a few things in Quake that might look better as transparent, like all the sprites (bubble, light ball, and explosion), all the lightning bolts, the large wall flames (though the torches would be problematic, since they have a wooden handle), possibly the lasers, probably the death knight spikes and scrag barbs, and maybe even the scrag itself.

And for my purposes, it would be nice if I could set one specific frame of the player model to be transparent -- maybe only have that effect kick in if the frame lasts longer than a couple tics in the game so that it doesn't occur during normal animations -- but that's just me thinking of possibilities -- I don't actually think you should add features that are only for specific mods, heh. But having some way for the client to control effects like transparency could be useful to everyone. 
Would a .tga skin with 8-bit alpha work? I bet some clients already support that. 
Fighting Z-fighting 
"Mark V does this for a couple of maps internally (E1M1, E1M2, ..)"

Baker, your anti-z-fighting hack is conflicting with my anti-z-fighting hack, heh.

On e1m1, you seem have have Mark V moving that secret lift down by like 26 units?

That's bad; here's why:

I think this, again, is something you shouldn't change engine-side UNLESS there is a way to turn it off. (Actually, I am all for trying outside-the-box stuff like this, even engine-side, but it's important that the defaults remain the defaults).

Because... I am tweaking things mod-side to eliminate z-fighting by altering door positions VERY slightly (0.15 units, which may just be rounding up to 0.2 units). There are various ways to implement this, with various side effects. The current thing I'm trying moves vertical "doors" (that hidden lift is actually a door that moves up and down) slightly down (and sideways) by 0.15 units. This seems to work great in most cases, but it causes a problem with that lift in e1m1 because you have already adjusted its position by a comparably large amount (you were aiming to make it flush with the ledge it goes up to, right?). So now after I adjust that down by a tiny amount, it's slightly below the ledge it raises up to, which causes the player to be blocked by that tiny lip when he tries to step off the lift!

You really only need to adjust something's position by 0.15 units to avoid the z-fighting.... And any hack like this in the engine needs to be capable of being disabled.

AND, if you're gonna tweak things like this, you should try to fix ALL z-fighting, like I'm doing mod-side, heh. Don't just go half-way!

Currently here's what I'm doing mod-side, just in case you wanna try similar things, heh:

func_plat -- adjust origin UP by 0.15 units. These are visible lifts, so just need to be sure they aren't on the same plane as the floor (e2m3 lift leading to top level).

func_wall -- move their origin perpendicular to their wide side by 0.15 units. Many of these are the "exit" signs that are usually on the same plane as the walls they are near. (e2m2 exit in DM mode, for example). Moving them on their "wide side" makes sure they are offset from those walls. e.g.,:

if (self.size_x > self.size_y) self.origin_y = self.origin_y + 0.15;
else self.origin_x = self.origin_x + 0.15;

fd_secret_use -- fix secret doors just by altering their end position. They already move in 2 directions, so won't be on the same plane as the wall they are on, but their end position may slide their narrow side to be exactly aligned with the wall (start area secret door on e2m3). Fix just by telling the door to not slide quite as far into the wall (the "v_forward * -0.15" is added to this line):

self.dest2 = (v_forward * -0.15) + (self.dest1) + (v_forward * (self.t_length));

Regular doors is where it gets a bit more tricky.

in func_door, just before it sets pos1 and pos2, check if it's a vertical-moving door (like our e1m1 lift), and change its origin by a bit (down, and along its wide side). We can do that safely here because these things don't need to blend into walls, so we won't be making any weird cracks where they shouldn't be:

if (self.movedir == '0 0 -1' || self.movedir == '0 0 1') {
self.origin = self.origin - (v_up * 0.15);
if (self.size_x > self.size_y) self.origin_y = self.origin_y + 0.15;
else if (self.size_x < self.size_y) self.origin_x = self.origin_x - 0.15;
setorigin(self, self.origin);

If there is no "wide side" for most doors, then you probably don't need any sideways adjustment... but otherwise you may need to adjust even for vertical doors, like for the gates blocking the exit on e2m7.

For regular doors you pretty much do the same adjustment as above, but only after the door reaches its open position, in door_hit_top (check to make sure it's NOT a vertical moving door there -- we fixed those above). You don't wanna move a door's origin like we did for the vertical ones, because sliding doors often need to blend in with walls, and moving them can make tiny cracks appear. And only moving the "end" position is safer -- it probably won't cause any weird side-effects.

And I've seen some pretty weird side effect with the various things I've tried tweaking to eliminate z-fighting, heh! But this is my most recent stuff (subject to change/improvement); it seems to work well. The only flaw with the current implementation is that there might be some z-fighting happening WHILE a door is still moving, but it will go away once the door is fully open.

Of course, I don't actually have a full list of all places in Quake where z-fighting occurs so that I can check, but these alterations should theoretically eliminate all of them! It will even prevent z-fighting where it was never occurring in the first place, because it affect ALL the doors, haha! But the idea is to alter them (ALL!) in such a small manner that it won't be noticeable or cause any problems. 
Eh, I posted my (current) full code and explanation for my anti-z-fighting hack over on the FvF forum (guess I didn't need to clutter this thread with it, heh), if anyone would like to really examine or comment on it:

Yes, I know it's a hack, heh, but it's an effective hack, and easier to implement than many other options (this will work for every client, without having to modify all the individual base maps).

The theoretical potential negative issue is that it's very broad, affecting everything globally to be sure it gets everything it needs to. If I actually had a list of all the instances of z-fighting in Quake, I could probably narrow the focus to make sure I'm only affecting things that need it. But I'm fairly certain it's not causing any significant negative side-effects. And you won't see any (persistent) z-fighting anywhere in FvF! (In theory!) 
An idea to toss out:

All bronze chat text tends to blend together, making it hard to quickly recognize text from each individual person.

What if chat text were automatically color-coded for each chatter? Like if my pants are blue, my chat text is blue. That might be a bit difficult -- each color would need a different image of all the characters, right? I think that's how Quake does its text (like a bitmapped font).

Alternately, what about just putting a color box of the player's color next to his chat text (like the color boxes appear in the scoreboard, with shirt and pants color behind the score for each player). The color box could either be placed in front of the name of the player who's chatting, or it could replace the space after the : after their name. Imagine the [] is the color box:

[]Gunter: color box shows my shirt and pants color


Gunter:[]so you can easily recognize my chat lines in the console


Gunter[] or maybe just replace the colon itself....


Gunter[:] or just put the color box behind the colon.

At least one of those options might look good, heh. 
Way Better Than Glass? ... Unlimited Mirror Support 
Unlimited Mirror Support - YouTube

No limit to the number of mirrors, provided they cannot see each other. You could have 10 mirrors on the same wall since mirrors on the same plane cannot see each other.

Engine scans surfaces for mirrors, generates additional visibility @ map load.

Same concept could be used for security cameras or even portals that preview the teleporter destination. 
That's quite a nice showing Baker! There are some really creative opportunities when using mirrors in this way.

Thanks for sharing. 
Cool Stuff 
I remember this being a feature of Glide 
Re-Texture In Real Time 
Retexturing In Real-Time

Tool Inspector

Added a "hdfolder" folder command to specify a content replacement folder which you can change in the console to switch to a different set. 
Inspector is a very nice idea! 
Awesome Stuff Baker! 
Mark V - 1.00 Release 
Windows: Open GL | WinQuake (software renderer)
Windows: Direct3D

No new Mac build for now.

Primary Features

Mirror support. Worldspawn key "mirroralpha". Textures must be prefixed with "mirror_". Can specify specific texture with r_texprefix_mirror. See the Quake startmap, go to easy hall.

No limit to # of mirrors, provided they cannot see each other (3 in a row on same plane = ok!).

Find command. Type "find sky" or "find speed" and you'll see what I mean. Similar to the DarkPlaces apropros command.

Nehahra Support is complete and fully polished to the absolute maximum. It's like a dream.

Built-In Quake Injector Install now auto-completes 500+ of the best releases. Press CTRL+space to autocomplete or TAB.

Like type "install travail" or "install rapture" in the console, it downloads and installs it. Then type "game travail" and do Single Player->New Game.

"hdfolder" command to specify an optional content replacement folder. Change it in the console.

Zoom key. Bind x +zoom_key -- one size fits all script for sniping scrags across a bridge.

International keyboard support. Needs tested for verification (in_keymap 0 turns it off).

Automatic HUD sizing. See menu. No more using scr_menuscale unless you want to.

Stretching For WinQuake version -- stretching. Play at 320x240 full-screen resolution even if video mode not available.

Co-Op, LAN and Networking Features
Co-Op ghosting for 5 seconds -- walk through other players/no telefrag for first 5 seconds. No coop spawns? Who cares!

Marcher Fortress can be be played co-operative, engine overrides a Marcher QuakeC oversight.

IPv6 support (from QSS)

connect lan, type that in console and no need to figure out LAN server IP address for playing co-op.

Server browser + single port server. (from Quakespasm Spiked)
"reconnect" -- reconnects to last server connected to.

Multiplayer save game capability. Save a co-op game.

Different gun positions available including "side-mounted" (r_viewmodel_offset).

Multiple HUD-support (i.e. Quakeworld HUD, .. see menu)

Texture gamma option. Do vid_hardwaregamma 0, and you can adjust gamma via typing "txgamma 0.7" in the console. No cpu/gpu cost.

Server Connectivity
Disconnecting from a server will discard any aliases the server provided.
Disconnecting form a server will discard any key binds the server sent.
Complete ProQuake support including depot map/model/sound download.

Final Malice bug fixed (for NightFright).
Original Quake centerprinting option. scr_originalquake2d
Ability to disable multisample attempt via cmdline -nomultisample. Same with stencil -nostencil. May make older computers be able to use OpenGL version.
Direct3D version can now do transparent weapon with invisibility ring. So can WinQuake build. (from qbism super 8)
Software renderer supports stretch modes.
Ability to have jerk stairs like original Quake. See menu.
sv_gameplayfix_setmodelrealbox for QRally and other ancient mods.

Source code

[Partial list, some other minor features may be in the thread. Source code link will work later in the day.] 
Bug Report For New Version 
Exe: OpenGL version of Mark_v
Issue: Crashes to desktop
Replication: 100%

How to: Go to options, controls, press return key to bind move forward. 
Visual Anomoly 
Testing the mirrors in gloom keep and I got this -

Also as the reflections are based on vis you tend to get HOM effects if you look at the mirrors from certain angles. 
Further Bug 
For some reason I can't seem to pull down the console even though it's bound to tilde. I rebound it to z and it works. 
i can confirm the console bug. 
I think it's about time I reported something that pretty much makes Mark V unusable for me. It exhibits a fairly stable (once per few seconds, with some longer periods of running normally) lag. All three exe files are affected. fitzquake_mark_5.exe dated 2012-07-31 seems to work fine.

I'm using this machine running in a power saving mode due to overheating (maintenance is long overdue). Quakespasm runs fine on it, even when fairly big/complex maps are concerned, but Mark V is stuttering even on start.bsp.

And a minor nitpick: "previous weapon" and "next weapon" commands seem to be swapped, as my autoexec gives me the opposite of what I want. 
Well, the GL version still crashes for me on map load even with -nomultisample -nostencil

The auto text sizes have increments that are too large (jumping right form 1 to 2). It needs 1.5 too (which is close to the maximum 1.55 that still allows player names to be positioned beside the "uncentered" DM HUD). It could even be useful to have 1.75 in widescreen resolutions. Hm, it appears that in proquake, a resolution of 640x480 has the equivalent of sizing things to 1, but at a resolution of 800x600 it automatically sets things at a size of 1.25, so the .25 increments can be useful -- perhaps this scale feature needs a slider bar for fine adjustment.

Hm, those "high" weapon models are too high, methinks.

Tested an old issue: it still crashes if you toggle external_textures when on maps E1M2 or E2M3. 
my irc mod had coloured chat text, you could adapt that.

screenshots are here:

the code was pretty hacky, but is functional. 
that inspector tool seems waaaay handy for info_null entity hacks. 
The auto text sizes have increments that are too large (jumping right form 1 to 2).

Graphics get rekt a little when you scale them by a fractional number. At least when texture filtering is disabled. 
Frickin' cool feature list there. Looking forward to trying out this release! 
(Can the original post for this thread be updated?) 
Going through my usual settings first....

The lavacolor has gone back to the incorrect value of "255 80 50 150"
Default should be "255 80 0 150"

Hm, I don't think "auto small" is a good default setting. It should probably just default to the "controlled with cvar" one. Even "auto medium" might be better for the default, OR get fancy and have "suto adjusted by resolution" so that the sizes will automatically be set based on your resolution so that the screen elements look approximately the same size no matter the resolution.

Things actually look fine for me at the .25 increments for scaling. Going to weirder values, like 1.55 does cause a bit more distortion, but the .25 ones look good.

scr_showfps still vanishes when you size the screen down (using the default -/= keys).

mwheeldown triggers mwheelup instead of mwheeldown.... This may be the problem dwere mentioned about "previous weapon/next weapon" not working, since the mouse wheel does those things by default?

Uhh, could still use solid dark black shadows for DX, since it can't do the stencils ones right. And of course, if you're hacking shadows, you should just hack them to not be drawn at all if they are more than like 100 units away from the entity, because that causes weird shadows....

You still have bolt1.mdl in the noshadow list... there is no bolt1.mdl in Quake, heh.

And of course I think k_spike.mdl and lavaball.mdl should be added to the noshadow list.... 
Should just be "bolt.mdl" 
Mark V automatically records demos every game.

Try cl_autodemo 0. I should probably default that to 0.

Might be why. Mandel also said something about that.

Also yeah, I'll fix the mousewheel up/down reversed issue --- the input code encountered a big re-write.

@gunter .. I was hoping that was the problem about your XP netbook.
@fifth .. yeah the 2 mirrors "can see each other problem". I have to put out a revision due the mousewheel anyway and I have an idea to improve that. 
Cool News 
works fine so far! 
Thanks, cl_autodemo 0 solved the issue. I never even noticed the new demo files. 
Disabling auto demos doesn't help in my case.

Hm, I dug up the Dr. Watson log file, and it contains all the usual gobbledygook, but right up near the top it says, "Exception number: c0000094 (divide by zero)"

If you think it would help, I could send you all the error logs and info that my computer spits out when this happens.... It's a lot of gobbledygook!

The mirrors, they are broken in DX. They just look solid (normal texture), but when I set gl_overbright 0 (I do this because it smooths out the fog in DX), then the mirror looks like... um... like the visual glitch when you are outside the map with no gl_clear in old glquake. If I set gl_clear 1, then the mirror turns solid grey. 
@dwere - I wanted to leave it on during beta to see how many people even noticed (very, very few). So shall be off by default in next version.

@qmaster -- the bolts, yeah .. fixing

@johnny -- I'll think of something, I have something in mind ...

@pulsar -- I fixed the demo pause thing, I forgot to list that. Thanks for reporting that! I hate stuff like that.

(1) --- that's for reminding me to disable mirrors in DX. In theory, they should work but the Direct3D wrapper has built-in optimizations that mirrors bust.
(2) r_shadows -1 will do what you want in next one, which will be less than an hour.
(3) Could you test download, "disconnect" and clears server aliases/key binds (3 items). Rename your maps folder so Quake can't find them. Connect to your server. Play dopa or terra. I need ProQuake depot auto-download tested. "alias" lists all aliases, "bindlist" lists all keybinds. your impulse 39 tricks for chat should get cleared on disconnect. 
Crash To Desktop Bug 
I'm guessing that my bug where trying to bind a new forward key through the menu is just me?

I get this crash in the winquake version too. 
I'll check that out and fix. If I can't reproduce, might need you to post your config. 
@fifth ... 
I've got it ;-) So no need. 
... Start up the open GL version
Post the c:\quake\id1\qconsole.log
Your post about Dr. Watson made me think about something. 
Feedbacks And Bugs 
Baker, thanks a lot for the release! .. I really appreciate.

second ... I�m a Mac user, hence I�ve only tested the software under Wine 1.8.5 (

The hdfolder command works fine but only one way. From "" to hdfoldername for example, but then it is not possible to come back to "", not even by restarting. The only workaround I�ve found is to set hdfolder to "" in the autoexec.cfg.

If the demo files are not present in pak0.pak the software stucks for a while (1 minute) but then it works fine.

In my configuration the software crashes systematically when the delete button is pressed for setting new command keys in the command menu.

Multiplayer works fine with me! � nice job! 
start up with -nomultisample -nostencil -developer when you do the log 
Thanks for the feedback on the hdfolder thing. 24 hours ago that wasn't even an idea.

I'll see if I can identify and correct.

/I'll think about quickly I can do a Mac build. Have to think about it. 
Resetting server-bound keys works. Good feature.

Hm, server-set aliases are cleared rather than reset to user settings. For example, if I set:

alias colors "say colors!"

Then connect to FvF -- which sets alias colors to an impulse to set your colors (including a hack to force the unsupported colors 14 and 15 to work -- which reminds me, how about support for colors 14 and 15? heh).

Then disconnect from the server. Now the "colors" alias is just cleared. I guess you just do an unalias command?

I don't see this as being much of a problem though....

Downloads work. Now do I turn it off? heh. It downloads loc file, which I have no use for.

It TRIES to download fvf sounds, but fails because those aren't located on Quakeone.

It successfully downloaded terra1.bsp 
Gunter: Type ... find loc in console. Should tell you what to do ;-)

Want to promote the idea that "find" solves a ton of questions instantly.

I'll add the FVF sounds to the primary depot. 

The hd folder can only be selected during the initialisation process and not afterwards.

If the demos are active, the initialisation console is skipped and no further initialisation commands can be introduced.

Once the demos are running, the hdfolder command only generate the following message "please disconnect first".

For users like me .. it can be confusing! 
I'll make hdfolder auto-disconnect. I was considering that since "game" already does that. 
Ah, the sound downloads work now!

I guess it doesn't download "skins" because they are attached to a model... annnd, yeah, that would be tricky since each server might have a different set of skins attached to the standard player model.... Hm, perhaps Mark V could keep a different folder for each server it connects to, and if it does not have the skinned models for that server, it could grab them. But then I guess that would require a different folder on Quakeone for each server.... Yeah, tricky.

But it could work -- you'd just have specific things in a server's folder instead of general things like the maps.

So like, you have a download folder for "" on Quakeone that contains the FvF files, then when a client gets an invalid skin request, it knows to try and download that model for the server it is connected to, and it will create an "" folder in id1 to store those files....

Though I suppose instead of doing it piece by piece like that, if you just have an "" folder at Quakeone, it could just contain the FvF custom pak file to download, and Mark V could automatically grab it when it connects to

Of course... that would take longer... but it would be kind of nice. Though perhaps that would need a user prompt, "automatically download pak file for this server (15 meg)?" 
qconsole.log following instructions posted above?
If you want me to help your old computer use GL, it's literally today or 2018? 
Today, please!

Command line: [ ]
Log file: C:\Documents and Settings\Aaron\My Documents\Games\Quake1/id1/qconsole.log
Wed Nov 16 18:13:32 2016
Mark V Version 1.00 Windows
Exe: mark_v.exe (1121 kb)
Exe: 06:35:23 Nov 16 2016
Caches: C:/Documents and Settings/Aaron/Application Data/Mark V/caches
UDP4 Initialized: INADDR_ANY,
UDP6_OpenSocket: Address family not supported by protocol family
UDP6_Init: Unable to open control socket, UDPv6 disabled
Exe: 06:37:32 Nov 16 2016
256.0 megabyte heap
GL_VERSION: 1.4.0 - Build
GL_EXT_texture_lodWarning: texture_non_power_of_two not supported
Intel Display Adapter detected
Max texture size: 2048
Multitexture: 455190012
Non-Power of 2: 0
Combine: 1
Stencil Bits: 8
Hardware gamma enabled
joystick not found -- no valid joysticks (a5)
Input initialized
Avi capturing module initialized
ACM module initialized

Sound Initialization
Set primary sound buffer format: yes
Using secondary sound buffer
2 channel(s)
16 bits/sample
11025 bytes/sec
DirectSound initialized
Audio: 16 bit, stereo, 11025 Hz
Sound sampling rate: 11025
CDAudio_Init: MCI_OPEN failed (266)

========= Quake Initialized =========

execing quake.rc
execing default.cfg
couldn't exec config.cfg
couldn't exec autoexec.cfg
3 demo(s) in loop
Playing demo from demo1.dem.

the Necropolis
Using protocol 15 
Wait, were "instructions posted above" adding the -nomultisample -nostencil?

That seems to make no difference, other than adding:

Warning: Stencil disabled at command line
Warning: Multisample disabled at command line

to the log.

Also, I could email this stuff instead of cluttering this thread.... 
Revision #2

Everything fixed except ...
1) Icaro HD folder. (Will be fixed in revision 3)
2) mfx/fifth tidle console. (Will be fixed in revision 3)

@fifth - Made 2 mirrors that can see other, the 2nd mirror becomes "non-mirror" in that frame. 
What are last 5 lines of qconsole.log when crash on your old XP computer? That may be enough for me.

Be sure to you are using -developer in the command line. 
Stab in the dark .. possible fix.

Let me know!

Make sure you run this .exe which has a different name. Crosses fingers. 
Oh, sorry, I missed that small post you made above telling me to use -developer.

I got the new version, and here's what I get as the last lines after crash:

Playing demo from demo1.dem.
Mouse Released
Serverinfo packet received.
Clearing memory

the Necropolis
Using protocol 15
e1m3 loadname
e1m3 cl.modelname 
huh, and if it matters, if I disable the startup demos and just try to load the Start map, the blank lines that appeared after "clearing memory" above (I deleted them because they just looked blank), instead say:

SpawnServer: start
Clearing memory
Programs occupy 403K.
PR_AllocStringSlots: realloc'ing for 256 slots
Mod appears to support impulse 12
start loadname
maps/start.bsp sv.modelname
Try the one I just posted that has a possible fix. 
Sorry again! I missed your "stab in the dark" ... This "forum" page is a bit hard to navigate, heh.

One moment....

Nope, no good. qconsole log seems the same. 
You up for one last try in the next 15 minutes?

I think your video card may not support glMatrixMode(GL_TEXTURE) 
Ok... Gunter.

Do it again, with **zero external textures** in your Quake folder.

If it works when you do that, your video card doesn't support glMatrixMode(GL_TEXTURE)

If it doesn't, it's something else. 
Yes, I'm ready to test.
The last GL version I COULD run was:

Would that happen to be right before you added glMatrixMode(GL_TEXTURE)? 
Yeah, I disabled (actually, renamed the folders) all external things for testing already.

Running the DX version to check, there are definitely no textures loading. 
I'm checking between that and 2015 May 2 version ... see if anything obvious ... 
Nothing Dead Obvious And Easy To Reverse, Sorry Gunter ... I Tried 
I gave it my all to try to make your old graphics card work -- all the possible leads I have would require a drastic rewrite (check out Quakespasm's thread to see insanely stupid and possibilities that bad opengl drivers can cause).

Looks like you'll have to use the DX version, but at least you can set shadows -1 and have weapon transparency now. 
Well, gosh darn it to heck. 
Solution: update graphics card? 
@fifth And/or Mfx (or Anyone With Issue) 
re: International keyboard support

For some reason I can't seem to pull down the console even though it's bound to tilde. I rebound it to z and it works.

What language keyboard + keyboard version are you using?

Like for example, I'm betting mfx uses German Qwertz. I need to know what the keyboard key you expect to toggle the console (and whether or not you are doing shift).

Shift + ESC should unconditionally toggle the console on any language keyboard as a temp workaround.

In the console, also as a temp measure, typing in_keymap 0 may make things behave as you expect.

Mostly if you guys can communicate to me how it should work, I should be able to get it right ... 
It's a laptop ... you need to make Gunter mad enough he throws it in a burst of anger. Haha 
Ah, I see. Well, maybe NOT fixing it can be a step in this direction... jk 
Just to be "Gunter-level-of-thorough," I booted up my OLD WinXP laptop (an HP Pavilion ze4101 circa 2002) and tested....

Again, the older mark_v_e.exe GL runs, but the new version crashes.

The error popup actually says:

The exception Interger division by zero,
(0xc0000094) occurred in the application at location 0x0046733d.

And here's the qconsole log, which is similar except the totally different (but even older) graphics card:

Command line: [ -developer ]
Log file: D:GamesQuake/id1/qconsole.log
Mon Oct 31 21:27:44 2016
Mark V Version 1.00 Windows
Exe: mark_v.exe (1122 kb)
Exe: 19:04:52 Nov 16 2016
Caches: C:/Documents and Settings/Aaron/Application Data/Mark V/caches
UDP4 Initialized: INADDR_ANY,
UDP6_GetLocalAddress: gethostbyname failed (Authoritative answer: Host not found)
UDP6_OpenSocket: Address family not supported by protocol family
UDP6_Init: Unable to open control socket, UDPv6 disabled
IPv4 address INADDR_ANY
IPv6 address [::]
Exe: 19:04:26 Nov 16 2016
256.0 megabyte heap
Start map determined to be start
GL_VENDOR: ATI Technologies Inc.
GL_VERSION: 1.3.4273 WinXP Release
FOUND: ARB_multitexture
FOUND: ARB_texture_env_combine
FOUND: ARB_texture_env_add
Warning: texture_non_power_of_two not supported
FOUND: EXT_texture_filter_anisotropic
Swap control enabled
8 bit stencil buffer
Max texture size: 2048
Multitexture: 45407760
Non-Power of 2: 0
Combine: 1
Stencil Bits: 8
completed.Gamma protector set
Windows and context menu key disabled
Hardware gamma enabled
joystick not found -- no valid joysticks (a5)
Accessibility key startup settings saved
Accessibility keys disabled
Mouse Captured
Input initialized
Gamma level 0
Avi capturing module initialized
ACM module initialized

Sound Initialization
Set primary sound buffer format: yes
Using secondary sound buffer
2 channel(s)
16 bits/sample
11025 bytes/sec
DirectSound initialized
Audio: 16 bit, stereo, 11025 Hz
Sound sampling rate: 11025
CDAudio: drive not ready
CDAudio_Init: No CD in player.
CD Audio Initialized

========= Quake Initialized =========

execing quake.rc
execing default.cfg
execing config.cfg
Unknown command "r_viewmodel_always"
Hardware change detected ... Custom Gamma set: contrast = 1
Unknown command "r_viewmodel_winquake"
couldn't exec autoexec.cfg
3 demo(s) in loop
Playing demo from demo1.dem.
Serverinfo packet received.
Clearing memory

the Necropolis
Using protocol 15
e1m3 loadname
e1m3 cl.modelname 
Where's your -nomultisample -nostencil?

I don't see that in your command line. 
You better double check and be double sure you did the command line right
1) The version I provided (special gunter one)
2) The correct .exe
3) -nomultisample -nostencil -developer

It is possible I solved your problem if you didn't use the right command line. 
It doesn't help, and changes little in the log, other than changing this part:

Swap control enabled
8 bit stencil buffer
Max texture size: 2048
Multitexture: 45407760
Non-Power of 2: 0
Combine: 1
Stencil Bits: 8
completed.Gamma protector set

To this:

Swap control enabled
Warning: Stencil disabled at command line
Warning: Multisample disabled at command line
completed.Gamma protector set

Everything else is identical, including the crash. 
triple-checked the special version, same result, but the error log has all the lines from above:

Swap control enabled
Intel Display Adapter detected
Warning: Stencil disabled at command line
Warning: Multisample disabled at command line
Max texture size: 2048
Multitexture: 452634108
Non-Power of 2: 0
Combine: 1
Stencil Bits: 0
completed.Gamma protector set 
Mark V 1.00 - Revision 3 
Windows: Open GL | WinQuake (software renderer)
Windows: Direct3D | Source

Still didn't update the Mac build.

Revision 3:

New Feature:

Multiple hdfolders. hdfolder "hires" (1 folder) or hdfolder "hires,qrp,plagues_pak" (multiple folders). Changed: paks in a hdfolder are *ignored*.

Outstanding Issue (only one, unless I skipped something):

International keyboard --> tilde (mfx/fifth) Need to know what keyboard layout and what physical key is being pressed. For the moment, Shift-ESC will always open console and "in_keymap 0" *might* make it work as expected. Let me know!

2 mirrors in view disables 2nd mirror (fifth re:e1m5), bolt.mdl -> bolt1.mdl (qmaster), lavacolor typo fixed (gunter), cl_autodemo off by default (dwere's computer), r_shadows -1 = full dark (gunter), Direct X version mirrors disabled (gunter), mousewheel up/down (dwere), hdfolder set will disconnect (icaro), menu bind key fix (fifth)

Punt or Non-Issue: server bind discard clearing existing alias if named same (gunter) = acceptable for now, few people use aliases. scr_showfps + viewsize < 100 doesn't show (gunter) = intended behavior.

@icaro .. if you still have any issues with hdfolder or how that works, let me know. You don't need to put it in autoexec. In fact, don't. It is read very, very early.

@gunter .. maybe something a thought will come to me on how to solve your video card, but the Direct X build does everything but 2 things. Not too bad. 
I don't suppose it would be possible for you to build a linux version?

Gulliver uses linux.... 
I assessed it, finishing up the Linux port probably take 40 hours of coding. Maybe 2017 some time. 
Above Downloads Updated 
To fix it so it works with Gunter's video card, which didn't have texture non-power of two capability which I noticed in the log. 
Malice Feedback 
Unfortunately, I have to say that the issue in map d15 of "Malice" still exists with the latest Mk V build. :/ If you play without saving, the game still returns your FOV to its original state, but as soon as you save and reload or quit and restart the game, FOV is set to 170.

I am also sorry to state that cutscenes still don't work. At the end of the level, game stops with this error:

ERROR: Couldn't open C:/Games/Quake/malice/cuts/cut8.dem

(Note: The first two dashes of the directory are actually inverted, but for some reason, these are not shown in this forum.)

This also wouldn't change if I extract the "cuts" folder from pak2.pak into the Malice installation directory. 
Tilde Key 
Additional note:
On my German keyboard, I have to press "�" (oe) to bring down the console. Used to be the key right on top of "Tab" (to the left of "1"). 
@johnny Law 
@johnny law -

I guess from now on I'll always have the current version there. It's not complex but does the job.

That page has a link to this thread.

a) Malice cut-scene issue addressed, Mark V doesn't expect demo names with slashes in them.

Go to the above page (which isn't very complex) and it has the current version download.

b) Can you give me a link to the picture of the keyboard layout (if I do Google I get conflicting pictures) ?

If you were in another application and did the keypress, would it do a tidle or do you press shift or a different modifier key?

I'm trying to determine whether I need to use the physical key scan code or what the key press produces. 
alk10 is a Nehahra mapset that is supposed to be installed into its own directory. Therefore, it either requires multiple -game parameters or -nehahra.

The only alternative I can see is splicing nehahra and alk10 into one directory. 
Mark V - Revision E 
Current download:


Made the "tilde" position on the keyboard a "holy" key that no matter what keyboard someone is using it toggles the console.

Should bring that to a closure.

Current source is always

@dwere - Interesting problem that will need addressed. I guess no one noticed before because to play Nehahra was a major pain in the arse. Never knew about alk10. I played the Tim Elek add on. And I *think* there may be 1 or 2 more Nehahra maps. 
Malice/keyboard Layout 
With the latest build, the two issues in "Malice" are finally history! Only one (cosmetic) thing remains now: When playing cutscenes, the statusbar is not hidden automatically. Dunno if that's important, though.

Regarding keyboard layout:
A German keyboard looks like this:

I had to edit config.cfg to make Mk V use the correct console key again:
bind "�" "toggleconsole" (before edit)
bind "/" "toggleconsole" (after - it's not this dash, but inverted)
Otherwise, console would only open with "�" key (which is probably "�" on English keyboard). 
Updated yet again, allowing the possibility of doing game alk10 -nehahra in the console to run that single player release.

Current download: 
/Malice, yeah it does horrible things ... it runs now ... I think I'm done dealing with it ;-)

The latest recently updated version of Mark V *should* assume on any keyboard that the key in that position (tidle in my case) is the toggle console key.

I need verification, but I think that is history.

I switched my keyboard layout to German and until I hit the "Z" key didn't even realize it when running Mark V. 
Keyboard Layout Feedback 
Console key works as intended now. The only odd thing is that if the game creates a new config.cfg file, the default setting is in_keymap "1". With this, Mark V will print every scancode onscreen whenever a key is pressed. That's kinda annoying. 
On Quaddicted there's also Invein, Maelstrom, ROTCS and TSD. 
Previous comment was addressing the 1 or 2 more Nehahra maps thing. 
Remaining Wishlist 
What's left on my wishlist for Mark V right now (just to mention it):

- Ingame menu toggle for texture filtering (switch between gl_nearest_mipmap_linear and gl_linear_mipmap_linear without having to use autoexec.cfg)

- Underwater warp effect like in software Quake (if that's even possible)

Side note:
Does r_mirroralpha work again? I just noticed the stained glass window in the "Easy" hallway of the intro map is reflective again. If you enabled that again recently - neat! 
Sorry for the long pause, real life issues. The console issue is gone, instead it prints every stroke now, as NightFright described.
Also the ^symbol is added to first new char i press when toggling the console now, QS had similar problems once.

Will look out for further bugs, AD mod loads fine here for now, even the new unreleased version + maps. 
Yeah, mirror support is a major feature in the current version.

I had thought about the texture mode thing but considering it's minor decided against It does autocomplete, press alt+space, but I know what you mean. Underwater warp is out-of-bounds for Mark V, would require GLSL and Mark V doesn't use GLSL. 
Glad to hear that fixes that .. I'll have to think of a "correct" way of blocking the unwanted extra character. Probably won't be too hard. 
Mfx/nightfright Issue Solved 
Mfx/nightfright issue with German keyboard added unwanted character after using the tilde key equivalent is solved.

Current download: 
mark_v.exe -nehahra -game alk10 +map alk10a works, but the engine crashes with a generic Windows error right after the map starts. This seems to be caused by the level using xm/s3m music, as Nehahra levels that don't use music load fine.

qconsole.log says:

Warning: FMOD module not found ( nehahra/fmod.dll )

I placed FMOD.DLL that comes with Nehahra into the nehahra directory just to see what's gonna happen, and it said that the module can't be initialized instead. 
Underwater warp is out-of-bounds for Mark V, would require GLSL

Use glCopyTex(Sub)Image2D then draw a grid (similar to what stock Fitz does for it's render-to-framebuffer warp, you may even be able to recycle the same code). No shaders needed. 
Basic Nehahra Support 
Starting Nehahra (with -nehahra) works fine until the first cutscene: the sound is working, but the screen is black. -game nehahra leads to more broken things. There are error messages, and the first cutscene now lacks sound as well. 
What's file date and time. Mine's 6/30/2004 160786 bytes. 
Well Hot Damn 
New GL version works for me!!!!!!!!!!!!!!!!!

*throws laptop against the wall in celebration*

Oh... nevermind. Don't need it anymore.

Heh, though it is spitting out a lot of "scancode" in the console; I think you left some debug code in. Or was that there for someone to test the international keyboard thing?

Also... how about the joystick support? It used to work (it works in the old mark_v_e.exe), but in the recent versions, it seems to detect the joystick and everything, but it just doesn't respond to any input from the connected usb gamepad. 
The cutscene in Nehahra stays black for annoyingly long time.

Stick with it, haha. It's how it works. 
Console Key Fixed 
Ah yes, invoking the console and having an unwanted character written there right away was quite annoying indeed. Thanks for fixing that one, too! 
FMOD.DLL in is 117760 bytes and is dated 2/19/2001. 
Nehahra FMOD 
Your fmod.dll should be dated June 30, 2004, 160.768 Bytes. With that one it works (for me at least).

What Mark V should however do is to ignore the music folder in id1 directory when playing Nehahra. Otherwise, you have the standard Quake soundtrack playing which isn't meant to happen. You could always move your music folder out of the id1 dir temporarly for that purpose, but I am sure it can be avoided. 
Fmod.dll Download For Nehahra 
If you don't know where to get that newer fmod.dll from that I mentioned above, I have uploaded it here.

Fmod.dll from Jun 30, 2004 for Nehahra (149 KB)

I don't remember how I got it, actually. 
Things work with this dll, thanks.

I'm assuming it can't be included with the engine for legal reasons? 
@baker the ^ issue when typing any char after console is toggled is still there. Both GL and DX8 versions.
This happens only on a crappy Lenovo ThinkPad with IntelGfx btw. Desktop is fine.

Found a typo when HD folder is set. Message misses a "set" i think. 
Testing Mirrors 
Now that GL works for me, I'm gonna test the heck out of stuff, like mirrors!

On E1M5, at the position of the screenshot FifthElephant posted above (#1378), the mirror just becomes solid for me. I see what's causing this -- if both those windows are onscreen at the same time, the one on the right becomes solid (to prevent the mirrors seeing each other, I assume). If you adjust your view so that only one of the windows is on your screen, it will become correctly transparent.

On the Start map, if I set r_texprefix_mirror tlight07 and go to the E1M1 gate room, the light textures are mirrors, but if both the lights are within my screen area (even if blocked by the slipgate), the one on the left becomes.. garbled, looking just like FifthElephant's screenshot, except it's STILL a mirror and I can see my reflection in it....

What I'm really wanting to see is r_texprefix_mirror *teleport ... but that doesn't seem to work.

And you get some weird effects using +0slip or slip1

cop3_4 (the rune floor stone near the start) looks cool, but does weird things, heh. You can get the other one (past the teleporters) to work, but you have to make sure your screen isn't pointing back at the first one.

city4_6 or city4_7 are fun... Glitchy mirrored floor!

Too bad *water2 doesn't work...

wizwood1_8 looks cool! Mirrored ceiling in center area, though the surface is glitched, and it seems that fullpitch glitches it out (ah, that's what was messing with the rune stone floor square too) -- if you look all the way up or down it flips the mirror weirdly.

wizwood1_5 is really weird... it's the angled ceiling in start area.

Yeah, I know I'm making this do things that were never intended, heh, but it's fun to play with.

How about making it a list, so that we can specify multiple textures to make mirrors?


r_texprefix_mirror_list window02_1,tlight07

Speaking of lists..... bolt1.mdl is still in the noshadow list, heh. Just remove it - it doesn't exist. You already have bolt.mdl in there. And the lavaball and k_spike got added in; that's nice. 
Running full screen at my netbook's native resolution (1024x600) I noticed some un-smoothness. So I set host_maxfps 60 and things look smoother (that's my netbook's refresh rate), but then I got some tearing. So I set vid_vsync 1 and after restarting, DX looks much better with no noticeable tearing, but the GL version still has tearing... vsync doesn't seem to alter it at all (even after restarting it).

Hm, gl_overbright 1 causes a pretty nasty FPS hit on DX. I was toggling it to test -- I usually keep it off in DX, due to it making fog ugly -- so here's another reason it's bad (at least for me) in DX. It doesn't cause these issues in GL. 
^ Issue 
Baker, this WIN_ResetDeadKeys function I contributed to SDL might help:

If you press the ^ key on a German keyboard (below esc), the next key you press will have an accent (I forget what windows message types it affects, but generally Windows will try to send your program an accented character). Calling WIN_ResetDeadKeys between the ^ and the next key will "undo" pressing the ^ key and make it so no accents are delivered on the next keypress. There's some more info on the blog post mentioned in the comment, which is where I got this method from. 
Thanks! Question:

It looks like this code is meant to be called after a WM_KEYDOWN?

Like you get the scancode, then run that code afterwards ...

Which would prevent the next character from
happening in this specific circumstance. 
Found a typo when HD folder is set. Message misses a "set" i think.

Could you explain this? 
Scancode: h 104 ascii 0

Scancode: 0 ascii h 104

Scancode: h 104 ascii 0

Scancode: d 100 ascii 0

Scancode: 0 ascii d 100

Scancode: d 100 ascii 0

Scancode: f 102 ascii 0

Scancode: 0 ascii f 102

Scancode: f 102 ascii 0

Scancode: 9 ascii 0

hdfolder (command)
Scancode: 0 ascii 0

Scancode: 9 ascii 0

Scancode: 13 ascii 0

Scancode: 0 ascii 0

Set high content resolution folder. Set to "" for none.
Current HD folder is to "hd".
Scancode: 13 ascii 0

Scancode: c 99 ascii 0

Scancode: 0 ascii c 99

Scancode: c 99 ascii 0

Scancode: o 111 ascii 0

Scancode: 0 ascii o 111

Scancode: o 111 ascii 0

Scancode: n 110 ascii 0

Scancode: 0 ascii n 110

Scancode: n 110 ascii 0

Scancode: d 100 ascii 0

Scancode: 0 ascii d 100

Scancode: d 100 ascii 0

Scancode: u 117 ascii 0

Scancode: 0 ascii u 117

Scancode: u 117 ascii 0

Scancode: m 109 ascii 0

Scancode: 0 ascii m 109

Scancode: m 109 ascii 0

Scancode: p 112 ascii 0

Scancode: 0 ascii p 112

Scancode: p 112 ascii 0

Scancode: 13 ascii 0

Scancode: 0 ascii 0 
Current HD folder is to "hd".

should read

Current HD folder is set to "hd". Or..? 
Looks like I need to remove that dprint I used for testing because it spams. 
Scancode spam annoys a lot 
New Version With Ericw's Deadkey Fix 
Current download:

Ericw's deadkey fix, seems to solve this issue!

The spams are gone and touched up the hdfolder print that mfx pointed out. 
It looks like this code is meant to be called after a WM_KEYDOWN?

Yeah, it should be safe to call it any time, but you probably want to call it after the WM_KEYDOWN that opens the console. In QS we call it when the console is opened / closed, or any time we enter or leave text input mode (for chat.)

The idea in QS is we are listening to WM_CHAR messages when the user is typing in the console / chat, so their keyboard layout is respected (QWERTZ, etc.), but in game we just use WM_KEYDOWN/WM_KEYUP. That WIN_ResetDeadKeys function prevents keys pressed in game mode that happen to be dead keys (e.g. the ^ key) from leaking over into the text input in the console.

MSDN link describing the messages that are sent when the user presses '^' then 'o' on a German keyboard.

It's all very confusing, hope this makes sense somewhat! 
Is Somebody Testing The Mac Version? 
On my machine it does not find the id1 directory and it can not load the gfx.wad, while the windows versions, installed in the same directory, are running perfectly. 
Baker, cool, sounds like the deadkey fix worked! I will give it a try later.

In my experience you need to enter "-basedir /full/path/to/quake" in the Mac version launcher.
Could be a problem that only affects newer macOS versions. 
Baker, ^ fixed. Thx! 
Ok, I implemented that for a change in the intended key input mode (scan code intent vs. character code intent -- console/menu/messagemode). Thanks for your explanation!

Updated again:

Perhaps now the international keyboard support is finally rock solid due to ericw.

@icaro -- the Mac version is about 3 revisions old. That being said, if the Quake folder on your Mac is say /Desktop/Quake and your pak0.pak lives at /Desktop/Quake/id1/pak0.pak then putting the Mac version in /Desktop/Quake should work. It is less polished than the Windows versions in some ways, but still isn't bad. Not sure when I will have the time to update the Mac version. But wanted to make the Mac version at least findable. 
@ericw ... Thanks, It Works 
Be sure to try this screenshot:

type: install
type: game undergate
menu Single Player->New Game 
Hm, Baker, you've changed something about exiting a map in the recent versions....

In FvF, upon exit, I draw a line out from the player and move the intermission point there, so it will point at the player while he dances.

But something weird is happening now and the camera is ending up on the '0 0 0' world spot....

Though if the player is moving, sometimes my safety code kicks for when he leaves the view of the first camera point, and it draws a new line and moves the camera there so that the player is in view. 
This might be a good read:

I don't know if it applies, but both ProQuake and FitzQuake 0.85 separately created the same intermission camera bug. Since JoeQuake uses ProQuake network code, that engine family line too (Qrack, etc.)

I fixed the bug via a solution from Enhanced GLQuake (Ben Jardrup's engine).

If this is the nature of the problem, a GLQuake or WinQuake would have the same issue because FitzQuake/QuakeSpasm/ProQuake/JoeQuake/Qrack all have the camera reversed. 
Download complete
Couldn't open zip C:\Documents and Settings\Aaron\My
Warning: Couldn't extract gfx/env/morose_bk.tga


It downloaded, but the install didn't work, and I can't locate the file anywhere on my hard drive. There is no _library folder.

Oh, I found the file. it's in c:\Documents and Settings\Aaron\Application Data\Mark V\caches\__tempfiles\

Wait, I'll make an id1\_library folder and try again....

Ok, that seems to have made it work. Now it installed and ran just fine after I manually created the _library folder and did the command again. 
I checked with the original Quake.exe -- my intermission code works fine in that. 
+1 on install bug.

Could you describe what the QuakeC does very specifically. Like step by step. Are you using "stuffcmd" during that?

It might be fighting against a Mark V defensive feature that prevents Nehahra or Zerstorer from wrecking your settings. 
Updated with "install" command fix. 
Uhhh... it's complicated.... Plus I wrote it years ago. And I hack code like a crazy mofo, heh.

But I'm pretty sure there's no stuffing at that point.

Um, let's see.... In execute_changelevel, it uses FindIntermission() to pick one of the intermission points (I guess that's standard behavior).

Then I search through the list of classname = "player" to find the person with the highest score, then I do a randomy traceline out from him and setorigin for the selected intermission point to that location, along with setting its model to the bubble sprite (I think I did that so I can give it a velocity sometimes).

Then I set its angles to point at the player, where "org" is the player's origin:

ang = vectoangles (org - cam.origin);
ang_x = 0 - ang_x;

cam.angles = ang;
cam.mangle = ang;

Hm, I'm pretty sure that code is not the problem, because I re-run it every couple seconds to make sure the cam stays pointed at the leader (often he will still have some momentum when the level ends), and then it also checks to be sure the leader is visible to the camera, and if not, it re-runs the positioning of the camera again.

It seems only the first run through of the code is getting the glitch and putting the camera on '0 0 0' with no angle pointing at the player (I think the angle is also '0 0 0'), but if the code runs a second time (due to the player getting out of view of the camera, which is harder to do when the camera is outside the map at '0 0 0' because it can see into the map almost everywhere) -- then it runs through the same function again, but works correctly....

Hm, interesting... when I check the entity information for the intermission camera, it says it's in the correct location, so maybe the issue is at the point when the player's view is set on the intermission camera.

Ok, here's a difference in what I do for each player

msg_entity = other;
WriteByte (MSG_ONE, 5);
WriteEntity (MSG_ONE, pos);

I believe that sets the player's view to that of my intermission camera since it can change angles and I want to keep them seeing through it's "eyes." I guess normally Quake doesn't do that because it has static intermission points with set angles, so it just sets each player to that spot and angle.

I'm guessing this is where the problem occurs... but wait... I never set that again, but as I said, if the code runs through a second time then it sets everything correctly.

So... it seems the player's view being TOLD to be set to the view of the camera, but on first pass, the player's view (and position?) is not correctly updated to reflect that. The cam itself seems to be in the correct position when I check its edict info... Perhaps at the time the player is trying to jump to the cam, the cam's fields are un-readable for some reason... but then... why does it only kick in when I re-position the camera, without any further setting of the player's view... hmm.

This would require some code alteration for me to really test this, but I can't get to that for a couple hours, because I have to watch Supernatural now, heh.

But maybe some of this rambling will help you zero in on the issue with whatever change has been made. 
In FvF, upon exit, I draw a line out from the player and move the intermission point there, so it will point at the player while he dances.

Need some clarity here. Precise clarity.

1) Is this on your ProQuake server with Mark V as a client?
2) This is on your computer. No ProQuake involved.

The difference is crucial.

If this is running on your ProQuake server, Mark V isn't involved with any QuakeC calculations.

B) Are stuffcmds involved at all where it changes a player's settings? 
The second one -- No Proquake involved. This is what happens when running FvF on Mark V on my own computer. Though previous versions of Mark V didn't do this.

There should be no stuffcmds happening at that point -- they only occur when a level first loads or a client first connects. 
What happens if ProQuake is the server and Mark V is the client running this code?

This will tell you whether or not it is a client or server issue. I'm assuming it is a server issue so a Mark V client connected to ProQuake will not experience the issue.

But there are several differences between a Mark V server and a ProQuake one.

1) Mark V does not support QCCX at all. May cause unpredictable results. If you can compile with fteqcc or frikqcc 2.7, you are fine.
2) Mark V's QuakeC interpreter is for all practical purposes using Quakespasm's QuakeC interpreter. It may generate NaN results (not a number) when GLQuake/WinQuake/ProQuake will not.

This is a highly technical issue that MH and Spike and the 2 original Quakespasm authors talked about --- I didn't fully grasp the conversation at the time. (But I knew far less back then).

Since you say you are getting 0,0,0 I wonder if you are dividing by zero or getting a NaN result.

Maybe write code to check if the result should be 0 and then try to trap an example.

If you have found a bug in the "Quakespasm Virtual Machine" can trap an example, I think all the engine guys would be grateful.

Because it probably means that bug will get fixed. Nehahra spits out "NaN developer errors" in Mark V with developer 1. 
Short Version: 
Write something like this:

oldxyz = xyz

(your calculation)

if (newvalue.x == 0 && newvalue.y == 0 && newvalue.z == 0)
... print all the factors of your calculation

Then post it here! 
Ok, ran proquake dedicated server on my computer, then ran Mark V on same computer to connect to it.

"connect lan" did not work; no servers found.
"connect 192.168.254.blah" did work.

Intermission camera functions as expected.

My compiler is frikqcc 2.6
I don't know what QCCX is, heh.

This issue doesn't occur in the previous version of Mark V which I was using from

The thing is, I'm not actually getting '0 0 0' when I check the edict info (everything looks correct there), but the view seems to be stuck at '0 0 0' in the world, like it was not correctly set. But then if the code runs to change the origin of the camera, then the view becomes correct with the camera without me issuing any additional command to set the player view to the camera. It seems like just changing the camera origin makes the view lock back on....

Hm, it seems that my special victory intermission cam that has a velocity also works -- the camera moving seems to cause the view to lock onto it. 
More testing will have to wait till tomorrow. 
Connect Lan Will Find Other Mark V Or Quakespasm Spiked Servers 
Connect lan will find other Mark V or Quakespasm Spiked servers. If I recall correctly, original Quake's TCP/IP broadcasting was broke -- only IPX -- and old networking protocol from the 1980s -- worked.

Spike fixed this in Quakespasm Spiked so that servers do broadcast correctly. 
Music Messages On Level Stats Screen 
When entering the level stats screen, Mark V displays the "Current Music Track" message on top of the screen. This should be hidden (like when entering a new level). 
Version updated:

@nightfright ... updated Mark V to only print those if developer 1. Same with external .vis files, missing impulse 12 message and lack of fish fix message.

@gunter - Here's a challenge for you.

Test your problem in these 2 engines, be sure to test it exactly the same ...

Quakespasm Spiked R4 -- (do +sv_protocol 666- +map [map you test on] )
Quakespasm Regular -- (you already got this)

If your problem only appears in Quakespasm Spiked R4, Mark V and not Regular Quakespasm it will tell me that Spike's ever so slight change to the network message read only is involved in your problem.

Mark V acquired this from Quakespasm Spiked R4, but I can't see it making a difference really but maybe in highly specialized cases in can. 
Useful stuff:

External .vis files for id1 maps, makes maps have transparent water data without vispatching:

Correct fmod.dll for Nehahra:

To run Nehahra it is game nehahra -nehahra 
The problem does not occur in Quakespasm or Quakespasm Spiked.

Tested several times in each engine -- I just load the Start map and take the e1m1 exit (but it affects any exit).

It happens consistently in the recent Mark V.

I'm gonna go do some code testing and see if I can narrow it down to the specific code that's causing the issue.... 
Fix Confirmed / VIS+LIT For Mission Packs 
Music message fix for level stats screen confirmed.

I am already using pak files with .vis/.lit files for Quake and all mission packs for a while. If any of you want to use them, here they are:

VIS/LIT files for ID1/Hipnotic/Rogue (.zip, 22.2 MB)

Basically just unzip this into your Quake installation dir. Make sure you don't have other custom pak files there which may get overwritten (ID1: pak2.pak, HIPNOTIC/ROGUE: pak1.pak). 
Baker, Ahoi 
frogbot mod, im trying to change the map, i'm typing map dm4, the game just says something like this "unknown command" "1" unknown command "8"

and i have to type admin 1 0 , all over again, to play the bots, NQ bots,(your version, modified by you and then modified by me) 
@nightfright ... awesome! .. mirrored as ...

@spy -- Hmmm. What's up with that? Investigating ... 
For the moment, use "changelevel dm3" instead of "map dm3"

And you shouldn't encounter issues.

Frogbots is clever and deals from both sides of the deck to save information even beyond "disconnect".

Mark V will flush away server aliases on disconnect, but frogbots went to a lot of trouble to store info across disconnect and then restore it for the player's convenience.

I'm planning a way to address this. 

1) frogbots issue resolved (spy)

(Type: "find frogbot" if you actually care about the setting that controls that. Me neither ..)

2) gunter e1m2 "toggle external_textures" issue resolved. That map has a missing texture, it was causing a problem.

3) hdfolder now only prints a folder not found if the user is actively setting it. By design a missing folder is allowed, it is just ignored .. made it do a better job of ignoring it.

4) Made a couple more things into develop prints because the user doesn't really need bothered with them.

Should be the end of the queue. Except if the FVF mod problem Gunter is having turns up something. 
question about the hdfolder ... where does it fit in the priority order for loading content? 
Great question. It's simple, but effective.

We read from it (first), but we never write to it, nor does it ever become gamedir.

Example: hdfolder "hdmymodels,hdtexture_set2"

1) READ (.pak files ignored in hdfolder)

The path will be:
hd\\mymodels (first priority)

2) WRITE - hdfolder does not become com_gamedir

- Has no impact on saves, demos, screenshots or server operations.

com_gamedir stays id1, travail, warpspawm -quoth. hdfolder has no effect on that. 
Try As I Might To Avoid, It Ate My Slashes 
hdfolder "hd\\mymodels,hd\\texture_set2" 
I think what he's asking is whether it breaks mods, or just not work with them.
use maps/start.ent as an example. :) 
Was supposed to look like this, basically

hdfolder "hd/mymodels,hd/texture_set2"

/messageboard > Baker, owned! 
Uh, while testing I encountered a weird bug. The first time it happened I thought it was a fluke, but it happened again.

After starting a game, I could not move. My other keys seemed to work (I could jump) but my motion keys like +forward were unresponsive. They were still correctly bound....

This last time it happened I believe it was right after changing "game blah" in the console and starting a new multiplayer game. I think I just re-started a new multiplayer game again and then the keys worked....

Not sure how to reproduce this.

Ok, back to the cam stuff, I compiled a clean progs.dat with just some cam code for you to try out (source included). I narrowed it down to the view not being set unless the cam has a movetype, or upon re-setting the cam's origin.....

Try running this with various engines. The glitch occurs in new versions of Mark V, but not the other engines I've tried. But I haven't tested in a large selection of engines.... 
An hdfolder shouldn't have .lit, .vis, .ent or .cfg in it.

It is supposed to have textures, .mdl and .bsp replacements.

But if someone does put a .lit in there, Mark V checks the light data length and if the .lit file isn't that length * 3, it says Con_Printf "Invalid .lit (map mismatch)" and merrily continues.

I do intend to put "ignore inappropriate" files blocker in there, I haven't coded it in yet.

Maybe I do that right now. 
@spike / Metlslime Part 2 
Part of this was why I asked so many questions about setmodel + setmodelsize. 
Are you saying adding a movetype to the camera fixes your FvF issue?

[I'll check out the file because I'm curious and see what I find.] 
@gunter ... Re: Gamedir Change Issue 
Can you reproduce on your computer.

Your FvF mod sends a ton of settings and keybinds to the client. And I don't know what you have in your autoexec. I do care about that problem, but I (probably) need more information. Your setup is so radically different from mine, I don't know that I can recreate it. 
Couple of random questions:

- Would you rather that folks call this "Mark V" or "Fitzquake Mark V" now?

- What remaining features are in Proquake but not in this? 
I can't reproduce it....

I'm not even sure changing the gamedir had anything to do with it.

I'll be watching for it to happen again though. It's a weird one. 
I think this engine has changed enough so that the "Fitzquake" part can be dropped.
It has become its own thing now.

Plus, it's much easier to just type "Mark V" :D 
that wasn't the question.

try player.mdl with TF.
either your hd dir takes precidence over the mod's player.mdl and you loose the class-specific skins, or the mod's takes precidence making the hd dir unusable for replacing mod content.

is it:
(broken players / maps, unless you're really careful)

(hd dir neutered)

or what? 
@johnny .. call it Mark V.

(It was supposed to be a FitzQuake patch and a engine coder bug-fix tutorial --- qbism used it for that a lot --- not a separate engine. Spike may be reliving that with Quakespasm Spiked a little. I wasn't ever looking to usurp the FitzQuake name, I was originally trying to help metlslime locate engine fixes discovered at inside3d in the hopes his unreleased FitzQuake might happen.)

@gunter -- yeah, let me know. I care. And thanks for isolating the intermission cam thing. I'll be checking it out. 
I see your angle, got it.

Originally, I thought of making it compatible with that.

However -- since most replacement content users are Quake experts ---

I stuck with the simple method that allows a user to shoot themselves in the foot -- Over a complex method that is very precise but that could be a little annoying.

Most content replacement users know what they can and cannot do.

What are your thoughts on this? Do you think I should change it? I want this to work in a manner that other engine coders (you, metlslime, Quakespasm, etc) find acceptable. 
Very nice little camera providing illustration.

Yeah, Mark V acquired some movetype enhancements/clip links crash fixes from Quakespasm Spiked. 
The World's Most Explosive Bug Report 
your website has a typo "frequenrly" 
Oh, it seems I wasn't including the most recent .qc source code with that demo. I guess that might matter a little if you were trying to follow along in the code to see everything.... I updated it now:

It seems to work for me without the glitch in Quakespasm Spiked, which I downloaded from the link you posted above. 
If you set the movetype it works correctly in Mark V, right?

Either way, I'm still going to look into it because it is a behavior difference (I hate those, no matter how small). 
Correct, and agreed. 
Cool bug, Gunter! You've caught something that would almost never surface.

Explicitly requires a multiplayer scenario and that reading the code, everything looks great. 
This bug could have gone uncaught for 100 years. 
Would be awesome if people still played Quake in 2116! 
@baker - Gamedirs 
What are your thoughts on this? Do you think I should change it?
My thoughts are that anything that requires setting console variables will suck. Anything that requires the user to be aware of filesystems will similarly be crap.

Make it a menu (like fte's menu_downloads [but more polished] or whatever). Then the filesystem becomes irrelevant and much easier to install high-res stuff (and also get rid of it again without breaking stuff).

Also, configs do kinda need to be part of your replacement content, if only so that you can enable/disable nearest filtering (and other equivelent settings that vary from one engine to the next). 
Well, I AM an insane code hacker. I live outside the box and push things to their limit -- which is also why I find so many bugs!

There's all kinds of crazy stuff in FvF. More people need to play FvF. The reason I do weird stuff with the intermission camera is so players can DANCE during intermission! Heh. I got that idea from Unreal, where the winner of the match would be shown during the intermission, and he could do taunts like the pelvic thrust. So I added that to FvF (we can vote into Deathmatch mode, though you can dance in Quest mode too). I gave the player 10 different dance moves to perform! Come and try it, people.

Yes, I'm self-promoting! We usually have "Sunday-night FvF" as the pre-planned time to gather and play each week.

@spike - I like my Quake simple which is why I like FitzQuake.

I don't even like menus, my engine has 1 more preferences menu than I like (because I would prefer zero).

I just like it to be simple.

I think users that are that serious that they need something like that -- need to be using an FTE or DarkPlaces. 
@gunter -- I was pursing a false lead, but I obsess about little behavioral differences like that. I'm going to overcome that and slap a "to be continued" on it since it's a Friday night. 
Quexpo 2116 
Celebrating 110 years of Quake.

Latest Engine updates to Mark LVI
Arcane Dimensions 3, so big we had to upgrade Mark LVI and QSS 101.5 to support bsp4 and protocol 77777.
QmasterIII's celebrating the release of his great grandfather's mod released in 2016 by adding aupport for AD2! 
@johnny -- Yeah I Fixed That Now ;-) 
We don't make typos.

Just syntax errors.... 
2116 - 1996 = 110? 
Never Was Good With Subtraction 
Hm, so vid_vsync simply does not work at all in the GL version (or Win version)?

In DX, changing the value gives a warning about it taking effect after mode change, and upon mode change (changing the resolution) the FPS will be clamped to 60 no matter what I have host_maxfps set at. And then everything looks smooth.

But in GL there is no warning and no change in FPS....

Can vsync not be made to work in GL (or Win)?

Also, since it requires a "mode change" it might be better to stick the vsync setting in the resolution menu so that it can be "applied" like any other mode change, but even without having to actually change resolution.....

Also, wasn't there a "mouse smoothing" thing in Quake at some point? I know there used to be the -dinput command line option.... My mouse movement does not seem very smooth. Er, well, I am using a touchpad on this netbook, heh, but still.. it is pretty un-smooth.

Let me plug in a usb mouse....

Oh! That's MUCH smoother with an actual mouse!

So I guess my question is: Is there any way to smooth the motion of my netbook's touchpad? heh. Shut up! I know I'm the only person on Earth who plays Quake with a netbook touchpad!

I have "mouse acceleration" disabled already. I hate that. 
Vsync in Direct3D is part of the specification. In Direct3D 8 or 9 you select it by setting PRESENT_INTERVAL_ONE (vsync on) or PRESENT_INTERVAL_IMMEDIATE (vsync off) when you create your Direct3D device. To change it you setup new present parameters with the appropriate options then Reset the device: the moral equivalent of a mode change. Direct3D 10+ is nicer: it's just a parameter on the Present call (equivalent of SwapBuffers for GL). To change it you just use a different value; no Reset or mode change needed.

Vsync is not part of the OpenGL specification because the OpenGL specification leaves that up to the OS (sometimes one wonders if the OpenGL spec authors take tips from Sir Humphrey Appleby). Typically on Windows it's implemented by the WGL_EXT_swap_control extension, although it's entirely possible for a vendor to define their own extension for it. Because it's an EXT extension, drivers aren't obliged to support it.

So if your OpenGL driver doesn't have an extension for vsync you don't get to have vsync in OpenGL - even if vsync works in Direct3D on the same hardware and OS.

In cases such as that you might find a setting for vsync in your driver's control panel. 
Hm, no vsync options in my limited OpenGL control panel.

I guess I will stick with the DX version, after all that hassle getting the GL one to work, hah.

Oh well, the mirrors look cool, but they actually cause a pretty big FPS decrease for me anyway. 
@gunter --- Like MH said ...It's your Open GL drivers. Your log says "Swap Support" found. So Mark V tries to use it. Apparently when it tries to use it, nothing happens. 
On the other hand... it seems I'm still getting the intermittent crash on level change with DX....

Dr. Watson says the crash was caused by "access violation."

I guess I'll run with -developer and wait for it to happen again to see if the qconsole log has any information.... 
Gunter ... do cl_autodemo 1

If you ever have that happen again, upload the autodemo (the most recent demo living in your id1 folder or whatever gamedir you are using).

Mark V cl_autodemo only keeps 3 autodemos at any time so it isn't a burden or resource consumer. 
Got it.

And m_filter was probably the mouse smoothing thing I Was thinking of.... However, in Mark V:

]help m_filter
Console variable: (TODO: UNUSED -- remove)


Also, I tested on the older WinXP laptop, and vsync did indeed work in GL Mark V. I guess my netbook just doesn't handle the GL vsync techniques correctly.

+zoom_key -- I think you are setting the sensitivity too low when this is used. 1/10th standard sensitivity seems better (10%). Looks like you're using 6.25%

There's an issue with the Winquake version if you run in a window with the vertical resolution set the same as your screen height. Like if I run in an 800 x 600 window on my 1024 x 600 netbook. The HUD is chopped off at the bottom of the screen. 
1) +zoom_key ... Make your own or edit it to your liking and put in autoexec.cfg as follows ...

type "aliases" in the console and then "copy" to copy the console contents to the clipboard.

Put your edited version in autoexec.cfg.

2) Then don't use 800x600 windowed mode ;-) Not engine's responsibility to save the user from his own choices.

do ... vid_fullscreen 0; vid_width 800; vid_height 540; vid_restart

or something 
Error Loading Game 
Hello again.
I have the following problem in the newest version playing standard Quake. I save the game at the beginning of levels. When i try to load it the game crashes with the message "R_Renderview: called without enough stack". Curiously, if I start a new game and then load the save, it loads properly. 
I'm using the software renderer. 
I'm trying to reproduce this. I'm not getting the problem.

Are you using a command line or the Quake Injector or anything that would be adding command line parameters? 
Nope, a clean installation with the original files from the gog version. Just deleted config.cfg and autoexec.bat and the problem persists. I get the same crash in the openGL version but a different message "R_Renderview: NULL worldmodel". 
When you're killed and press a button to respawn, you're moved to the beginning of the level but you're still "dead". 
The problem you are having is pretty different, I'd like to help you solve it I can, but need information since "R_Renderview: NULL worldmodel" -- should be almost impossible as error with a valid map.

1) Are you playing regular Quake or a Mission Pack or something else or a specific map?
1b) If not regular, what are typing in to play it?

2) Are you using replacement content?
2a) Are you using .lit and .vis from the download?

(NightFright supplied that I haven't personally tested it, but he's very thorough but if put in the wrong folder could cause problems.)

3) You are on Windows using the current version at

4) Could you post your config.cfg, autoexec.cfg and qconsole.log (when it crashes)? 
To make sure everything is in order I made a new directory, only id1 folder with pak0.pak and pak1.pak and the mark v files (also downloaded again). I started the game on normal, entered the portal and saved at the slipgate complex. If I start mark v and attempt to load the game from the menu I get the crash.

1)Just pak.0.pak and pak1.pak from the gog installation, no mods installed no changes in config, no autoexec.


3)win10 home 64bit, yes newest version, both opengl and software crash.

4)config.cfg (default, made no changes for the purpose of this test)
// Mark V
bind "TAB" "+showscores"
bind "ENTER" "+jump"
bind "ESCAPE" "togglemenu"
bind "SPACE" "+jump"
bind "+" "sizeup"
bind "," "+klook"
bind "-" "sizedown"
bind "." "+mlook"
bind "0" "impulse 0"
bind "1" "impulse 1"
bind "2" "impulse 2"
bind "3" "impulse 3"
bind "4" "impulse 4"
bind "5" "impulse 5"
bind "6" "impulse 6"
bind "7" "impulse 7"
bind "8" "impulse 8"
bind "=" "sizeup"
bind "[" "impulse 10"
bind "]" "impulse 12"
bind "`" "toggleconsole"
bind "a" "+moveleft"
bind "d" "+moveright"
bind "e" "+movedown"
bind "q" "+moveup"
bind "s" "+back"
bind "t" "messagemode"
bind "w" "+forward"
bind "~" "toggleconsole"
bind "CTRL" "+attack"
bind "ALT" "+strafe"
bind "SHIFT" "+speed"
bind "PAUSE" "pause"
bind "LEFTARROW" "+left"
bind "RIGHTARROW" "+right"
bind "UPARROW" "+forward"
bind "DOWNARROW" "+back"
bind "PGUP" "+lookup"
bind "PGDN" "+lookdown"
bind "END" "centerview"
bind "F1" "help"
bind "F2" "menu_save"
bind "F3" "menu_load"
bind "F4" "menu_options"
bind "F5" "menu_multiplayer"
bind "F6" "echo Quicksaving...; wait; save quick"
bind "F9" "echo Quickloading...; wait; load quick"
bind "F10" "quit"
bind "F12" "screenshot"
bind "MOUSE1" "+attack"
bind "MOUSE2" "+forward"
bind "MOUSE3" "+zoom_key"
bind "MWHEELUP" "impulse 10"
bind "MWHEELDOWN" "impulse 12"
_cl_color "0"
_cl_name "player"
_cl_sky ""
_hd_folder "hd"
_snd_mixahead "0.1"
bgmvolume "1"
capturevideo_codec "auto"
capturevideo_console "1"
capturevideo_fps "30.0"
capturevideo_hack "0"
capturevideo_mp3 "0"
capturevideo_mp3_kbps "128"
cfg_unbindall "1"
cl_anglespeedkey "1.5"
cl_autodemo "0"
cl_backspeed "400"
cl_bob "0.02"
cl_bobcycle "0.6"
cl_bobside "0.02"
cl_bobsidecycle "0.9"
cl_bobsideup "0.5"
cl_bobup "0.5"
cl_forwardspeed "400"
cl_maxpitch "90"
cl_minpitch "-90"
cl_movespeedkey "2.0"
cl_pitchspeed "150"
cl_rollangle "2.0"
cl_sidebobbing "0"
cl_sidespeed "350"
cl_upspeed "200"
cl_yawspeed "140"
contrast "1"
crosshair "0"
cutscene "1"
external_music "1"
fov "90"
gamma "1.0"
gl_polyblend "1"
host_maxfps "72"
host_sleep "0"
host_startdemos "1"
in_freelook "1"
in_keymap "1"
in_system_enhanced_keys "1"
lookspring "0"
m_filter "0"
m_forward "1"
m_pitch "0.022"
m_side "0.8"
m_yaw "0.022"
nomouse "0"
pq_bindprotect "0"
pq_download_http_locs "1"
r_clearcolor "2"
r_lavaalpha "1"
r_mirroralpha "0.2"
r_slimealpha "0.7"
r_stains "1"
r_viewmodel_fov "90"
r_viewmodel_offset "0"
r_viewmodel_quake "0"
r_viewmodel_ring "0"
r_viewmodel_size "0"
r_wateralpha "0.5"
r_waterripple "0"
r_waterwarp "1"
saved1 "0"
saved2 "0"
saved3 "0"
saved4 "0"
savedgamecfg "0"
scr_clock "-1"
scr_conspeed "300"
scr_originalquake2d "0"
scr_sbaralpha "1"
scr_sbarcentered "1"
scr_scaleauto "1"
scr_showfps "0"
sensitivity "3"
sndspeed "11025"
sv_aim "0.93"
sv_altnoclip "1"
sw_sky_load_skyboxes "1"
v_gunkick "1"
v_kickpitch "0.6"
v_kickroll "0.6"
v_kicktime "0.5"
v_polyblend_lite "0"
v_smoothstairs "1"
vid_fullscreen "0"
vid_height "480"
vid_refreshrate "60"
vid_sound_thread "1"
vid_stretch "1"
vid_vsync "0"
vid_width "640"
viewsize "100"
volume "0.7"

no autoexec file


Command line: [ ]
Log file: D:\test/id1/qconsole.log
Sat Nov 19 23:32:18 2016
WinQuake Mark V Windows (Build: 900)
Exe: mark_v_winquake.exe (1064 kb)
Exe: 14:43:15 Nov 18 2016
Caches: C:/Users/myname/AppData/Roaming/Mark V/caches
UDP4 Initialized: INADDR_ANY,
IPv6 Initialized: [fe80:0:0:0:9d90:b865:2c23:5f89%5]
Exe: 14:43:00 Nov 18 2016
256.0 megabyte heap
joystick not found -- no valid joysticks (a5)
Input initialized
Avi capturing module initialized
ACM module initialized

Sound Initialization
Set primary sound buffer format: yes
Using secondary sound buffer
2 channel(s)
16 bits/sample
11025 bytes/sec
DirectSound initialized
Audio: 16 bit, stereo, 11025 Hz
Sound sampling rate: 11025
CDAudio_Init: No CD in player.
CD Audio Initialized

========= Quake Initialized =========

execing quake.rc
execing default.cfg
execing config.cfg
couldn't exec autoexec.cfg
3 demo(s) in loop
Playing demo from demo1.dem.

the Necropolis
Using protocol 15
You got the shells
You got the Grenade Launcher
Loading game from D:\test/id1/s0.sav... 
Can you upload this save game file and both of your pak files?

This is very weird and I'd like to examine this. 
I just checked it with rogue/pak0.pak, same deal, if I save in the expansion next time I enter the game when I try to load I get the error.

Same exact files work fine with 20160915 version of mark v (checked again now just to be sure, fresh folder etc).

If you wish I can upload the files but I think this proves they're not the issue here. 
I need the files uploaded if I am to have any chance of examining your problem and solving it.

Keep in mind several people have used both the Open GL and WinQuake versions. 
As You Wish 
Going to take a look at this.

Cross your fingers and hope I can experience this problem. I have my fingers crossed.

/Otherwise, I can't think of any way I can help :( 
I'm getting the same kind of crash. It seems that the demo playback is causing it. Starting a singleplayer game or simply not running anything makes the savegame work. 
Good News! 
With your pak files and your save game I can reproduce your problem.

It appears to be your pak files, somehow. Your pak0.pak in particular is not the same size. Your pak1.pak appears to be the same as mine.

Your save game does not cause me problems with my pak files.

I'll have to come up with a plan to figure out what is different and why it is happening.

/It's getting late and I'll probably do that tomorrow. But looks good that I'll be able to solve your problem. 
Pretty awesome I can reproduce problem and if you are getting it too, that helps.

I'm not getting problem with my own pak files.

And he says slightly older Mark V didn't have issue.

So I'll see what solves this little mystery and what is going on. 
/But it's late. Tomorrow sometime is most likely time. 
Pak sizes in my installation:

pak0 18312419
pak1 34362368

They're different on my CD:

pak0 18689235
pak1 34257856

I checked and, as expected, the difference is applying the vis patch. Regardless, the paks copied from the CD didn't fix the crashing for me (which is present in mods like Malice as well). 
There's currently a hard limit on the number of polygons a model can have at 2048, and unfortunately that means some model packs don't really work now. I don't see why that's in there, perhaps that cap can be removed? 
Model Limits 
I've thought about the model limits. Quakespasm Spiked, for instance, loosens those up, and Enhanced GLQuake and I believe JoeQuake had higher limits.

In trying to get to the engine out beta stage to release Quake stage, I decided to skip thinking about that in the current release.

FitzQuake 0.85 has compatibility warnings (*), and I'd want to make sure a compatibility warning printed and also make sure no consequences in the software render (WinQuake) version of Mark V.

Short version: Something I care about but decided to not address before doing the release.

Is it an issue? It sure is. I know of replacement models that won't work.

(*) which new Mark V mirrored the Quakespasm approach to only print those if developer is set to 2 or higher 
I'll address this in some form in the next 24 hours. 
WinQuake Model Limit 
According to Enhanced GLQuake/Enhanced WinQuake by Ben Jardrup ...

He raised the vertex limit to 3984 with the comment 3985 or higher seems to crash assembler (?) ... (means WinQuake's assembly language code).

So looks like I'm going to use 3984 as the new vertex limit which is about double current limits.

He raised the triangle limit to from 2048 to 4096. So I'll increase to that limit.

So both of those limits will about double, and it will be compatible with both the Open GL version and the WinQuake version.

(Ben Jardrup wrote one of the most backwards compatability-minded and thoughtful engines ever. Widely used until FitzQuake 0.85 came out with a similar limit raising capabilities). 
New version update, details in the new thread

This thread should really be closed and I'm going to post in General Abuse ask if a moderator could do that.

/Crazy to have 2 threads open. 
2 posts not shown on this page because they were spam
First | Previous | Next | Last
This thread has been closed by a moderator.
Website copyright © 2002-2019 John Fitzgibbons. All posts are copyright their respective authors.