News | Forum | People | FAQ | Links | Search | Register | Log in
Mark V - Release 1.00

* Nehahra support -- better and deeper link
* Mirror support, "mirror_" textures. video
* Quaddicted install via console (i.e. "install travail")
* Full external texture support DP naming convention
* Enhanced dev tools texturepointer video inspector video
* IPv6 support, enhanced server capabilities
* Enhance co-operative play (excels at this!)
* Software renderer version (WinQuake)
* "Find" information command (ex. type "find sky")

Thanks to the beta testers! NightFright, fifth, spy, gunter, pulsar, johnny law, dwere, qmaster, mfx, icaro, kinn, adib, onetruepurple, railmccoy

And thanks to the other developers who actively provided advice or assistance: Spike (!), mh, ericw, metlslime and the sw guys: mankrip and qbism.

/Mac version is not current yet ...; Linux will happen sometime in 2017
First | Previous | Next | Last
@steve - I'm Not Doing An MD3 Tutorial 
I'm not doing an MD3 tutorial. 
@mh - Pointing Out A Line Of Code 
d3d9_glcontext.cpp - line 206

if (mode.Format != d3d_Formats[i]);

Note trailing semi-colon. 
Ouch! Good catch. 
Some More Feeback ... 
Good catch.

I was like, "Uh, that doesn't look like intentional code. MH wouldn't do it like that, I don't think. He'd probably have empty brackets"


glEnable (GL_STENCIL_TEST) ... EnableDisable ... unknown param. Haha ... I was hoping I'd be looking at myself in the mirror on the start map when I just compiled.

GL_ARB_texture_non_power_of_two not found. Since I think you actually wrote this, I'll probably just improvise.

Have some plenty more integration to do, but it's going pretty smoothly ;-)

It runs and plays at the DX8 functionality level, but of course that isn't the goal here and I have about 45 instances of slightly different treatment that I did for DX8 which I have to recode/tune/etc. 
@pulsar - Re:autosaves 
I did change the name of the autosaves to auto_save_0.sav, auto_save_1.sav, auto_save_2.sav (they used to be named a0, a1, a2)

Type: load auto_save_0

... for most recent autosave. It does default on. And should auto-complete.


Type: load (press ALT+Space .. autocomplete from nothing capability)
Type: load a (press TAB)

Let me know if everything is ok.

btw -- Better than even chance "shadows on platforms, lifts, etc." will be available as an option to put in worldspawn at some point. At one time you expressed interest in "true lightpoint" and is something being discussed as an mapping opt-in. 
I did everything for stencil test except the enable...!

I could easily add NPO2. 
I made a quick and unknowledgable run at making glEnable for GL_STENCIL_TEST work. But was unsuccessful.

Mirrors work though -- this means that glDepthRange is working quite nicely! (The current implementation of mirrors doesn't need stencil very much. I use glColorMask (0,0,0,0) /*don't write color*/ mostly to do a depth write where the mirror surface lives instead. ) 
@johhny - Concept Visual For In-engine "Quake Injector" 
Spirit and a few others (mostly of the engine development variety) may remember this.

Baker's Visual Concept of a Built-In "Quake Injector"

Take that and then consider the Undergate and becomes possible to see the vague direction it is ultimately heading. And explains some of Mark V feature set very well.

/Note: I actually made something like the Quake Injector before the Quake Injector existed screenshot. Only a few people were interested in it, was harder to get people interested in single player at the time. Plus engine coding was more interesting to me. Was happy when the Quake Injector came out, promoted it quite a bit. 
OK, I've pretty much fixed all of those items.

I currently don't have a test case for stencil because the stock Fitz code doesn't use it. What I'll probably do is add stencil buffer support to r_shadows 1, because it's quick and easy to do and was in a well-known tutorial too, so it's well-known to the community.

Adding the enable/disable for stencil should have been easy and more or less self-explanatory: just follow the pattern of the others, using GL_STENCIL_TEST and D3DRS_STENCILENABLE. There are a number of reasons why this might not work though, including if a pixel format was selected without a stencil buffer.

I'll fix all that up and make it nice and robust. 
Hah, nice screenies there Baker.

It's kind of hard to get a handle on all the Quake content out there and how to use, but at least partially that's a "nice problem to have" sort of situation. 
MD3 Loading 
The fun thing about MD3 loading is: where do you stop?

You see, MD3 is more than just a model format. Once you have that done, you're going to want textures too. And because content creators always want maximum flexibility, you're going to want the full Q3A shader system. And you're going to want to draw it from vertex arrays because that's the way the format is designed. But by that point you've more-or-less reimplemented the full Q3A renderer in the Quake engine.

This is a design goal of engines like DarkPlaces and FTE. It's not a design goal of other engines, and because time isn't an infinite resource, time spent doing this is time not spent doing other stuff.

Back when I quit working on DirectQ, part of the reason why I killed the engine was because it was being pulled in too many different directions. The SP guys wanted one set of things, the MP guys another, content replacement people wanted something else, modders, mappers, QC people, low-end people, high-end people - all different and sometimes overlapping but sometimes conflicting requirements. Meantime there was only one of me.

You absoluetly do need a laser-sharp focus and you absolutely do need to say "no" and be non-negotiable about it. DirectQ is a cautionary tale of what can happen when you don't.

If I had 5 $/�/�/� for each time somebody asked me "can you just implement $PET_FEATURE, I'm sure it will only take you 5 minutes and it would be so cool" - I wouldn't need to work for a living and would actually have time to do this kind of stuff!

As it stands I don't have that kind of luxury, so I have to cherry-pick what I spend my time doing, and also mix it in with beer/friends/other hobbies/eating/sleeping/entertainment/etc.

While the very same specifics may or may not apply to Baker, it should be obvious from his prior posts that he is similarly time-constrained.

So, options. If Baker has 1 week between now and June, is it better spent writing an MD3 tutorial or is it better spent doing other Mark V work? 
Stencil Buffer Stuff 
That's all working now.

One point to note in Mark V:

32, // 32-bit z-buffer
8, // 8-bit stencil buffer

This is actually bumping your hardware requirements to D3D10 or higher class hardware.

Hardware typically doesn't actually have separate depth and stencil buffers, but rather a single interleaved depth/stencil buffer. The common options are:

* 16-bit depth.
* 24-bit depth, 8 bit unused.
* 24-bit depth, 4-bit stencil, 4-bit unused.
* 24-bit depth, 8-bit stencil.
* 32-bit depth.

I'm not sure how prevalent 24-depth/4-stencil/4-unused is in the wild, and I think 32-depth had issues on older hardware (I recall some Intels actually giving you 16-bit depth if you requested 32), but the other formats are robust and compatible.

So if you require a stencil buffer you should always request an 8-bit stencil buffer and always drop depth bits to 24.

Because they're interleaved, you should always try to clear both depth and stencil at the same time too. You'll get a faster clear that way.

Anyway, in it's current state the wrapper just sniffs for the presence of stencil bits in the PIXELFORMATDESCRIPTOR and if present it gives you a 24-depth/8-stencil format, irrespective of how many bits of either you request. Otherwise you get 24-depth/8-unused (which I might change to 32-depth sometime).

This behaviour may change in future versions to better reflect what you actually ask for, so I don't advise relying on it. 
I know about the stencil, at least on a subconscious level, switching areas of the engine quite often (IPv6 --> input --> system messages --> etc.) I lose sharpness.

mh: Back when I quit working on DirectQ, part of the reason why I killed the engine was because it was being pulled in too many different directions.

I don't want to beat this to death, but you always have to tell someone "no" to "help me with my engine coding" 3 or 4 times because are in above their heads in something.

And if you help them, you have created a cycle of dependency, like giving a homeless person some food.

They'll be back on your doorstep tomorrow if you help them.

I already said explicitly I am not an engine help forum, but I knew I would need to say "no" more times because I have been in that situation dozens of times.

Someone who exhibited the capability to truly engine code would be able to take what is in JoeQuake (the MD3 code in that engine is quite easy to understand) and do it themselves. Plus they would not be using CodeBlocks on Windows, they would be using the vastly superior Visual Studio.

Anyways ... I can empathize with the situation, but if you can't take the md3 code from JoeQuake and use that as a tutorial, you have no business engine coding at all and need to immediately stop doing it.

/Enough said. Much to do! 
Plus also, if you don't have Visual Studio that means you never tried to compile JoeQuake which is in Visual Studio.

Therefore, by definition, you aren't trying very hard to begin with. And engine coding is hard as hell and such laziness disqualifies you from having what it takes to engine code.

/Ok, I lied a little last post. Enough said. Like this time I really, really mean it. Unless I change my mind. ;-) Much to do ... 
@baker: There is no reason to get rude.. 
Dude --- you've told me
1) My source code was broken.
2) 5-6 instances of "engine coding help" type questions, with 2-3 of "other model format" after a politely, but clearly worded "no".

Did you not eventually expect get the "Are you hard of hearing?" version?

I sure would have ;-)

You probably have a great project, but by all appearances you simply don't have what it takes to do engine coding.

Whether or not that is "rude" or fair or even not fair, it just is what it is.

It is important for someone in your situation --- the "I'm in over my head situation" --- to get a reality check.

As someone who has been the beneficiary of "reality checks" by other engine coders (mh and Spike have given me "reality checks" in the past, especially when I was very new. Bet you didn't know that! They were very helpful reality checks. It wasn't what I wanted to hear, it was what I **needed** to hear) ...

In low-level coding this is someone doing you a favor. 
Beta Mark V Direct3D 9 Version 
Direct X 9 Version | Source Code

If started with -nostencil .. is mostly solid.

And no switching between full-screen and windowed mode, and no alt-tab in full-screen mode, should work ok.

Doesn't have r_waterwater integrated yet, not shader based gamma/contrast isn't available yet either.

More work to be done in the mode changing and ALT-TAB department. ALT-TAB in some instances has issue with gl_oldwater 0, seems to be full-screen mode only).

Likely an incomplete implementation on my part, it appears something subtle is missing and I'll have to do a deeper examination to see what it is. 
DirectFitz9 video mode changing issue

bind y "toggle vid_fullscreen; vid_restart"

Switch to the largest resolution available.
Then press "y" a couple of times.

The window positioning acts up. I remember with the Direct3D 8 wrapper there may be been an issue with windowed resolutions that overlapped with the window taskbar (the bottom of the screen bar showing applications running).

With the Direct3D 8 wrapper, I believe that since I completely destroyed the window and everything else upon switching between fullscreen and windowed mode, it wasn't a problem.

From all appearances, doesn't look like the Direct3D 9 wrapper supports that. And maybe it shouldn't.

(*) Note: I don't know what version or versions of Windows you run, but at one point Windows 8 was rather displeased with changing Window borders and attributes without DestroyWindow even with Open GL. Since DestroyWindow and ReleaseDC and then recreating the window in Open GL, and then reassigning the context (HGLRC) typically works, not much of an inconvenience. I haven't checked Windows 8 SP 1 or Windows 10 to see if Microsoft "fixed" that behavior that Windows 8 introduced in a later update. 
Dx 9 + Topmost Window (solved) 
The "always on top" window issue I experienced works like this:

1) Only if dx9 starts up in fullscreen mode, it seems that Direct3D (not in your code) gives it the topmost attribute.

In d3d9_glcontext.cpp, adding this (trivial) statement before Sleep (10) in ResetMode solves the issue:

if (windowed) SetWindowPos (this->PresentParams.hDeviceWindow, HWND_NOTOPMOST, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE);

The issue is not immediately experienced in DirectFitz 9 because it starts up in windowed mode, then executes config.cfg which contains a vid_restart command.

However, switching to fullscreen and then back to windowed mode, the window will exhibit a permanently topmost behavior. 
Beer for Baker, that's good detective work and useful info for me! Hope to have a new release over the next few days. 
I did change the name of the autosaves to auto_save_0.sav, auto_save_1.sav, auto_save_2.sav (they used to be named a0, a1, a2) </a>

ah, see. I used to type load a0 without tab and was suprised when found that file is missing. 
@mh - Shader Gamma No Problem With Off By 1 Pixel So Far 
I have not yet ever experienced the "off by 1 pixel" issue with shader gamma in Mark V.

I wonder why it happens in DirectFitz9.

Haven't implemented resize-window-on-the-fly. I'm hoping that the "off by 1 pixel" oddity doesn't surface there either.

More to do. 
Sorry, Pulsar. I should have done a better just communicating the change.

Wanted to make the autosave names more clear and obvious to a newcomer. 
DirectQ V2.0? 
Are you guys making a DirectX engine that can play Arcane Dimensions, right? My low-end netbook can barely play it on Quakespasm sometimes but with the DX9 engine it stays mostly on 60 fps on the few maps that can support it, most still crash.

That would be a miracle. 
I suspect over the course of the week that the answer is mostly likely a "Yes!" 
Direct X 9 - Beta 1022 
Direct X 9 Version | Source Code

Requires -nostencil in the command line. Stencil buffer is not yet operational. Does not yet have WinQuake-like r_waterwarp integrated.

c:/quake/DirectMark5.exe -nostencil

Does have fully resizable window capability.


Set to 0 = shader gamma (looks nicer in windowed mode)
Set to 1 = hardware gamma [default] (in high resolutions, can be very much faster than shader gamma)

@mh - Some issues exhibited in DirectFitz 9 prototype do not seem to happen in DirectMark5.exe Build 1022. Will do some more testing, but Mark V handles video mode changes differently than FitzQuake and I rewrote small parts of the wrapper. I think the issue list may have gotten smaller, but more testing will tell.

/Source code link will probably work in 10-15 minutes. 
@mh - Vid_vsync + Windowed Mode 
vid_vsync 1 works in windowed mode, but apparently not right away. If I press ALT-ENTER a couple of times, windowed mode doesn't take it.

As a work around for now, I feed it into the command buffer as such ...

Added into end of setmode for now ...

// Vid_SetMode
// Window already created or recreated ...

Vid_Vsync (); // Fullscreen fine, windowed mode no effect though ...

// ensure swap settings right
if (vid.screen.type == MODE_WINDOWED && vid_vsync.value)
... Cbuf_AddText ("vid_vsync 0; wait; vid_vsync 1"); // Works!

Wanted to make the autosave names more clear and obvious to a newcomer.
Any particular reason you inserted an extra underscore in auto_save, then? autosave_0, autosave_1 etc seem more obvious to me since I've always read it as a single word and not two words separated by a space. Or even autosave0, autosave1...: the underscore is more of a programmer thing that isn't intuitively used by n00bz. Plus, the less characters to type the better IMHO. 
To Avoid Name Collision With Existing Single Player Mods 
There are some single player releases with autosaves built into them. So I don't want to use a name like "autosave", for instance.

In Mark V, someone who used it any length of time would just type "load a" and press TAB.

1) So no one would be typing more stuff ;-)
2) You just need to remember the "a", you don't need to know the name.

Mark V auto-completes even ..
1) skybox names (!!!)
2) key names
3) demo names
4) save names
5) map names
6) game folders
7) Several other things.

Mark V can auto-complete in the middle of line! If you have a long line, you can backspace in the middle of it and press TAB or ALT-SPACE and it won't mess anything up.

In fact, Mark V even has undo and re-do! You can press CTRL-Z or CTRL-SHIFT-Z (redo) in the console.

That's in addition to being able to hold down shift and select text in the console and copy it or paste it.

And in addition to being able to press CTRL+PGDN and CTRL+PGUP to resize the console.

Mark V is user-convenience engine ;-) 
Direct X 9 - Mark V - Beta Build 1023 
Direct X 9 Version | Source Code

Requires -nostencil in command line, as stencil buffer isn't ironed out.

1) r_waterwarp 2 is WinQuake style waterwarp
2) Resizable window at any time
3) Shader based gamma available (vid_hardwaregamma 0), look nicer in windowed mode. Hardware gamma is faster, especially in high resolutions.
4) The renderer is faster. Startup and Alt-Enter are astonishingly fast. Haven't been able to get a complete handle on the speed increase, but certain highly complex maps seem to render at least twice as fast.

@mh - I've taken it about as far I can go ;-) Aside from some outstanding testing situations I've thought of and some polishing up ideas I've charted out.

1) stencil
2) non-power of 2 texture sizes
3) Technically, vid_vsync 1 + windowed mode doesn't immediately work at video mode change time, but I did a workaround putting some commands in the command buffer.
4) Without thinking too hard, I do not believe there are any other outstanding issues. I don't have any known mode switching issues ever nor the off by 1 pixel shader gamma issue either.

I have the engine use the provided Direct 3D screenshot method when the buffer already has gamma/contrast applied to it (if shader gamma is on, for instance), since it seems to be at least 3 times faster when writing PNG (PNG is a notoriously slow format to write). 
So there is a valid reason, then. OK thanks. 
MarkV Has Better Autocomplete Than Some Text Editors 
I have no time for testing with a house full of visiting mini-ogres. And it looks like there's still work to be done before exhaustive testing really begins. 
Been sick the past few days so I'm a little behind schedule, but all of the items mentioned by Baker above are now fixed. I haven't yet integrated the changes Baker made to the wrapper.

There's some weird interactions I want to shake out between video startup, mode switching and window resizing, but if it takes me too long I'll just do another upload of the current version with window resizing flagged as "potentially unstable". 
More On Vsync 
Current vsync behaviour is a bug in my code.

What's happening is that the vsync setting is not holding across a device reset. Now, sometimes (e.g. if creating a new context or doing anything else which reverts all state back to defaults) that's the behaviour you want, but other times (mode change, alt tab, etc) it's not.

The quick and dirty fix is to find the line "this->PresentParams.PresentationInterval = D3DPRESENT_INTERVAL_IMMEDIATE;" in context_t::SetupPresentParams, remove it from there and put it into context_t::context_t *above* the call to this->SetupPresentParams instead.

That should be enough to get you going and you can remove your workaround. :) 
A bit more about the flickering:

I played through DOPA using mark_v_winquake.exe and didn't notice any flickering.

I switched over to using mark_v.exe for playing ad_mire, and I noticed flickering pretty regularly (played up to the point of turning the first valve). Switched to quakespasm_sdl2.exe and played through the same part of the map, no flickering.

I'm using a GTX 1070 with latest drivers. Let me know if you ever want some additional system info, or for me to try anything out. 
Autosave Issues 
A couple of things about autosaves:

- I noticed they don't show up in the load-a-saved-game GUI menu. Is this intentional?

- The first time you play in a particular gamedir, "load a" will not autocomplete any autosave names even if enough time has elapsed to create one or more autosaves. It looks like the autosave names are not recognized, at least for autocomplete purposes, until you after do a manual savegame. 
@Baker: New Wrapper Version

You'll need to do a diff with the original wrapper engine code for this too, because there are some subtle changes required engine-side relating to Alt-Tab handling.

I dropped your "ResizeWindow" and rewrote "ResetMode" to handle switching from Windowed to Windowed without other changes.

There's a changelog included so you can see what's different/fixed/broken/etc since the last release. 
Cool! I'm kind of sporadic during the holidays.

Look forward to checking out the code!


I noticed they don't show up in the load-a-saved-game GUI menu. Is this intentional?

Yes, at least for now. FrightNight and I didn't like non-user based save games in the menu. Doesn't mean that is a "final answer" or that couldn't change, but unwanted "randomish" save games in the menu seemed wrong.

The first time you play in a particular gamedir, "load a" will not autocomplete any autosave names even if enough time has elapsed to create one or more autosaves.

I'm rather certain that is perception only. While I haven't checked, one thing I do know is that any save game forces an autocomplete update.

The first save has a bit of different interval because who really cares about a save game when you've played less than 2 minutes, if you see my point.

An autosave is a "Help! I forgot to save and played for 45 minutes!" feature as a safety net for the player.

The "I died 100 seconds into the map" isn't really what autosave is there for, you know ;-) 
Also, you have hit on a fine-tuning weakness.

I usually start coding something "too conservatively" and then gravitate it towards what the user would expect.

Which is fine and the right way to do things.

You make it work efficiently first, then you relax it to conform to user expectations and figure out how it fits into the user interface correctly.

It is ok for something to be over-efficient at first, but not user-tuned. If something is written over-efficiently, that is the right kind of problem to have as a starting-point. 
It's Not Perception-only 
Give it a try. :-)

The issue is that Lists_Update_Savelist is only invoked on new game or on manual save (in Host_Savegame_f). 
@johnny - Everyone Can Make Mistakes 
That being said,

void Host_Savegame_f (lparse_t *line)
Lists_Update_Savelist (); <---

It don't think I'm wrong about this, but even if I happen to be right (at a quick glance looks to be the case) don't stop telling me about things you think I overlooked. 
But actually you are right. That is the user-initiated pathway. The auto-save mechanism never hits there.

Shadows That Suck Slightly Less 
I ported Q3A's r_shadows 2 mode to DirectFitz.

I guess not many people are aware of this mode (I'm certainly not aware of any well-known Q1 source ports that use it), but it uses a simplified variant on stencil shadow volumes to resolve many of the major annoyances of classic Quake's r_shadows.

Just to manage expectations a little, it's not real-time lighting, it doesn't give you arbitrary shadows from any number of lights, it doesn't fix dynamic light shine-through; what it does do is fix cases where classic Quake r_shadows 1 breaks down, such as on steps, at edges, on angled surfaces, etc. 
Definitely Looks Better In That Screenshot. 
This Is Cool 
I was aware of this mode in Q3A, but I couldn't enable it on my latest system.

Am I seeing self-shadowing on the shot? 
Looks Neat 
I think I would prefer just a kind of simple blob shadow under the monster ala turok or something like you see in severance 
@MH Q3A R_shadows 2 
I implemented Rich's shadow tut years ago in Qrack,(the un-interpolated version) and works fine enough, yet it's BASIC openGL v1.1; no vertex arrays. Combined with applying an alpha value based on how bright the surrounding light brightness can make it look someone real, hard-edge yet conforms to stairs/walls/slopes.
I'll have to look at Q3A's method for a quick and dirty CPU-driven shadows vs the stock shadows in Quake.
The pic you posted above imho is what Quake should have had from day one. It just makes the scene more immersive :)! 
The Q3A shadow code doesn't use vertex arrays, but just to correct a misconception: vertex arrays are also basic GL 1.1. 
lol, you'd think I would know this by now ;) 
No Readme? 
Some of us like to refer to documentation. Let me guess... it's built in? Well how and I to know that? 8-P 
Next version will have a worldspawn option to increase sound distance. As an experiment to see if it is useful. Mostly because of issue you mentioned about sound cut-off being undesirable for what you are working on.

re:readme - this thread mostly serves that purpose for now. The "find" command in the engine is also helpful (like type "find sky" in the console ).

This is more of an interactive project with those that want to participate and help test and refine and such. 
@mh - Borders 
@rook - Yeah, I quite like what MH did with the shadows and your "what Quake should have had from day one" is what I think about that awesomeness. ;-)

mh - regarding window borders. aguirRe back quite a while ago now, made a "fullscreen windowed mode" and every engine I worked on since emulated that behavior.

If the window size is the desktop size, no borders. So that is one reason why I wanted the engine to say what the borders should be. Also want to preserve resizable borders as an option (the D3D wrapper may end up encasing the software renderer in an optional build that uses a texture as the frame buffer, which I don't feel like implementing resize for the software renderer right now since is moderate hassle) or keep the option of no borders as a possibility even in windowed mode (because some external video capture tools capture window borders).

So that's what is up with that and my comment in the code. If that seems reasonable. 
Random Engine Dev Stuff 
1) Noticed Requiem engine (by jdhack, I've referred to it as "Spirit's engine", and johhny law as I understand it has put some work into it too) --- uses "force char as unsigned char" option during compilation. Tried that option with Mark V, about 5 fields of code inherited elsewhere had to be changed from char to int.

Any proper C code is going to treat char as both signed and unsigned simultaneously (C specification allows both as valid treatment) but when debugging I don't want to see -40 or -128 or even -1 as a value for a char field. Slows down debugging to have to think ;-)

2) Newlines in Con_Print, etc.

I view newlines and quotes in a printf as a source of fragility and an ease-of-reading nuisance.

And as an example, Google's Android platform debug logging expressly thinks in terms of fully-formed lines and you don't supply the newline.

I used a tool to "robotically" identify and replace Con_Printf to Con_PrintLinef where applicable and then examined what remained.

Most of the Con_Printf without a newline at the end, it was unintentional, as I suspected.

Anyway, in the next version, that behavior has largely been expunged in the entire engine barring obvious circumstances that must persist like QuakeC or messages from the server or the reverse.

Makes code easier to read and more maintainable.

3) Speaking of Con_Printf ...

Con_Printf has always been borderline undesirable, especially with vsync because it causes an immediate rendering of a frame --- but since using vid_vsync will pause engine operations until it is time to render a frame, can be quite undesirable.

In some circumstances you do want immediate feedback. Like "Connecting ..." or a very slow operation like "edicts" or some intermittent feedback for "imagedump" (FitzQuake dump OpenGL textures to folder command).

But most of the time, you simply do not want Con_Printf at all. It the opposite of an optimization. 
isn't there a Con_SafePrintf to solve that problem? 
Yes ;-) 
@johnny, Pulsar - Nvidia 
In unreleased Mark V (grabbed Windows DPI awareness from Quakespasm) tested on GeForce with driver version 373.19

No flickering.

Driver version 373.19 = ok
And didn't see flickering for 372.70 in previous test = looked ok

Will see what results are after next Mark V update. 
Next version will have a worldspawn option to increase sound distance. As an experiment to see if it is useful. Mostly because of issue you mentioned about sound cut-off being undesirable for what you are working on. That's great news. I had the same issue in my Retrojam map as well. A very large chamber and the doors and plats were silent. In reality you'd hear the sounds echoing from a distance.

I think adding dev tools like your inspector are a great help.

A suggestion: Can the console text be resized separately from the in- game text? I usually have in-game text at a legible size but that limits how much you can display in the console. Just an inquiry. 
@dumptruck_ds I'm pretty sure this is possible, in Qrack I have the realtime ability to resize the console text using ctrl+mwheelup/down which doesnt affect the mesagemode text size. 
@dumptruck_ds I'm pretty sure this is possible, in Qrack I have the realtime ability to resize the console text using ctrl+mwheelup/down which doesnt affect the mesagemode text size. 
haha what's Qrack? I downloaded but there's no readme????? Website is pretty minimal. Well I guess I could just try it. :) 
I do understand where you're coming from, but...

There are architectural and internal differences between GL and D3D, and how they interact with the windowing system. This is compounded by WDDM on Windows Vista or higher.

GL doesn't specify any interaction with the windowing system. You use GDI and native API calls, you have full control over everything, but also full responsibility to do everything yourself.

D3D has tighter integration and interaction with the windowing system is defined as part of the API. For example, you don't use ChangeDisplaySettings and a window resize to set a full screen mode; instead you specify a backbuffer size then Reset the device, and D3D will do this automatically for you.

That's why there are other differences too, such as the changes I've made to AppActivate. I don't make those changes for the jollies, or for some idealistic crusade for cleaner or nicer code. I make them because they're required.

Full screen is different between GL and D3D. D3D has a concept of a cooperative level, which is how (and if) your program cooperates with others. Windowed modes have non-exclusive ownership of the graphics hardware, meaning that other programs that also have non-exclusive ownership can run and use the hardware. Full screen modes have exclusive ownership, only one of those can use the hardware, and no non-exclusive programs can use it. (That's why lost devices happen - something else starts using the hardware that blocks your program's access to it).

GL has absolutely none of this. If a full screen mode has any meaning in GL then the driver is going to have to apply heuristics to detect it, perhaps by sniffing at the window styles or by comparing the window size to the display mode. What you think is a full screen windowed mode might actually be being converted to a proper full screen mode by the driver (another reason why it might seem to work in GL).

That's all background intended to help you understand that you just can't always do a 1:1 mapping between behaviours and that API differences go deeper than just syntax. Differences are architectural, and D3D is a whole driver model as well as just an API.

Regarding borders and full screen windowed modes - I tried it and it didn't work. I actually spent about 2 weeks at it over a year ago, and 2 weeks spent toggling between modes, setting breakpoints, printing out window and backbuffer sizes, then change something and try again, is enough for anyone.

The most common problem was that Windows wouldn't let the program window cover the taskbar. I don't have a direct link for this, but I believe that this is a deliberate change in newer versions.

Coming right up behind it was that the backbuffer was sized differently to the window client rect. This could be really subtle, but it was enough to cause the driver to need to do a stretch blit instead of just a buffer swap, and performance fell off a cliff.

Other problems included window positioning, not actually going full screen windowed at all, and issues around Aero styling when toggling modes.

In other words, when I say "I tried it and it didn't work" I'm quite satisfied that I did make a comprehensive enough attempt, and when I say "don't do this" I do expect you to believe that there are reasons for it. I'm not saying "don't do this" because I'm too lazy or don't want to make the required code changes, I'm saying "don't do this" because you really shouldn't. 
@mh - Limits 
Got it. It's all good ;-)

I know D3D is wired differently and I've read your comments. I was trying to express why I even would even want to do such a thing.

I'm rather good at working within boundaries ;-)

I rather cleverly worked within the limits of the DX8 wrapper and I can do that here too.

No worries! 
Ah, Aero style! That's jogging some memories with the DX8 wrapper. Not fun memories either! 
Aero Style 
Aero styles is one of those things that every time I do this it messes up in some way, so I spend a few days "poking it with a stick to see if it moves", until eventually I get there.

I should have probably added - none of this is that way that real cross-platform/cross-API games are written. What we're doing is taking code written around the way GL works/the requirements of GL, then mangling it to work with D3D. A real cross-API game isn't written like that at all. Instead it would have "SetModeGL", "SetModeD3D" and use the correct native code in each.

Much of this is from the perspective of pre-empting queries along the lines of "but game X does it so I don't understand why you can't". 
its at times like this that I apprechiate vulkan's WSI (windowing system integration).
its a bit like gl (in that its simply attached to the client part of a window), except with explicit swapchains like d3d (but cleaner and less annoying. its just much more sane than either.
fte now uses the same gl_vidnt.c file for both gl and vulkan. one renderer creates a wgl context attached to the window, the other a wsi surface. which is much nicer than having d3d doing random poorly-documented things to your window thereby breaking things.

vulkan's backbuffer is actually an image just like any other, which means you can blit true-colour software-rendered images to the backbuffer using only simple buffer copies, no glsl required. unfortunately the queues and stuff are kinda annoying. when everything uses compositors anyway, there's not really any difference between the backbuffer and a texture nowadays - render-to-texture for all!

I assume d3d12 is similar, but I've never really looked at that. 
From what I've seen of D3D12 it's much the same DXGI interfaces as D3D11, so you've got the same swapchains, texture with rendertarget view, and arseways crap of running in one of two modes: "we control everything and nothing works the way you actually want it to" or "we control nothing and you have full responsibility for all of the pain and suffering" - neither of which are the way you'd actually like it to run. 
eww, dxgi 
Ignored Opengl32.dll In Quake Folder Implemented 
My idea of doing a chdir to id1, forcing the opengl32.dll to load, then chdir back failed.

Had to revert to Spike's LoadLibrary/GetProcAddress suggestion.

Wasn't a big deal, since Mark V is already setup to rewire rendering functions (OpenGL vs. Direct X 9, etc.)

A call to getenv("COMSPEC") /* should be highly retrocompatible*/ obtains the system directory where the correct opengl32.dll should live.

If it doesn't find the .dll there, or can't load that .dll or any of the functions fail to load, it describes the problem and asks user to rename opengl32.dll

It also prints a few lines of bronzed text complaining.

Why does this matter?

Because --- the DRM-free game buying site --- distributes GLQuake complete with a toxic OpenGL32.dll provided. 
qboolean CheckOpengl32(void)
FILE *f;
char ogname[1024];

Q_snprintfz (ogname, sizeof(ogname), "%s\\opengl32.dll", com_basedir);
if ((f = fopen(ogname, "rb")))
fclose (f);
return true;

return false;

void VID_Init(unsigned char *palette)
int i, existingmode;
int basenummodes, width, height, bpp, refreshrate, findbpp, done;
HDC hdc;
DEVMODE devmode;
extern void VID_Menu_CalcConTextSize (float cw, float w);

if (CheckOpengl32() == true)
Sys_Error ("Please delete the opengl32.dll from the Quake folder."); 
I've had one that similar to that in ProQuake for ages.

I wanted one that doesn't require any user action at all and simply ignores it, haha ;-)

Mission Accomplished. 
Qrack is an old engine based on joequake .13dev (circa 2004) I released a final version for Quake's 20th bday, hense the silly webpage; looks like a 90s website. The "whatsnew.txt" is in the zip in the Qrack folder. it's just a changelog (where most of the documentation can be discerned). Newest version will load arcane dimensions and has protocol 666 etc but not bsp2 support. it's basically just my personal project to keep me entertained and doesnt try too hard to do anything else :P 
@R00k Part 2 
It requires at a minimum using /DELAYLOAD:opengl32.dll in visual studio

Or I guess simply not linking to the opengl32.dll at all is also an option. 
nice, "**warning Mark V detected an evil troll, killed it with the glowing sword, you may proceed.."

"The Troll Room
This is a small room with passages to the east and south and a forbidding hole leading west. Bloodstains and deep scratches (perhaps made by an axe) mar the walls.
A nasty-looking troll, brandishing a bloody axe, blocks all passages out of the room.

Your sword has begun to glow very brightly.
The troll swings his azxe, but it misses.

>swing sword
The troll swings, you parry, but the force of his blow knocks your sword away.

>get sword

The troll hits you with a glancing blow, and you are momentarily stunned.

>kill troll with sword
The troll is staggered, and drops to his knees.
The troll slowly regains his feet." 
Beer Etc. 
I've always wanted to make a QuakeC console version of some kinda Zork clone hehe to play while wiating for a multiplayer game to start. ;) 
Arcane Dimensions 
A fair number of the Arcane Dimensions maps are BSP2.

Spike added BSP2 in this patch:

I'm sure I've posted you a link the above before. BSP2 is way easier than protocol 666.

There is also the Quakespasm acquisition of that BSP2 patch at which has a diff file. 
I do have a working version with bsp2 support but somehow it broke my normal quake skys. Sky boxes work fine. Spike made suggestions yet i havent had any time to fix :S 
O_o really? Would be interesting. 
Happy Fun Time! 
In 24 hours or less, some fun stuff to play with ...

* A very nice Direct X 9 build, with mirror support.

* Ubuntu Linux Open GL build
* Ubuntu Linux WinQuake build

* GL builds have MH WinQuake-style water warp. Default setting. Setting r_waterwarp 2 will get the FitzQuake look.

* Windows WinQuake through Open GL for KillPixel. I also happened to need to make this for Linux purposes.

* GeForce/Nvidia issues and DPI annoyances should be gone.

This feature is somehow a super-perfect fit with Quake. You don't quite realize it is missing until you have it available, and then not having it feels wrong.

* A rather extensive changelog, but I couldn't say for sure what is in it.

* I do know it has a worldspawn option for dumptruck_ds to set the sound distance.

* WinQuake version now also has resizable window in real-time like the Open GL and Direct X 9 versions.

* Mac mouse acceleration fix (The "SleepWalkr" fix, as I think of it).
* IPv6 tune-up on non-Windows platforms giving it all the nice features available in the Windows version.

Linux versions have about 99.5% of the Windows feature set, with the main omission from my perspective being video capture -- which the Requiem engine has and I haven't had time to get "X Windows"-ish with the code base.

Oddly enough, the Linux build requires SDL 2.0.5 ... at one point I was preparing for an Android build (which isn't coming anytime in the new future, but I always lay foundations in advance) and I need SDL for Android.

Many people think that any engine using SDL needs to have external dlls. It's not true. Just for fun, I'll throw in a Windows SDL build that requires no DLLs. To keep things relevant, I guess I'll make this SDL build a WinQuake Through Open GL SDL build for Windows. 
Sounds Interesting 
looking forward to waterwarp especially :) 
My Body Is Ready 
@fifth/@kp -- Trying to fill my mana bar for final gauntlet.

I actually have a list of 24 separate individual items on a sheet of paper to apply what I hope is the right level of polish to this.

Engine coding is all about the small ball.

Testing 4 or 5 Windows builds (GL, DX9, DX8, WinQuake, WinQuake via GL), 2 Mac builds, 2 Linux builds, making sure the Debug and Release builds are right and then in Windows making sure it works in Visual Studio and CodeBlocks is a hassle.

But if all goes well ... it'll be worth it ;-)

/Sometimes I ask myself "Ok what is the reason to do all of this again?" Usually the answer is "Because it is there." Or something, haha ;-)

No seriously, should be quite worth it. ;-) 
That's nice and all but is there twue rotation w/collision :-P

I heard the time is now... 
Hold Your Horses There Damage 
He needs to add 4 player splitscreen coop yet ;) 
To The Back Of The Line I Go 
... grrr, hehe 
+10 Mana 
Someone Set Us Up The Bomb 
Mark V - Version 1.25 Beta

Ubuntu Linux Open GL
Ubuntu Linux WinQuake (software renderer)

(* Requires SDL 2.0.4, only tested with Ubuntu Linux 16.04 LTS.)

Direct X 9 Renderer
Direct X 8 Renderer
Windows Open GL
Windows WinQuake (killpixel, it may work good 4 you now)
Windows WinQuake via GL (killpixel, if above doesn't this one should in theory be a sure thing)

RARE: Windows SDL 2.0.4 Open GL build (***)

(*** Does NOT require ANY DLLS - just to demonstrate that Windows engine builds using SDL2 need not have external DLLs).

@fifth - "He needs to add 4 player splitscreen coop yet" --- Yeah, exactly! Hahaha.

MH Waterwarp

All the Open GL and Direct 3D builds have MH WinQuake Waterwarp (except DX8) and it defaults on. r_waterwarp 2 is classic FitzQuake waterwarp in those engines.

(Mac version is resisting me at the moment. I'll upload source codez after the Mac version is owned.) 
Using openSUSE 42.1 linux here.

Will try compiling for my distro. when source code is available. Will there be a MAKE file? Maybe a configuration file? 
Winquake GL Runs Great 
I haven't spent that much time in the non-gl version to say for sure, but the stuttering seems to be gone as well. How'd you do it?

minor bug in WinGL: the prompt isn't visible after selecting new game (reminder, a game has to be in session to get this prompt).

nice work, baker. this is definitely my go-to engine. I'll have more time to test it out in the coming days. *eyeballs last few mapjams* 
So many versions to choose from!
This will rightfully become the standard Quake client for everyone....

Well, the DX9 version no longer makes my fog look worse when gl_overbright 1 is set.

vid_hardwaregamma 0 behaves differently in DX9.
When using it, the gamma slider still works, and it does not affect my desktop gamma (just the Quake window gamma). That's nice. But txgamma does not work, so I'm getting gamma-adjusted polyblends again (which makes them too intense).

In DX9, changing to a 800x600 window causes the Quake window to... vanish completely (netbook res = 1024x600). If I start up having previously set to 800x600 window, it works but tells me I'm actually in a 800x578 window. The window looks the same as with the DX8 version when I tell it to use an 800x600 window.

It seems the SDL version doesn't play the MP3s. 
I've Been Watching College Football 
So right now, it's Baker vs. 24 pack of beer. Which is fine, I usually win that war by attrition.

Case in point, it is now Baker vs. 14 beers. ;-) The beer is clearly losing, haha.

Anyway on to important things ...

A) @Damage. Rotation. The next burst of energy I get and that goes down in flames. I have some planning on paper, other gremlins have kept me at bay. For now.

B) @JimBob. I don't have a makefile plan at the moment but have invested some time in trying to figure out to integrate that into my workflow (depending on what someone defines as as a platform I do 7 to 10 of them). But yeah, I'm actually quite the Linux n00b. So no answers at the moment --- only questions.

I do have some experience with Linux, but it isn't very deep.

And I'm the kind of guy who understands that growth comes from awareness of ones own limitations -- but yeah, although Linux isn't new ground for me, I do not claim expertise.

C) killpixel - thanks for the feedback and please provide more as I continue. What frame rate do you get in the normal build?

d) Gunter - this tells me that MH's Direct3D9 gamma shader doesn't work on your computer -- but also I have not fully had the chance to integrate all of MH's recent work. Maybe next build some of the other things will work.

Thanks for the feedback identifying that the gamma shader doesn't work on your hardware. 
Wait. Are you saying the DX9 gamma does work or doesn't work?

With the DX9 build, the DX9 shader supercedes "txgamma".

/Anyway, tonight its Baker vs. 24 pack of beer and now its down to a mere 12 (good job Baker!) --- but yeah, I think my next post is tomrrow, hahah. GG! 
I'm glad that Baker got this far with the releases before succumbing to alcohol poisoning. 

Same with mark_v.exe. Old (stable) mark_v.exe works, and the SDL version works.

I should probably mention that my video driver is from 2009, because using anything newer means using a generic driver, and that would likely break something (laptops are painful). 
The gamma shader is conservative in that if it doesn't load nothing else will fail, and it reports back to the engine so that a fallback can be implemented.

That said, I understand from the comment that "the gamma slider still works, and it does not affect my desktop gamma" that it actually is working.

There's nothing in the gamma shader that prevents texture gamma from also working.

We discussed the 800x600 window before, and at your desktop resolution this is just something that you have to accept is going to happen.

I've reproduced this behaviour at 1366x768, 1440x900 and 1920x1080. In every case you get weird behaviour if you set height of a windowed mode the same as desktop height.


Sorry for shouting but I've already written a number of lengthy posts about D3D vs GL differences, driver and runtime behaviours, and the message isn't getting through.

Reporting the same bug over and over again won't make it any different. If the driver or runtime takes control and imposes it's own behaviour, you're stuck. D3D is not GL. You can try to fight it and create a bigger mess. Or you can accept it, say "well just don't do that then", and move on. 
This Is Epic 
OMG... proper water warp effect in the GL builds at long last! I can die in peace now! This year starts really well. Amazing job, Baker (and probably mh, I guess)! 
20/24 Beer Defeated -- Guess What? I'm Still Rational 
Alright, I wouldn't be able to code in this state but Quake and indeed FitzQuakeism (metlslime's code was the Rosetta stone of modern Quake) flows through my blood just by nature so ...

a) @dwere -- kinda of weird since my Windows 7 machine is in perma-stasis lock since 2012. I'm not a Microsoft trusting sort and my primarily machine has not been updated in any way since April 2012. So I'll meditate on this more tomorrow. In fact, I'm rather annoyed at the moment ;-)

b) @MH - Your work is nearly perfect like usual. Meanwhile, I'm still made out of a human. I did the currently release without 8 of my "must have" list -- just because I hit my human limits and needed to have something to show for my integration efforts ...

Knowing I can sneak in a 1.26 tomrrow with few people being the wiser. ;-)

So enjoy! Your work is eventually completely safe with me, especially since it is awesome! 
I'm Predicting... 
... the next version will be: Mark V - SPIKED
with beerzzz :-P

Comes with a free sax pick on download! 
Monsieur, With These Rocher You Are Really Spoiling Us! 
Quick question - is there a hard limit to the number of surfaces WinQuake/WinQuakeGL will display? I tried raising r_maxedges, r_maxsurfs, but it seems after a point it makes no difference (try jam6_ericwtronyn hehe)

But yes very very nice so far! 
What frame rate do you get in the normal build

In both win and wingl:

320x240 stretch - ~1k
640x480 stretch - 400 - 600

minor bug: setting fullscreen/res via options menu sets to 640x480 stretch. 
@Baker I was surprised to find that mark_v.exe (Windows GL) runs remarkably well under WINE, so I'll just use that in the meantime.

I don't have in-depth knowledge of Linux either, though I too have used it before. Fortunately these days I think most anyone can figure out most of the user-side stuff by googling.

Anyhow, thanks for all your efforts to bring Mark V to Linux! 
Not certain if this is confined to my PC or not.

On first run, MarkV fails to exec my config.cfg. On exit however it successfully saves and overwrites it, then subsequent runs work.

This is a pretty standard "generated by Quake" config and works fine with other engines. I can provide a pastebin if necessary, but I don't think it's relevant because...

What I've also observed is that on such a failed run it will create a new directory, at the same level as ID1, but named with a random character (e.g. "�", "a", etc) within which there is *another* ID1, that containing a config.cfg.

default.cfg runs OK indicating that it's loading quake.rc and default.cfg fine from the PAK files. autoexec.cfg and all other PAK file content loads OK, and screenshots/etc are created in the correct folder: i.e. it's solely confined to config.cfg.

This is on Windows 10 64-bit, fully patched. The only thing unusual I do is that I have a separate directory for each engine and I use mklink to create hard links/directory junctions for the PAK files and Music directory. 
To try and be clear, in DX9 with vid_hardwaregamma 1, the gamma slider affects everything -- both Quake and my desktop.

With vid_hardwaregamma 0, the gamma slider only affects Quake, and not my desktop.

But txgamma does nothing. It doesn't even return a value.

I'm preferring to use txgamma, since it does not affect the polyblends, and so makes them look correct instead of gamma-adjusting them, which makes them too intense.

About the 800x600 window, it may be related, but it's not the same bug I've ever reported before. The Quake window just completely becomes invisible. I can hear it, but I don't see anything. If I can mange to change the window size back to something else, the window re-appears. And again, if I restart Quake after having previously set to 800x600, then I get an 800x578 window, which is fine, and apparently what DX8 does automatically without turning my window invisible. Though vid_height still reports 600 in both exes -- it's only in the Options menu where DX9 (not DX8, which shows 800x600) reports my resolution at 800x578.

So the main point is: on my 1024x600 netbook, using the menu to set DX8 to 800x600 window works fine, whereas trying to set 800x600 in DX9 via the menu causes Quake to become completely invisible -- no visible window at all, though it still is running, and shown in the task bar.

But if there's nothing that can be done about it, then there's nothing that can be done about it....

I also get a similar glitch if I try to alt-tab away from a full-screen mode in DX9. When I try to go back to Quake, I get invisible Quake with no way to bring it back without restarting it.
If I try to change the resolution without restarting it (by sound) it freezes up (it gets stuck repeating a menu sound). 
@kp - In the WinQuake through GL build, I capped the stretch because I was having frame rate issues at certain larger sizes, which apparently is a total non-issue in your case it would seem.

@kinn - I have to check that out. Haven't thought about it in a while. Seems you have found a map that challenges that limit. I'll investigate at some point.

@dwere - I'll have to take another look at that. I did change Mark V to bypass an openg32.dll living in the Quake folder --- do you normally need an opengl32.dll in your Quake folder?

@damage - Winter + cold and a bit of elation of wrapping up a very complex set of builds sometimes leads to ideas that the next day don't look quite as smart, haha. Anyways --- I haven't forgotten about rotation.

@gunter - Like MH said, nothing about the Direct3D relates to texture gamma at all -- so DX9 doesn't have texture gamma at all because 3 different gamma systems in the same build would have been a headache for me. 
@gunter - Texture Gamma Is All Me And 0% DirectX 9 
I could have coded texture gamma in Direct X 9 build.

I didn't because of the complexity of having to figure out how to make 3 different gamma systems interoperate.

I wanted to get a build out.

texture gamma will likely be available in a future DX9 build when I have more time to plan it out. 
Mark V fails to exec my config.cfg

I thought I noticed that. Will have to investigate. 
Ah, I See 
I get 150-200 fps at 1920x1080 with the win build. 
@gunter - Part 2 
It is important to note that the Direct X 9 build is not "final".

I have outstanding improvements from MH that I have yet to integrate.

I marked this build "Beta" -- suspecting there would be some things that need ironed out. 
I don't need it, and it's not there right now. 
The bad config.cfg is coming from %appdata%\MarkV\caches; every other cfg file runs from com_gamedir but for some reason config.cfg is running from there. 
Is the pure WinQuake build performing nice enough that the WinQuake through GL build is basically not needed?

/It'd always be available as an option, besides it can do one thing that the pure WinQuake build can't --- it can do vid_vsync ;-) 
More Config.cfg 
This block of code in Cmd_Exec_f is where it's happening (based off 1023 source, 1025 seems to have no source release & may be different):

if (String_Does_Match_Caseless (line->args[1], CONFIG_CFG))
const char *check_string = va("// %s", ENGINE_FAMILY_NAME);
cbool is_our = String_Does_Start_With (file_text, check_string);
//int len = strlen(check_string);

// cbool is_ok = false;
// Baker: Make sure it is a Mark V config
if (!is_our)

So my reading is that Mark V is attempting to detect if the config was created by itself (using the presence of a comment at the start as an indicator) and refusing to exec it if not. 
Music Doesnt Appear To Work 
I can't get it working with any version of Mark_V. Seems to work fine with Quakespasm, not sure what seems to be causing it. I'm sure this was fixed at one point. 
@fifth - you're probably using ogg, try mp3.

@baker - winquake seems to run great. the stuttering issue from before is gone. however, there may be a brief "hang" that seldom happens that I didn't detect in the wingl build. Don't hold me to this, I haven't found time to sit down and really test them. 
Source Code 
@mh - Yes, exactly. Mark V writes a backup config to prevent a loss of settings.

I need to revisit it and double-check everything there and combined with what Johhny Law identified as a scenario --- give it a thorough look over.

Source code

re Linux: I use CodeBlocks with SDL 2 Dev 2.0.4 package installed to compile.

/It is possible that at some future date, a Linux makefile may become available if I can determine a way to automatically have CodeBlocks generate it via a plug-in. 
DX9 Windowed Modes 
OK, so I played around a little more with windowed modes in the DX9 wrapper; this is my own development version which is a coupla steps ahead of what Baker currently has.

First thing to check was window resizing. Is it possible to resize a DX9 windowed mode to something equal to or larger than the display resolution? The method used to test this was to drag the window down so that it is partially offscreen, then attempt to resize via the top border.

Answer is "no": either the driver, the DirectX runtime or the OS are intervening and clamping the window size.

I cross-checked this with MarkV GL and I get the same behaviour there. I then cross-checked with MarkV software and confirm the same there too.

I then checked a Notepad.exe window and got the same there too.

My conclusion is that clamping the size of windowed modes is totally outside of the control of the application; most likely the OS is enforcing that.

On a 1920x1080 monitor, I attempted to start with heights ranging from 1000 to 1080. From -height 1054 onwards I got a grey screen instead of the standard window with the game running in it. On this PC the taskbar is 40 pixels high, so I think we can rule that out. So within 36 or fewer pixels of the destop vertical resolution, you cannot run a windowed mode.

I used AdjustWindowRect and determined that with a client rect height of 1053, top was -31 and bottom was 1061.

I cross-checked with some other D3D9 code I had, which contains debug assertions that verify the window client rect is the same size as the requested mode. In this code the client rect is clamped to 1053. I removed the assertions and did further testing which determined that Direct3D was indeed setting the backbuffer size to the requested mode, but was clamping the window client rect.

I cross-checked with some D3D11 code I have and determined that the client rect was likewise being clamped to 1053.

Finally I tested some OpenGL code and determined that the same clamping behaviour existed, but in that case to 1063. For the sake of completeness I attempted running with height 1080 and 1090, both of which clamped to 1063.

Finally I wrote a skeleton Windows program (just WinMain and WndProc), created it's window at 1080 height, and observed it being clamped to 1041.

It's notable that there were differences between the window styles of all of these programs - I could repeat the tests using the same styles but I don't feel too inclined to, because the data I have is sufficient. However, and just to be absolutely complete, I modified the last program to use WS_POPUP where the window height was not clamped, but was occluded by the task bar.

So there you have it. I can spend more time testing other combinations, different Direct3D versions, other OpenGL programs, but I honestly think that at this stage it's not a productive use of my time - I'd be better off watching Japanese porn.

Final conclusions. Above certain values the OS *will* clamp the size of a window, unless you use specific window styles, but even in that case it *will* be occluded by the task bar.

So to repeat: don't do it; just don't. 
Is in mp3 format 
don't you have a virtual drive installed? it used to be the cause of the si,inlar problem with mp3 playback in mark v 
Maybe a naming issue? e.g. track_002 as opposed to track_02.

I had an issue with music too that ended up being something simple that I overlooked, can't remember what it was though. 
Virtual Drive 
I just have C: and D: drives (both SSD's, quake is on D:) E: is my blu-ray and F: is my removal mechanical. 
Track Names 
are track02.mp3 to track11.mp3 in id1/music 
Re: Music Playing 
I use .ogg files and so, I converted track02.ogg to .mp3 and instantly had music in the opening demo. These are in id1\music.

User setups at error here? 
If you haven't already, check out the music section of the readme and see if you can spot a discrepancy between what you're doing and what it says. Music works for me. Strange :/ 
"My conclusion is that clamping the size of windowed modes is totally outside of the control of the application; most likely the OS is enforcing that."

The clamping is fine. I don't really mind if I tell it to set Quake to an 800x600 window and I actually get an 800x578 window. Close enough.

Also, I found that if I set -width 800 -height 600 in the command line, I don't get the strange behavior. I just get the nice, clamped window as usual.

The problem I am seeing is actually a bit more interesting than I thought.... My Quake window isn't being made invisible -- it's being moved WAYYYYY off screen!

I downloaded this tool so I can keep track of my window position:

(Chrome throws a fit over that file and won't let you download it... but it's legit. I'm sure there are other tools to do this as well).

So I run DX9 Mark V and select its window to keep track of in WinSpy++ (though it doesn't track the position in real time -- you have to hit F5 on WinSpy++ to get an updated window position after moving it).

No problems so far. I can move the window around and refresh WinSpy++ and it will tell me the position of the DX9 Mark V window.

Now I go into the Quake Options menu and change the resolution to 800x600 windowed... and ... where did my window go? It's vanished! Sooo, refresh the WinSpy++ information and guess where my window is located? "108, 32767" ! Every single time, the same location... wayyy off the bottom of the screen.

Then I can right-click on the DX9 Mark V indicator in my windows taskbar and select "Move" then tap an arrow key to grab it, then move the mouse up, and pull it right back onto my usable screen area... (it jumps to the mouse cursor position).

So that's weird, right?

Let me test to see if this is what's happening when I alt-tab from a fullscreen mode....

Wow! Even better, when I do that, Quake gets sent to limbo at -32000,-32000

And I can't seem to make it come back.... Though it may be a bit different, because I can't refresh my WinSpy++ when the fullscreen Quake has focus... way off in limbo where I can't see it, I assume. 
Window Cramps 
What is the specific reason that people want to have the game run in a window that's the same effective size as the desktop resolution? I feel like I must have missed a post explaining the need for it.

In any case, I don't personally know much about it, but many games support a "borderless window" mode that is almsot indistinguishable from fullscreen, but is techincally a windowed application. Would that be an acceptable solution, assuming it can be implemented? 
Some people like to play and get steam messages or popups etc without having to alt-tab. I guess. 
A screenshot is worth a thousand words:

My netbook screen res is 1024 x 600. I either run Quake fullscreen at 1024 x 600 resolution, or (as the screenshot shows) in an 800 x 600 window (which gets clamped to 800 x 578) when I want to be able to switch away from Quake easily so I can look at other things like QView or Func_Msgboard or when I need to make notes in notepad about bugs I encounter, or any other kind of multi-tasking where I can see both Quake and something else at the same time. 
Linux Compile 
Is there a guide to compiling this with Code::Blocks ? I'm not a developer, and I've only dabbled through the years. I've successfully compiled maybe 4 different engines before, but only via make files.

So far I've installed CodeBlocks 16.01 on openSUSE 42.1.

I assume SDL 2.0.5 library is okay. Or does it specifically have to be 2.0.4?

And what compiler should I choose? It gave me options on first-run, but I only had GCC available. Not even 100% sure what project to load. 
borderless fullscreen means alt+tab is quicker as it doesn't necessitate a video mode change, so textures don't get purged by the os, etc, and yes, its less hostile to other programs too as it doesn't result in the registry saying one resolution and yet currently displaying another.
there's also less risk of windows randomly moving desktop icons around...

big negatives sounds like its using an unsigned negation, eg: ypos = ((unsigned)screenheight-desiredwindowheight)/2;
side note: with d3d, make sure that your d3d backbuffer actually matches the size of your client area. if it doesn't then d3d will be a little more expensive whereas opengl will just resize the backbuffer for you.
this also makes handling WM_SIZE much more annoying in d3d. 
@JimBob - CodeBlocks Compile Instructions 
mark.cbp is the CodeBlocks Project File.

You open it in CodeBlocks then ...

1) Click "Build", "Select Target" ->"Linux SDL GL Release" screenshot

2) Click "Build" -> "Build" to compile. screenshot
3) Then it compiles and you get to read about 12 warnings that don't apply and get to see about 100 developer comments of mine.

Requires SDL2 2.0.4 Dev (or later) installed to compile.

To run the engine, you'd need SDL2 2.0.4 (or later) installed.

I hope it works for you. But I have no idea if it will work for you on a different distribution.

I also don't know what version of GCC I used. I used whatever version was already there after I installed CodeBlocks, which I installed out of the Ubuntu Software Center screenshot, which of course is Ubuntu thing.

I hope that helps! 
@JimBob - Linux CodeBlocks Compile Instructions (Rev. 2) 
mark_v.cbp is the CodeBlocks Project File.

You open it in CodeBlocks then ...

1) Click "Build", "Select Target" ->"Linux SDL GL Release" screenshot
2) Click "Build" -> "Build" to compile. screenshot
3) Then it compiles and you get to read about 12 warnings that don't apply and get to see about 100 developer comments of mine.

Requires SDL2 2.0.4 Dev (or later) installed to compile.

To run the engine, you'd need SDL2 2.0.4 (or later) installed.

I hope it works for you. But I have no idea if it will work for you on a different distribution.

I also don't know what version of GCC I used. I used whatever version was already there after I installed CodeBlocks, which I installed out of the Ubuntu Software Center screenshot, which of course is Ubuntu thing.

I hope that helps! 
I'm able to reproduce this undesirable behavior in the DX9 build.

I haven't incorporated all the MH changes yet, I had too many builds/platforms I was juggling around.

I'm generally an ALT-ENTER user and didn't think of testing DX9 with a fullscreen windowed mode.

What you independently verified and what Spike is suggesting as the likely mechanism sounds right.

Short version: I'll see if I can tune up the DX9 version to get to use the all the latest MH 12/30/2016 changes.

Keep in mind, mh is saying that some of this stuff D3D is very touchy about --- so ....

Remember --- you might not actually be able to have everything exactly the way you want it. 
OpenSUSE Seg. Fault 
Thanks, Baker!

Turns out I had everything right, except that I didn't know to "Select Target."

Unfortunately, with this build I'm still getting the instant "Segmentation Fault" crash I was with the Ubuntu binary. :/

Ah well. 
Ah, too bad. I wished it worked for you, obviously. At least the Windows version runs under WINE for you on OpenSUSE.

I knew to specifically call it a Ubuntu Linux version. 
install valgrind, drop to a terminal, start via valgrind, eg:
LIBGL_ALWAYS_INDIRECT=1 valgrind ./markv -window -game whatever

then publically shame baker with each and every stack trace that it spits out on its way to crashing...

then you ask baker how to re-enable debug info (if you're lucky then 'make clean && make CFLAGS=-ggdb' will do it), then repeat...

valgrind is so much easier to debug linux programs than gdb, at least if its simple enough that a stack trace is all that's needed.
if nothing else it'll give baker somewhere to look.
the libgl_always_indirect thing is to keep valgrind from tripping up over the graphics drivers poking user-memory from kernel space. you may see similar false-positives from sound drivers.
It might also point out a whole load of other things that someone's overlooked which have so far failed to crash anything, so probably just focus on the last one or something. 
Just For Shiggles 
winquake still gets decent fps even at 3840x2160.

@kp - awesome

@spike - I have a todo-list you know. ;-) Like my main priority is DX9 integration because MH's time and effort is important to me -- and it is a voluntary surprise contribution on his part, which I appreciate and clearly many others do as well.

I'm also just one guy. And this is a free and open source project for a game.

Despite disagreements about multi-game, I think it is rather clear that on most topics we are in complete agreement.

No obligation or expectations, but if at any point you wanted to contribute as much or as little as you chose, it would be welcomed and used. And if not that, that's ok too!

You've more than done enough to help me over the years, and never think I don't appreciate it.

Anyway, that door is always open and you are always welcome. And like my interactions with MH and his interactions with me --- it's all about developer fun.

So ... I have some DX9 I hope to integrate! And a list of issues presented by others above that I hope to knock off. 
The Winquake version resolves an issue I reported way upthread -- if I set it to an 800x600 window, it now behaves like the GL or DX8 versions and doesn't cut off part of the HUD at the bottom of the screen (along with the usual clamping behavior). Nice.

The Winquake-GL version just shows me a solid white screen no matter the resolution setting, but I can hear the demons running. 
Thanks for the info.

Yeah, the WinQuake GL was not targeted to your machine. If it doesn't have non-power of 2 texture support, it'll explode.

Rare case where I was writing an engine build almost exclusively targeted towards killpixel's machine -- which with that 3840x2160 screenshot shows is pretty decked out. 
@Spike - Valgrind 
This is all valgrind spit out on the binary I compiled, if anyone is curious:

@Baker. Please disregard :P 
@JimBob - Interesting ... 
Next update, I'll have the option to disable pthreads.

And tell you what to do to take another swing at this.

Mark V does not use pthreads very much.

Now this doesn't guarantee that even with pthreads disabled that it will work.

But maybe it will work. ;-)

/Either way, I'd say you fit in here just fine as a beta tester!

(And thanks to Spike for providing the suggestion.) 
Such A Shame It Didn't Have Debug Info :P 
I believe I know the issue.

I use pthreads.

I normally don't do SDL builds, I try to go native. SDL has some sort of threads feature.

SDL's threads feature and pthreads fight.

I'm about ready to upload the new source for JimBob. 
Thanks, Baker! I'll be sure to check in on this thread now and again. 

Also when you compile, instead of selecting the Build->Select Target->SDL release you might select SDL Debug instead, which will keep the debugging symbols intact (more information becomes available). 
@Baker - Pthreads 
Hey! It runs now! And looks great! Thank you, Baker :)

Only problem I see now is mouse drift (or looseness). It's like I have an uncalibrated joystick, except I don't have a joystick or gamepad at all. It keeps spinning or drifting even when my mouse isn't moving.

Clicking a mouse button will stop it (until I move the mouse again).

Windowed mode didn't help.

Tried this command line to no avail:

./mark_v_sdl_winquake_gl_debug_gcc -iplog -noforcemaccel -noforcemparms -zone 2048 -noipx -nojoy -dinput -m_smooth

Tried a different mouse -- same issue.

Tried darkplaces again (just to be sure) and it's not happening in that engine.

Anyhow, I'm just reporting this to report it. This could be a rabbit hole for all I know. So whenever/if-ever you (or another coder) can find the time to look into it is fine by me. 
Can we safely overwrite a previous install or is it better to make a new clean install? 
Type nomouse 1 in the console or add -nomouse to the command line for now to disable the mouse.

Out of curiosity are you using Gnome or KDE or something else? 
I think using SDL_SetRelativeMouseMode(SDL_TRUE) will fix JimBob's mouse issues.

This will hide the cursor for you and start sending the application relative mouse events read from the system's raw input API's on linux and Windows (I started a mac implementation which I need to polish up and get the SDL people to merge..), it's the right way to get mouse input for FPS games with SDL2. 
@Baker - Mouse 
Will do!

I'm using KDE with Plasma Shell v5.5.5. 
I'm currently putting together a Windows "skeleton app" which will just create a window and initialize Direct3D. This will enable me to do another bunch of testing and determine which issues are coming from Direct3D (which we don't have control over) and which are coming from the engine (which we might have control over).

I see from your screenshot that your netboot is running XP. I have access to an MSDN subscription so I can spin up an XP VM in VMWare Player which should be representative of your netbook's hardware, then do a bunch of testing there too.

I do know that behaviour of so-called "fullscreen windowed" modes, interaction with the taskbar, etc changed at some time in the post-XP timeframe. It may be the case that special-case code is needed for XP versus post-XP. I assume that nobody gives a toss about Vista, so establishing the behaviour on XP and 7 seems like a good place to start.

I have doubts about the best way to handle this. Right now I have a bunch of code that checks the window size and will throw errors, but I wouldn't seriously propose that as a solution. I'm not even certain that it's appropriate to handle it in the wrapper, although if the D3D behaviour is sufficiently different to GL, it might be.

If you have any suggestions I'd be interested in hearing them. Assume for the moment that I can't get it working - what would an acceptable fallback be?

Until then I suggest run it with -height 560 or thereabouts. 
@ericw / @jimBob 
Here is what is funny -- back in 2012 when I wrote the "single frame mouse code" for Mark V, I had SDL 1.2 and Linux in the back of my mind.

SDL2 either didn't exist or was a concept or upcoming project.

And the undesirable "grab the pointer position" and "center the mouse in the window" method was what most Linux Quake engines did.

Current code isn't very accumulator friendly.


@JimBob -- just tried with KDE/Plasma --- yeah KDE sure hates the mouse code.

I can switch between Gnome and KDE rather easily, if you are able to load up Gnome it may work.

KDE no like the current mouse code. 
Hmmm ... actually Ubuntu uses Unity which works fine, if I switched to pure Gnome which also hates the mouse code.

So look at the moment that the SDL2 library only supports some of the new functions in 2.0.4 and 2.0.5 on Ubuntu's Unity?

As a Linux novice this is my interpretation of what I am seeing.

More work to do.

Well, I can say this the Ubuntu Linux version is quite nice running on Ubuntu with Unity -- has a resizable window and about 99% of the Mark V niceties.

But at present time, the other desktop environments and current SDL2 do not seem to play nice with the current implement of the Mark V SDL2 mouse code. 
Unity On OpenSUSE 
Well, I guess if I get too impatient I can try this:

But I'm afraid I'll break something if I do. 
I'll wait till Baker releases a new version to see if he fixes any of the issues (Spike put him on to a possibility).

Just to try and be clear, since everyone seems to be talking about different things, I am not using one of the borderless windowed full-screen modes. That mode actually works fine for me (1024x600 windowed, my desktop res). I can alt-tab away and back to it with no issue.

Oops. I spoke too soon.... Ok, if I have JUST set it to 1024x600 windowed via the Options menu, then I can alt-tab away from it and see any other window, then alt-tab right back to Quake with no issue....

However, if I close and restart DX9 Mark V so that it starts up in that mode, then Mark V seems to be "always on top" and it blocks the view of any other window that I give focus, unless that other window is also set to "always on top." I can see the Start menu if I cause that to pop up via the Windows key, but DX9 Mark V blocks other windows that I give focus to....

All kinds of fun weird things happening.... This doesn't happen in DX8 Mark v.

Anyway, if I am in any fullscreen mode in DX9 Mark V, an alt-tab results in my Quake "window" being sent to -32000,-32000 and it won't come back when I try to give it focus again. If I then exit Quake (I can hear the menu sounds to navigate to "Quit") I get a "Quake Error" popup that says "context_t::CreateTexture: unable to create a texture"

But as far as using an "800x600" window, That works fine as long as I don't try to change it to that setting using the menu in DX9 Mark V (ie, if I set it by command line or just restart after having changed it to that, it works as expected, just clamping my window at 800x578).

However, If I use the menu to change it to that, it does create the window, clamped at 800x578, but the window gets repositioned at 108,32767 -- way off the bottom of my screen, but now that I know this, I can use right-click commands to move the window back onto my screen, as I mentioned in my previous post.

Anyway... I guess I'll wait for Baker to release a new version to see if any of this has been addressed....

I'll just reiterate that the problem isn't about the window being clamped to 578 height when I tell it to set to 600. That's all fine. 578 fits my screen res (1024x600) well enough (shown in the screenshot above). And Mark V seems to handle the window just fine at that size. The problem is that when I try to set that windowed mode (800x600) via the menu, the window gets sent to limbo way offscreen at coordinates 108,32767. This only happens in the DX9 build. It looks like it should be created at 108,-17 (that's where it appears at startup using the same settings).

So (this issue anyway) just to be a matter of window positioning....

Can you replicate this by setting your virtual WinXP to a resolution of 1024x600 then trying to set windowed 800x600 in DX9 Mark V by the menu? 
SDL2 with Relative Mouse Mode accumulator, as ericw suggested.

Better than even chance this solves the mouse problem for KDE + company. 
Ok, actually there is more happening than just window position. It seems that after changing the resolution to 800x600 windowed via the menu, not only does the window get sent to limbo offscreen, but it looks like this (top image):

And it THINKS it's at 800x600, even though it's not.... The screenshot comes out at 800x600 resolution, even though the game window size is exactly the same as the earlier desktop screenshot (Oh... that must be why the menu text looks wrong in the former case, though I didn't capture that text, but it's definitely missing some rows of pixels). And I bet the added black bar at the top makes up the extra pixels from 578 to 600.

The lower image is how it looks after restarting Quake. No weird black bar at the top, and the image resolution is 800x578.

So it seems to me that upon startup, DX9 Mark V checks the resolution stuff and sets everything correctly (even when clamping the window size is needed), but when changing it via the Options menu, it does not perform the same checks or something, and stuff gets messed up. And the window position gets sent to limbo.

I believe Spike mentioned something possibly related:

"side note: with d3d, make sure that your d3d backbuffer actually matches the size of your client area. if it doesn't then d3d will be a little more expensive whereas opengl will just resize the backbuffer for you.
this also makes handling WM_SIZE much more annoying in d3d. "

So it seems things are correctly set at startup (even if I set -height 600 on the command line and clamping is needed), but not when changing the resolution in the menu if window size clamping occurs and you get a window smaller than expected. 
EDIT: Added a 3rd screenshot (desktop rather than in-game) that better shows how Quake thinks it's in 800x600 when it's really in 800x578, as described above. You can see it's chopping off rows of pixels in the menu text.

Ok, now I'll shut up until a new version comes out. ;) 
Source code posted in post #900 is working for me using the KDE desktop environment. 
@Baker (and @ericw) 
That works for me, too. Thank you for taking the extra time to sort that out!

Quake feels new again with a new engine to play with ^_^ 
Thanks for your help and feedback.

I tried it on Unity, Gnome and KDE Plasma just now.

Unity was an A+++, Gnome was a A-, KDE Plasma was mixed for me --- but my KDE Plasma may not be update to date plus I rarely use it so I have no idea on how to tune KDE Plasma settings -- so hopefully is just me. 
If you don't mind, could you tell me if these binaries happen to run on your machine ...

May need to chmod them first, obviously. 
Ok, I was wrong. I have more things to report.

Ehhh... but I am having trouble doing testing now. Mark V won't let me delete my config.cfg file in the FvF folder to blank out my settings. It keeps re-loading the cfg from some backup place. I dislike the loss of control over my cfgs! heh Something like that necessitates a prompt for user control, "do you want to load cfg from backup?"

It seems I can delete the config.cfg file in id1 just fine though, without the settings persisting.

Mirrors do not get along well with skyboxes in DX9. Just activate a skybox and go peek in the Start map window mirror from various angles and you'll see....

Hm, and mirrors don't work at all if you use a different game dir....

For example, make an empty directory called "none"
Run DX9MV and start a new game. Go look in Start map mirror. Then change "game none" and start a new game and repeat. No more mirror. Change back to "game id1" and the mirror works again.... Results are the same when starting with "-game none" (or any other game dir -- I noticed the mirrors weren't working when I was running FvF). 
Those 2 binaries appear to run just fine (with my 5 minutes of testing for each heh).

The only *potential* issue I notice in those (as well as the ones I compiled) is minor, being the apparent lack of mp3 music audio. But that's not a game-breaker. 
@jimbob - There are few things I have to do research into for the Linux build.

It's not too bad for a build that is not quite 2 days old yet, haha.

Make it run first, make it great later. It's how coding is done.

@gunter - I have various homeworks to with some of the things you've pointed out.

With some luck, I'll have DX9 current and test things and see where everything stands with up-to-date code. 
True! It's not bad at all. And I'm happy to have something that's playable.

"mirrors don't work at all if you use a different game dir" - Gunter

Just want to confirm that this quirk also occurs in mark_v_sdl_gl_gcc . 
The Id1 Mirror Texture Only Works With Id1 -- It's Intended Behavior 
If someone makes a map pack and they want mirrors ... you call the texture "mirror_whatever".

One of the Arcane Dimensions maps by pulsar has a mirror in it, for example.

The window02_1 in the start map and E1M5 in standard Quake is an homage to the original GLQuake with the feature.

But if someone is playing Soul of Evil or Travail or something and some random texture is pointlessly a mirror because it is window02_1, that would be annoying as hell ... 
That makes sense.

Guess I got confused by the r_texprefix_mirror cvar.

Also I blame Gunter ;P 

This is the same as the problem I reported.

If you do:
* Start
* Run
* %appdata%

You'll find a "Mark V" folder which also contains a config.cfg; delete that too.

Display modes/etc

I'll need to take time to reread your posts more carefully. It seems to me that the most probable cause is that when changing modes, alt-tabbing, etc, GL requires you to write your own code for some things that D3D doesn't, and D3D requires you to write your own code for other things that GL doesn't. What that means is that there is going to be something where either (1) in-engine code is fighting against an automatic behaviour, or (2) in-engine code is missing for something.

I'm inclined to suspect (1) from experience. For example, in GL the AppActivate function vontains code to explicitly restore display modes and minimize the window on Alt-Tab events. D3D requires none of that, and in fact changing the display mode this way will cause trouble for D3D.

In the most recent code I gave Baker I rewrote AppActivate, and provided new wrappers for ChangeDisplaySettings and EnumDisplaySettings, designed to avoid all of this. I'm not sure how completely he's integrated these yet, but if he still has work to do with them it would be consistent with your experience. 
the alternative is to support EGL+GLES2 on windows and grab the dlls from ANGLE(or chrome/firefox), and get it running in either d3d9 or d3d11.

how angle works around d3d9/dxgi quirks I've no idea - maybe it just creates a nested/child window and does all its rendering to that... 
@gunter - We've Got Work To Do ... 
I've got MH's latest DX9 integrated.

Annoyingly the shader gamma off by 1 pixel has returned -- but instead it stretches, hard to notice except when in options. At first I was thinking it might be a matrix calculation issue in the menu canvas somehow, sometimes the 2D matrix needs a 0.5 kick to get the rounding right -- if I recall. Perhaps something in that ballpark is happening here?

Had to address ...
1) A border painting issue.
2) Made the window centered on ALT-ENTER and video mode switch.
3) The windowed mode window was staying topmost after a fullscreen. Baker addressed.
4) Made resized window stay in the same place during resize.

Need to double-check the ALT-TAB modifications MH made and ensure I did them right in the engine code.

Everything else looks great except if stencil was anticipated to work -- I don't know either way -- does not seem to work for me (doesn't in DirectFitz either) ....

So I made a single #ifdef in the code near the top of quakedef.h to toggle compile with DX9 stencil on or off.

I need to double check some things before I do a DX9 version update, but it very close. 
Mark V - DX9 - Beta Build 1026 
Mark V Build 1026 - Direct X 9 | Source

A screenshot of a few things combined together as a test ...


Mirrors, non-power of 2, external textures, particle effects, alternate HUD, lightning gun sparks, QMB flames, DX9 depth test level, gamma shader, vid_vsync, resizable window, combine, alpha, texture matrix. The .png screenshot was written via the DX9 accelerated screenshot API.

(* about 9 things the DX9 wrapper does that DX8 didn't)

@gunter - the sky will not show up in mirrors in DX9 in this build, stencil isn't seeming fully operational. I did a trick or 2 to obtain most of the effect ;-) 
This is becoming an engine to my liking. I'm already using it for the inspector tools (the texture inspector is more handy than DP's in that it highlights the faces instead of just displaying the texture names) and that awesome ffwd/rewind feature in demo playback, but if you keep on "spiking" Mark V like that, I might actually start using it to play, at least for the maps that DP doesn't handle well.

What's the name of that QMB lightning texture? When I try to activate this option in DP, it reverts back to the original polygon lightning, so I guess it's because it lacks the texture and I need to copy/paste it into DP. 
Lightning Texture 
In JoeQuake or Qrack, the name is zing1.tga living inside a pak0.pak somewhere if you wanted to obtain that file.

Mark V has it built-in, the same way Mark V doesn't need any .dlls. 
Stencil Schmencil 
Just done some stepping through a debug build of the latest Mark V and I think I know what's wrong with stencil.

In OpenGL glClear is affected by the various write masks (glColorMask, glDepthMask, glStencilMask).

In Direct3D the equivalent is not.

However, in Direct3D clears are clipped to the viewport rectangle, whereas in OpenGL they are not.

Therefore, if you make a glClear call through the wrapper, and if the previous glViewport was to create a partial viewport, the full window won't be cleared.

This was a very real problem caused by FitzQuake's render-to-framebuffer water where it updates the warp images before calling glClear. The GL_SetCanvas stuff (which IMO needlessly complicates the 2D renderer) sets a partial viewport, then we come along and call glClear and only that partial viewport is cleared.

Result is that only a small square in bottom-left (or top-left, can't remember) of the window gets anything drawn in it during the main 3D render.

To work around this I added code to my implementation of glClear which reset the viewport to the full window before clearing. This was done in the expectation that there would only be one glClear call per frame which would clear all required buffers.

That's obviously not the case in Mark V which clears the stencil buffer before drawing it's mirror sky stuff.

Added complication: in D3D viewport rectangle and depth range are combined in a single state. In GL they're separate states. So resetting the viewport also messes with the depth range.

End result is that both the viewport rect and the depth range are messed-up as soon as you make that glClear (GL_STENCIL_BUFFER_BIT) call.

I'm going to fix this by putting the viewport back to the way it was after making the clear call. With hindsight I should have done this from the outset, but you know what they say about hindsight. 
I haven't had time to load up Windows 8 or Windows 10, but I did testing on Win 7 with and without Aero and so far everything looks ok --- at least in Windows 7 with whatever Direct X drivers came with Win 7 -- I know they aren't the same as, say, XP which may behave radically different.

You may have noticed I added on-the-fly resizable window to WinQuake to make the "let engine decide window borders" into irrelevant issue. The DX9 build was my main reason for wiring up WinQuake to resize-on-the-fly. 
@mh - 2D Canvas 
The GL_SetCanvas stuff (which IMO needlessly complicates the 2D renderer)

Don't have much of an opinion on that ...

But I can say it was hard as hell to make WinQuake 2D render identical to FitzQuake.

So when Gunter was saying "original Quake centerprint" it somewhat follows I wasn't that big on the idea initially.

@Stencil clear -- Open GL should have done it that way, which is the better behavior ... and they would have in hindsight ;-) 
Stencil Clear 
This is a case where I think no API gets it right.

Clears being affected by the write masks and the viewport rect are both IMO undesirable behaviours. GL adds the scissor rect to bound the clear, D3D9 lets you specify an array of RECTs but they're clipped to the viewport too, D3D11 has none of this crap so it gets partially there but in the end it fails because it doesn't let you specify a subrect to clear at all.

The ideal API would look something like:

Buffer->Clear (RECT clearRect, int clearMask, int ClearValue);

In other words, you explicitly specify what you want cleared, how much of it you want cleared, and what you want it cleared to. No side-effects from previous state.

I'm dubious about having a clearMask but one feature it does give you is the ability to clear RGB without clearing A (or vice-versa) in the color buffer. I don't personally have a use case for that but others might. 
Man, that %appdata config saving shiz is annoying.

I was trying out the new DX9 build but still had the skybox error as with previous version... took some time to find that and delete it so I could get a fresh start. Which solved it.

Is this by design, cause it takes such a simple concept and fucks it up, imo.

I mean, I just want a config file, saved in my id1/mod directory.

I know other games/apps do this but I don't try out 35 different flavors of those games/apps like we do with Quake ;) 
Damage, this is beta at the moment.

When it works properly, you wouldn't even know it was there because it was meticulously planned.

It was there for 2+ years, not even super-picky Gunter noticed.

Until I slightly broke it recently.

I'm very against advanced-enginitis disease.

/Keep in mind that only in this last week was anyone even aware of convenience that made life easy street for 2+ years in Mark V. ;-) 
I just read 2 pages back what was going on behind the scenes! 
I do hate when control is taken away from me without my consent, even in an attempt to "protect me." As I mentioned, a feature like this NEEDS a prompt for user control. It's not necessarily a bad thing... except that it takes away (easy) user control of the cfg file. It would be better with just printing something like, "Your config.cfg file has been altered by outside sources. type 'exec backup.cfg' to load last Mark V cfg settings." But apparently this feature is not currently working as intended or something.... How exactly is is supposed to work?

Ok, looks like we're moving in the right direction. My window no longer gets sent to limbo in any of the previous situations.

But I still have the issue I reported above, where the window gets clamped to 800x578 but it thinks its at 800x600, resulting in some ugly stuff happening.

(seen in the 1st & 3rd screenshot I had posted:

However, if I press alt-enter, then alt-enter again, that issue goes away and then DX9MV knows it's actually in a 800x578 window again (just like if I start it up in that res to begin with). Then the window looks all correct, like in a previous screenshot I posted:

Ok, it looks like the issue is only occurring in the (admittedly unusual) situation where my window has been set to 800x578 (due to the automatic clamping) and then I reset it to 800x600 windowed mode in the Options menu again.

It does not appear to happen if I am making any change from a completely different resolution, whether windowed or not.

And it looks like the "full screen borderless window" mode of 1024x600 no longer works the same. Now it does have a border.... which is causing the clamping of the height to 578 as well, which means I can reproduce the same issue (when already in window 1024x578 then trying to set to windowed 1024x600).

And it seems the full screen modes are... um... not correct. They are displaying the same chopped text as when it THINKS it's in a 800 height window but it's actually in a 578 height window....

So it seems like the full-screen modes are accounting for there being borders or something.... I get this effect even when I first start up DX9MV at the fullscreen res of 1024x600 without any weird res changing

Here's a screenshot:

My scr_conscale is at the weird 1.5 but that alone previously didn't cause the issue, as the 2nd screenshot from DX8MV shows. Oh, it appears the previous DX9 version had this issue as well, so I guess it's not new to today's release.

But with this new version, I am getting a long delay when starting a game -- about 13 seconds. I don't have MP3s enabled. It only takes about 5 seconds to start a game in DX8MV.

This delay happens regardless of my resolution settings. Ah, it seems to be taking extra long for HQ textures to load.... If I disable them, then it loads a new game in about 4 seconds. This delay did not happen in the previous DX9 version.

About r_waterwarp:

Console variable: Toggle the use of the screen warping effect when the player is submerged in liquids. Set to below zero for water warp in GL version, but not in WinQuake version. r_waterwarp 2 in Open GL is FitzQuake style waterwarp.

I find that information confusing, and it doesn't seem to work.

In GL or DX9, you can ONLY get the new effect no matter the setting (though "0" is "off").

In DX8 there is only the old GL warp effect (I understand the new effect isn't in this version).

And in the Winquake version, the water warp is so subtle/slow you can BARELY notice it. 

If I start up DX9MV with 1024x600 windowed having been previously set, it correctly appears to be the borderless window that takes up my full screen, but the distorted text is still occurring.

If I change to 1024x600 windowed mode from any other mode (including just hitting alt-enter twice after starting as above), then the window borders appear and the window gets clamped to 1024x578, but then the text is no longer distorted.... 
The REAL Question Is... 
... when can we expect the Vulkan version, baaaahahahahha

Why should modern day Quake be relegated to such archaic API's!!! 
New Wrapper Version

Stencil is fixed, tested & confirmed working in latest Mark V release too.


I'm still in "investigate mode" for those. I considered the stencil issue sufficiently important to release a new version fixing that, since it affects everyone and currently has ugly special-case code in MarkV.


I asked you above if you had any suggestions for an acceptable fallback if it does turn out that the 800x600 behaviour is something that we don't have control over in software.

I'd really appreciate an answer to that, because I really cannot change the way Direct3D works.

I am willing to put significant work into tuning this to meet your requirements, but I do need to be seeing something coming from you too, and right now I'm not. 
Congrats On Getting To V1.00 (and Now Beyond) 
Really good to see things like true lightning in, and I could mention a whole series of other features I like about the engine, but I can sum up by praising the user convenience it provides. That manifests itself mainly in the console, where all the features like text editing shortcuts, find, help and shift-tab to reverse cycle are incredibly handy for anyone who uses the console frequently. Also good to see mh helping out, since DirectQuake was always my favourite engine prior to Mark V.

While fiddling around with it I've found a few issues you may be interested in. I hope these haven't all been covered already (I did ctrl+f a bit through this thread, but it's coming up on 1000 comments now and tricky to track everything said). My system is an up-to-date Windows 10 64 bit; i7 870; Nvidia 970 with driver 376.33.

1. Just confirming 2 things mentioned above - the r_oldwater crash mentioned by Baker in comment 761 is still present. The vid_hardwaregamma 0 alt-tab issue mentioned by Gunter in comment 335 seems to no longer be present in v1026.

Some other points about alt-tab/alt-enter/fullscreen stuff which I think Gunter has discussed, but I may as well give my own experience of it since I made some notes. I use a 1920x1080 display. In v1025 + v1026 the game always seems to start in what appears to be fullscreen borderless mode even when vid_width 1920; vid_height 1080; vid_fullscreen 1; vid_restart are in autoexec.cfg in that order. In the dx9 builds, an alt+enter at this point gives you fullscreen exclusive. OpenGL works as might be expected with this cfg - ie providing fullscreen exclusive behaviour immediately. On v1025, continuing to toggle alt+enter results in switching between 1920x1080 fullscreen borderless and 1920x1080 fullscreen exclusive. On v1026, toggling results in 1920x1080 bordered window and 1920x1080 fullscreen exclusive.

2. It seems vid_multisample has no effect in dx8, dx9 and OpenGL. I also noticed vid_fsaa doesn't work for me in Quakespasm, though DirectQuake's vid_multisample does.

Mark V -
DirectQuake -

3. It seems r_showtris 1+2 both do the same thing. The description indicates that one shows triangles visible to the engine, whereas the other shows those only the human eye can see, yet they both seem to only draw the engine's view.

4. Mirrors don't function correctly in dx9 when reflecting the sky.

dx8 -
dx9 -

5. Noticeable input latency in dx8. When testing the dx8 build I had the sense that the game was feeling much less smooth generally than the other builds, almost juddery and with what felt like a significant difference in input latency. I borrowed a 120fps camera and did the following test - record the mouse and the screen simultaneously -> press mouse1 to fire -> count the number of frames from mouse button depression to response on screen. Not perfect, obviously ideally you want an LED attached to the mouse, but I think the test gives a good enough indication.

On dx8, on a mouse with a polling rate of 500, host_maxfps 500, a screen refreshing at 60hz and vid_vsync 0, the average number of video frames from button press to screen response was 4.7

On dx9 under the same conditions, it was 1

No idea if this is simply a limitation of dx8, but thought it might be worth knowing. The point I mentioned earlier about the game always starting windowed in dx9 is also relevant to this, since subjectively I noticed windowed has greater input latency, which is usually (always?) the case when playing any game windowed. 
I'm not really sure what you're asking, mh.

Acceptable fallback? Just make it work correctly like it did in the DX8 version, heh.

I'm pretty sure I've provided enough detailed feedback for Baker to start hammering away the problems. And I'm pretty sure this IS something controllable by software, because, as I noted:

I've found the problem (Mark V thinking it's at 800x600 when it's really clamped to 800x578 window) only occurs when I try to change to 800x600 windowed via the menu when it's currently at 800x578 windowed (I know, there's never actually any reason to do this, other than testing).

New bit of info: at that point if I do vid_restart I get: "Video mode request is same as current mode."

So again, it THINKS it's in 800x600 but it's actually in a clamped window of 800x578, and that is causing rendering issues.

But the problem fixes itself upon mode change by hitting alt-enter twice (going to fullscreen then back to windowed mode). So when it knows it's changing modes, it sets things up correctly.

The problem also doesn't happen when starting with -width 800 -height 600 by the command line (I get a correctly clamped and rendered window).

So it just seems that it needs to go through the proper steps after each mode change *even if it thinks a mode change is not occurring*

So, it needs to do something like:

-set new mode
-check for window clamping altering that request
-adjust video stuff to correctly reflect clamped size

Instead, when I am currently in the 800x578 previously-correctly-clamped window (when DX9MV has correctly detected it, it shows that in the Options menu, even though vid_height reports 600) and then I tell it by the menu to change to 800x600 (for texsing...), it does something like:

-set new mode
-don't notice the window was clamped back to the previous setting (meaning no window size change actually occurred)
-draw things at the non-clamped setting (800x600), causing issues, and report that the video mode is 800x600, which doesn't match the window size.

Perhaps the glitch is occurring because the actual clamped new window size is the same as the old window size, so it does not think anything was adjusted... so it doesn't realize the window is not the size it was requested to be.

I'm not sure what more info I can give as a bug tester, heh. I think Baker should be able to address this with the info provided.

But if you can be more specific in what you're asking, mh, I will, of course, try to provide any help I can. Assuming you're not just asking me for something you know is impossible for me to provide? ;) 
Looks Like Mh Has Been Busy ... DX9 Build 1027 ... 
Coming up very shortly ... 
Further info:

The reason my little glitch can never occur in DX8MV is that it reports I am at 800x600 in the menu even when the window is correctly clamped to 800x578, so it won't let me try to change to 800x600 since it thinks I am at 800x600 already.

Whereas DX9MV correctly reports 800x578 in the menu, so it WILL let me try to change to 800x600... which confuses it, apparently.

This glitch has become pretty minor though, now that Baker fixed the window positioning thing (I previously thought they were related). 
Another new wrapper version probably coming up soon, depending how many fixes I can get in over the next hour or two.

Alt-tab from fullscreen modes loses the warp images and occasional device reset fails - fixed. Again, it's just a single fix but it is important enough to warrant an update. 
Mark V DX9 - Build - Revision A 
Perfect mirrors + stencil shadows.

Direct X 9 - Build 1027 A

Once I saw the source code, I knew this will be followed by Revision B with ...

the "2017 HOLEEFUK feature of the Year" ... as some may describe it. I want to see this myself.

The source will appear in the folder here just a min, in case MH needs sooner rather than later. 
That Was Quick 
With 1027a, r_oldwater 0 + alt-tab when in fullscreen no longer causes a crash, but does produce the following strangeness -

Can confirm skies now reflect correctly in mirrors. 
I think at this stage I'm more confused about what's happening than anything else.

Anyway... now that I have an XP VM I have Pix and the DirectX control panel back - WOO-HOO! - I never realised how much I missed them.

I already have a fix for one issue coming in... 
With 1027a, r_oldwater 0 + alt-tab when in fullscreen no longer causes a crash, but does produce the following strangeness

Fix in next version. 
Welcome back! And thanks!

/Gotta get this Revision B going ... 
Mh - Solved The Age Old Question ... 
Question: Where is my shadow?

MH's answer: in visual form 
Another New Wrapper

Fixes "With 1027a, r_oldwater 0 + alt-tab when in fullscreen no longer causes a crash, but does produce the following strangeness "

I didn't get Gunter's stuff in although I now have one solid lead for what's going on.

Thanks to the DirectX control panel and the debug runtimes I can see that I'm getting a lot of "viewport is outside the render target" errors when running at the same height as the desktop mode.

That needs to be fixed as a first priority, and the reason why it happens is that the display mode clamps.

I can't right now see a good way of handling this without adding more code that's going to percolate back up to the engine.

So rather than take the time to work it through and delay the required alt-tab fix, I'm releasing now so that Baker can get that fix. 
Mark V DX9 - Build 1027 - Revision B 
Direct X 9 - Build 1027 B

Latest mh revisions addressing issues. Source will soon be in the same place as last time.

/MH shadow volumes awaits in revision C. 
You guys are crazy productive sometimes. I really appreciate all the work that various Quake-dudes put into this little hobby.

I'll check the latest builds tonight to see if the flickering has gone away on my system. Should I also check autosave behavior? Anything else? 
Multisample in Open GL, at least for Windows, has been disabled for ... actually it's been quite a while ... You are the first one to notice ;-)

mh is down on the idea on adding to the Direct3D build. There's a post somewhere in this thread where he discusses why.

I could re-enable it in the Windows Open GL build with some effort of rewriting some things slightly, but in the age of 3800 x 2600 monitors, multisample is going to be hella hard to notice.

Looming as a larger factor -- the Direct 3D build has ...

1) superior frames-per-second performance
2) superior compatibility on older hardware

Direct3D 9 is going to become the main build hardware accelerated build for Windows eventually. 

If you want to join in the fun, grab the current source code and try to compile the Linux version in CodeBlocks on your CentOS and see if it runs ok. Requires SDL 2.0.4 dev.

I haven't had time to raid Requiem for the goodness in the Linux build like video capture and such. 
@johnny - Part 2 
I'll check the latest builds tonight to see if the flickering has gone away on my system. Should I also check autosave behavior? Anything else?

Lots of irons in the fire lately, I still have more on my todo list --- and I need tackle MH shadow volumes. I don't even have the Mac version quite up-to-date.

/And pesky little issues like ones reported by dwere, yourself (config read order, built-in Quaddicted installer unpack with certain file names like your dll example) and nuisance gremlins remain -- hence it's beta.

Autosave should be fixed. And any information on whether or not the flickering is gone for your machine (and pulsars) would be great! 
The shadow volumes aren't robust, by the way. You're going to find places where they leak through geometry or fly around at odd angles. In terms of shadow volumes they're probably as good as you can get without going towards a realtime light/shadow setup.

So I'd advise them as an additional option rather than an outright replacement for planar shadows. That means the choice comes down to one of two imperfect shadow types, or no shadows. Not ideal, I know, but different imperfections drive different people nuts in different ways, so hopefully it covers enough angles. 
New Wrapper Version

This one resolves one of the problems when running a windowed mode the same height as your desktop, and where the mode gets clamped. That being viewport/rendertarget size mismatch. Extra code is in GL_BeginRendering and the #define name should come with a smiley - it's meant to be humourous, not insulting. ;)

This one also resolves a second minor issue where a rendertarget used as a texture needs to be unbound before it can be set as a rendertarget again. Not such a big deal because D3D will detect this and unbind it for you, but still nice to have it done properly.

The wrapper now gets a totally clean run on the Direct3D debug runtimes. 
Hm, I am finding that since version 1.26, activating id1 mirrors will completely freeze me up. r_mirroralpha 1 prevents it from happening.

That's in addition to the weird extra-long delay when loading external textures, which also showed up in 1.26

Might it have to do with these new warnings I get as of 1.26?

Warning: texture_env_combine not supported
Warning: texture_env_add not supported

I also get this one, but it was always there in DX9:

Warning: texture_non_power_of_two not supported

And it looks like the env_combine warning is also present in DX8. But there are no mirrors in DX8, and it loads external textures without an extra delay. 
/me imagines a function name,

I'll Hold Out For Opengl 
the directx version runs uber sluggish for me 
Typo Or Wrong File? 
The file in revision B link is named 
Yeah change the revision_a to revision_b to download. 
Also, as of DX9 version 1.26, the fog got uglier again when gl_overbright 1 is set....

It's an issue I reported on the old page (#1217 of old page, if you wanna see the screenshot), but it was improved in DX9 1.25, and now it's back to the previous, a bit uglier, behavior (fewer fog bands on lit wall areas, making a rougher gradient).... 
Played thru ad_mire using mark_v.exe from the 1025 beta zip; no flicker. 
@johhny - awesome.

@gunter - So DX9 1.25 was good, DX9 1.26 fog less good. Right?

@railmccoy - r_oldwater = no issues now, right? 
I'm sure mh is gonna want to know more about the specifics.

I get 700 peak frames per second with basic FitzQuake settings in some areas of the start map just wandering around.

And my machine is rather average. 
@gunter - As the DX9 had more capabilities enabled, I disabled DX8 limitations that I had imposed on DX9.

In the case of external textures, I have Mark V using glMatrixMode (GL_TEXTURE) to perform scaling for texture coordinates to align it with the original texture, a feature which DX8 did not have.

I'll wait for mh comments before delving into it, I noticed changes to the mip-mapping process, etc. 
Unknown Command "max_edicts" 
The AD quake.rc sets max_edicts 8192 for Fitz/QS/Mark V but apparently dx9_mark_v doesn't recognize the command.

Also, textures are still blurred while I have GL_NEAREST_MIPMAP_LINEAR specified in both quake.rc and autoexec.cfg. 
@Gunter @Baker @Fifth @Mugwump 

So I don't have to do a new release for Baker to get this fix.

Bug in d3d9_glcontext.cpp, line 409, in "if (D3DSHADER_VERSION_MAJOR (d3d_Globals.DeviceCaps.PixelShaderVersion) > 2)" change ">" to ">=". Oops.

That will fix the engine reporting combine and add not available, and I believe that it will also fix the whole ugly fog business.

With gl_overbright 1 and without combine the engine will do multiple passes blending in coloured fog with black fog. Where combine is available it will do it all in a single pass.

I now believe that the multiple pasees are the cause, rather than per-vertex vs per-pixel or API differences.

This should be reproducable with original FitzQuake or with QuakeSpasm by running -nocombine.

I'd encourage further performance testing after that. D3D9 being sluggish should go away: it would explain why Baker and I get good perf but some others don't - because you're being incorrectly dropped from single-pass to multi-pass the renderer is obviously doing at least twice as much work.

I've a hunch this may also fix Gunter's reported issue with mirrors.

It's the Quake equivalent of NASA's minus sign.

Changes to mipmapping/Textures

I decided that default glTexImage behaviour was insane. You can specify miplevels in any order, with different formats, textures can be incomplete and the whole thing can't be validated until draw time.

So what I did was ignore every miplevel but 0, using that to build the texture. A full mipmap chain is always built and sampler states are used to control level selection. I have to take over mipmap level building myself here too as a result of all this.

So what this means is that the engine is building mipmap levels twice. Once in the regular code, which the wrappper just discards, and once again in the wrapper.

I suggest just calling glTexImage for level 0 in the D3D9 build and everything else will just work.

textures are still blurred while I have GL_NEAREST_MIPMAP_LINEAR specified

Because you have anisotropic filtering set to higher than 1. Nothing I can do about that; D3D defines 3 texture filter modes: point, linear and anisotropic. If anisotropic filtering is higher than 1 then point filtering (the equivalent of GL_NEAREST) is ignored.

A workaround might be to ignore anisotropic filtering for GL_NEAREST modes but I suspect other people would complain about that. 
Both Mark V and Quakespasm use max_edicts 8192, although in Quakespasm you can change it and in Mark V you can't.

GL_NEAREST_MIPMAP_LINEAR specified in both quake.rc and autoexec.cfg

Sounds like a bug in Mark V related the currently slightly borked config execution.

When the beta gets closer to being a stable, I'll make sure your example is ok. 
@mh - Brainstorming ... 
Mark V uses the stencil buffer for sky draw and the stencil sky draw is in the middle ...

So stencil sky draw is going to wipe it and it looks like you draw shadow volumes at the tail end.

I'm rather stencil rusty at the moment and you're in the thick of it, if you have a quick thought on how to adjust the stencil calls to only use maybe a certain bit, would be greatly appreciated.

I've always read that at least in Open GL, I should be wary of trying to do anything other than 0 or ~0 (-1).

But there's 4-8 bits of stencil available.

Meanwhile, I'll just come up with a workaround because I want to get the next release out.

Then the other school of thought is just firing off the shadows before drawing sky and we'll just say alpha entities don't have them ;-) And shadows on water is just tough luck.

R_DrawShadows (); //johnfitz -- render entity shadows

R_DrawEntitiesOnList (false); //johnfitz -- false means this is the pass for nonalpha entities

Sky_Stencil_Draw (); // Baker: This will draw the sky if there is stencil.

R_DrawTextureChains_Water (false); //Baker -- solid warp surfaces here

R_DrawEntitiesOnList (true); //johnfitz -- true means this is the pass for alpha entities

R_DrawTextureChains_Water (true); //johnfitz -- drawn here since they might have transparency

Yeah, I have to say I like the shadows quite a bit. They may not be completely perfect, but they're still a mighty nice upgrade. 
Unfortunately the shadow volumes need all 8 bits because they increment/decrement rather than just marking specific bits.

What I'd do is split the R_DrawEntitiesOnList (false) call into two.

First call before sky and only draws bmodel entities.

Second call after sky and draws alias model entities.

You then need another clear of the stencil buffer after drawing sky too, but I think that's the simplest and cleanest way to do it. 
Makes sense. Thanks! 
Mark V - Beta Build 1028 - DX9/Open GL - Volumetric Shadows 
Mark V Build 1028 - Direct X 9, Open GL, DX8

The Direct X 9 build should be fully up-to-date with everything including the latest tweak suggestions from MH and all the revisions.

I often get triple or higher the fps with DX9 vs. the Open GL build.

Fifth and gunter had issues with some sluggishness in DX9, but the latest version should make those problems go away.

Volumetric Shadows

Most easily experienced typing in the console:

chase_active 1; r_shadows 3 // 3 = volume

Volumetric shadows are in the DX9 and Open GL builds, as is MH waterwarp. There is a DX8 build in the zip, mostly for beta testing use as DX9 gets hammered and molded.

Linux Build - Although I didn't include binaries, the CodeBlocks project should be up-to-date for building and would have all the above features. Source code is in the same folder as the download in this post. 
Volumetric Shadows 
The new shadows look really cool, especially on rotating items.

Anyway, it doesn't look that cool in certain situations such as this (regarding the casting location of the shadows).

However, I think that problem already existed with the old shadow system, so I guess we have to file it under visual glitch. 
Heh, yeah that's what I said above about where they leak through geometry.

In order to solve that you'd need to start casting shadows from all brush and world geometry, and next thing you know you've got a full-blown real-time lighting engine.

Personally I always run Quake without shadows anyway, on the basis that no shadows are better than bad shadows. This just offers shadows that are bad in a different way. 
I Think I'd Prefer 
A blob like in quake 3 
A Blob Like In Quake 3 
Still has all the flaws of standard GLQuake shadows. 
Because you have anisotropic filtering set to higher than 1.
OK, I set it to 1. Fixed the blurriness but now my liquids umm... scintillate? (don't know the exact word for it) in the distance, a bit like old TV static. I suppose this is an either/or situation? 
ow my liquids umm... scintillate? (don't know the exact word for it) in the distance

Original FitzQuake doesn't mipmap water textures and this is inherited from that.

On the one hand that replicates the behaviour of software Quake. It also makes the render-to-framebuffer waterwarp easier because you only need to render a single miplevel instead of the full chain.

On the other hand it causes sparklies in the distance. 
That's Quite A Compliment Though 
'Scintillating water!'

Put it on the back of the box.

No issues with fullscreen alt-tab and r_oldwater 0 now. Gonna play around with the new builds now and see if there's anything else to report. 
Compiled On OpenSUSE 
Bendy shadows are neato! (and ghost shadows are amusing) 
Mirror freezeup = fixed!
Window clamping resolution glitch = fixed!
New shadows = neat!
Old stencil shadows = now working too.
fugly fog = less fugly!

Fantastic work, mh!

Issues that still exist:

Delay upon first starting a game still happens.

Using external textures and a skybox, no MP3s, all settings the same, upon first starting a new game (starting Quake fresh before each test), time between telling it to start the game in the menu and when the game actually starts:

DX8 = 3.16 seconds
Dx9 1.25 = 3.17 seconds
Dx9 1.26 = 7.17 seconds
Dx9 1.28 = 6.89 seconds

DX9 1.28 with no skybox = 6.45 seconds
DX9 1.28 no external textures = 2.87 seconds
DX9 1.28 no skybox + no textures = 2.42 seconds

DX9 1.25 no sky + no textures = .87 seconds

So the skybox causes a slight delay, but it's the external textures which are really causing the delay, as of version 1.26

The above tests are running id1. The delay gets worse when I'm running FvF, which may be loading other things like monster skins:

DX8 1.28 = 5.96 seconds
DX9 1.28 = 12.59 seconds

So it seems like it is taking very close to twice as long, which may be a clue, like maybe it's loading the textures twice....

Also still happening as of 1.26, when first setting a full-screen windowed mode that matches screen resolution, I'm instead getting a clamped, bordered window (1024x578) instead of the previous 1024x600 borderless window. But the text in the bordered window looks correct....

Upon restarting Quake after making that setting, I get the 1024x600 borderless windowed mode, but I can tell the menu text is distorted (using scr_conwidth 1.5 -- I previously showed screenshots of this effect).

I seem to be getting that distortion in any full-screen mode (this was happening as of 1.25, but not in any of the DX8 builds), which seems to indicate it's still not quite got its rendering resolution just right in full-screen mode.

Ah, I think it's only happening when it's a full-screen mode with height equal to my resolution (so 800x600 or 1024x600 full-screen modes). It seems like it's drawing at a resolution equal to the clamped window's screen height (578), even when that's not needed because it has the full-screen mode height (600 with no borders) to work with.... 
Vertical Stretch? 
I may be tripping, but everything seems taller.

Thinner ogre legs are weirding me out. 
Old issue has popped up. Well, it was an old issue in DX8, but it was fixed in that. It exists as of DX9 1.25:

gl_fullbright 1 = most weapons opaque when using ring + transparent weapon models (but not axe) unless using custom textures (must be as metlslime said, and the custom textures don't contain fullbright pixels). Illusionary ent guy is also opaque.

gl_fullbrighs 0 = everything transparent, including illusionary guy.

Interestingly, I can see my shadow through the otherwise opaque illusonary ent guy IF I set r_shadows 3.

r_shadows 3 looks cool, and works fine when I'm running around a map by myself, but my little netbook cannot handle it when there are lots of other things casting shadows! Yikes, kills my FPS hard....

And it can make some weird effect, heh, like this:

But as the 2nd screenshot shows with standard shadows, weird shadows were always a thing in Quake! 
@fifth - If you have a chance, could you let us know if the 1028 build DX9 works ok now?

@jimbob - thanks for info. Awesome. "Thinner ogre legs are weirding me out" ... I'm assuminng you are talking ogre shadows with r_shadows 3, but if not could you post a screenshot?

@rail - nice to see r_oldwater issue is put to rest.

@gunter - I'm getting this too.

I type map "dm3" with r_viewmodel_ring 1 (it's in the menu by setting "Invisibility: Draw Weapon")

I grab the ring and the weapon is fully visible, instead of translucent.

Also in some cases, transparent entities are more transparent than in Open GL. Putting this e1m1 external .ent file in quakeid1maps, which turns the starting elevator into a transparent func_illusionary, it is close to fully invisible in DX9 but rather visible in Open GL.

That elevator example wasn't of enough interest by itself, but since Gunter pointed out the invisibility weapon draw, I thought now was a good time to mention it.

However, I didn't want to point it out until I had time to verify that the state of all the gl capabilities is correct --- i.e. I cannot be 100% that it couldn't be a Mark V mistake that shows no symptoms in Open GL. 
@mh - 640x480 + Vid_hardwaregamma 0 (shader Gamma) 
Shader gamma - stretch looking

What I think could be going on there relates to how 2D matrix calculations often need a 0.5 nudge for even numbers.

The menu canvas in that scenario should be 320 x 200. I don't see the "stretch effect" in the console at 640x480 in Mark V, but the stretch impact might be too minimal.

If I were to type vid_hardwaregamma 1, instead using display brightness adjustment and not the shader, the menu text appears normal. 
Comment you made elsewhere was insightful -- "It suits me as well to work on the rendering layer and let other people deal with the other stuff."

Since the inverse has been helpful for me, since I've been able to focus on an entirely different set of objectives, like concentrating on get some extra builds ironed out (linux, trying to address killpixel's now deceased issues with WinQuake, etc.)

The fact that waterwarp and shadows work on these other platforms like linux is awesome, clearly.

/Time for me to attack outstanding issues, Mac build and see if firewalled .bsp rotation support can be implemented for damage_inc/sock. 
DX9 Is Much Improved 
Although I have no need to use it. Is there a reason why gl_texturemode is always linear? 
Great Stuff 
Baker and MH, you two are just incredibly passionate workers.

DX9 version is of interest to me because ShadowPlay(Nvidia recorder) can hook with it. Water warp is a great effect and I get smooth gameplay with the latest beta release. r_shadow 2 looks great, with 3 having strange issues like the shadows being cast on the geometry below.

Is there a reason why gl_texturemode is always linear?

From my brief test, I also noticed this! 
mh on how d3d filtering is different

Because you have anisotropic filtering set to higher than 1. Nothing I can do about that; D3D defines 3 texture filter modes: point, linear and anisotropic. If anisotropic filtering is higher than 1 then point filtering (the equivalent of GL_NEAREST) is ignored.

At some point, I'll add an FAQ or some way to convey that information because I can see that continually getting asked.

Shorter version: Disable anisotropic 
Ah, Baker identified the distorted text issue I was talking about above, when in fullscreen modes. If I go back to vid_hardwaregamma 1 then the text looks correct.

vid_hardwaregamma 0 makes it distorted again.

Note: though the help info says "2," "r_waterwarp 3" is the setting needed to revert it to the old GL style (the new waterwarp kills my FPS in GL, though it works great in DX).

@Baker: I remember gl_overbright_models would affect how transparent the illusonary ent guy appeared, but he is a player model.... That setting probably wouldn't affect the elevator. Well, I just know that you fixed what seemed to be the same issue for DX8 back in build 1009.

Random feature request: Many modern mice also have a left/right motion for their scroll wheels (and trackpads do too), used for sideways scrolling. You could make those actions bindable:

A Few Notes 
1. Alpha masked texture support is buggered in dx9 -

2. Getting really bad framerates in OpenGL. Noticed it most severely in final fight on ad_fenrir, where I dropped to 40s. Thought it might be just AD mod, but it's id1 too, as I was getting framerates of only 100 in areas with a wpoly count of 1000, which isn't normal (I usually cap at 72 obviously; just host_maxfps 250 to test). Input latency felt worse in both OpenGL and dx9. I can measure that again with a high fps camera if necessary, but I'm pretty sure about it.

3. Engine still seems to start fullscreen borderless in dx9.

4. On shadows - it's nice to have another method, and they do look a bit better than standard glQuake ones certainly, though I agree with others in that my tendency is to use no shadows rather than ones which frequently display in weird ways.

I'm aware that mh pointed out that blob shadows have the same issues as the ones currently present, but in some ways they are less conspicuous in their flaws, simply as a result of being smaller and not projecting as far. They also serve a useful gameplay purpose in aiding depth perception, especially when using rockets to fire at the floor. I don't remember those in Quake 3 having glaring flaws, and FTE has its own blob shadows that seem to work very nicely in my experience.

I'm also kind of curious about how games like HL2 did its shadows (the first game, not Episode 2 and later versions of the engine that added real-time shadows from flashlights etc). That game relied on lightmapping and yet had pretty good projected shadows for characters and props. They weren't flawless and did clip through [i]very[/i] thin walls in some circumstances, but they were generally very good.

5. Multisampling - I'd certainly defer to mh if he feels it's not worth the hassle in D3D. I did use it without issue in DirectQuake, though that is only a data point of 1. If you were to consider implementing it in OpenGL, I suppose the arguments for it vs using simply using very high resolution would be firstly, performance, and secondly the fact that not everyone will have a high res monitor to run 4k etc, with downscaling tending to produce a blurrier image. If you're going to support dx8, you may as well also cater to those who have older monitors.

I don't mind either way, just discussing the hypotheticals really. 
Gl_nearest And Anisotropy In DX9 
Maybe the solution to this is to have the engine reset gl_anisotropy to 0 or 1 if gl_nearest is activated for the DX9 version then, and maybe print something or notify the user. 
@gunter, Maybe @rail - An Obscure Feature 
[@fifth - Yeah that is what I decided ... Beats writing up documentation no one will read, hence people would still be confused]

Mark V dir command - an obscure feature

In Mark V, the dir command will list all the files in the current Quake folder (recursively) and sum the sizes.

1) dir
2) dir retro*.bsp // Find map beginning with retro
2) dir *.tga
3) dir "*.tga;*.png" // semi-colon requires quotes
4) dir a?*.* // ? is means any single character
5) dir *a*.* // Anything with an a in it
6) dir "<reject>*.dem;<accept>*.*" // list all files that are not demos

The above system is kind of a byproduct of the auto-completion system.

The auto-complete abilities need to be able to filter through lists of files with Gunter-like pickiness to match the ones that apply.

/End obscure feature 
@Baker - Linux 
I have started a list of Linux issues and feature requests (and observations?), available upon request :P

Don't want to just dump more stuff onto your pile, though. And it will probably mostly be stuff you know about already... 
THERAILMCCOY, I can only replicate the issue you are having (starting in borderless fullscreen window rather than true fullscreen) when I start with command line options like:

DX9_Mark_V -width 1024 -height 600

Normally if I exit the game when running a fullscreen mode, it starts up next time in that fullscreen mode....

If I use the above command line, it starts up in the borderless window mode every time (or a bordered window if I'm setting like 800 x 600).

-fullscreen command line option doesn't help (if that's valid).

But if I also add autoexec.cfg settings like you described (vid_width 1024; vid_height 600; vid_fullscreen 1; vid_restart) then it correctly sets me to true fullscreen mode... 
Dump away. I want to know what works well, what doesn't work well, etc.

I may not be able to act immediately, but when I know about things it helps plan. 
GL_NEAREST modes and anisotropic filtering

This is one of those cases where you have to balance correct behaviour vs expected behaviour. D3D doesn't allow you to have both set at the same time. Previously I had erred on the side of anisotropic filtering as the expected behaviour. I was wrong. If people set a GL_NEAREST mode it's because they want crunchy pixels, and anisotropic filtering be damned. I'm prepared to be pragmatic about this. I've a coupla things to test but if it turns out to be the case that GL_NEAREST needs to take priority, then so be it.


Some day I'm going to work through this and see what's reasonable to do. The fact that I haven't done so yet doesn't mean I'll never do so.

This is one of those "API differences" things. GL lets you throw some numbers at it and the driver does the right thing. D3D exposes more of the ugliness that actually lies beneath the covers. Get it wrong in D3D and the driver will crash.

I'm just saying that it's much more work than people probably realise.

Off-by-1 crap

In my own tests this only seems to happen in the menus. I set gamma to 0.7 and press ESC to toggle the menu. You can clearly see the rendered frame shifting.

This makes absolutely no sense whatsoever to me. I still suspect GL_SetCanvas though.

Borderless modes

The wrapper actually always starts up in a borderless mode and then switches to proper fullscreen as soon as Direct3D is initialized.

This was very deliberate and intentional.

This behaviour is required by DXGI on Vista+.

If anything goes wrong during startup you get to still have control over your desktop this way.

It plays nicer with other programs that may be using the graphics hardware.

This one is non-negotiable. If there are glitches as a result I'll make a best effort to fix them, but the behaviour itself is not going to change. 
@Baker - Linux List 

1. gamma and contrast appear to do nothing (No big deal in my case, cos I have a desktop workaround).

2. Toggling external textures in windowed mode crashes cleanly to desktop.

3. When I go fullscreen, it always reports that it has set Quake to my desktop resolution (1680x1050), and refuses to stretch out lower resolutions to full screen. Not sure if by design, but frankly, it's so fast that I'm not sure it matters.


1. support for 6+ mouse buttons (seems limited to 5 right now). Not sure how mwheelup and mwheeldown factor in, so I might need up to 10?

2. MP3 emulation of CD music (Is it missing in Linux, or do I just need a workaround?)

3. "Restore" printing of console messages to Linux terminal too (minor, but would be nice). 
Shadow Stuff 
This is something that crops up from time to time. "How come HL/HL2 can do XYZ but Quake can't?"

On the surface it seems reasonable. Both HL and HL2 are ultimately derived from Quake.

The difference isn't technology. The difference is content.

If you're starting from scratch with entirely new content you get to be able to say things like "brush models don't exist" or "I only have one directional light and that's the only light that casts shadows" and whole classes of problems just go away.

If you're retrofitting new technology on existing content you often don't have that luxury.

As always, a best effort will be made, but Thou Shalt Not Break Existing Content. 
vid_hardwaregamma 0 should give you control over gamma/contrast. Use the "txgamma" console command to change gamma. I haven't taken the time to fully integrate it into the menu.

mp3 music. At the moment, no Linux music option. I've had my eye on a few different methods including what VideoLAN does to unlock mp3 hardware accelerated decoding on Linux already built into your processor (Intel, AMD, ..). Haven't had time to conduct experiments and evaluate choices.

/So the quick ones are out of the way ;-) 
I'll play with the GL_SetCanvas and see what happens. 
From what I've read, only the video decoding part of video playback is hardware accelerated, since it takes very little CPU power to decode mp3, but I am curious anyway. Some link dumps:

Wonder if gstreamer would be an option? It's a big bloated API, but I think it handles sending audio to the OS mixer itself.. so maybe you could get away with no changes to the Quake sfx mixer. Wouldn't be great for Mac though as it's more of a Linux library. 
MP3 Music 
txgamma works!

IDK if this helps at all, but Darkplaces for linux has working MP3/CD audio. 
I tried doing "dir" just to see it...

YIKES. I'd say it's a bad idea to do a complete listing of every file contained in every subfolder in the current directory... (I have a lot of content folders in my fvf directory...).

Make it like DOS does. Only show the names of folders, and not a full directory listing of each of those subfolders.

...unless I Ask for "dir maps" ...which doesn't actually work....

Also, just thought, can that fugly fog fix (and other stuff) be applied to the DX8 build? 
DX8 Build 
Some, but not all, could be applied to DX8. I'm not sure there's any really huge need to, however. 
Just To Be Clear... 
The "fugly fog fix" isn't a one-line-of-code thing.

It means implementing GL_COMBINE modes, close on 100 lines and a complete re-architecting of how texture environment modes work.

Then you get to do the one-line-of-code thing.

Given that the DX9 build will run on downlevel hardware I don't think it's a productive use of time. 
Nearest Vs Anisotropy Dx9 
Then perhaps have this work so that whatever is set last take precedent. So if anisotropy is already set and then nearest is chosen it undoes anisotropy. And vice versa, that way you get a visual feedback back that you can't have your cake and eat it 
At least from my point of view that seems like an improper request.

Let's focus on the future.

There is only so much time in the day, let's use it wisely. 
/I was referring to the idea of updating DX8. 
iirc nearest+anistrophy is undefined in opengl, so fte only enables anisotropy with mag=linear so you know what you're going to get.
should probably force mip filters too... :s 

GL actually does define GL_NEAREST + anisotropy, but it modifies the behaviour of GL_NEAREST from being a "crunchy pixel" mode to being a "select the type of anisotropic filtering used" mode.

The extension notes that such hardware actually does exist. Maybe it did back then but I'm not certain that it does any more.

Cross-checking this extension with FitzQuake's checks for anisotropic filtering, I'm not sure what the intent behind the latter is, but the extension notes that 2 is minimum value so it would be sufficient for FitzQuake to just check for 2.

Setting to 1 disables anisotropic filtering. I'm not sure how well-known that is; disabling anisotropic filtering is a value of 1, not 0. Setting to 0 will actually throw a GL_INVALID_VALUE.


Direct3D 9 doesn't clearly define how anisotropic filtering works at all. You need a bunch of trial and error to figure it out yourself.

It does state that you cannot set an anisotripic mip filter, but you also cannot set an anisotropic mag filter - the D3D debug runtimes will throw "unsupported mag filter" errors. So anisotropic is for min filter only.

Setting max anisotropy to any > 1 value without also setting the min filter will not give you anisotropic filtering.

Setting mag filter to point/nearest and min filter to anisotropic will actually give you a blurry mag filter.

What a mess.

Decision time

I'm going to do the same as Spike and only enable anisotropy with mag filter = linear. It's clear from upthread that expected behaviour is "if I ask for crunchy pixels I want to get crunchy pixels".

I think setting them in the order that commands are issued is just going to create a mess that will eventually explode in your face. I do understand the visual feedback element, but that only applies if you're entering commands manually in the console. Whatever is chosen must also give expected behaviour with config files. 
Fair Play 
Can't Play The DX9 Build Of Mark V 
I get this error: video: ChoosePixelFormat failed 
ChoosePixelFormat Failed 
The OpenGL build should also fail because this is common to both.

I'll override ChoosePixelFormat for DX9. 
Fixed Off-by-1 Crap 
FitzQuake's GL_SetCanvas (CANVAS_MENU) was leaving the viewport smaller than the full render target when doing the gamma/contrast pass. That's what caused it to be off-by-1 and that's why I saw it shifting while toggling the menus.

I've a nice body of fixes built up again now so may do another code dump soon. 
Thanks for the shadow explanation, mh.

Gunter - I did stress that it seems to be in fullscreen borderless mode. It gives the impression of being so due to the appearance of a mouse cursor on the screen, that then goes away if I alt+enter. Once the game is definitely in fullscreen exclusive mode, alt+enter always triggers a switch to bordered window mode. Not sure if this was of any use to determine if what you describe in comment 991 is working correctly, mh.

Regarding the OpenGL performance issues I mentioned in comment 985 - it seems they actually started appearing from 125 on. I tried a few builds prior to that - 1001, 1016, 1017, 1019 (1019 being the last Windows OpenGL build I could see before 1025) - and they all performed well on ad_swampy. 1025 + 1028, the 2 Windows OpenGL builds I could see since 1019, both peform very poorly on the same map. 
Testing LAN Play 
So I'm testing LAN play at the moment!

It seems I have to connect using the connect command with IP addresses. I have tried using the 'local search' function but it doesn't seem to find the games being hosted.

I'm not an expert on LAN stuff so maybe I am missing something important? 
OMG, Thanks For This! 
Also, I wanted mirrors. You can fake reflective water, a mirror teleport, you can do a lot of cool stuff... =~) So happy now. 
@fifth - Re: LAN Play, @rail, @breezep 
1) See post #8 in this thread

Computer #1: In console: maxplayers 4; coop 1; map start
Computer #2: In console: connect lan // you're done!

2) @breezep - What are your computer specs? Like operating system, video card. I would guess that the DX8 build is a sure thing, but I would think all of them should work so this bugs me.

3) @rail - This bugs me just a little. I'll have to check and see what I changed since 1020 in the Open GL, but its not been anything deep. 
The 'dir' command seems to work fine, lists all the files inside the current game directory and its sub-folders.

The other commands you listed all seem to work fine too, though they only apply to the game directory itself, not its sub-folders (ie id1, but not id1/maps). So one can find *.pak but not *.bsp, for example. Not sure if this is as intended.

It's actually a potentially handy feature if you have a ton of maps inside a folder but can only remember a partial name for one. Quicker than scanning through the results of 'maps' command anyway. The ultimate would be a dir type command for Quaddicted files. =) 

I just wanted to see what this would look like. Almost requires darkness and a base map with bright lights. Medieval wouldn't be a fit.

I was engine-mining and this wasn't what I was after, just incidental (what I was after is rather obscure and is likely on the verge of forgotten). It's been assimilated, although the code is not exactly efficient. 
Eye Twitching 
Remember when Fitz was a "faithful to the original 1996 Quake" engine? 
I was engine-mining and this wasn't what I was after, just incidental

I would stay away from engine-mines that contain bloom. Apparently such places are known for motion-blur cave-ins, and also contain noxious quantities of chromatic aberration gas that can cause explosions of film grain and vignetting.

I hear, however, that there are mines out there with much better health and safety rules that contain copious deposits of framerate independent physics. 
New Wrapper Version

Several fixes and improvements, including:

* GL_NEAREST takes priority over anisotropic filtering.

* Off-by-1 crap with gamma != 1 in the menus is fixed.

* Performance improvements in texture loading and mipmap generation. 
No Problem With New Features 
You could always have lite and "ultra" version. 
Are all features born equally?

FitzQuake has fog, coloured light, external textures, interpolation, skyboxes; none of which were in 1996 Quake.

FitzQuake was never claimed to be "faithful to 1996".

My primary focus is fixing a lot of the rendering bugs which made glquake inferior to the software renderer. My secondary focus is adding conveniences for mappers and general users. I am also slowly adding support for new modding or mapping features such as skyboxes, fog, and colored light. 
I did make an assumption that the engine goal was to modernise while retaining the original games feel. I assume that Baker would try not add too much bloat 
Almost done integrating the latest DX9 ... 
Shadow Volumes 
I'm trying to get my head around something in the shadow volume code.

I can reproduce test cases where they do and where they don't leak through geometry.

What I need to figure out is: is this happening because the volume isn't projected far enough (only 512 units) or is it happening because the draw order is significant?

If the latter then shadow volumes may be about to become about 2 billion times more robust. 
One of my goals is acquire key features from great engines of the past ...

The authors contributions to Quake lives on ...

And the unmaintained binary form of their work can rest in peace.

There have been several dozen brilliant engine authors who have made great contributions, often adopted by other engines.

Engine developers tend to have awareness of this kind of thing.

Maybe it is extended form of developer courtesy saying thanks to them.

Perhaps similar to how the best mappers are very aware of great mapping innovators of the past. 
Mark V - Build 1029 - DX9 Only 
Build 1029 - DX9 enhancements only

mh tuning of DX9 ...

- "Crunchy pixels" gl_texturemode GL_NEAREST should just work now.
- Should resolve a PixelFormat issue in some situations (breezeep)
- Faster mipmap generation for some setups (gunter)
- vid_hardwaregamma 0 (dx9 shader gamma) scrunched pixels fix. 
I quite liked how pre-1029 dx9 builds provided smoothed console text with 'gl_texturemode linear_mipmap_linear' and gl_texture_anisotropy set to any value above 1. It ensured improved legibility. Is the loss of this smoothing simply an unavoidable consequence of ensuring gl_nearest works as expected?

1028 -
1029 - 
Looking good. Previous issues are indeed resolved (distorted text fixed, longer loading times gone).

The following issue still remains, and did not appear until DX9 1.26

borderless full-screen windowed mode (at your desktop res) only works if that mode was set before starting up (set from a previous run, or by command line) [**let me refer this this as Situation A]

Attempting to change to that mode after starting Quake (even just by toggling alt-enter twice) produces a bordered window, which obviously doesn't cover the full screen.

Ah, I see this also happens in the Windows version, but that has probably always been the case for that version, and that applies even if the setting was made before startup.

**Hm. and it looks like alt-tabbing away from Situation A is touchy.... Sometimes it seems to freeze up, and Quake never comes back (not even any menu sounds)... and I have to close it by right-clicking it in the taskbar. It doesn't happen every time I alt-tab, but it seems like about a 50% chance of it happening.

Alt-tabbing in true fullscreen works fine, as does it when using the bordered window. But alt-tabbing in Situation A seems to behave as if it's full screen -- the Quake window seems to minimize, whereas alt-tabbing from a bordered fullscreen window leaves the window behind whatever I have given focus.

THERAILMCCOY, try alt-tabbing a few times when you start up in the borderless window, just to see if this also affects you. 
@gunter - Glad to see loading times for you are fast again.

@railmccoy - In your 1028 screenshot, Mark V at least with automatic 2D scaling enabled shouldn't allow "smooth text" (I'd be a little surprised if the Open GL version behaved the same). The super-crisp text like in the 1029 screenshot is how text in Mark V is intended to be with automatic scaling.

I suspect viewport MH's fixes caused that to go away.

Although it sounds like you thought of the smooth text in your 1028 as a feature, although my intent was integer-only scaling ;-)

/If you are not using automatic 2D scaling, then the above wouldn't necessarily apply. 
/Forgot to add: source uploaded to usual folder where the download lives. Wanted to check all the builds before uploading to ensure they still compiled. 
Pre-1029 it seems to smooth text regardless of the value scr_scaleauto is set to - 0, 1 or 2.

scr_scaleauto 0 -
scr_scaleauto 1 -

All my scr_ settings are included in the above images. Also, yes, I've only seen this in dx9, it never appeared in dx8 or OpenGL. It did sort of feel like a feature, yeh, in fact I think I've seen cvars in other Quake engines for controlling the smoothness of console text.

Gunter - I can't reproduce alt-tab issues in the scenario you describe. 
@rail - yeah, I get that and I've had smooth text in other engine projects. But wasn't intended here as I hope to at some point in the future have integral scaling in the WinQuake build (but it's rather low priority, especially since Mark V WinQuake's stretch mode in video options to some extent provides a similar flexibility).

mh closed the book on that with the latest DX9 fixes in 1029. 
Latest DX9 No "{" Alphamasked Textures? 
The other flavors of Mark V are good, hope I'm not reporting something that is known or ongoing ;) 
"{" Textures On Arcane Dimensions Start Map + DX9 
Arcane Dimensions start.bsp - alpha masked vines screenshot
DX8 screenshot start.bsp, which has no combine
DX9 screenshot start.bsp

Arcane Dimensions 1.50 download link:

1) c:/quake/dx9_mark_v.exe -nocombine (perfect!)
2) c:/quake/dx9_mark_v.exe -nomtex (perfect!)

3) c:/quake/dx9_mark_v.exe (doesn't look right ...)

If I type r_fullbright 1 in the console they become proper masked textures.

Typing fog 0 or gl_overbright 0 or gl_fullbrights 0 appears to have no impact.

So it looks related to combine + multi-texture + lightmaps.

It's a very complicated case. 
I Wasn't Using AD 
Just an alphamasked test image: 
Doh :( 
Yeah -nocombine/-nomtex fixed it. 
The one thing that always annoyed me about QMB -- which has effects for many things --- the Enforcers had no laser effect.

YouTube - Laser Effect in upcoming build

Modelled a bit after AMFQuake, which is a forgotten engine. 
Alpha masked textures must have always been there in prior versions. Or at least I don't understand how the latest wrapper changes could affect it. It sounds like a combine alpha mode is not set up correctly. Combine RGB is, that would be immediately obvious.

Sharp text actually goes back to original GLQuake, and was retained in Quake II. I believe the reason is technical rather than aesthetic: adjacent characters would bleed into each other with bilerping. Nonetheless, it was a very deliberate feature of the original code. 
My gut instinct on this is that it is probably not a wrapper issue.

I'd make the assumption that it isn't a wrapper issue until there is evidence that it is a wrapper issue.

I couldn't say with any level of confidence that the engine is hitting those draw functions in the same state every time, because there is no state manager.

Nor could I say for sure that everything that should be set, is being set.

Remember in prior time when the DX8 wrapper was new and you tested it on TyrQuake and discovered there was glPopMatrix with no push in the code (or something to that effect)?

Is something like that happening here? It is possible. I always assume something "not known to be under quality control" should be assumed to not be under quality control. 
It's possible that the bug is outside the wrapper although I'm not 100% clear on that owing to the following:

* I only see comparison screnshots with DX8 which didn't have combine.

* I only fixed the wrapper bug where combine wasn't reported for PS2.0 hardware quite recently.

So I consider there being some likelihood that it is in the wrapper. If -nocombine fixes it and if it's related to alpha masking, then alpha combine modes seem a possible first port of call to me.

Does anybody have a good test map for these? Preferably something that doesn't require BSP2 or a custom progs? 
Here is a bsp that'll load in Fitz 0.85 without a progs.

You'll have to noclip up the vines.

I played around with the function in Mark V's gl_world.c:R_DrawBrushModel_DrawSequentialPoly ... if (gl_overbright.value)
if (renderer.gl_texture_env_combine && renderer.gl_mtexable) section ...

And made a number of attempts to explicitly set everything and it looks like somehow D3D isn't honoring the GL_ALPHA_TEST on first texture in the combine. 
somehow D3D isn't honoring the GL_ALPHA_TEST on first texture in the combine

This is what I suspect, yes.

The combine mode should be passing through the alpha channel from the diffuse texture to output, ignoring the alpha channel of everything else. It looks as though it's configured to not do so. Perhaps passing through alpha from the lightmap texture instead, although without a closer examination of the code it's only speculation. 
tmustate_t doesn't look like its initialising the combine_alpha.
which means that tmu0 == disabled, instead of selectarg1(texture)

you can probably fix it by overwriting its non-defaults with the following in the engine:

the proper fix is of course in the wrapper. 
And Now It Works! 
After doing what Spike said about setting GL_SOURCE0_ALPHA_ARB and GL_SOURCE1_ALPHA_ARB 
Correction ... 
I built the Open GL build on accident. Yeah, the wrapper isn't aware of those constants. 
Low-end Friendlier? 
Quakespasm in AD 1.5 randomly changes my average fps between 10 and 30 when doing nothing at ad_start. Will this solve such problems?

Specs: Underclocked Celeron N2806 with Bay-Trail iGPU. Aero disabled in W7.

Maybe I should whine in QS related threads instead. 
Will this solve such problems?
Download dx9 build 1029 and find out.

Only way to know. 
I suspect that QuakeSpasm will run faster for a number of reasons.

Story from ancient history.

One of the reasons why I moved to D3D9 originally was that I was fed up of poor Intel driver quality (the other reason was to stop people behaving as though they had a god-given right to demand Linux builds but that's another story).

The thing I found however was that, if you write your OpenGL code in a similar style, you'll actually get the same end result. Faster, more stable prformance.

The trouble with Intel drivers was actually programs doing horrible things that NV and AMD were more robust with. But the things that programs did were still horrible: writing to the front buffer, GL_RGB texture formats, lots of tiny lightmap updates.

QuakeSpasm has picked up lots of my old code (or code similar to it) that actually resolves many Intel problems. Example: QuakeSpasm draws directly from vertex buffers whereas MarkV via the D3D9 wrapper needs to shuffle data around in memory and mangle it from glBegin/glEnd calls to something D3D9 can use. That's a lot of extra overhead that QuakeSpasm just doesn't have.

Intel Bay-Trail is a DX11-class iGPU and QuakeSpasm is capable of taking advantage of newer API features to run faster and more stable (it's a complete fallacy that older API features are more low-end friendly). MarkV doesn't even try.

For sure download it and try it though. 
I'll have to dig into this one, but if I press the Windows key + D (show desktop), DX9 does an error ResetDevice::failed.

A bit odd since minimizing the window by clicking minimize doesn't have a similar issue. 
I'll have to dig into this one, but if I press the Windows key + D (show desktop), DX9 does an error ResetDevice::failed

Windows-D seems to have different behaviour to minimizing. Specifically, Windows-D sets the window client rect to 0/0/0/0 so it looks as though device reset is failing by trying to create a 0-dimension back buffer.

You can add code to check for attempted mode changes to 0 width or 0 height and just not change the mode if detected; that should do it. 
Just stepping through a frame in PIX to determine states/etc when drawing a '{' texture, and came across something fairly astonishing.

About 80% of the Direct3D calls in a frame are spent on sky.

It's clear what's happening here: the FitzQuake code is changeing state after each quad used in the sky render, so D3D is unable to batch.

I'm going to rewrite this a little to be significantly more efficient and it should hopefully be easy enough to pick up in MarkV.

Meantime back to PIX traces for '{' textures.... 
'{' Textures, Problem 1 
You may already have this fixed, but I'm finding it useful to step through the calls made and textures used and get a full picture of exactly what's going on.

It's also good to have a record of problems hit and bugs fixed along the way.

FitzQuake is incorrectly identifying palette index 255 as fullbright.

This needs fixing in two places: first in the check for fullbright texels (add a continue if we find index 255), second in the actual palette building (revert index 255 to being alpha rather than solid black in both the fullbright and nobrights palettes).

The first fix will get the general case of most '{' textures. The second fix is needed for '{' textures with fullbright texels. 
Quakespasm in AD 1.5 randomly changes my average fps between 10 and 30 when doing nothing at ad_start. Will this solve such problems?

This must be lightmap uploads. If I turn on "r_speeds 1", every 5-10 frames there are 5 lightmaps updated from the flickering torches. However, when a lava ball pops up, that causes 5-10 lightmap uploads every frame.

QS is using GL_RGBA / GL_UNSIGNED_BYTE for lightmap uploads, iirc MH reported that BGRA and/or the unsigned int 8888 format are needed for faster uploads on some GL drivers. (our batching of uploads is also slightly weird... QS does all uploads for the world, then draws it, then for each bmodel it does the lightmap uploads, then draws the surfaces)

let's continue in the QS thread, if you don't mind trying a test build or two we can probably improve it.

Btw how does MarkV GL perform for you? 
Alpha mask textures are now fixed.

It turns out that D3D texture stage state defaults (which I was setting) are slightly different to GL combine mode defaults (which I wasn't). A bunch of glGetTexEnv calls in a GL engine and I had the correct defaults, then set them up, and everything works.

I'm going to wait a day or so before doing a code-drop in case anything else comes up. 
@mh - Re: Sky 
Yeah, the sky is slow. ;-) I know. I know that you wrote several sky speed up tutorials in the past (Z-fail skys, etc, etc.) . ;-)

Also frames per second is funny topic.

Quakespasm gets a large speed boost from using vertex arrays. In highly complex scenes, it gets a lot more frames per second. With gamma 1 and contrast 1.

Then cashes in much of the gains via shader gamma (33% fps loss sometimes) that gets more expensive the higher the screen resolution

Somewhere in a thread, ericw and I once discussed this topic and I raised the theoretical idea of real-time changeable texture gamma.

Which of course is now a Mark V feature, one that gunter thinks looks better than hardware gamma or shader gamma.

So what on the surfaces looks like apples and apples, is more like apples and oranges ;-)

It's not a straight road, but more of a curvy road.

And engine coding is mostly about pioneering new ideas and having fun.

Any code that I write, I hope someone takes that and uses it --- qbism added automatic underwater transparency from Mark V last year, for instance, I told him how it worked and where to look.

I coded the texture gamma system in Mark V to see what it would look like, after the insideqc discussion ericw started and also see if it could be done. 
However, when a lava ball pops up, that causes 5-10 lightmap uploads every frame.

I love you how you worded that ;-)

Lavaball shows up, ruins the day. 
FitzQuake is incorrectly identifying palette index 255 as fullbright

Keep in mind that color 255 is standard Quake is, in fact, a fullbright color.

The Kurok engine that I once used to enjoy playing around with forced 255 to transparent full-time.

And when playing standard Quake with that Kurok engine --- would notice maps and mods that actually used color 255 in textures.

Particular if you hit up conversions ...

At the time, that discovery was a real kill-joy for me. Because I loved alpha masked textures and the Kurok's simple treatment of all 255 is transparent was easy as newbie engine developer to work with ...

So let's just say I was disappointed when I found actual maps and mods using color 255 on purpose. 
Hm, I was just comparing FPS in various builds....

I found I am getting significantly better FPS in DX8MV than in DX9MV, which I think is mainly because my FPS drops significantly when I use gamma or contrast, and this affects DX9MV much worse than DX8MV.

And it looks like DX8 1.28 really improved my FPS by like 15-20 points over the previous DX8 1.25 release (and earlier builds)... although the txgamma looks darker/uglier/washed-out starting at 1.28

Just standing in the start map facing forward, 800x600 window, and vid_hardwaregamma 0, mirrors off (and freezeall to prevent lava balls from affecting it):

DX8 1.25
no contrast adjustment = 74 FPS
with contrast adjustment = 70 FPS
turn and face wall, no contrast = 125 FPS
facing wall, contrast applied = 114 FPS

DX8 1.28
no contrast adjustment = 91 FPS
with contrast adjustment = 86 FPS
turn and face wall, no contrast = 142 FPS
facing wall, contrast applied = 130 FPS

DX9 1.28
no contrast adjustment = 90 FPS
with contrast or gamma adjustment = 55 FPS
turn & face wall, no contrast/gamma = 150 FPS
facing wall, contrast/gamma applied = 100 FPS

So, yeah.... With the previous DX8 build I could just use txgamma and even a little contrast and the FPS would be decent.

In the new DX8 1.28, the txgamma just doesn't look good, but darn, the FPS is better! What did you do, Baker?

In DX9, I must use gamma so I get the bad FPS hit.

Oh, I guess I do have another option: I can use vid_hardwaregamma 1 and then my FPS is no longer affected by adjustments..... But my desktop is.

In that case I get pretty much the same performance with DX8 and DX9, though DX9 does 8-10 FPS better when I'm facing a wall, heh. 
Eventually DX9 will have texture gamma.

I would conduct the DX8 vs. DX9 speed comparisons using vid_hardwaregamma 1.

Otherwise, you are throwing an unfair speed penalty on the DX9, because shader gamma isn't free. 
Also, the start map isn't a good choice of maps.

DX9 supports mirrors. DX8 doesn't.

The mirror draw is expensive, haha ;-) 
I also have a lot of I's to dot and T's to cross.

I'll check out whatever I did in DX8 1.28 that affected txgamma appearance. 
@gunter - DX9 1029 build is current one. MH did a lot of fixes based on your comments. 
"The one thing that always annoyed me about QMB -- which has effects for many things --- the Enforcers had no laser effect.
Ya I added an effect to the enforcers and those laser, though I like the little lines around the effect of AMFQuake...

btw speaking on QMB effects Ralf and I added the lightning effect which JoeQuake added later, just the image/splash not the cl_true_lightning.
(i cant remember Ralf's Quake name hmm).. 
Mark V - Build 1030 - Bloom, Lasers, DX9 Alpha Textures 
Mark V - 1030 Beta Build

- QMB Enforcer Laser when QMB is enabled Lasers video
- Bloom option in only Open GL build (r_bloom 1) Bloom Video
- DX9 alpha masked textures temp workaround until mh patch

r_bloom 1 doesn't save to config. I view bloom as a bit of novelty.

It is also a performance killer and I think the code is probably inefficient -- but since its a toy around feature that's ok.

Tonight, might see if I can resolve some of the issues others have noted and maybe get out a 1031 build. And if mh has a patch tomorrow, do that.

Then comes an extended break with the hopes that will be able to do more updates in the spring some time. 
Ah, I had no idea you did that in Qrack.

Do you have a link to your current source code? I'd like to compare notes.

The lack of a laser effect always ticked me off about QMB, haha.

But until very recently, didn't have an engine with QMB available, so never thought about it. 
Re-reading ... I didn't know you created the lightning gun sparks in JoeQuake either. But it doesn't surprise me at all considering effects ideas is "your thing" and you like experimenting with those ideas, like how fast rendering is "MH's thing". 
New Wrapper Version

Then comes an extended break with the hopes that will be able to do more updates in the spring some time.

I guess a code drop is in order then.

This one includes:

* Alpha mask texture fix.
* Sky polygon batcher.
* Guards against 0-dimension video modes. 
@baker Latest Qrack Stable Release 
if you compare jq0.13dev to any qrack you'll see what's diff, that was the base i started on; and the first file I focused on was gl_rpart.c ;) 
Random Notes 
1) MH's revised sky draw is a pretty decent speed boost for the scrolling sky.

2) I needed to know whether or not MH was right about color 255 not supposed to be fullbright.

Original WinQuake color 255

In the above screenshot, notice I took care to stand next to a wall with lighting.

The brownish color on the walls is color 255, which is surrounded by fullbright white (color 254) and the black area is non-fullbright red (color 79).

Color 255 isn't generally a very useful color. It is rarely used.

But in WinQuake it is acting as a fullbright color. 
Index 255 
I haven't checked but I have a good degree of confidence that the colormap has it as a column of 255. So from the perspective of the colormap it is fullbright and I'm probably wrong.

Where things get tricky is how you interpret index 255 because '{' textures should be able to have fullbrights on them too, and 255 cannot be both fullbright and alpha in a '{' texture.

It's also the case that in all of ID1 no BSP texture uses index 255 (I checked).

There's also this in the colormap generation code in qlumpy (

note: 254 instead of 255 because 255 is the transparent color, and we don't want anything remapping to that

So I can say with a good degree of confidence that even though 255 is represented as fullbright in the colormap, it is not intended to be actually used for anything other than transparent. 
Where things get tricky is how you interpret index 255 because '{' textures should be able to have fullbrights on them too, and 255 cannot be both fullbright and alpha in a '{' texture.

I think it has to be transparent, otherwise fence textures would cease to exist as a feature. Since it's transparent, it should not be added to the fullbright mask. And alphaedgefix should be used to fill it in with neighboring colors.

On non-fence textures, it should be fullbright since that is how it works in all versions of the game (software and accelerated) that support fullbrights. 
Windows + D (show Desktop Key) Vs. Minimized 
@mh - It disturbed me that such a behavior difference occured.

I wanted to know exactly why Windows + D caused a problem. Here is the reason.

Dumping system messages:

WM_WINDOWPOSCHANGING wparam: 0 lparam 18fab0
WM_GETMINMAXINFO wparam: 0 lparam 18f7b0
WM_NCCALCSIZE wparam: 1 lparam 18fa88
(Windows + D show desktop, Quake will run a frame here because the message queue is empty -- we have not received a WM_SIZE message yet so we don't know we are minimized.)
WM_NCPAINT wparam: 1 lparam 0
WM_GETTEXT wparam: 1fe lparam 18e580
WM_ERASEBKGND wparam: 5011197 lparam 0
WM_WINDOWPOSCHANGED wparam: 0 lparam 18f890
WM_MOVE wparam: 0 lparam 99016b
WM_SIZE wparam: 0 lparam 1e00280

(Minimized runs frame here, we received WM_SIZE already so we are ok!) 
Mark V - Beta Build 1031 
Beta Build 1031

1- Correct alpha masked texture support in DX9

2- MH faster scrolling sky rendering (DX9, DX8 and Open GL)

2- Resolves a DX9 + "Windows key + D (show desktop)" issue.

Should have one more build later. 
Gamma Musings 
Just been doing some testing comparing texture gamma ("txgamma") to shader gamma (which will have the same result, if not the same perf, as full-screen desktop gamma, which I didn't test).

Visually they're not identical. This should have been obvious, but wasn't, at least to me.

With texture gamma the calculation is pow (texture, gamma) * lightmap

With shader gamma the calculation is pow (texture * lightmap, gamma)

Shader gamma feels more "right" because it applies gamma as a post-process after the entire scene is composited.

You can't deny the performance of texture gamma, and it does give a richer look which can be more visually appealing.

To make texture gamma give the same result as shader gamma, you should also gamma-adjust the lightmaps. pow (texture, gamma) * pow (lightmap, gamma) because exponents are distributive over multiplication. 
Thanks for the calculation comparison analysis.

Yeah, texture gamma and shader gamma have differences. You'll notice Gunter perspective that the polyblends look better with texture gamma. Meanwhile, I wonder about transparent brushes/models which is a "double application" scenario with texture gamma.

Ironically, with texture gamma, I had to modify the FitzQuake texture manager to be aware of textures intended for blending and exclude them from texture gamma (example: the optional QMB particles are blended) to avoid "double application" (although I doubt the final color is technically "gamma-correct" according to the calc). 
Frames Per Second 
I'm not all that caught up in this topic.

I think frames per second is important, but I also think fps above 72 in single player is a bit superfluous. Because Quake physics acts up around 250 or 300 fps (killer lifts, missed triggers on maps like E3M2. 144 fps ... which matters because some monitors, hopefully isn't too bad.

Anyway, like I said, I'm not caught up in this ...

Here is Mark V DX9 and Quakespasm (Mark V Open GL would lose substantially). Quakespasm is set to gamma 1 and contrast 1 to keep shader gamma out of the equation.

But we'll have mirrors on in DX9 just too give DX9 some extra work to do ...

For fun, here is Mark V DX9 and FTE. DX9 Mark V is using external textures.

Spike's FTE is probably the fps champion of all Open GL engines.

MH's DirectQ? Yeah, DirectQ smokes all of the above in a curb stomp which not even close.

My Win 7 laptop has rather modest specs, anyone with an actual "good" graphics card is going to see way higher fps than above.

Anyway, anything above 72 or arguably 144 fps in single player Quake isn't too useful anyway. 
Has anyone ever tried to disconnect the rendering from game logic in Quake? I feel like that'd be a nice thing to have, then we'd be able to run at any FPS we liked and avoid the bugs mentioned above.

I also feel like it would be a giant pain in the ass to figure out and actually implement... 
DarkPlaces has it.

DirectQ had it with a tiny inconsistency that someone picky like me or Gunter would notice, otherwise I almost acquired it from DirectQ and inside Mark V is a partial implementation of retaining some of the improvements from the attempt (more consistent clock timers).

All modern Quakeworld engines have it.

FTE has it on steroids.

At some point will happen in Mark V. 
I know that unborked physics at higher fps in on the wishlist for a bunch of speedrunners. 
Mark V - Beta Build 1032 - Windows / Linux / Direct X 9 
Mark V 1032 Beta - Windows, Linux, DX9, DX8, Open GL, WinQuake

Source Code

Features Vs. Mark V 1.2

- Very fast "triple the fps" DirectX 9 build courtesy of MH
- WinQuake looking water warp in Open GL/DX9 (MH again)
- Volumetric shadows - r_shadows 3 (MH again)
- Sky speed up in Open GL/DX8/DX9 (Yeah, MH)

- Linux Open GL build (thanks to JimBob for testing, Spike for debug tips)
- Linux WinQuake build

- Resize on-the-fly windowed mode in all builds (except DX8). Yes, even Linux. Tried to make the Linux build fancy. May have succeeded.

- QMB enforcer lasers available video

- Improved performance on NVidia cards
- 2 Extra options in video menu for convenience.

- Other things, no doubt. But what were they? Scroll back in the thread ;-)

Hopefully resolved the remaining significant issues, like dwere's context creation failure message. Attempted to add texture gamma to DX9 and then ended up with a blank screen and plenty of wasted time, killing the opportunity to add true rotation and even get the Mac build running. :(

Engine coding sucks like that sometimes, but I won't pretend to not be irritated about missing a few items I very much wanted to get done.

/All feedback and any issues reported do get read.

Next update is likely in the spring. 
In DX9 only, models with fullbright pixels still can't handle transparency (like an illusionary player model, or the gun view models except axe). gl_fullbrights 0 makes them transparent again.

Hm, there is still a big difference in the water warp effect in the Winquake version as compared to DX & GL. The Windows one just doesn't warp as much, and is less noticeable. 
Waterwarp - Win Vs DX/GL 
Software Quake waterwarp is resolution-dependent. Run it at 320x200 and you'll see a very different effect to if you run it at higher res.

The waterwarp code I wrote is resolution-independent.

IMO the software Quake behaviour is undesirable.

More discussion, test cases, etc here:

You'll notice that my warp code reverses the X-axis direction but is otherwise good. That's something I intend to fix some day (the X-axis bit, not the otherwise good bit). 
Ah, I see. I agree about the undesirable part. 
1032 On OpenSUSE W/ KDE 
Binaries still work on KDE without need for re-compilation.

The laser effect is neato -- kinda like they're being squeezed out of the gun. Would make for a decent "shooting star" effect. Might be nice if they could be toggled off for the player (like the FVF Laser Android class), while still being enabled for the enforcer. But not a big deal *shrug*

Winquake crashes (seg. fault) when I try to drag-expand the window too much. Appears it may be trying to snap to fullscreen (like a snap-to-edge behavior). That doesn't bother me, though, cos I likely won't be using Winquake, and that's an easy situation to avoid anyhow. Otherwise runs fine.

Anyhow, please ignore that until the spring. And thanks again for bringing Mark V to Linux. I will enjoy playing Quake with it in the meantime :) 
I had the same reaction as Gunter that the GL waterwarp effect has a surprisingly strong distortion. I guess I was used to running WinQuake at a non-minimum resolution back in the day.

It's not a big deal, but out of curiosity: how feasible is it to expose "warp amount" as a console variable? 
how feasible is it to expose "warp amount" as a console variable?

There are a few hard-coded numbers in it and I even have a comment on one of them: "tune it or cvarize it all you wish".

I'm actually working over this code at present fixing up a few issues with it, but I don't feel that I'll be the one adding cvars: it's really up to Baker, how or even if he wishes to expose this. 
Hm, yeah, the FvF Laser Android uses the same laser-firing function as enforcers do, but apples various flashing colored skins to the laser projectile.

The QMB effect now has every Android laser shot look just like the enforcer's laser.

And it really hits my FPS when firing the Super Spread Laser (8 simultaneous laser shots, heh).

It's too bad the effect color can't be made to match the laser skin color....
I suppose a quick hack (which I'm not at all sure how it would end up looking, since the Laser Android does use the standard laser color too) might be to only apply the QMB effect if the laser projectile is using its default skin 0.

Or I suppose have the effect only apply if launched by an enforcer, as JimBob suggested.

Though I always thought the laser android could use some kind of QMB-type effects too (when such things are enabled).... 
OK, I'm pretty much done working over the code. It's a shame I didn't get this in time for Baker's release, so you're just going to have to be patient until his time frees up again.

Picked up the latest vkQuake code adjusting the water warp for screen aspect. Yes, my water warp code was based off vkQuake.

Made it as close to consistent as I can get with Mankrip's tests at

Mankrip has criticised the vkQuake code before, but I think he's being unfair. vkQuake is actually 99% there; the only things it needs are a sign-flip ("(x - (sin (y" instead of "(x + (sin (y", likewise for y/x) and a tweak to the value of AMP (2/300 instead of 1/300).

This is not based on any rigorous code analysis, just tweaking values until it looks right, but it's close enough for me.



There's a bug where if you change resolution when underwater, water textures get turned to binary garbage. Don't bother reporting it - I'm aware of it. 
Oh my.... The Ninja also uses the laser model (skinned) for his throwing darts, heh... and now they look like laser effects in QMB. 
Mankrips Looks Better 
for some reason waterwarp in both opengl and directx seems to be down-ressed? is that correct? 
Yes, I downscaled it.

This is essentially the same kind of problem and same kind of tradeoff as we have with shader gamma. Because it needs to run as a post-process it's slower, so I downscaled it to compensate.

It's a no-win situation because if I didn't downscale it people would complain that it was slow.

My expectation is that cvars could be provided to tune the size, so that you could select downscaling or not, based on your own preferred tradeoffs (and hardware capabilities). But that's not my decision. 
Would Be Interesting To See What The Hit Is 
on my gtx 970 
Just kind of a note, anything that MH wants to do will end up being added to the engine when new builds happen again.

@gunter - if I would have known about the fullbright pixels + alpha, I could have coded a temp workaround.

Spring will be here before you know it. Time flies. 
@Baker: twas reported above in #977 and verified by you in #978 ;)

I might have mentioned it again, but I was waiting to see if it would be resolved along with other transparency issues that were being worked on.

It's not a big deal in any case.

I would request that you make the most recent zip package available on the site at since that's where I always send people to download it. The link here will quickly get lost in the posts on this page.... I know it's "beta" but it's still the best version so far, containing numerous fixes.... I also like having all the platform versions in one zip file. 
Ok, I see you did link to here at the top of the page on ... though the link doesn't take me directly to the post to download it. A direct link to the zip file would be convenient. 
MDLs Transparent To Sky Edges In GL? 
Is it me, or are monsters sort of transparent to the sky?

Like if I look up through a monster at a sky brush, I can see the edges where the architecture meets the sky.

Not sure if I have some setting enabled to make this happen. 
Hopefully resolved the remaining significant issues, like dwere's context creation failure message.

The message is still there, I'm afraid. 
Verified: you can see the sky (kind of) through monsters, starting DX9 1.28

You can also see shadows through monsters, if r_shadows 3 
@dwere ... Grrr. That's going to annoy the hell out of me for a couple of months. Sorry :(

@gunter ... I did an update to the page including the installer.

I am sort of mixed on doing that considering that dwere, as an example, has an issue and I'm a compatibility hawk and that's like a having a thorn in my boot.

On the other hand, the current build solves compatibility issues on the other side of the spectrum (killpixel, johnny law, pulsar's machine presumably).

/Grumpy cat face!

I'll read the comments every once in a while, all feedback gets read, this Func_Msgboard is awesome in how the layout is conducive to that. 
I suspect you're actually using an older build.

In all of this I'm assuming that you're using DX9. In the most recent code I provided a replacement ChoosePixelFormat that never fails. I need to cross-check the MarkV integration of course, but it seems you're describing something impossible. 
Shadows through monsters with r_shadows 3 is a known issue, that's part of what I meant when I said "it's not robust" and "shadows leak through geometry".

If it can be fixed it will. If it can't be fixed you'll have to take it in the spirit of Carmack's original comment on GLQuake's novelty features: "not very robust but cool to look at". 
Let me know if these work and/or what happens. (Open GL, WinQuake version).

If it solves your problem, I'll have a lot more piece of mind.

Let me know! 
He was using mark_v.exe --- the Open GL.

In the above 1033 dwere test, I did 2 things:
1) I requested a 32 bit Z-buffer and an 8-bit stencil to mirror what Mark V 1.20 did. In later versions, I changed to Z-buffer request to 24-bit with 8-bit stencil.

2) Mark V Open GL will route around an opengl32.dll living the Quake folder, largely to avoid the crappy one and the fact that a opengl32.dll in the Quake folder is almost always some 1997 relic.

If that is what is going, the dwere build will do a messagebox saying that's what's up. 
Interesting screenshot. 
Hm. it gets more interesting....

If r_shadows 3, then you can no longer see the sky through monsters. But that's when you can see shadows through monsters. It's not just shadows leaking through anything -- you can see the shadows through the monsters at a distance, in a very similar way as you can see the sky through the monsters when not using r_shadows 3....

I would suspect a relation, since both these issues appear starting in DX9 1.28, when the new shadows were added.... 
Yeah. Really I think it's more like the sky is shading the monster, rather than the monster actually being transparent to the sky. Er. It's confusing. 
Shadows & sky is an understood problem.

Both have weird interactions with the depth/stencil buffer, and are therefore interacting with each other.

Fixing individual problems as they occur is not going to solve this, so everybody - please stop reporting bugs with it.

I know what the solution actually is, and it involves decoupling the shadow pass from the MDL passes so that the former can be done in isolation and without affecting other stuff, then figuring out the correct draw order placing for it (which will be one of two options).

If you look upthread you'll see that I already said this, but in a bit less detail.

Right now giving me the head space to actually do this is a lot more helpful than piling on the bug reports. 
Let me know if these work and/or what happens.

The same message appears, sorry.

mark_v_winquake.exe works, but it always worked, unlike mark_v_winquake_gl.exe. 
Delete You Config Files 
Always start afresh 
@dwere what about the normal mark_v.exe? Does that work ok?

The mark_v_winquake_gl.exe is a discontinued experimental build, it's just like the mark_v_winquake.exe except it uses Open GL to put it on the screen. 
Interesting thing (maybe?) about build 1032.

Occasionally I use a Windows 10 VM on my Macbook to check out Windows things. I've run past mark_v.exe versions in there without problems. This one though fails to run, as does dx9_mark_v.exe. dx8_mark_v.exe and mark_v_winquake.exe work fine.

This doesn't matter much to me since I don't actually play Quake on this VM, but maybe it's an indicator of something you might want to know about. So, FYI:

mark_v.exe fails with this dialog:

Quake Error
Could not initialize GL (wglCreateContext failed).

Make sure you in are 65535 color mode, and try running -window.

(I did try using "-window" for the heck of it; same error.)

dx9_mark_v.exe fails with this dialog:

Quake Error
R_LoadD3DX : failed to load D3DX
Please update your installation of DirectX...

This is a VMware Fusion VM, and in the Display settings under the "Accelerate 3D Graphics" switch (which is on) the description of that option says "Supports DirectX 9.0EX with Aero and OpenGL 2.1". Perhaps the wglCreateContext invocation in mark_v.exe has been changed to require something unsupported in OpenGL 2.1, and dx9_mark_v.exe is requiring something beyond DirectX 9.0EX?

(It looks like if I were to spring for an upgrade to the latest Fusion version I could get better graphics API support, like DirectX 10 and OpenGL 3... hmm.) 
No More Opengl Winquake? 
@dwere what about the normal mark_v.exe? Does that work ok?

I was talking about mark_v.exe when I said that the message still appears, so no. 
Oh hey I guess the wglCreateContext part of my post is the same thing that dwere was reporting. FWIW, the "dwere build" 1033 behaves the same way as 1032 in my VM. 
The DX9 build requires the latest DirectX runtime installed. There are components of DX9 that were added in subsequent releases but which are not included in DX10+ on a fresh Windows install. This can be safely installed without affecting DX10+.

For OpenGL startup problems I suggest grabbing the OpenGL Extensions Viewer from Realtech VR. This is a great way of verifying your OpenGL driver.

Down the left-hand side of the Viewer you'll see a list of links, with the top one ("Summary") selected.

Please report what it says for "System Info | Renderer" and "OpenGL | Version".

Third one down is "Display modes & pixel formats".

Unfortunately they don't provide a way to search or filter these, but look for pixel formats with WGL_ACCELERATION_ARB set to FULL_ACCELERATION, WGL_COLOR_BITS_ARB 24 or 32, WGL_DEPTH_BITS_ARB 24 or 32, WGL_SUPPORT_OPENGL_ARB True and WGL_DOUBLEBUFFER_ARB True. 
@dwere Or @johhny 
Can either of you post a qconsole.log where the error occurs? Mark V automatically does a qconsole.log. I'm trying to walk through all the small differences between 1020 and 1025 builds. 
Yup, will try/report various things later today. 
OpenGL Extensions Viewer quits silently in the middle of loading extensions.

Maybe my system just sucks - I had to "temporarily" install a shady Win 7 distro with some features disabled. The list of disabled features looked innocent, but I had some video driver installation problems. In the end, I just reinstalled everything with a driver that I knew worked fine, and left it at that.

All 3D games I tried so far worked fine, including Quake source ports (Quakespasm and mark_v.exe dated 2016/12/03).

I tried to reboot from an old HDD with Vista installed, and the latest mark_v.exe started without any problems. But I have different drivers there.

Can either of you post a qconsole.log where the error occurs?

Command line: [ ]
Log file: D:/Games/Quake/id1/qconsole.log
Fri Jan 20 00:02:40 2017
Mark V Windows (Build: 1033)
Exe: mark_v.exe (1327 kb)
Exe: 00:44:32 Jan 19 2017
Caches: C:/Users/User/AppData/Roaming/Mark V/caches
UDP4 Initialized: INADDR_ANY,
IPv6 Initialized: [fe80:0:0:0:9459:106d:2bee:97d8%12]
Exe: 00:44:04 Jan 19 2017
256.0 megabyte heap 
Maybe my system just sucks

If an earlier Mark V worked, I'm not going to be happy until this one works.

I did install DirectX June 10 SDK, which may have changed some libraries.

Need to meditate on this a bit. 
Fitz 0.85 works fine on my XP VM but MarkV fails with the same error.

It's XP on a Windows 10 host, but I believe the core guts of the driver are the same: VMWare Tools provided Mesa/Gallium driver.

I have a full development environment on this VM so I'll have the fix identified soon! 
Another thing going on here, you also have the problem with winquake_gl -- which doesn't even use Visual Studio to compile, it uses CodeBlocks/gcc/mingw and winquake_gl is an SDL build, so it uses SDL functions to set the pixel format and create the opengl context. 
Reporting Back: 
The DX9 version works after installing that runtime package.

In the OpenGL Extensions Viewer:

- "System Info | Renderer" is "Gallium 0.4 on SVGA3D; build: RELEASE"

- "OpenGL | Version" is "2.1 Mesa 8"

- In the pixel formats, WGL_DOUBLEBUFFER_ARB is sometimes False, for some values of number in the spinner there (don't know what that number is). For 7-12 it's True, for 19-24 it's True, stopped looking at that point. For some of those, color bits or depth bits are 16, but others match all the desired values you mentioned.

Let me know if there's other digging around I should do in the extension viewer. I copied the text from the Report pane to

qconsole.log from trying to run mark_v.exe:

Command line: [ ]
Log file: C:/Users/joel/Desktop/Quake/id1/qconsole.log
Thu Jan 19 13:16:05 2017
Mark V Windows (Build: 1032)
Exe: mark_v.exe (1327 kb)
Exe: 10:00:00 Jan 18 2017
Caches: C:/Users/joel/AppData/Roaming/Mark V/caches
UDP4 Initialized: INADDR_ANY,
IPv6 Initialized: [fe80:0:0:0:a48d:1a8a:5eb0:7e8b%8]
Exe: 09:59:32 Jan 18 2017
256.0 megabyte heap 
Fucking awesome!!

Yeah, since I can't experience the problem firsthand, I'm not able to get my hands dirty as I would like. 
qconsole.log from build 1033 is the same except for obvious differences in build number. 
An obscure change is that current Mark V uses /J compiler option - make char be unsigned char.

Wanted to mention that, although I do not believe this relates to the issue. 
Another small change is that Mark V uses /DELAYLOAD:opengl32.dll

I can't see how that would relate to this, but anything is possible with something odd like this. 
It's because you're delay-loading.

See!topic/ for a prior example; wglCreateContext fails with error 2000 which is exactly the same as MarkV does.

The quick 'n' dirty fix I did was to pop in this little line of code before setting up the pixel format:

GetProcAddress (LoadLibrary ("opengl32.dll"), "glBegin");

You'll probably want to #define it for the GL build, but that forces opengl32.dll to be loaded and then everything works. 
Thanks MH!

Where did you insert that line in your test? 
@dwere, @johnny - Build 1034 Comng Up 
Let me know if it works! 
@dwere, @johhny 
Build 1034 with DelayLoad fix.

Let me know! Thanks! 
I put it just before the call to WIN_SetupPixelFormat in VID_Local_SetMode, but you could put it earlier if you wish.

I assume that you're delay-loading so that you can test for the 3DFX opengl32.dll? Maybe immediately after your test would be a good place.

Do you need a new wrapper code drop for 1034 or would integration delay you at this point in time? 
If you have a new wrapper drops, let's get that in there. 
1034 Works On My VM 
Beer for Baker! 
I'm rather relieved that this obscure problem is resolved.

I hate it when I can't experience an issue. And this one ranked up there in the obscurity department. Fucking delayload.

Beer for MH! 
New Wrapper Drop

It's just the underwater warp stuff so no sweat if you can't get it in. 
I'll be integrating it here in a few minutes. Probably within an hour I'll post 1035. Need to update a zips, installer, etc.

This issue being resolved gives me great peace of mind! 
1034 Works For Me Too 
@dwere, @fifth 
@dwere - Awesome!

@fifth - Is there is any particular reason you want the WinQuake GL build? The pure WinQuake performs better. 
1034 works for me. 
beer for MH and Baker ++ 
Pure Winquake Performs Better? 
I dont think it did when I checked it last, weird...

You dont need to support it on my behalf tbh, I'm not likely to use it anyway 
I forced 640x480 stretch in WinQuake GL for higher fps than it would have had otherwise to somewhat compensate.

Still killpixel said every once in a rare while that it would stutter a little. 
one thing i have noticed recently on almost all Quake engines, is if I specify a full-screen resolution that is not the monitors native (1920x1080) there is a black border around the screen. So it looks like a 640x480 window ontop of completely black desktop. At first I thought it was a Qrack issue, but MarkV does this too. So i think it's an nVidia/Windows 10 thingy. My windows xp machine doesnt have this effect.

Any ideas? 
almost all Quake engines

Which ones don't have the issue? 
Figured It Out

its a setting in the control panel now, why they changed the default behavior i have no idea... :S 
Mark V - Release 1.35 - Windows / Linux (Stable!) 
Download at normal location:

The Mac build remains version 1.20.

New Features vs. Mark V 1.20

- Very fast "triple the fps" DirectX 9 build courtesy of MH
- WinQuake looking water warp in Open GL/DX9 (MH again)
- Volumetric shadows - r_shadows 3 (MH again)
- Sky speed up in Open GL/DX8/DX9 (Yeah, MH)

- Linux Open GL build (thanks to JimBob for testing, Spike for debug tips)
- Linux WinQuake build

- Resize on-the-fly windowed mode in all builds (except DX8). Yes, even Linux. Tried to make the Linux build fancy. May have succeeded.

- QMB enforcer lasers available video

- Improved NVidia cards experience (killpixel, Kinn, johnny law, pulsar)
- 2 Extra options in video menu for convenience.

- Automatically bypasses's ancient opengl32.dll (Syrion)
- Warpspasm correct startdemos by overriding Quoth 2.2 (path0gen)
- MH solved context creation issue in version 1.25 (dwere, breezep, ...)
- MH added extra control over r_waterwarp in 1.35. Type "find r_waterwarp" in console for details.

Next update hopefully some time in the spring! All feedback, comments, etc eventually get considered, a nice thing about the Func_Msgboard layout. 
Should have noted Gunter, railmccoy did a lot of testing of DX9. Maybe others. I've been updating page, installers, .zips, etc -- if missed someone who helped beta test it sure wasn't on purpose. 
Instant crash when attempting to launch any form of 1035. dx8,9 and good ole mark_v.

Apologies if I missed something in this bustling thread regarding this.

You two deserve many beers. 
More Beta Tester Credits 
Other reporting issues or feedback during latest development spree:

Fifth, Damage Inc, mugwump, nightfright, pritchard, adib (hope I didn't miss anyone, had to glance through hundreds of posts).

@damage - Sorry, if I couldn't implement true rotation. Ran out of time. Will have to hit that up next development period (likely the spring). You can always use the RMQ engine or presumably DarkPlaces or FTE for such experiments in the mean time. 
Can you add -developer to the command line and then post a quake\id1\qconsole.log? 
Sure Can! 
If Its Crashing 
then remember to delete your .cfg file. I've had this happen to me a few times with new builds and deleting the cfg has sorted it out. 
Thanks. Can I get a copy of your autoexec.cfg, okcam.cfg and config.cfg so I can examine them? 
I'd still like to know what settings would cause the engine to actually crash.

If there are settings that can cause the engine to crash, I would want to make the engine handle that without crashing. 
Here Ya Go 
Do you have to okcam.cfg? I'm looking through things. I can say I don't crash with the config.cfg and autoexec.cfg you provided, but the okcam.cfg wasn't in your download.

/Is looking through settings 
Does the following:

cl_bob "0.012"
cl_bobcycle "0.55"
cl_bobup "0.7"

Just a cosmetic tweak. 
I'm going to make a guess here ...

Does work ok? 
Same Issue 
I do not see an okcam.cfg anywhere!

But yes, 1032 still crashes for me. 
It's in my model pack. 
Ah, model is causing crash. Makes sense! Thanks for letting me know!

I couldn't find anything that made any sense, DX8 doesn't even have most of the new features, haha. 
Okay Cam! 
Well, just for testing I completely removed dwere's pak and I still receive the same crash.

Just to clarify it's simply: "Has stopped working" prompt.

This is testing on 1032. 
If I misinterpreted the above ...

Other than how you have an unusual resolution like 3440x 1440 ... which since you have max texture size of 16384 I don't think would be a problem ...

My only thoughts ---
1) NVidia driver issue?
2) Borked mp3 sound track
3) Does work with reset config and clean id1 folder.

I'm just not seeing anything that would cause DX9, DX8 and regular Mark V crash?

What is most recent that works for you? I'd try Mark 1.20

And if you aren't having some sort of content specific issue somehow ... maybe someone else will report same issue? 
Ok, is a "has stopped working".

What was previous version that worked?

All the builds:

If you can tell me the last one that works, I might have something to work with ... 
Let me know if 1.20 (Build 1020) works. 
Okay, so I believe the last version that worked was 1028...when performance was improved on dx9.

Clean Quake folder runs 1035.

Placed my mp3 tracks and it still runs fine.

Placed dwere's pak and runs fine.

However, I went to change texture mode to '3' and it crashes to desktop with "Has stopped working" 
It's Gl_texturemode 3 
That's the only thing in my autoexec. I apologize I sent you the wrong one as I have numerous quake directories for engines.

I can run on my "dirty" installation just fine when I removed that entry. 
Triple Post In The Name Of Testing 
If I try to change the texture mode to anything it crashes. 
I'll do a quick update without an hour. 
Mark V - Version 1.36 
Downloads at the usual place ...

-Mistake in gl_texturemode corrected (reported by Bloughburgh)

Which is one of the 2 new items in the video menu added in 1032. 
Time For Beer 
Thanks for the help getting this polished up!

All the downloads are up-to-date and no compatibility issues!

Thanks to Bloughsbough for finding that issue 5 minutes after Build 1035. ;-) Way better timing than something like that happening a week from now.

/Next updates in the spring! 
Texture Filtering 
Thanks a lot for the menu choice between filtered and non-filtered (pixellated) texture filtering modes. I had been asking for that for a long time. ^^

Two questions:
1) Is the option "GL_NEAREST" equivalent with the filtering mode gl_nearest_mipmap_linear?
2) I guess having this option in the menu now means that it's not necessary any more to put it into autoexec.cfg? 
It's ALIVE! 
Ya every thing works for me so far no issues! 
@mukor - Thanks! Yeah, "Time for beer" is quite literal and I'm doing the mfx right now ;-)

24 hours ago, I was left with the prospect of taking a timeout with flaw of unknown origin affecting dwere, and compatibility stuff ticks me off, compatability is #1 on the list for me and is a major reason why I engine code. Obv, I also do not like engine crashes (so couldn't rest until Bloughsburgh's problem was resolved).

Some timely insight by Johnny Law, a dev note by myself and then MH actually being able to experience the problem ... invaluable as an engine coder -- let me tell you.

@nightfright --- I added the "pixelization" option to the video menu because I honestly didn't know which one was the "right one" -- I like my FitzQuake gl_linear_mipmap_linear and if I want crunchy pixels I use therailmccoy (WinQuake version).

I found a thread where Spirit and MH discussed the issue ... Spirit said there is almost no difference between gl_nearest_mipmap_nearest and gl_nearest_mipmap_linear -- but mh (who knows both the GL renderer and WinQuake renderer better than anyone else) said gl_nearest_mipmap_nearest is the closest one.

1) gl_nearest isn't gl_nearest_mipmap_linear, it's different
2) gl_nearest_mipmap_nearest is better according to mh.

I don't think about this topic often, but the "too much detail math" is here ...

I fall into the gl_linear_mipmap_linear preference camp, so I don't think about this topic much but I understand the appeal to those that do.

Perhaps this will be followed up with a better explanation by those more familiar with the topic. Since I'm a gl_linear_mipmap_linear (trilinear) guy ... I'm not the best guy for this job ;-) 
@rook - Thanks!

R00k -- you know what sucks? When Bloughsburg had a crash issue, I ended up booting both my Windows 8 and Windows 10 machines -- because I thought the issue could involve Win 10.

I enjoyed playing Quake on Ubuntu more than either Windows 8 or Windows 10. On Windows 10 I hit some fucked up key that activated a narrator (fuck you Windows 10!).

Meanwhile, the Linux experience was dreamy --- and in no small part because I juiced the Linux build with all the Windows-ish goodness I possibly could.

/Also, for a while I wouldn't turn on my Windows 8 machine because I feared it might be a Windows 10 machine the next morning. Windows 8 sucks compared to 7, but Windows 10 sucks 5x more than Windows 8 because the next update it might undo all the customization and cleaning out garbage out of the menu you spent time doing. 
Texture Filtering II 
According to a definition on the Quaddicted site, it's like this:

Point sampled. Lowest quality, highest performance.

GL_NEAREST but with a bit more quality for far objects (software-like).

GL_NEAREST but with even more quality for far objects.

Personally, I also think mipmap_linear offers better quality than mipmap_nearest, and that's why it was the mode I had been using all the time. Are there any chances to add this mode as well (maybe as "Pixellated/Smooth")? 

X = how close-up textures are rendered.

Y = how different mip levels are blended together as objects move closer or farther away. 
Nearest_mipmap_nearest is closest to software Quake because software Quake used mipmaps. It's as simple as that.

If I'm in a crunchy pixel mood I use nearest_mipmap_linear which avoids banding between the mip levels. I can post screenshots later on that demonstrate this. It's one of those things that you might not notice, but once you do it drives you nuts.

Nearest on it's own disables mipmapping, which causes distant textures to shimmer and sparkle as you move around. Sometimes people mistake noise for detail, but this is basic sampling theory stuff. There's a weight of mathematical papers on it, including articles in the Mike Abrash Black Book, and I'm not going to get bogged down rehashing what others have said better elsewhere. You don't want to disable mipmaps, that's all.

The last thing is relating to mipmapped water, which Fitz and most derivatives don't have. As the water warps it can subtly shift between different miplevels. Again, drives you nuts once you notice it. Solution is to use ddx/ddy (GLSL dFdx/dFdy) on the unwarped texcoords then a tex2Dgrad lookup. You can't do that without shaders. Not sure if vkQuake or any other publicly released engine does it though. 

This was recorded in 1.00, so it's pretty out of date. I died, rapidly clicked and started the map again like this. That's all I have to say - I haven't tried reproducing it yet. 
Thanks Baker, I just happened to pop on at the right time I guess. Cool to see those options be included in the menu as well!

I found it strange that it crashed after trying to set a mode...then I went to the correct autoexec and saw it ONLY had the texturemode command hah. I really need to conform all of my directories with my master config.

Looking forward to trying when I get home! 
Yeah FWIW I use nearest_mipmap_linear too. And with some anisotropy set (so I really need to go re-read that discussion above about those interactions).

Obviously that's not the pure Winquake look but I likes it. :-) 
Same, nearest and mipmap linear. I like the distant smoothness with the crunchy pixels nearby. 
Good Stuff 
You two rock as I have said, more beer!

No problems running 1036 from a quick test around!

Love to be able to change the water is a bit intense at 3440x1440! 
May I Just Say... 
It's been a fucking pleasure working with Baker on this. 
@mh - Yeah, Was Fun ... 
Each of us working on different set of features at the same time in way that allowed asynchronous development which covered quite a bit mileage in short span of time.

A very enjoyable experience, indeed.

Looks like I should have picked gl_nearest_mipmap_linear instead of nearest/nearest for the option.

@bloughsburg - type "find warp" in the console. 
Pixellated Mode 
I doubt that gl_nearest is a mode many people will use. My suggestion would be to simply replace it with nearest_mipmap_linear and use that for "Pixellated" mode. 
Any luck on Intel graphics 3x performance? So far DX9 runs stable at 15-40 fps and is definitely better than QS. 
That's your fps on Arcane Dimensions right? 
Something I Commented In Ad 1.5 Thread 
Mark V has a bug with the rewind feature in demos. when you rewind, the clock go forward instead of backward.
when you pause (down arrow) and unpause, the time is resynced.

this is scr_clock 
@topher - thanks for reporting that. Must have wired up the wrong clock when absorbing some JoeQuake/ProQuake features back a couple of months ago.

/+1 to do in the spring update 
A workaround in the meantime, if you are interested. Add +pq_timer 0 to the command line or throw it in autoexec.cfg 
QuakePone, if you're interested I posted 2 builds in the QS thread here to check for a potential problem that affected some versions of Intel graphics.

Additionally, as MH mentions, try benchmarking "gl_flashblend 0" vs "gl_flashblend 1" (this may be faster; it stops the lava balls from casting dynamic lights and just draws a fake glow instead.) 
I tried this in my own engine, on a nvidia 960gtx, and it really didnt matter. yet as I like you are using gbra uploads, but then in the most classic settings, im getting 2200+fps with playdemo demo2 on Qrack vs 1600 in Mark V using really close effects; no motionblur, no r_novis, classic particles, etc. in DirectQ / RMQ i get 3000-5000fps.

maybe lightmap uploads matter? 
er 5000 in dq not rmq 
bottomline is a stable fps in given map we dont need >200fps in single player maps. 
An NV 960 is irrelevant unless you can get a test case that goes below about 500 fps.

Gimme the Intel benchmarks, that's the interesting stuff.

There's probably things I can do for lightmap updates but I'm not willing to gut the code unless I'm satisfied that there will be payback at the end of it.

I might also make one of my experimental GPU lightmaps engines available, because I'm interested in how that might perform. I'm cautious about not creating expectations in the community though.... 
Found In The Mirror In Arcane Dimensions 1.50 
Map = ad_magna

In console type: "setpos 2496 56 -292" And you'll be at the mirror.


/In Mark V, you can type "viewpos" to see your current x, y, z -- which also sets the default setpos. So if you type "viewpos" at a red armor, walk away and then type "setpos" you'll be back at the red armor. 
If it is lightmaps --- and that's an if --- slowing things down.

Type: r_dynamic 0

Then dynamic lighting is simply turned off. 
In Mark V, do the following after starting up Arcane Dimensions.

temp1 0 // Turn extra ad particles off
r_dynamic 0 // Turn off dynamic lights .. no lightmap updates will happen at all.
sv_cullentities 2 // Strict visibility tests on all entities
map start // Restart the Arcane Dimensions start map


See if your fps improves. 
These commands helped a lot in previously barely playable maps like ad_tfuma and ad_swampy. I might leave temp1 on 1024 and r_shadows on 1, still. 
Cool! Glad it helped out some.

In the Quakespasm thread, mh, ericw and myself and others are discussing performance related issues related to Arcane Dimensions. 
I'm starting to warm to the idea of doing some kind of release of one of my GPU lightmap experiments. ericw has expressed interest in how parts of it work and I'd be fascinated to learn how it performs on QuakePone's machine.

I've basically got 3 engines: Quake/OpenGL/assembly shaders, Quake/Direct3D 11 and Quake II/Direct3D 9. The Quake II engine is probably the most developed but it misses D3D 11 enhancements and draw call overhead does pile up. The Quake/GL engine is very barebones and I'm not sure where the code is. The Quake/D3D 11 is most likely to be let out. 
Huh. About the issue where models in front of the sky look "darkened" ... well, it makes the shaft look BETTER because then the contrast doesn't cause it to be as washed out!

(see my post on Old Page #1321 with screenshot illustrating that fullbright textures get ugly and washed out when contrast is applied)

Here's a screenshot showing this effect:

Shaft looks better with sky behind it! Maybe something like this could help all fullbright textures to make them not as ugly when contrast is applied....

Starting with -nostencil removes the sky effect, though it still lets you see r_shadows 3 through models (second screenshot above shows a distant grunt shadow visible through a dog's butt, heh).

I know you're aware of the stencil issue, mh, but I just had to display these interesting screenies ;) 
@gunter - Was Playing Co-op On Your Server 
On your server with JimBob and ORL.

Hadn't played Frostbite in some time, that map and the rest of the "2005 Wintery Map Pack" are always great experiences.

You might talk JimBob or even yourself into delete all maps and extra sounds in your Quake folder to watch the map/model/sound download in action.

JimBob wondered how I had the maps and the music, haha ;) Well, I didn't until I connected.

They downloaded automatically, of course.

Mark V has the best stay-connected http map/model/sound download this side of FTE. 
The auto-downloading is great. And I have noticed the .LOC files downloading before. I guess those are for frogbots?

I just wasn't sure if you actually got the music. I don't mean the intermission dance loop WAVs. Rather, I mean the soundtrack MP3s I selected to match the edited .ENT files (e.g., "'sounds' '65'"). I didn't know if Gunter had uploaded those.

Also, I'm not sure where it all comes from, since I think the FvF server is still Magic Proquake? I do vaguely seem to recall you talking (once upon a time) about having downloads come from a 3rd-party source like QuakeOne or w/e? 
Locs are for team deathmatch and such (dm3, etc.) like "At the red armor with 87 health"). You can turn off downloading locs. Type "find loc" in the console, you'll see a cvar that can be set to turn that off.

/mp3 don't download, mp3 tend to be large, aren't needed to play. It's a player preference anyway. 
Any Chance... 
of also moving r_shadows and r_waterquality variables into config.cfg?

I find it a bit complicated to set them externally through autoexec.cfg. And since texture filtering has already been moved... 
I've been really enjoying the winquake build, it runs very well. I ran into this little guy after I disabled mips. He's harmless but has worn out his welcome :) 
just found "showram".

Whenever I get stuck on something I just make a forum post or drop a message on irc so 30 seconds later I can figure it out myself :P never fails. ever. 
Don't know, but I'll think about it.

I worry about mods changing obscure things, causing niche settings to write to config.

1) quake.rc, autoexec.cfg
2) QuakeC

Case in point, Malice messes with untold numbers of weird cvars like viewidlescale that most users have never heard of.

Imagine if you exited and everything saved, all those peculiar settings would be part of your config and short of reseting/deleting your config, you wouldn't know how to reset them.

I'll think about it.

But my instincts tell me that no matter what, someone with very specific tastes is always going to find something that needs to be an autoexec.cfg 
Mods will only affect the config in the mod's directory tho. 
Mods should be properly set "gamedir" and yes everything saved, including .sav files .dem and .cfg to that folder.A footprint to a gamedir should mean anything I do here when i quit should save to gamedir. 
that's true except, when you switch gamedirs during a session, the cvars and aliases and keybinds are retained, and when you eventually quit that session they will be written to the last gamedir you switched to. 
What Metlslime Said 
Some people use game command (i.e. "game travail"). Some people like R00k probably use gamedir capability more for CTF.

And although no small number of people use the command line either from habit or because of the Quake Injector -- there are those that use "game travail" way.

And these different set of circumstances have to be factored in. 
when implementing the command in fitzquake, i considered writing the config to current gamedir, clearing all values to default and then loading the config in the new gamedir as a way to resolve this, but it could have negative results such as changing your video mode or mouse sensitivity, or other settings that the player doesn't expect to be per-mod.

The core problem is that some settings are global user settings and some are mod settings and there is no formal distinction between the two.

Most experienced players don't feel too much pain from this since they have autoexec.cfg files that force the correct settings (of course this breaks down when a mod includes an autoexec!) 
Spring Thoughts 
These are major things that, in addition to the topics noted above and earlier in the thread, are likely to be goals in the spring.

List of some different future possibilities

1. Coopable 3D "Quake Injector" built-in, concept Undergate screenshot About everything needed to finish the concept is in the engine already.

2. iPad/iPhone/Android versions with Minecraft-like controls (Minecraft is very playable on an iPad). I played the awesome Kurok mod for Quake FitzQuake version on a PlayStation Portable and am not likely to be satisfied until I can play Quake on at least an iPad and also like it.

I also did tons of engine modding of PSP Quake engines, so yeah I'm not pleased about not being able to Quake on devices.

3. Kurok capability screenshot. I have added almost every required capability into Mark V, but a small few remain.

4. Multiple-players, same computer. working prototype demonstration. This means studying Microsoft's XInput for game controllers, because the working code does not have the needed input support.

5. Spiked Quakespasm's super-compressed protocol. I like demo rewind and will have plan out right way to achieve it.

6. Playing .zip archives without ever decompressing them. i.e. Travail .zip never gets unzipped.

7. LAN Co-operative peer-to-peer multi-threaded download of required files (Like the client downloading "" from the server). Would make LAN co-op setup even easier and Mark V already has a ton of co-op capabilities. Mark V actually has a beta form of capability disabled in the engine for polishing.

(Note: Even a 70 MB download is nothing on a LAN. Over LAN that file could have downloaded hundreds of times while I typed this sentence.)

8. A re-written sound caching system to allow changing sndspeed between 11025, 22050, 44100 at any time.

9. Native Linux without SDL. Will add better support for video capture, hardware gamma.

(Might adopt Spirit/jdhack's Requiem Engine decision to use fmod for mp3 playback, but I still haven't explored all the mp3 options, including some of ericw's thoughts.)

10. Other things mentioned elsewhere in the thread, I'm sure. 
Yeah, exactly. I've invested some time and energy into ideas on how to sort out those issues. 
"when you switch gamedirs during a session, the cvars and aliases and keybinds are retained, and when you eventually quit that session they will be written to the last gamedir you switched to."

Uhh, I just tested, and Mark V does not actually do that. Well, I mean, it does carry over settings, but all config changes seem to save to the directory you started in, always, not the last dir you were in when you quit. But if that's the way you are starting the mod every time, I guess you would end up with all your config settings each time you play anyway....

Though I don't think that's the correct way to go about it.

I'm with Rook on this -- let each game dir house its own cfg stuff for that mod. And I still say it should automatically exec that config stuff upon changing to a new gamedir. This would allow the user to keep settings for each game truly separate. And if someone changes to a new dir, it won't carry over config stuff from a previous dir that perhaps shouldn't apply (assuming there's a setting for the mod that should supersede an old setting -- just retaining defaults is fine). And it wouldn't (shouldn't) save config stuff you change while playing that mod back to the base id1 folder (as it does now if you start in id1 and manually change to the new dir).

So yeah, each game dir should have its own configs, really, which override anything from outside that game dir. And when you quit, the config for your current game dir SHOULD save within that game dir.

I could illustrate a problem with the current approach:

Start Quake normally (plain id1). Let's say you have normally bound "shift" to cycle weapons. Then you want to play FvF or something with a grapple, so after you change "game fvf" and "bind shift +hook" then you quit the game, it saves that binding back in your id1 flder....
Now if you want to play normal Quake again, you have to rebind the shift key.

If it saved your (now altered) bindings in the fvf folder, you wouldn't have a problem. And if it would exec all the configs from the folder you changed to, it would all be set up automatically the next time you change to the gamedir....

Then that would make everything work consistently in the same manner no matter what method someone uses to select a gamedir:

"marv_v -game fvf"
would behave identically (loading configs) to typing in the console:
"game fvf"

Wouldn't that consistency be better? 
Gunter Keeps Revealing Secret Tweaks 
If someone uses the game console command (i.e. "game travail" or such), they start out in id1.

Then switch to travail.

Obviously, if you always start up in id1, you would want any changes to video resolution or setup to also apply to id1.

Since id1 is the config run on startup, yeah, that's where it should save too!

If someone uses -game whatever from the commandline or the Quake Injector, the config saves in game whatever just like you would expect. 
So While Revealing Secret Polishing Tweaks ... 
Mark V saves settings every time you exit the settings menu or the console.

So if you wonder why no matter what happens, everything is always saved the console history is always up-to-date.

That's why!

/I prefer to not mention these little niceties and polish-ups because I just consider it part of polish.

Like how Mark V forces a WASD default key setup and makes the mousewheel do previous weapon/next weapon by default. 
makes me want to rip out my autoexec cfg and do some gamedir testing... i think if i do a gamedir AD then my current gamedir should save config.cfg first switch dirs then load config.cfg from there, and vice versa. I hope this is the case already if not i'll have to change it. I have added a writealias command that dumps an alias.cfg for each gamedir but the user then has to make an autoexec.cfg to exec alias.cfg or maybe i should make it do that automatically...hmm 
Levels Menu? 
my levels menu doesn't work in the quakespasm folder. I have the quake HRP and the menu graphics change. What does this? In the DP folder works fine.

DX9 version is great, it kills on my R9 280.

Also what graphical things are supported? Just unpacked textures? Can it ever support things like dp pretty water? 
Any Chance Of Co-op Saves? 
Is it possible? 

"New Game"
"Levels" (Only appears if nothing above graphically replaced)

So if an exceptionally rare mod (X-Men, for instance) replaces a graphics there ...

Or if a user is using high definition graphics for those menu items ...

Rather than present the user a "Levels" graphic that clashes with the appearance of the menu, it simply disables itself ;-)

I'm just rather picky and I'd rather have menus that look nice than a menu with an item that clashes with the rest of the items on-screen. 
@fifth - Mark V Can Save/load Co-op Games 
Mark V can save multiplayer games, including co-op games which was the main target.

/If it isn't working, let me know. 
Also what graphical things are supported? Just unpacked textures? Can it ever support things like dp pretty water?

QMB particle option in menu, MH waterwarp (defaults on), MH volumetric shadows (r_shadows 3).

The Open GL version (not DX9) has a raw test implementation of bloom that needs more work in the future.

Eventually, it'll be run through the gauntlet, maybe possibly sometime in the spring, but not necessarily because isn't high priority item.

External textures use the same names as DarkPlaces. Mark V only supports .tga files. 
Can It Ever Support Things Like Dp Pretty Water? 
That would need a VERY significant overhaul of the entire renderer.

It might not be immediately obvious, but DP pretty water needs shaders. Then you're in a position where, in order to have other effects be consistent, you have to implement *everything* in shaders.

Another thing is: the reason why DP runs slower is because it does all these effects. If you start with another engine that runs faster, port DP's effects to it, then ... the other engine will also end up running slower. End result is that somebody's time has just been wasted in rewriting DarkPlaces.

I've always been of the opinion that it's a big world and there should be room for lots of engine options in it. Each engine has different goals. If you want to "pimp my Quake" then DarkPlaces is the engine for you, but other engines don't share that goal to the same extent. 
@johnny - DX9 Version 
DX9 version is great, it kills on my R9 280.

MH did an incredible job with the DX9.

One of the rare (and fun) examples of something going from simply non-existent to polished in just over 3 weeks.

The awesome beta-testers here who help out and provide fast, high quality feedback is unimaginably helpful to engine development.

Most incredible beta-testers ever! Engine development is hard, but smart detailed-oriented testing can take quite the edge off! 
Lol, I had no idea. I thought it was like standard quakes implementation. Plus the save option sits under the single player menu 
Stuff like DP dies on AD, down to 7fps. Other games, ie Q2, Q4 run much better at the same resolution with HD and extra effects cranked.

I've had the best luck with this engine and quakespasm spiked.

For instance ad_fuma... markv/dp = slowdown right at the start by the lift. markvDX9 = smooth.

>QMB particle option in menu, MH waterwarp (defaults on), MH volumetric shadows (r_shadows 3)

I found the particles and if waterwarp is on by default I just have to try the shadows. My transparent water in QSS has issues rendering, wrong things or distant things will show up.

>>Rather than present the user a "Levels" graphic that clashes with the appearance of the menu, it simply disables itself ;-)

I wish I could override this. Typing map is somewhat of a substitute. I do 1080P on a 42" screen so I really like the high res. See your point on shaders though; I remember playing quake and quake2 on voodoo2 back in the day and to see it keel over with a quad, 16gb of ram and a card faster than the original PC is shocking. 
Remove or rename gfx\sp_menu.tga (or gfx\sp_menu.lmp) and will probably load, if that is what is going on.

Possible (non-ideal) workaround. 
Hm, I would say the information and function is more important than the aesthetics.

It's no big deal if the "Levels" menu looks different; it's no less useful, and it's not like people are going to be staring at the menus for long periods of time. A menu isn't there for artistic value -- it's there for functionality, just as a way to get to the setting you want. 
Oh... AND it makes it even worse with your force-choosing what map to stick me on when I go to start a New Single-Player Game (oh how
I hate that feature).

I tested with FvF3 (a later version, not the version my server is based on) which contains custom menu graphics. If install the custom maps from FvF4 (which contains one called fvfstart.bsp) along with, say, the iikka, terra, and dopa maps, then your map-forcing feature (which I hate so, so much) decides to ALWAYS stick me on fvfstart rather than the default start.bsp when I use the default menu option to start a single-player game.

Furthermore, since there are custom menu graphics, the "Levels" menu is missing, so I cannot even use the menu to work around the feature (which I truly, truly hate) to start the standard start.bsp.

So, the "Levels" menu should always be there, even if it's ugly, but more importantly... (you can imagine me shouting this loudly to properly convey the hatred I have for this feature) THE DEFAULT MENU OPTION TO START A SINGLE-PLAYER GAME SHOULD *ALWAYS* START THE DEFAULT SINGLE-PLAYER GAME. heh.

I know, you probably spent time and effort coding this feature thinking it was a great idea, but it's just not. This is as bad as all the "toxic settings" you hate so much when some servers or mods force upon the user. This is just as bad as a mod containing an autoexec.cfg within a pak file that force-starts you on the same map every time despite what you, the user, want to do, because just like in the case of an autoexec in a pak file, it cannot be disabled in Mark V.

And no matter if I am wanting to run the dopa, terra, or iikka maps, I will get forced to start on the fvfstart map every time, because it is first alphabetically, so it's not like the feature is working well to begin with -- you can't read the mind of the user, and selecting a map alphabetically is no substitute. So just go back to the default function for the default menu, and if the user wants to do something non-default, the wonderful "Levels" menu lets him run whichever non-default mission he wants.

Well, assuming you don't hide the "Levels" menu because it doesn't match new menu graphics.... But as I said, I feel the functionality is far more important than the aesthetics. 
1) FVF running (-game fvf)
2) Single Player->New Game
3) fvfstart.bsp loads

99 of 100 people would call that perfect behavior ;-) 
IF U Have a starting map in your own gamedir then just call it start.bsp, like everyone since 1997 does it? ;) 
nvmd re-read gunter's post 
Pixel Lock Test 
Select and rotate pitch and yaw by selecting a single pixel on the screen and dragging it.


Initially was a bit frustrating, then the slightly rusty 3D math kicked back in. Have to imagine the frustum as a sphere.

Combining and project and modelview matrix, the center of any pixel on the screen has an exact "pitch" and "yaw".

There are shortcut cuts methods that wouldn't achieve pixel-level selection precision, but I wanted the real one. 
[ The above is what happens when you click submit instead of preview, typos galore :( ] 
heh. for me the key to that feature is the convenience of the list. renaming the graphics isn't the worst thing. I don't have as much passion about is as gunter. I'd just start from the command line if it was picking the wrong map regularly.

lots of stuff, ie the mapjams never even had a start map. not sure if "maps" works in any other engine but it would have saved me alt_tabbing at least. AD has mod folder selection from a menu but no maps.

the r_shadows 3 looks good, I would have never found it. 
>>AD has mod

should say DP 
Start Maps 
recommended behaviour would be for mods to create startmap_sp/startmap_dm aliases that specifies exactly what to do, and for engines to invoke that instead of doing 'map start'.
that way you're not getting randomness...

if only more engines+mods used that...
more seriously though, what kind of weirdo actually uses the menus? :o
(especially if the console's maplist dump supports clicking) 
Stuff like DP dies on AD, down to 7fps. Other games, ie Q2, Q4 run much better at the same resolution with HD and extra effects cranked.

I've had the best luck with this engine and quakespasm spiked.

For instance ad_fuma... markv/dp = slowdown right at the start by the lift. markvDX9 = smooth.

I can see why that might happen - polygon counts are absolutely insane in this part of the map.

There are a combination of things going on here.

Insane polygon counts.

MarkV GL makes no attempt at draw call batching. That's going to mean that bigger more complex scenes will bog down more and more.

MarkV D3D9 takes those GL calls and batches them, so it can handle those scenes better. It's still transferring a LOT of data to the GPU every frame though.

Quake 1 map formats are working against you. There's actually not a whole lot visible in that start scene, but Quake 1 lacks the vis format enhancements that even Quake 2 had, so it's pulling in a LOT of hidden surfaces.

DarkPlaces + huge data set + bad vis format + bling is not a good combination.

Quake 2 doesn't have the bad vis format, so it's data set is smaller, so you can bling it without as much slowdown. Likewise more modern formats.

Putting your data into vertex buffers so that it's already on the GPU rather than needing to be transferred every frame helps a LOT with bigger data sets too.

It's like the Quake equivalent of death by a thousand cuts. 
"1) FVF running (-game fvf)
2) Single Player->New Game
3) fvfstart.bsp loads

99 of 100 people would call that perfect behavior"

Maybe, but I complain louder than those other 99 hypothetical people combined! :D

And the problem is that this same thing would happen no matter what mod you were running in "step 1." You'd get fvfstart.bsp no matter what mod, because it's first alphabetically....

Actually, in the FvF4 full version package, the mod is programmed to always start the fvfstart.bsp map when a player goes to start a new single-player game. Probably somewhere in the QuakeC it does that.... This is more like what Spike suggested. If the mod actually specifies a map to run, that's fine -- you give control of such things to a mod when you run a mod.

Though the automatic start map picking does not seem to occur when you are just running id1 Quake.... Why is that?

That actually seems backward, in a way....

I mean, if you're running a mod, the mod itself will usually contain some way of starting whatever map it want to start, if it doesn't want the default start map.

But if you're running just plain Quake and you have a single-player map pack installed... then you DON'T try to select the start map via the engine ?

Well, I don't understand the reasoning behind that, but I dislike the feature in either case.

I do love the "Levels" menu though. 
My perspective most closely aligns with Spike's above about how mods should supply the information on the proper start map.

In a perfect world, that is the correct solution. 
Should always be the name of the start map imo

Anything else is asking for trouble. 
I can think of only one case where "start.bsp should always be the name of the start map" doesn't apply, and that's where a mod has only one map.

If a mod has only one map, and if a player selects "New Game", then IMO it's obvious what the player's intention is (hint: it's not to load ID1's start.bsp).

We're conditioned to think of "New Game" as being the equivalent of "map start" but if you step back and think: "is it really?" you might get a different perspective. 
" mods should supply the information on the proper start map. "

Agree. But if they don't do that, then the default start.bsp should be used instead of just guessing at it.

"Anything else is asking for trouble. "

Completely agree. I have been running into said trouble in actual practice -- though it's not that it can't be worked around but manually changing levels after I get dropped in the wrong map; it's that it is a major change from Quake's expected default behavior.

"If a mod has only one map, and if a player selects "New Game", then IMO it's obvious what the player's intention is (hint: it's not to load ID1's start.bsp). "

Actually, I don't agree with that, due to something I have done with FvF....

I have a modified DM6 map that contain an extra area which has nothing but a deadly lava pit with ledges above it, referred to as "The Purifier." When players vote to start a new Quest, I first transfer them to The Purifier area to kill them off before starting. The reason for this goes back to before I had the source code, and couldn't just strip everyone's weapons and frags from then without killing them... so the solution was just to kill them in a deadly trap before starting a new Quest game. At first, I had a separate small map for this, but later Orl modified DM6 to contain the Purifier in an extra area. This allows all players connected to the server to not be stuck in the console when The Purifier is called -- instead, if they don't have the modified map, they just feel like they are floating in space above DM6 while they die (the map on the server has the lava area, so the players can be in the DM6 map, inside that area, even if they can't see it). Of course, now I have the source code and could just strip the players' weapons and frags away before restarting Quest mode, but The Purifier became a traditional part of FvF, so it remains and is included with the FvF download files.

So, long story short (too late!), even though FvF has only one map included with it, it should never use that map by default when I go to start a new single-player game... because (before I had installed other maps in my FvF folder) I get put on DM6 when I try to start a new single-player game!

That is something that should never, never happen....

So yeah, default menu function for starting a new single-player game should start start.bsp EVERY time.

There are many different ways a mod can control that if it's not what is desired. 
Mark V's first priority is to play single player releases at Quaddicted and those released here. That first priority will never change.

FVF is not a traditional single player release like ARWOP, lunsp1, Travail, Marcher Fortress, Once Upon Atrocity, Grendel's Keep, Warpspasm, Soul of Evil, The Colony, GMSP1, Middle Evil, Rubicon 2, etc.

So yeah, maybe you have to add +map dopastart to the command line.

Oh the horror!

Mark V - #1 priority is Quaddicted/Func_Msgboard map releases. Feature is well suited to those.

But yeah, you can argue this until the cows come home and it will never change, because it is conflict with the stated goal of supporting single player releases conveniently. 
If I install ...

1) "game cda" - Castle of Dark Ages - Single Player new game should play the release.
2) "game lunsp1" - Single Player new game should play the release.
3) "game coagulatest" - Single Player new game should play the release.

I could name 200 more examples.

Now maybe someone like Gunter doesn't play single player releases off Quaddicted.

That's fine. But you have to remember that this engine is built to work in harmony with single player releases.

Arguing something in conflict with the #1 stated goal of the engine is just a waste of time. 
All that being said, what Spike said #1244 has been a low priority item to examine and possibly implement.

Not even close to the first time Spike has conversed about such a feature, it has come up at insideqc in the past on multiple occasions.

So possible future ability to specify what you think the start map should be for FVF via quake.rc or such doesn't seem like a stretch. 
No, I'm not familiar with all the single-player releases, but I have to ask, of those you mentioned, are they actual mods that should be installed to their own folder? Or are they just map packs?

Mods should have their own method of starting the correct map.

Map packs (like Terra and Iikka that I know of) are just installed to the maps folder, usually in id1.

In the former case, your map guessing isn't needed, and in the latter case it apparently doesn't function.

Let me check all the ones out you named, to be sure I thoroughly examine the issue.

CDS - pak file with progs included, so it's a mod, but it contains a readme with instructions: "3. Then load the map by typing 'map cda'."

lunsp1 - same, with instructions, "type 'map lunsp1'."

coagula - instructs user to use command line "-game coagula +map cogstart"

ARWOP - has instructions "Start a new game, and you will be taken to the start level of
'A Roman Wilderness of Pain'." So it's done the correct way, within the mod itself.

Travail - same, mod does it correctly/automatically.

Marcher Fortress - contains instructions to use command line "-game marcher +map marcher"

Once Upon Atrocity - starts the map in the included autoexec.cfg

Grendel's Keep - instructs to start map + mod by command line.

Warmspasm - looks like it does it automatically by the mod.

Soul of Evil - also done correctly by the mod.

The Colony - well, there is one "Colony" that is just a bsp with instructions to copy into id1\maps\ and run with "map" command, but there's also:

The Colony GMSP1 -- gives command line to start mod + map.

Middle Evil - instructs to use "map" command.

Rubicon2 -- apparently does it correctly in the mod.

So let me just tally this up.
Of the 14 potential things you mentioned (there were 2 Colonies):

5 of them do it the most correct way, within the mod itself, when you start a single-player game.

1 of them does it by an included autoexec.cfg, which is the second mostest correctest way to do it, I'd say.

1 of them is just a bsp which is placed in 1d1 with instructions to use "map" command (noted separately since the map-guessing feature doesn't work unless a mod is running).

3 of them have instructions to use "map" command.

4 of them provide a command line for the user to start the map + mod (oh, the horror of having to use the command line ;)

So, is the feature REALLY well-suited to these things?

In half the cases it either is completely unnecessary or won't work.

In the other 7 cases, if the user is following the instructions, it will never be used, (even though it would function correctly).

I'm sure there are many, many more map packs we could examine, and we could each look at the examples that either make it look good, or unnecessary, or bad.

But the feature is completely necessary in 0% of the cases, since all the map packs provide instructions for starting the map.

The feature is useless in 50% of the cases, because the mods either do it correctly already, or the feature doesn't work for maps in id1.

The feature is actually bad in some cases, such as ones I have mentioned....

So you've got a feature that's 0% necessary and only 50% useful, while sometimes actually being detrimental....

It's just not an overall good feature, even for the intended purpose of single-player maps.

Do I expect you to remove the feature? No -- I can tell you love it as your special child which you put time and effort and thought into creating ;) But I'm sorry, even though you love it, your special child is a tard XD

Even the people who aren't complaining as much as I am have said that start.bsp should always be the default (with mh's note that this may not necessarily be the case if there is only one map).

Me? I'm a Default Purist. I still am bothered that your pitch settings are off by .17 from default Quake :D

But this -- changing a cardinal menu function? That's so much worse to me....

But no, I don't expect you will remove it.

What I ask is please, please, PLEASE for the love of cake give me the option to disable it! A console variable, a menu setting, heck, a command-line option, ANYTHING so that I can have my Quake and eat it too! Er, I mean, so that I can have my Quake default functionality restored to it's proper functioning like it did back in 1996!

Let me just quote you the words of a wise man, please consider them carefully ;)

"Mod authors almost never intentionally did wrong things, they only sought to provide a good user experience for their mod.

Nonetheless, there are toxic quake.rc and autoexec.cfg files out there.

And playing single player release with the player in control of his settings is #1 for Mark V."

I know you didn't intentionally do the wrong thing, but this setting is toxic to me, and you have taken away my control to even disable it.... ;) 
I would definitely count all instances where the user is instructed to use the "map" command as instances where automatically launching the map is desirable/necessary. Mark V is designed for a plug-and-play experience - you aren't supposed to have to leave the game/engine to read readme files, just like you don't have to with the Quake Injector. 
Don't know. I'm not going to be doing more engine coding until (probably) the spring, except anything I decide to do as a leisure activity or experiment for my own satisfaction.

I won't be making any kind of decisions right now. Nor thinking about the "to do" list.

If I code something before then, it will be a leisure activity or solving a complex 3d math puzzle or something.

Wallclimbing mod

Found the old pubdm mod pretty much written by R00k. 
I'd personally discount those that give instructions. People don't read readmes. Never have, never will, you can keep your credit card details in a file called "readme", perfectly safe.

Discount a mod that provides an autoexec. That's the LEAST acceptable method to me (of those you list, there are worse). The mod author is making a statement here: Their preferred settings are more important than mine. That kind of thinking can fuck off. I'm the player, the autoexec belongs to me.

So I make that 9 that are player-hostile (1 actively so) vs 5 that do the right thing. Almost two-thirds.

Now, I'm not saying that Baker's approach is the best. One useful purpose it has served is starting a discussion around this problem, because despite what you claim, it IS a problem. People have trouble getting the Quake executable into the right folder, so you cannot claim that installing and using a mod is an intuitive trouble-free experience for everyone.

Personally I'd love to see something built into the Quake Injector. Maybe something built around Spike's suggestion, or something else, so long as it can be standardized and adopted. 
What do you mean "built into the Quake Injector"? I thought that already handled loading maps without a startmap. 
I'm not familiar with the Quake Injector -- I've heard it mentioned, but have never used it. But I was just thinking, "maybe a good solution would be a stand-alone Quake runner, much like QView, but for running mods + maps.... Maybe that 'Quake Injector' could be made to do something like that."

So yeah, you could have a program that looks like Qview, only it scans your Quake folder for mod folders and asks you which one you want to run, and maybe it scans that folder for map files, and if there is only one it runs that, or it could use a similar "guessing" algorithm to select the most likely start map, perhaps showing a list of those maps with the default one selected. Then you click run, and bingo-bango, it automatically runs your selected Quake exe with command like automatically tacked on (similar to how Qview does it to connect you to a server), with -game +map automagically set for you. (Though Qview just tacks on "-exec Qview.cfg" and puts its settings in that).

Heck, someone should make an updated Qview that can both handle running local mods and connecting to online servers, perhaps with a master server list setting included....

You have a point about people sometimes not reading the readme.... Though I'd think in general if they were downloading the zip files manually and unpacking them, they know what they are doing and would likely check the readme, or would just check the map folder and see what's there. Though the Quake Injector thing might bypass that? in which case, yeah, the user may not check the readme.

Though, in that case, there is the wonderful "Levels" menu in Mark V so they can run the included map (I really like menu, and feel it is the correct and best way to handle maps).

In regard to mods including autoexec.cfg, that actually seems like one of the best ways to handle it to me (even better than just having your map named start.bsp) for the very reason you mentioned, mh -- "the autoexec belongs to me."

Meaning I can edit the file easily to include or remove whatever settings I want. I don't mind the mod author putting his suggested settings in there, because, again, they are easy to change (assuming they don't commit the terrible sin of sticking the autoexec in a pak file, but that is rare).

It actually seems handy to me that the mod author would include an (easily editable) autoexec which will automatically start the intended map.

But yeah, I agree that it would be nice to have something for noobs built into Quake Injector for running mods/maps (if it doesn't already?), or just a new version of Qview with that functionality included, or just a new little stand-alone app (which would be pretty simple, really) that could run mods and/or maps with a few mouse clicks. 
Just a couple unrelated observations because I was starting up the Soul of Evil mod while testing the map running stuff. This mod uses its own start.bsp map.

I use an old version of Fitzquake (.85) for comparison, and I noticed two things:

1. Mark V is smart enough to not use the default start.lit file from my id1 folder.... Fitzquake does use that file, resulting in some... unusual colored lighting effects, heh. It doesn't look bad, it just look different, with strange colored lights splashing on the walls from no apparent source. But yeah, Mark V is probably correctly doing this.

2. Even upon first running the mod (by command line), so there would be no cfg files to read from in the mod folder, Mark V carries over some settings from id1. This can be good or not so good....

It doesn't seem to carry over the resolution settings -- that would actually be a good one to set....

It does carry over controls I have set up, which is good for basic movement controls, but not so good in that it keeps keys bound to aliases which are now no longer set (by the autoexec in id1).

It also grabs the settings I have made in the menu, including disabling the demo playing... and in this case that turns out to be bad, because the mod has a little "intro screen" demo that runs by default.

This is a tricky thing, because it's either "all or nothing" using the settings from id1 (or its hidden cfg file somewhere?) as the defaults in a case where you run a new mod... (weren't me and someone else complaining about that previously? heh).

On the one hand, it's handy to not have to set up your controls again, but on the other hand, generally you should be starting from scratch (with the actual Quake defaults) when you run a fresh mod (or delete your cfg file)....

Of course, knowledgeable users will have their basic keybindings in a separate cfg file which they can exec to set up all their default controls and preferred settings....

I think in this particular case, despite the user setting his id1 Quake to not run demos (because he's seen those 1000 times before), upon running a mod where the setting has not been previously made, the demos should default to play (it's actually an intentional part of this mod's experience).

Hm, yeah, this is tricky. There are good and not so good points about it... in which case I start to lean toward sticking to the default behavior (no cfg? default settings apply).

Perhaps there would be some middle ground where keyboard bindings were retained (not much problem with that), but default settings such as "play demos" are not taken from id1 when a new mod is ran. 
so the shadows(3) sometimes go through walls and floors. bug or a byproduct of the mentioned overdrawing by quake?

I could take SS if needed. For instance dead ogres on top of a bridge are casting shadows on the ceiling when you walk under. 
Bit of both.

It seems possible that this is related to the draw order, and I'm going to work out what the possible best compromise is.

Assuming it can be fixed it will be in one of Baker's spring updates. Until then you need to accept it as a choice between 2 imperfect shadow options.

I think this is the fifth time I've said this... :) 
sorry, i tried going through the whole thread and must have missed it.

Documentation is a little sparse, maybe I'd have a better idea of all these things if I checked the source. 
Lit Water 
I thought I would raise this subject here because it seems like Mark V is one of the few engines currently under active development that isn't DarkPlaces.

What do people think about supporting lighting on water surfaces? Personally, I think it's a very nice visual effect and I'd quite like to see it in more engines *wink wink nudge nudge*. As far as I know compilers like ericw's tyrutils suite fork can support it, but I've never played with an engine that actually renders it...

Sorry if this has been brought up before. 
The other thing I thought of asking about is if it's possible to disable the Gamma Protector Clock? It makes my screens flash when it fights with f.lux. 
Go to video options and switch hardware gamma off? 
I'm currently using Mark V 1.20 (not sure if that's the latest version), there's only 4 options under Video Options - Resolution selection, Fullscreen on/off, and apply and test buttons. The only thing I've seen relating to gamma is the slider, but that doesn't sound like what you mean. 
That menu item was added in the current version, 1.36. You'll probably prefer the DX9 build over the traditional Open GL version since it is much faster (nearly 3x faster in many situations), but both are available. 
Reminds Me Of 96 
Woah, what happened to my framerate? I tried the dx9 build and it was fine, but the GL build tanked. I was getting a perfect 72 on my map before, but now I get something in the range of 22-23 fps with the standard mark_v.exe.

At least dx9 works. 
Also, r_waterripple is really cool, it's a shame about the seams though. 
Lit Water 
Is another topic that pops up occasionally. I'd like to see support for it. May be tough due to the way water morphs and deforms though 
As far as I know light maps are blended after textures are drawn, so depending on where the textures are warped it wouldn't be too much of an issue? I'm not sure how the water warping is done though. 
lightmaps and textures use different UVs so in theory the lightmaps don't have to warp. 
Pritchard, gl_subdivide_size 32 should get rid of the ugly seams, if you're talking about what I think you are, related to r_waterripple.

Something to try which might improve frame rate (GL or otherwise):

r_mirroralpha 1

Using non-hardware gamma will also decrease FPS, unless the gamma and contrast sliders are all the way down (basically disabled).

r_shadows decreases my FPS, so if you happen to be using that setting, try disabling it. 
I was thinking....

So, Mark V keeps a (somewhat hidden?) backup config.cfg file to prevent bad things, such as other Quake engines blanking out a lot of settings and such.

This is both good and not so good....

The good part is obvious.

But it can be not so good for some situations, like if I WANT to blank out my settings in my FvF folder... (they just get re-loaded from somewhere), and like above where I noted that when you play a new mod for the first time, things like "disable demo playing" should certainly revert to its default value (play the demos).

So part of this behavior is taking away user control, and part of it is altering a default behavior that can sometimes be better to not alter.

Anyway, here's my suggestion:

Instead of using a hidden config.cfg file, just have Mark V create its OWN config file in the current game directory, perhaps named something like Mark_V_config.cfg

And Mark V will automatically load the standard config.cfg file, then after that load it's own Mark_V_Config.cfg file.

This is an improvement in my view, because:

- The Mark_V_config.cfg file is easily editable/deletable by the user.

- Mark_V_config.cfg settings will not be altered by another engine which messed with the config.cfg

- Loading that file after the config.cfg will mean Mark V's settings will override settings that other engines have made (or erased) in config.cfg

Mark V would still alter the standard config.cfg file (as is standard Quake behavior) so that any applicable changed settings will apply to other engines. Probably the special Mark_V_config.cfg file would be nothing but a duplicate of the standard config.cfg file... (which is probably functionally equivalent to your special backup config.cfg file, but it's stored in the same game directory now).

And if a new mod is ran which does not contain a config.cfg or Mark_V_config.cfg, then the default settings should be applied (such as playing demos).

If you wanna get fancy, then save all BASIC keybindings and aliases somewhere and let them carry over even if no config exists for a new mod.

Extra fancy would be some menu option for this -- "Save basic config settings," "load basic config settings," "always retain basic config settings," or something like that within the Customize Controls menu (though I know how much you hate extra menus).

Or perhaps some of this this might mean making another config file, much like R00k was suggesting in #1224 (which sounds like a great way to do it all around -- saving aliases and such automatically, and automatically switching to new configs when changing mod directories).

So Mark V could write it's Mark_V_config.cfg which is basically a backup of the config.cfg, and also a Mark_V_user.cfg which will always be written to id1 and read no matter what mod is ran, which will just contain basic key bindings and aliases which would be unlikely to change from mod to mod. Though the Mark_V_user.cfg from id1 should load first in case the user has set up special key bindings for a mod -- such settings would then be read from the gamedir config files and override the basic user controls.

Hm, then, of course, any key bindings made while playing a mod wouldn't carry back to the basic user settings stored in the Mark_V_user.cfg in id1, but that's actually correct behavior, in my view -- UNLESS the user uses that hypothetical menu option "Save basic config settings". Of course, if the user was just running id1, those settings would be saved automatically.

So... in summary, and in order of loading:

Mark_V_user.cfg (always in id1, contains key bindings and aliases, loaded every time even when running other gamedirs. Saved automatically if running id1, or by user selecting a "save config" option when he's running a mod)

config.cfg (standard function, for cross-engine compatibility when possible)

Mark_V_config.cfg (saved alongside the config.cfg in current game directory, backing up all Mark V settings and overriding settings that other engines made to config.cfg).

All files are easily user-accessible.

And like R00k suggested, configs should be automatically saved/loaded upon switching gamedirs. 
Lit Water 
It would be better to discuss lit water after a couple of single player releases have the feature.

Would be proof that mappers will use the feature, that the compile tools work reliably, that another engine has achieved a stable implementation.

When these maps exist in the wild and after the rank-file can play these maps and potentially report/discuss issues in engines that current support them, it isn't out of the "idea stage".

Where are these maps?

Until they exist, from my perspective they exist this is the same as talking about leprechauns or the Loch Ness Monster. 
Methinks the reason for the absence of such maps is exactly the fact that there's no proper engine support.

Right now - what, Darkplaces has it? FTE, maybe? I'm not even sure. People don't work with advanced engines here. And it's not exactly the kind of feature that you could squeeze in as an optional bonus for special engines. It affects the way the level looks a bit too much. 
I would like to include lit water in my map - as far as I know doing so is as simple as setting a flag on my compiler. But it is a chicken-egg situation; I don't have any way to know how my map actually looks with such an effect, since I know of absolutely 0 engines which support it.

I'm sure you can imagine that authors may have reservations about releasing a project with something that is "maybe it works and looks good here, but I have no idea since I'm practically blind".

It's totally fair to not want to be the first/only engine with support for something, even if that is a little disappointing. I'm just concerned that someone will have to take the plunge with support, and given features like mirrors, I had hoped that Mark V might finally do it. 
the latest version of gl mark v runs really slow on ad_magna, while it ran fine on previous version that i had (mid december). dx9 version of the latest build runs it fine. what fps killing features did i miss previous month? 
Just checked, the DP dev build render lit water:

Add "-splitturb" to the tyrutils-ericw qbsp command line to get it. 
@pulsar - I guess I'll be double-checking the Open GL build come spring time to see if I did something that inadvertently caused a performance drop in Open GL. 
Lit water is one of those things that seems like a great idea until you go poking at all the edge cases.

Yes, I implemented it, saw what it looked like, and got rid of it.

I'm willing to add it to my DirectFitz thingy but please be aware of the following.

An engine can 100% reliably detect if a map has lit water.

An engine cannot 100% reliably detect if a map has not.

That's because a surface not having a lightmap doesn't mean that the surface isn't lit in Quake. It means that it's in total darkness. This is the kind of "let's save maybe 200 bytes per map" thing that matters when you're trying to run on an 8mb MS DOS machine but that causes untold pain and suffering later.

So a map with no lightmaps on water can mean one of two things: either the map doesn't have lit water (draw it fullbright) or the map does have lit water but the water is in total darkness (draw it with black lightmaps).

Do you light lava? Slime?

Do you add a warp effect to lightmaps? The lightmaps are a combination of (1) still, and (2) darkening the original texture, so the warp effect on the original texture is lessened.

What about translucent water? Darkening the water will make it appear more translucent. Maybe we should decide that because light goes through translucent water it doesn't get lit.

Should a map with unlit water still have dynamic lights added to it's water surfaces? And if so, is it OK that this would make the light seem brighter than on surrounding solid surfaces?


These are probably questions that people can't answer until they see it and start exploring around it. Like I said, I'm willing to add it to my D3D9 FitzQuake port if anyone wants it that badly, but don't expect it to be a 100% robust implementation at present. 
Just For The Sake Of Completeness 
Mankrip said maps like e1m4 don't compile with lit water. This was months ago, maybe that changed.

Until someone steps forward proving any of this stuff works and is polished ... I'm not sold.

I would like to include lit water in my map - as far as I know doing so is as simple as setting a flag on my compiler.

Man up?

Maybe find the courage to actually use the compiler option?

Maybe find the courage to load the map in DarkPlaces or existing engine that supports it? 

This, of course, is not compiled by any light tool. 
Do you light lava? Slime?

Should be up to the mapper.

Do you add a warp effect to lightmaps?

I wouldn't, but it depends on how you perceive the warping. Does it only represent horizontal movement of the substance, or does it also imitate vertical waves to a certain degree? Distorting the lightmap can help with the latter, I suppose.

Maybe we should decide that because light goes through translucent water it doesn't get lit.

Then it will glow on its own. 
Only Suports X & Y Targa 
So some of the HD backs from here:

fail with Only type 2 and 10 targas are supported message. I get thrown back to windows until I find the files and delete/rename.

Of course I had to extract them from the pk3s but even re-extracting doesn't help. Example is +1wall58.tga from arcanum HD textures. 
I'll look at having tga files that aren't type 2 or type 10 just do console prints instead of errors in the future (next updates likely in the spring).

Erroring out to windows seems like overkill.

Thanks for point this out. 
I couldn't figure out how to get the Darkplaces Autobuild from ericw's link to display the lit water. And yes, the turbs were split.

Man Up?
It wasn't/isn't an issue of "manning up", at least not from my perspective. I'm fine with turning on a compiler flag. I just like to be able to see the results.
Imagine compiling lighting for a map in general and never ever looking at it. Doesn't that seem like a daft idea? Perhaps you got the values all wrong, everything is too dark or too bright. But because you never look and see what the results are, you'll never know and your map will suck.

untold pain and suffering
Would it be possible at all for a compiler to actually write that data? Obviously it would increase file sizes, but would it necessarily break compatibility with engines if that were the case?

The other way to handle that that I can think of right now would be to change the result based on whether there is ANY water with light data or not. If there is some, you could pretty safely assume that all water is supposed to be "lit", and so water surfaces without light data could be rendered black. If there is no light data for any water surface, then you could assume that it is not supposed to be lit. There may be a few edge cases there, but that would, I imagine, cover support for correct water rendering in 99% of maps, as well as allow for it in the rare pre-existing "lit water" map and all future ones.

Also, I'd be interested in finding out why some maps refuse to compile with lit water? I've never had any kind of lighting setup outright refuse to compile on me. 
@Pritchard try this map in DP:

Here is what it looks like for me: 
I just like to be able to see the results. I couldn't figure out how to get the Darkplaces Autobuild from ericw's link to display the lit water.

Understood. ;-) I'd want to be able to see the results too. 
@ericw - that map works; the water is bright, and then it gets darker... and it's glorious. *hint hint, nudge nudge @Baker*

Now the question is why can't I get it working for my map? But that's something for your compiler tools thread, I imagine. 
Would it be possible at all for a compiler to actually write that data? Obviously it would increase file sizes, but would it necessarily break compatibility with engines if that were the case?

What I'm actually talking about is the 20+ years of existing maps that have this behaviour. 
Yes, of course, but if you could look at a map and say "none of these water surfaces have any light data, I should not apply lighting effects to the water", that'd be fine, wouldn't it? 
More Questions 
Should water have fullbrights? The stock ID1 lava texture is actually mostly from the fullbright palette ranges, a possibility that ID themselves had considered but rejected lit water.

Should water block light? It's possible for a surface to receive light but not block it - that's what doors & plats do. But if water blocks light it means scenes like the lava pit in start.bsp would be almost full dark - most of the light entities are inside the lava. 
I wouldn't be able to give advice on fullbrights for water without having seen it, but I imagine the answer is no. It would probably look like very ugly specular highlighting.

I don't think water should block light - it's unrealistic and would make extra work for mappers that they probably wouldn't see a point to doing.

Perhaps lava should have fullbrights though - it might look good for that. I also think the issue with lava looking bad if it's lit can be counteracted with surface lights, although it is something that would trip up noobs... 
The stock ID1 lava texture is actually mostly from the fullbright palette ranges, a possibility that ID themselves had considered but rejected lit water.

I think the orange fullbright range is just the best color range for lava in the palette.

I wouldn't be able to give advice on fullbrights for water without having seen it, but I imagine the answer is no. It would probably look like very ugly specular highlighting.

It can be a problem with existing texture sets, since they were developed with an assumption that liquids are never lit (therefore there's a greater chance for bad fullbright distribution on liquid textures).

But what if someone actually wants fullbrights on liquids? 
<-- Beer Is The Only Liquid-themed Icon We Have 
I'm a big fan of the idea of lit water
That looks pretty good - although it's hard to tell from such a small blurry image, but I'm pretty sure it looks a ton better than regular water.

should light block water

The only way of blocking light that would look correct, is if it affects the attenuation of the light trace as it travels through the water volume. That's probably a bit of a faff? Or could be easy, I have no idea.

What about directional considerations?

In this shot, the water looks bad because light is coming up from below the surface, lighting the rocks, but the surface of the water doesn't receive it, so the water/rock transition looks bad:

To look better, the water surface would somehow need to be lit taking into account light coming from both above and below the water surface, I think?

Kinda like quake's window textures - if the light is coming from either side of the window, you'll expect to see light on the window surface. 
With tools like defullbright out there, it might not be such an issue with existing texture sets. Perhaps it would be best to render fullbrights for liquids. 
Water would definitely have to be lit differently to normal surfaces, like Kinn describes. Again, that's on the compiler, rather than the engine... 
was mentioned last time this topic came up, but the lightmap on water should probably get blurred a bit too - hard shadows would probably not look good. 
Extra Soft And Supple 
I thought everyone used -extra4 -soft ;) 
I'm not sure how much this is a consideration, but...

To look better, the water surface would somehow need to be lit taking into account light coming from both above and below the water surface, I think?

...this reminds me that Q1 BSP actually stores each water surface twice. Once for the underwater view, once for the above-water view, and so visibility (not so important if you have translucent water) and backface culling (always important) work correctly. 
I don't use -soft, I'm not keen on that look nowadays.

On water though of course it's a different story. 
Quotin Maself 
The only way of blocking light that would look correct, is if it affects the attenuation of the light trace as it travels through the water volume. That's probably a bit of a faff? Or could be easy, I have no idea.

Thinking about this it's probably not too bad. I'm not ericw, but I think when you do a raycast you can note the point when the ray hit a water surface and take that into account when lighting geometry under the water. I have raised this to "probably would want it" because consider an outdoor pool/lake - you have sunlight lighting all the geometry outside, but you want to dive into that pool and see the sunlight penetrates the water to light objects just below the surface, but as you go deeper, the sunlight fades to black... 
meanwhile all the fish at the surface are pitch black because they get their light from the floor trolololoool 
Nothin' wrong with black fish. Some of my best fish friends are black. 
GPU Lightmaps With Lightmapped Translucent Water 
If that makes it into a release somewhere, anywhere, I'll be a very happy chappy. 
That Looks Pretty Cool 
Spring update anyone? 
I think Baker's gonna need to make the judgement call on whether or not MarkV gets it, because it's pretty much all renderer front-end work. I'm 99% certain that the current back-end will support it without modification, but I'm willing to commit to any modifications that may be required should Baker decide to go for it. 
@mh (and 1 For Ericw, 1 For Mappers) 
Just various random thoughts

1. Mark V has optional stain maps (defaults on), like FTE, which uses the lightmaps.

2. I'm sure you already have this one taken into account, rotated and moved brushes.

3. Here's a more complex one --- fullbright colors in water texture + software renderer :( This isn't necessarily as annoying as it sounds and in-engine conversion of a water texture's pixels from fullbright blue to non-fullbright blue at map load is likely an option. I guess I'll need to look at the textures/palette, I hope there isn't a fullbright blue without a non-fullbright equivalent.

4. Do non-supporting engines load lit water maps ok? It is sounds like they do, which would be an advantage.

5. Would be very helpful if ericw could mark the .bsp as having transparent water somehow to avoid the "don't know" scenario you outlined. One thought is inserting a worldspawn key "litwater" "1" (is this the best way to mark the maps? I'm not saying it is. But if lit water maps can be loaded in standard engines, at least this method does not require a new map format. But there could be a better way and this is just one thought, but avoids MH's "don't know" scenario.). 
Did a quick palette conversion test of the traditional blue water to a non-fullbright palette. It's fine. Non-obstacle.

Lava will have to be fullbright because the software renderer doesn't have a choice except to use the Quake palette, and there are no non-fullbright versions of bright red. 
I don't really have an opinion on lit water.
I guess it looks ok in those screenshots.

What I really wanna see is reflective water!
But r_texprefix_mirror doesn't seem to do anything when set to a water texture.... 
Sorry For Hijacking Your Thread Baker 
About corner cases:

- Winquake.exe seems to be fine with the example lit water map I posted.. it doesn't have a problem with liquid faces missing TEX_SPECIAL.

- The qbsp options "-splitturb" (and "-splitspecial" which is older) unset TEX_SPECIAL on the affected faces.

The main problematic case I can see is a face with:

- texture = "*water"
- lightofs = -1
- styles = {255, 255, 255, 255}
- TEX_SPECIAL is unset in the texinfo

Do you render that fullbright or solid black in an engine with lit water? I think it needs to be rendered fullbright; faces with those settings will exist in the wild if anyone ever used the "-splitspecial" qbsp option. It would be worth checking how Darkplaces handles this corner case since it's the first released implementation afaik.

So to fix this case, the light tool just needs to avoid writing those "implicitly black" faces for lit liquids. IIRC, mankrip requested that a while ago but it looks like I didn't implement it yet in my light tool. I think if I do that, we don't need any other kind flag to mark the map as using lit water. (presumably the engine should support mixing lit water and non-lightmapped lava)

- Other rendering stuff: imo fullbrights should be rendered normally (for fitz engines, respecting the gl_fullbrights cvar), the lightmap should not warp (I'm imagining it as a shadow cast on floating leaves that are swirling around; the shadow shouldn't swirl).

- Light tool stuff: there is already some handling in my tool that mankrip contributed; lit water faces can receive light from either above or below, and they don't cast shadows. This part I'm not so concerned about, it's easy to tweak with features as they are needed. 
Here's a more complex one --- fullbright colors in water texture + software renderer

That didn't even occur to me, but yeah - a GL/D3D engine can just not draw a fullbright, but software doesn't even have the option.

Rather than remapping I think if it was me I'd probably do an extra colormap.

Do non-supporting engines load lit water maps ok? It is sounds like they do, which would be an advantage

Not a problem. Most of the work is actually changing various cases of "if (surf->flags & SURF_DRAWTURB)" to "if ((surf->flags & SURF_DRAWTURB) && !litwater)" at runtime, so load time is fine.

Would be very helpful if ericw could mark the .bsp as having transparent water somehow to avoid the "don't know" scenario you outlined.

I think the don't know case was me being nitpicky more than anything else. It is possible but the probabiility is so low that I don't think you'd ever actually see it.

What would be more worrying is bad tools setting surf->samples for a drawturb surface in a map that shouldn't have lightmapped water, because that's really the only way you have of checking, but I don't know if such bad tools even exist. Either way, providing an r_lightmappedwater cvar that the user can set to 0 can help with that. 
Water with garbage fullbright pixels is a texture pack problem, as it always was with garbage fullbright pixels. I don't think it should be solved engine-side. That would only complicate things. 
Random Extra Thoughts 
Although not an official texture, *tele teleporter textures should probably be fullbright (not lit). Both Mark V and Quakespasm treat *tele textures differently.

dwere: Water with garbage fullbright pixels is a texture pack problem ... I don't think it should be solved engine-side

Sounds logical. 
What About 
tell the mapper to put liquid brushes in a func_group and then set all the different liquid lighting options on the func_group. 
Personally, I've had enough of having to do that with _phong 1 on all my func_details... 
The idea isn't to annoy the mapper by making him manually set the rules up on each func_group - I assume there would be default liquid lighting settings that are used if nothing is specified, but...if you want custom light behaviour on a certain liquid body then you can func_group the liquid and set some options...

Beats having hardcoded arbitrary rules for teleport textures and whatnot imo. 
Or Even Better 
Do it like surface lights - have an entity whose sole purpose is to specify the light properties (aka override the defaults) of a particular texture, which then applies to all instances of that texture in the map. No need to use func_groups.

I only thought of this because with custom liquid textures used for random things like teleporters or energy fields, the texture names can be unpredictable (I think Knave has a *starfluid texture or something) 
I think the special entity could work, although I don't think it's ever been done before - with surface lights, it's a single key that specifies that the light it's on should be duplicated and spread across all instances of that texture. It's not specifically a custom entity that does anything different to a normal light.

This is quite offtopic, anyway... 
(Maybe) Simplified Navigation For Non-Traditional Platforms 
I'm slightly tempted to add an (optional) auto-jump feature where a player at an edge will automatically jump *only* if they can make the jump at the current speed *and* they are running.

If they can't make the jump and are running, the option would work like "edgefriction 999999" (if you don't know what it is, you might try it) and make it very difficult to fall off an edge.

And perhaps have the option have an "automatic jump up" if forward progress requires a upwards jump that can be made.

(Because pressing "jump" seems to be an annoying burden if you aren't using a mouse + keyboard). 
Not Sure I Understand 
But is it similar to quake 3's awesome stair clipping. I hate q1's momentum loss around short floor variances 
I can understand that this might seem attractive on accessibility grounds, but (and unless I'm seriously missing something) wouldn't it totally fuck with your game if you were playing with "always run" enabled? 
rebind the jump button to +run 
I don't fully get it, but it sounds like a terrible idea.

Why don't you just make it a full bot so the player doesn't have to press "attack" in addition to not having to press "jump?" Because "aiming" is an annoying burden if you aren't using mouse + keyboard... or, you know, if you just suck at Quake :p heh. I know you're probably thinking about Gamepad controls, but still, meh.

mh, the "always run" menu option already fucks with my game by borking up my sidestep speed... AND Mark V changes it to default ON (that's an old complaint of mine, heh. [oldpage #1154]). 
I know you're probably thinking about Gamepad controls, but still, meh.

I think he's talking about things like phones and tablets. Gamepad users don't have a problem with jumping. 
Touch screens is exactly what I thought it was too, where you might have left thumb to move, right thumb to look, tap to shoot, and ideally you'd like to be able to jump while moving and shoot while jumping but you're out of options for how to handle it. 
mh, the "always run" menu option already fucks with my game by borking up my sidestep speed... AND Mark V changes it to default ON (that's an old complaint of mine, heh. [oldpage #1154]).

I'm not sure about the details of how MarkV implements this.

I like the Quake 2 method which maintains a separate cl_run cvar and just multiplies the speeds by 2 if it's set. Seems less messy to me that Quake's faffing around with cl_forwardspeed. Any reasons why that hasn't been adopted (aside from "iiiiit's nottttt Quaaaaaakkkkkkkke", that is)? 
Triple Post 
@Gunter - found your discussion of "always run" in the other thread; repeating here for info:

This is not a good setting to default ON. It's weird. It doesn't actually do what you'd think (make it like you're holding down the +speed run button) -- it just messes with your normal "walking" forward and back speed, but not your sidestepping speed, exactly. So you end up being able to run forward fast, BUT when doing so you sidestep slowly... EVEN AFTER you press the run button or use +speed in the console. Always Run must be switched off to get proper sidestep speed when running, even when using the +speed option (unless you make other settings, I guess?). Please default it back to off. A better fix would be to change the "Always Run" menu option to actually lock +speed on instead of whatever weird thing it currently does.

This is basically what Quake II does.

It's "always run" option, via the cl_run cvar, is exactly the same behaviour as the +speed key. In addition it has the following nice behaviour.

If "always run" is off, pressing the +speed key will speed you up.

If "always run" is on, pressing the +speed key will slow you down.

Even nicer, it's basically (aside from cvar declarations and removing the old cl_forwardspeed behaviour) a one-liner:

I'm coming more and more strongly in favour of this being something that should be standardized across Quake engines. 
Thus far, I've only seen one control scheme for touchscreen that was "ok" (Minecraft) but have some thoughts for improvement.

The difficulty of "getting it right" somehow increases the appeal to me. 
Mark V merely defaults always run on. Like what happens in the original Quake if you toggle it.

Gunter is arguing it should do more than that because turning on "Always run" in original Quake didn't also increase backspeed or sidespeed.

Which I didn't do in Mark V because in my opinion it should use the FitzQuake definition of always run.

So Gunter is arguing against the original Quake behavior, saying Mark V's "always run" should do more (ProQuake's always run sets all 3, for instance).

+speed - I myself have never found a scenario where I would want to walk instead of run in Quake. Not in any of hundreds of single player maps. Not in any of countless of multiplayer games/maps. But I can describe scenarios where changing it to Quake 2 style is a behavior change in original Quake.

I might be a bit of bad person in that I find both of the above kind of topics on the "boring side" of the spectrum. 
OK, I suspected that didn't come across as clearly as intended.

Just to summarize:

Quake has two run behaviours, and they're both different.

"Always run On" via the menus just bumps the values of cl_forwardspeed and cl_backspeed.

+speed applies the value of cl_movespeedkey uniformly to all axes of movement.

Quake II's behaviour is identical to +speed in Quake 1. Let's not get the idea that anybody is advocating for porting "Quake II movement" to Quake 1, because that's not happening.

What Gunter is arguing, and I am supporting him in this, is that the Quake behaviours should be consistent.

This is a simple matter of player expectation and principle of least surprise. If you have a "+speed" key, you expect it to have the same behaviour as "Always run On". 
I prefer the mark_v and fitz implementation of always run. I find quakespasm is too quick to judge when you strafe 
@fifth - Agreed. And because Mark V is intended to preserve the feel of FitzQuake. Modern ProQuake does what Gunter advocates and it doesn't feel exactly the same to me. So I stuck with the FitzQuake way.

@mh - The behavior of +speed is described here ....

Devil's advocate: Why mess with a defined behavior? Couldn't someone who wanted +speed to slow them down instead set cl_movespeedkey 0.5 in their autoexec.cfg?

My thought is this is already available to a user if they decided to do so. So it is not necessary to break defined and known Quake functionality like what, say, Quakespasm does. 
QuakeSpasm, Fitz and MarkV are all the exact same so far as strafing is concerned. No difference whatsoever in the code. 
Devil's advocate: Why mess with a defined behavior? Couldn't someone who wanted +speed to slow them down instead set cl_movespeedkey 0.5 in their autoexec.cfg?


That's not what I'm saying. That's a side effect, not the main thing. The main thing is an "Always run" option that's the same as +speed.

You don't have to have +speed slow you down. Just change the "^" to "||" in the one line of code and it won't.

Again: the main issue is that "Always run" and "+speed" behave differently. I am saying that they should behave the same. That is all. 
And incidentally, the Quake wiki is wrong. That's not what +speed does; all you have to do is look at the code to see that.

What +speed does, in the original Quake code, is adjust all 3 axes of the final movement. It doesn't modify cl_forwardspeed or cl_backspeed. What's described in the wiki is what "Always run" in the menus does (with the exception of the cl_movespeedkey part).

You see - two different behaviours. One modifies all 3 axes: forward/back, up/down, left/right; the other only modifies forward/back. One modified after the full movement is calculated; the other modifies before. One applies the value of cl_movespeedkey; the other just doubles. 
if that's the case why does QS feel a bit twitchier on the strafing than Mark v?

I feel like I hit strafe in QS and I feel I have less control cause I shoot off so fast.

I'm not trying to be an ass about it, genuinely feels different to me. 
I think I'm seeing where you are coming from now. Quake has a number of inconsistencies in that department.

Like how +jump is slower in water than +moveup.

Quake is crazy like that :( 
I almost inserted the word "allegedly" when describing the +speed entry.

(As an engine coder, I don't trust a non-engine coder's description of what something does because they didn't use the code as reference. Although that page was made pre-source code release). 
Here is the "fucked up" thing.

Client movement is "normalized" (vector math).

So if you mess with the sidespeed max, it affects your diagonal movement speed.

This is (probably) why that behavior in Quakespasm doesn't feel like FitzQuake, because I think Quakespasm uses the same increases "all of them" that modern ProQuake does.

Which to me doesn't feel like FitzQuake, which in turn is why I didn't do that in Mark V. 
And when I say "normalized" --- I mean that increasing the sidespeed max has the consequence of decreasing the effective forward speed max when moving diagonally.

So even slight diagonal movement feels different than original Quake/FitzQuake/Mark V in an engine that increases all the speeds like Quakespasm or modern ProQuake. 
I have used QS more frequently recently and that's due to the music not working again in mark v and also the twitch integration in one of the QS forks.

Currently using Mark V off-cam and QS on cam. So there's that I guess.

I also have a "pure" quake folder with winquake and various folders with pretty much each engine.

But I do have to re-adjust my thinking when playing in QS due to the strafe differences. It's probably not noticeable to most people but it's fairly jarring to me for some reason 
QS changed some stuff in 2013, I think it now behaves like you suggest (+speed and "always run" both affect forwardmove/sidemove/upmove, +speed with "always run" slows you back down to walking speed):

(I don't understand why that "cmd->forwardmove /= cl_movespeedkey.value;" line was added though.)

Baker, I play with always run on and do use shift to walk sometimes (e.g. useful for navigating narrow ledges to get to secrets). But I can see where you're coming from regarding keeping winquake / Fitz behaviour identically.

I have a hard time noticing the difference between sidespeed 350 and 400. 
I do like the option to have +speed slow you to walking speed if "always run" is on -- it seems like I've encountered that behavior in one of the other engines, maybe Quakespasm or FTE. It's like, "why not?" because +speed effectively won't do anything if you are already running, so go ahead and have it toggle your speed.

FifthElephant, look on the old page ( ) at post #1154. That will explain why the strafing feels different in Quakespasm (or if you are using a +speed key instead of "always run"). I believe that's actually the correct behavior -- you SHOULD sidestep fast if you are running, so you can avoid rockets and stuff.

I really dislike my sidestep speed suffering when "always run" is on. I know Baker has resisted making an adjustment to this behavior (which I believe is a flaw or oversight in Quake's original coding -- and I would much prefer it to be consistent as mh suggests), but my plea in that case it to leave the menu option defaulted to OFF (as it was in original Quake). It ends up being more config settings for me to return to Quake default behavior:

cl_forwardspeed 200
cl_backspeed 200

And I actually have a key bound like this:

alias +slow -speed
alias -slow +speed
bind b +slow

because sometimes I do want to return to walking speed, like if I want to position myself carefully to take a screenshot, or to get just the right sniper position, or if I want to build up a massive fireball for the Mage in FvF (his Delayed Fireball attack travels at walking speed, so if you are moving forward and firing them, you get like 4 of 5 of them all piled on top of each other, heh, for a massive explosion when they hit something).

Touch-screen controls? Yikes. That would be tricky. If someone really wants to play Quake on their phone, I'd say, "get a bluetooth gamepad," heh. Like the Ipega 9055 that clamps around your device.... 
Yes, my bad, that was indeed changed.

It looks as though that line was added to prevent cl_movespeedkey from being applied twice, once from the menu code and once from the following block.

Quake II drops the side speed default to 200, then when always running it goes to 400.

I wonder how all of this behaves with values of cl_forwardspeed set in configs? 
I just checked and Quakespasm also modifies forwardspeed and backspeed. Now I'm even more confused. 
Hey, what about a sort of compromise where the "Always Run" menu option would have 3 possible values:

All Directions 
Regardless, anyone who doesn't like autorun behaving exactly like +speed can just set some cvars instead of using the menu item. Being picky about EXACTLY how something behaves is experienced users' lot, and experienced users shouldn't have any problems creating an autoexec.cfg.

A reminder:

cl_forwardspeed 400
cl_backspeed 400
cl_sidespeed 350
cl_upspeed 200

Those are the values for when autorun is toggled ON from the menu in the original game. If you want to be able to walk, set cl_movespeedkey to less than 1 and use +speed to slow down.

Though you might want to set cl_upspeed to around 400 if you don't want to swim like crap. 
Nice To Know Dwere 
@dwere For The Win; "Keep It Simple" Is Winning Strat 
Being picky about EXACTLY how something behaves is experienced users' lot, and experienced users shouldn't have any problems creating an autoexec.cfg

When I first started engine coding I discovered "expert user bias". I was building modern ProQuake, I added a field-of-view slider that went from 90 to 110. Spirit said "I use 130 and the slider doesn't go that far".

I wasn't for or against anyone's particular settings but it didn't take long to realize that accommodating all preferences while keeping things simple for the average user.

Expert users can already do what they want.

There are engines that try to appeal to all possible settings.

ezQuake has a ridiculous settings menu with several pages and each of them scroll. Likewise, DarkPlaces has menus galore.

I think this flies in the face of the KISS rule --- "Keep it simple, stupid!"

"Keep it simple, stupid!" -- is why conservative engines rule and why advanced engines are frustrating. 
I probably shouldn't harp on this, but this is what I believe ...

Bad engine design expresses itself in the form of menus. 
Well, the thing is: an average user would probably prefer autorun to behave in a modern, convenient way. The problem here isn't even the fact that there are subtle movement angle differences. There are more jarring symptoms of hackery.

Like, turning the autorun ON doesn't invert it. In other words, you can't slow down anymore. I can't recall any game made in the last 20 years that would behave like that.

Another thing is that the strafing speed is locked at 350, which means that you can't strafe slowly at all.

Bad engine design expresses itself in the form of menus.

This I agree with. Doom source ports are a great example of what happens when you pile up engine modifications and try to be flexible about them. Though the game was always at a disadvantage when it came to extending the gameplay functionality. 
There are also certain mod concerns with how the menu always worked.

Malice is probably the only example, but I consider it fairly important. Toggling "always run" forces certain speed settings upon the player, which is fine in Quake, but what if the mod wants different values?

Having a separate variable would allow mods like Malice to have a (somewhat) working autorun toggler that wouldn't break anything.

Just my two cents. Since I'm aware of the problem, it doesn't really affect me. 
But the behavior of Quake's always run is hardcoded in menu of the Quake engine. So whether or not Malice has different settings that option in the menu changes it just the same.

Mark V is meant to be an equivalent drop-in replacement for the original Quake, except that it has Quake's definition of mouse look and always run on (instead of requiring a user to go to the menu).

Mark V does not change any of the Quake cvars from their default -- aside from the always run defaulting on. 
But the behavior of Quake's always run is hardcoded in menu of the Quake engine. So whether or not Malice has different settings that option in the menu changes it just the same.

I know. That's the problem.

I hope that at least QS will implement the Q2-like functionality (I think there were some plans for it), because what's there right now clearly isn't that. 
I actually kind of like EZQuake's menus, I remember installing it and spending a good 30 - 40 minutes messing around with all the different options to see what changed. Should totally add a 15+ page menu with every possible cvar on it to Mark V. /s 
(ironically That Engine Was At One Point A Model Of Clean Design) 
I thought ezQuake was the possibly the greatest Quake engine ever the version before they did that with the infinite menus and the laggy mouse driven cursor.

When it was like a FuhQuake with extra features, it had a simple menu that let you do many general settings.

So at one point, ezQuake was quite a nice engine that was laid out so cleanly it was arguably the model of excellent engine design.

Then they decided to add "Cool features" or something and it got all dorkulated. 
I'm Surprised 
That Baker even added the extra menus that he did. I never expected much more than standard 
Re: Adding The Preferences Menu 
I hated every second of it. I felt like I had failed.

WinQuake gun position as an option forced me to do it.

I still try to think of ways to kill the preferences menu. 
Having additional menu items is fine, as long as the menu as a whole stays concise and organized. Not adding important things that regular users might need is about as bad as adding unnecessary junk.

For example, adding "previous weapon" to the controls menu is helpful. 
It's funny that you say that cause I agree, despite using that menu myself. Unreal had a little known secret menu hidden from the casual user. I think that is a good way of having a clean look but allows power users to tinker 
The benefit of menus is that they provide the user with visible options that they otherwise won't know about (because they are hidden in obscure console variables).

Experienced users are mostly aware of these options, but Mark V has so many more options (with not-so-great documentation) that even I am uncertain I know all the options I may want to fiddle with. The "find" option in the console is certainly very helpful, but you have to know what you want to search for before you can search for it.... With a menu, it's like, "oh, that's an option? Neat, let's see what it looks like..."

I don't think being "automatically anti-menu" is really the best approach. The problem may be that you've encountered some BAD menus, but that doesn't mean all additional menus are bad.

It would be nice to have the Basic menus for the basic user, then perhaps some deeper level of Advanced menus for people who really want to tweak their settings (sounds like that secret menu FE just mentioned).

I'm against "bad menus" myself.... I don't want things to get too cluttered up when I am trying to change some basic options. But I am not against having advanced menus with tons of settings in them, as long as they are clean and easy to understand and navigate. 
I think Quake is in a unique position because a lot of it's defaults are actually no longer sensible defaults.

That's at least partially on account of it's heritage - moving from a mostly-keyboard setup with no free looking, nobody actually had a clue how the game would have been played.

It's obvious that ID had expected joysticks to be the predominant control mechanism. Just look at all the joystick setup cvars, the existence of a dedicated readme for joysticks, sample .cfg files for different models, sponsorship deals, not to mention the ganky joystick code in the engine itself.

The existence of sensible defaults means that menu options are not really such a huge necessity. In Quake you need to either change the defaults or give the player an easily discoverable way of doing so themselves. 
"I do like the option to have +speed slow you to walking speed if "always run" is on -- it seems like I've encountered that behavior in one of the other engines, maybe Quakespasm or FTE. It's like, "why not?" because +speed effectively won't do anything if you are already running, so go ahead and have it toggle your speed."

I also have this behavior in Qrack, if your speed is > 300 then it will cut your speed in half, if its less then it will double it, both forward back, side as well. I'm used to pressing shift in modern games to "sprint" so it helps. 
@r00k - Gunter Quote 
Your quote of gunter -- that's actually probably the strongest argument I've seen.

Not the "other games" part -- I'm indifferent about that -- but the +speed "doesn't do anything if you already running".

I somehow missed seeing that in the thread until now. Probably because where lots of comments in a short period of time. 
The core issue is that all of the cl_*speed cvars relating to movement have defaults of 200, with the exception of cl_sidespeed which is 350.

Most people are used to "always run" just doubling forward and back speed, so it becomes forward 400, back 400, side 350 and up 200 (up is rarely used).

Doubling the speed on all axes, either via +speed or a Quake II-ish method, will increase cl_sidespeed further and cause it to dominate.

Quake II changes cl_sidespeed to 200 and removes cl_backspeed. I'm not sure when cl_sidespeed was changed but I do know that cl_backspeed was removed in the last month before Quake II went gold, so that was a change made after Quake II was it's own engine rather than just an experimental branch of Quake.

Quake II also changes cl_forwardspeed to not be saved to your config. I believe saving it was just a hack in Quake 1 so that the always run setting would be saved, but have no evidence either way.

All of this is discussion points. I know which behaviour I personally prefer but I'm not trying to convince anyone else. 
So, does capturevideo only work when watching a demo? Or can it record "live" gameplay? I set my codec and FPS but it complains about them not being set when i enter the command. If it only works on demos, adding that explanation to the error text would be useful. 
You can capture in real time, but capturevideo is intense and not necessarily a good fit for real-time capture --- it's going to be an fps/cpu hit and at higher resolutions the penalty gets stiff.

bind x "capturevideo toggle"

Make sure you have the other capturevideo settings the way you want:

capturevideo_codec xvid // I'd recommend this at least at first
capturevideo_fps 15 // You can always increase it.

Smaller resolutions like 640 x 480 are going to work better than larger ones because pixel count increases drastically.

You may also wish to consider something like Bandicam which works great with DirectX which Mark V DX9 obviously is. Someone earlier in the thread said how great Bandicam is. 
"Quake II changes cl_sidespeed to 200 and"

no wonder i always though sidespeed was weird in quake 1.
I played Quake1 freeware version all the way through, then later played Quake II extensively. Then came back to Quake 1.

//R00k: i didnt want +/-speed with 'always run on' to eventually STOP the player, but instead toggle the speed from walk to run, or run to walk.

if (cl_basespeedkey.value && cl_movespeedkey.value)
if ((cl_forwardspeed.value > 200) && (in_speed.state & 1))
if (!(in_klook.state & 1))
cmd->forwardmove += 200 * CL_KeyState (&in_forward);
cmd->forwardmove -= 200 * CL_KeyState (&in_back);
if (!(in_klook.state & 1))
cmd->forwardmove += cl_forwardspeed.value * CL_KeyState (&in_forward);
cmd->forwardmove -= cl_backspeed.value * CL_KeyState (&in_back);

if (in_speed.state & 1)
cmd->forwardmove *= cl_movespeedkey.value;
cmd->sidemove *= cl_movespeedkey.value;
cmd->upmove *= cl_movespeedkey.value;
if (!(in_klook.state & 1))
cmd->forwardmove += cl_forwardspeed.value * CL_KeyState (&in_forward);
cmd->forwardmove -= cl_backspeed.value * CL_KeyState (&in_back);

if (in_speed.state & 1)
cmd->forwardmove *= cl_movespeedkey.value;
cmd->sidemove *= cl_movespeedkey.value;
cmd->upmove *= cl_movespeedkey.value;

only issue i have with above code is when you set your speed cvars to something like 180 then you will go in the opposite direction with +speed :P 
no wonder i always though sidespeed was weird in quake 1.

Probably to make dodging easier for keyboard-only players. Once again, only somewhat relevant in 1996.

Useless trivia: Chasm made itself look like even more of a Quake clone by copying this behavior.

only issue i have with above code is when you set your speed cvars to something like 180 then you will go in the opposite direction with +speed :P

Uhhhh, I have them at 160... 
So is that "reloading the level dead" bug specific to Mark V? I've been getting it a lot lately. Don't remember ever seeing it with QS. 
Centerprint Positioning 
<p>if (scr_center_lines <= 4)
y = vid.height*0.35;
y = 48;</p>

This code always puzzled me. At modes larger than 320x200 the result is that centerprints more than 4 lines (including the e2 entrance message in start.bsp) will be rammed up near the top of the screen, whereas centerprints of 4 lines or less will be more accurately centered. This looks awful.

There was some kerfuffle over the whole thing in the old thread.

I believe I know the reason why.

It's for the slow finale printing at the end of an episode.

The give away is the positioning of the gfx/finale.lmp banner in Sbar_FinaleOverlay - it's at a y of 16, and when we add the banner height of 24 we get 40; 8 more pixels for a blank line between the banner and the centerprint and there's the 48.

Why did Carmack do it this way rather than checking for cl.intermission == 2? Probably the same reason he did a lot of other crazy-seeming things in the Quake code - a rush to get things done and get the game shipped. 
Some further evidence: Carmack's .plan for 17th June 1996 gives us the exact date that the centerprint change was made.

Interestingly he was also working on items relating to level transitions and boss/finale stuff on that day. "end of e4 text crash" was an item. So the evidence definitely correlates this change with work on finale messages. 
Well, like you said, he could have easily made it only apply to the "Congratulations" messages and not other Centerprints if he wanted, but he just notes in the changelog:

"changed center print position for very long text messages"

And I'm sure he would have noticed the E2 entrance message being affected by this, since it's right on the Start map, so it's no accident.

It just makes sense to me that any "very long" message would be moved up, out of the direct center of your view.

I actually didn't know that the Congratulations messages were considered Centerprints -- they use different functions in QuakeC, but I guess the engine funnels them through the same printing method. I tested it and, indeed, an end level message of only 4 lines will be centered lower on the screen. Weird.

If he were just trying to position those end-level messages only, counting the number of lines would be a very hacky way to do it. that sounds like something *I* would do! 
Picked up a couple of new Mark V users last night -- some old returning FvF players (I'm talking old players from the 90s).

They said Mark V works much better for them than GLquake (obv!), but they were still having some connection problems -- and I've seen another player who has this issue on the server too (I think it's Mr. Burns who has this issue, maybe):

When the level changes, they get stuck in the console and never reconnect to the server. We still see their names as connected players, but their frags are shown as "0." I believe we told Mr. Burns to try typing "ping" in the console when this happens, and that sometimes allows him to connect and get back in without having to totally reconnect and lose all his frags.

I don't have any control over the server (Polarite does that), but it appears to be running "Magic ProQuake Server Version 3.90" in linux.

I really can't provide much more information about this issue.... I assume it's one of those things where it gets stuck doing the "keepalive" messages in the console. I'll ask more specifically the next time someone encounters this -- it's only a few players, but it affects them consistently.

Also, one of the returning players asked about mirrors -- he wanted to be able to see his reflection (mentioning that it was a pretty big deal/cool feature back in the day), and I told him mirrors only worked when running plain ID1... but I realized that it really SHOULDN'T be this way, as it violates what I think should be a pretty important aspect of Quake engine design: you shouldn't take away user control and force your own preference on the end user (even with good intentions).

I mean, there are already various mirror variables that the user can set if he wants mirrors to be on or off (and actually, they should probably be off by default). If the user wants to turn them on, even in a mod or map where it might not work well, he should be able to do so.

Also, for those users that want to play with mirrors, how about an easy way to set a mirror texture. Specifically, something like (probably used in conjunction with tool_texturepointer, but not necessarily): if you input "set_mirror" in the console, it will assign the mirror effect to whatever texture you are pointing at (manually typing in those texture names for the mirror texture prefix is a chore and prone to typos, heh).

Of course, there's the issue of having to restart a map before it takes affect, but it would still be handy for people that want to play around with mirrors.

I suppose it would be handy to be able to feed the pointed-at texture into any of the tex prefix variables, actually.... Not sure how that could be implemented, other than copying the selected texture name into the console and allowing tab to autocomplete the various things you might want to apply it to.

Ah, yeah, it would work if you just had it stick "r_tex [copied texture name]" in the console and positioned the cursor right after r_tex, then tab will autocomplete all the various r_texprefix things with the selected texture already filled in. 
Mirror ??? 
I want to see a Quake ingame video of this effect 
If he were just trying to position those end-level messages only, counting the number of lines would be a very hacky way to do it. that sounds like something *I* would do!

This is actually exactly the way Carmack coded a lot of things in Quake.

How did he test to see if you were connected to a server and therefore the status bar should be drawn? By checking the number of console lines drawn. How did he test to see if a map was running? By checking if the console was fullscreen. Quake is full of crap like this. 
Holy shit. I would love to read a compilation of "quake code nightmares" like this. 
Lightmapped Water 
Well that was unexpected. :/

The "semi-official" 32-player deathmatch map death32c, still available on ID's FTP server ( has lightmapped water.

And the lightmaps are messed-up:

I guess this means that other maps with messed-up lightmaps on water surfaces may very well be out there in the wild, but in the absence of engine support for lightmapped water nobody was ever aware of them.

You could control this with a cvar but that's pushing responsibility back to the player, which I don't like.

Since lightmapped water is a new feature I suggest a worldspawn key indicating it's presence. That way engines that don't support it can ignore it. Engines that do support it can pick it up. Maps like death32c aren't subject to false positives. 
I wonder which compilers were writing that junk data? Worldspawn key has my +1. I've already forgotten all the discussion we had a while back, so I'm a clean slate on that (except for the point that it'd be really cool, that still stands). 
check the styles. if there's multiple 0s then its clearly uninitialised.
while its possible for a light util to write multiple of the same style, 4 of them is basically pointless as it would oversaturate everything. 
check the styles. if there's multiple 0s then its clearly uninitialised.

Bingo, buy the man a large beer.

I believe that these maps may have been lit with ID's then-unfinished qrad tool. 
DarkPlaces shows the same problem on death32c:

I would lean towards a worldspawn key now as well, since there are no released maps using lit water yet. 
"Quake Code Nightmares" 
From the video code:


These are all global variables that are used to store what is essentially the same information. I don't even think I have all of them here. But all that you really need to store is the window handle and you can derive everything else from it. Sure you can potentially optimize by caching some stuff, but this crap reads like any time something was added to the video code, a new set of globals was added just for it. Of course they all have to be kept in sync and consistent, so any work on the video code is a tangled mess from the outset. 
I'm trying to host a dedicated server with this and anyone outside my network can't connect..

I love how faithful this client feels to the original Quake and I know netquake is tricky and not as ideal as QW but honestly QW feels OFF to me..

Any ideas on why folks can't connect? Tried dedicated.. noipx.. My ports are open, no firewalls.. I hosted a QW server last night without a hitch. 
Mark V should launch a single port server just like Quakeworld. Only port 26000 needs to be open. (Feature is essentially courtesy of Spike).

It could be the clients other people are using.

By default, Mark V uses FitzQuake protocol 666 --- this means DarkPlaces and ProQuake cannot connect, for instance, since they don't support protocol 666. sv_protocol 15 is regular Quake.

What you should do is try to connect to yourself from another client through your public IP. Also you may wish to do sv_public 1. 
ericw: I lean towards worldspawn key

If that's the best way to do ... then whatever solves the problem ;-) And any engine should be able to read a worldspawn key pretty easy ;-) 
@JPL - Mirrors ... 
Mirrors ... here you go ...

If you want to play on that quickly assembled test map:

Pulsar threw a mirror into Arcane Dimensions ad_magna map, but it is very difficult to find it because the map is huge.

In Mark V, type "setpos 2496 56 -292" in the console with ad_magna loaded and teleport directly to the mirror ;-) 
Yeah, folks were using Mark V and could connect to my QW server just now.. haven't tried SV_public 1

The server does list my local IP rather than external, anything I need to do there? 
Also super weird... I can't connect to my own server anymore using localhost, 127, or my network address.. but I CAN join through the multiplayer public menu. No one else can see my server though. 
And when I type sv_public it says UDP WRITE, sendto, bad adresss ? 
Holy shit. I would love to read a compilation of "quake code nightmares" like this.

It's turtles all the way down. 
Add -noudp6 to the command line to disable ipv6.

See if that solves the problem, what operating system and version are you using? Like is this Windows XP or a certain version of Linux? 
I'm using Windows 10, it's definitely attaching to an ipv6 address so I bet that will do something. I'll try it later, thanks for the help! 
I've seen that ipv6 oddness before, but not on Windows -- ironically, the iPad example doesn't like ipv6 when connecting to a server.

The next time I load up Windows 10, I'll see how it reacts to ipv6. 
Something I noticed with Mark V - Release 1.00.

When I first get into the game, my frames are all over the place for like 5 seconds and then it goes to normal, anyone know why? I'm on an AMD 480, Freesync with windows 10.

Also an FOV adapt feature would be nice, Like the one in QuakeSpasm. 
Also an FOV adapt feature would be nice

Mark V uses a similar algorithm to fov adapt, although if I recall it is an mh variant (640/432?). Even the software renderer uses it.

It can't be turned off, but since it is aspect ratio correct, I can't think of why someone would want to turn it off.

If misunderstood what you meant, let me know. 
Cool I'm fine with that!

Also...being able to change mods/maps in game would be great...instead of just being able to change the levels.

Something QuakeSpasm doesn't have, you have to use Injector.

Injector works but seems it will never had a final version. 
Something QuakeSpasm doesn't have, you have to use Injector.

QS and MarkV both have this, the "game" command:

game xxx
exec quake.rc (optional.. loads the configs from the new mod.) 
In Mark V, you can type "install travail" or "install rapture" in the console and it will install Travail or rapture off Quaddicted.

You can type "install b" and press TAB and it will autocomplete one of the about 530 Quaddicted mods recognized.

I'm just lettting you know these things.

Like ericw pointed out, the "game" has existed for a very long time in FitzQuake and derived engines like Mark V and Quakespasm. 
there's a mirror in my explore jam 2 map as well. it's big and right on the mandatory route.

I do love this feature. 
I remember the mirror corridors section in Prey (the old one, who the hell decided to call the new game the same as the old one that did not have any siquel). I wish it could have been done in mark v, but it's impossible so far with one mirror at a time limit.

I still wish it will be possible one day. 
The calculation I used originates in a thread at and an online FOV calculator that used to be at - the latter can probably be picked up at nowadays.

I just lifted the calculations over to the Quake engine.

640x432 was chosen as a baseline aspect ratio which everything is calculated relative to. This is GLQuake's default 640x480 less 48 status bar lines. Arguments can be made for and against different baselines.

QuakeSpasm uses a different widescreen FOV calculation standard, and I'm not going to argue that either is more correct than the other. The great thing about standards is that there are so many of them. 
Still no one will comment on my bug :( should I try and make a demo of it or something? Do those even work when the issue occurs when restarting a level? 
#1376 ? 
I think it's safe enough to say that nobody else has even seen that bug.

You might give a little more info. Map? Custom progs? Etc? 
I first mentioned this happening in post #1182, here's the link I posted back then:

That's a RJ6 map, and I'm pretty sure that pack used original id1? Anyway, what happens is that if I die and click lmb to restart the map, I start the map "dead" like in the video. Except I can swing my invisible axe and make particles, also shown in the video. I'll see if I can make it happen again soon and try collecting more evidence. 
Here is me playing that map ...

Kinn was playing that map in WinQuake and he didn't say he had a problem with dying and spawning wrong.

There are tons of QuakeC bugs (i.e. the progs.dat).

A demo and a savegame would be something to go ;-) 
Yeah, I'll try playing some id1 maps tonight and see if I can get it to happen. I've had it happen both in that map and one other which I forget the name of. The other one was a mod though so it's not as useful. 
I've experienced this numerous times (can't confirm the axe thing, never tried) with vanilla quake. I was unsure if the behavior was intentional and too busy to check. 
The two new Mark V users played again tonight, and both experienced the disconnecting issue when loading a new level. One of them had fiddled with his firewall and thought he'd maybe fixed it, but nope. It only happened to them one time each. It's odd that both of them are having the issue, since they have different setups.

One is from Texas, one is from Canada. One is Win7, the other Win10.

The error they said they got was "level load failed"

One said he usually spams the console with "ping" to sometimes get back in... but I guess it didn't work this time.

I told them to try and come here and post any more details if they could figure out anything else.

Other than that, they really like Mark V, heh. 
You might need to adjust your server's connection timeout, and to be honest as a non-server operator I'm not 100% on how that's done.

Are they using external textures or lots of external fluff? (If they using the really high res versions of an external texture pack, the impact is going to be multiplied.)

During reconnect, if someone is using a lot external textures it increases the load time and can increase it beyond the connect timeout.

I've played a number of multiplayer games on your server. Never had any level change problems ever.

But I don't use external textures except if I am doing testing that needs it. 
I think I found out how to repeat the bug: it happens when you die after reloading a save. Or at least a quicksave, I haven't tested with regular saves but I'd assume it's the same. Can anyone else make this happen, or just me? 
I'm able to reproduce this problem. I'll see what's up when I have time. 
The "semi-official" 32-player deathmatch map death32c, still available on ID's FTP server ( has lightmapped water.
And the lightmaps are messed-up
other maps with messed-up lightmaps on water surfaces may very well be out there in the wild, but in the absence of engine support for lightmapped water nobody was ever aware of them.
Since lightmapped water is a new feature I suggest a worldspawn key indicating it's presence. That way engines that don't support it can ignore it. Engines that do support it can pick it up. Maps like death32c aren't subject to false positives.

DarkPlaces shows the same problem on death32c

Just because mh, lordhavoc and others don't know how to reliably detect lit water, it doesn't mean it's impossible. Retroquad never accepts false positives.

Cluttering the tools and engine code with a worldspawn key for this is pointless, and only serves to hide the fact that the engine's support for lit water is done poorly.

Also, let me rectify Baker's false statement @ #1285:
Mankrip said maps like e1m4 don't compile with lit water.
This is false. What I said is that a few ID1 GPL maps such as e1m4 has countless leaks. This means that their VIS data can't be compiled, which has nothing to do with the lighting. I've already compiled it with lit water and no VIS ages ago, but I wanted to be able to get the VIS data compiled too.

Until someone steps forward proving any of this stuff works and is polished ... I'm not sold.
The solution in Retroquad works flawlessly, is robust, clean and polished. But I try not to care about proving stuff for others. Nobody ever asked me about it, it would just make me seem bitter, and I'm sure I've already mentioned ages ago that the Retroquad implementation of lit water was finally perfect.

Also, <a href="">by the end of last September, EricW's implementation in the light tool was already perfect too. I've done extensive testing for him and showed it when the final problems got fixed. 
</a> Fail 
I always have net_connecttimeout set to 45 seconds, and I know the players with the connection trouble aren't using any external textures (I keep telling them they should try the external textures, heh).

It could very well be some issue with the server. It's just odd how it only affects certain players, and it affects them repeatedly, but nobody else. Extra odd how it affects BOTH these two new players....

Though the fact that it's known that typing "ping" in the console can sometimes get around it, would indicate that it's been a Quake issue for a long time....

I can't really provide enough information about it to really troubleshoot :/ 
I didn't know the GPL map sources for e1m4 had leaks. I thought when you mentioned the problem that it was a tool issue when using lit water.

Anyway, the conversation evolved a lot since then and yeah ... I'm sold now.

But my non-belief was largely due to the apparent non-existence of any known test maps.

When avirox, myself and gb were working on true rotation, we made a number of test maps with QuakeC sources, engine sources, .map files and map compile instructions. 
I guess if one of them could play using "developer 1" and also record a demo, then the next time they get the problem zip up the demo + qconsole.log, there would be some information to go on.

From your description about how typing "ping" helps, it sounds like a message got blocked by a firewall in a non-NAT fixed client.

If I had a qconsole.log where developer 1 was enabled where one of these players had the problem, I might be able to learn more.

I just now connected to your server, I don't experience this problem. And apparently you don't.

At the moment, there really isn't enough information to speculate. 
So how do you detect that those water faces weren't compiled with lit water? 
I obviously can't speak for Mankrip, but I adopted Spike's suggestion of checking the styles too, and confirmed that they were all 0. Lightdata offset for these surfaces was also 0, so whichever light tool was used clearly left the surface uninitialized rather than explicitly setting offset to -1.

My current tests looks like this:

1) Initialize loadmodel->litwater to false at the start of Mod_LoadFaces.

2) Check lightdata offset as standard; if it's -1 there's no lightmap so none of the rest applies.

3) As an additional check test all styles for 0 and lightdata offset for also 0; if this check passes then we have an uninitialized surface so also no lightmap.

4) Otherwise there is a lightmap; at this stage check if the surface has a water texture and if so loadmodel->litwater goes to true.

5) Finally when building the surface polys and lightmaps, I set surf->litwater to the value of m->litwater.

It's clear what happened here; the code that correctly initializes the face for no light ( must have been removed from whicever tool was used for lighting this map. 
ericw: Detecting maps compiled with lit liquids.

mh: whichever light tool was used clearly left the surface uninitialized rather than explicitly setting offset to -1

That's not a problem, because there's no need to initialize the surface cache parameters since they should be ignored on non-lit surfaces. See my code on the link above.

My current tests looks like this:

1) Initialize loadmodel->litwater to false at the start of Mod_LoadFaces.

That is bad. Non-lit surfaces are defined on a per-texture basis, and it's perfectly possible for a map to be compiled with both unlit slime and lit water, for example. The engine should not use a global setting for this.

4) Otherwise there is a lightmap; at this stage check if the surface has a water texture and if so loadmodel->litwater goes to true.

There's no need to tie the engine's lightmap usage to texture naming conventions.
One of the potential ideas I have is to implement support for non-subdivided unlit surfaces with regular textures: for example, surfaces using fully black textures (or textures with fullbright texels only) could be rendered much faster this way.

the code that correctly initializes the face for no light (...) must have been removed from whicever tool was used for lighting this map.

It was not removed, because what truly defines the lack of lighting on specific surfaces is not the face data. The map was correctly set to use no lighting. 
TEX_SPECIAL works cleanly. I guess the fact that it's unused in the engine made it easy to miss.

That's not a problem, because there's no need to initialize the surface cache parameters since they should be ignored on non-lit surfaces. See my code on the link above.

I'm actually talking about the face having been left unitialized by the light tool, not by the engine.

If you check the link I posted to LightFace ( you'll see that what it does is first set offset to -1 and all styles to 255, then does the TEX_SPECIAL check.

A face with TEX_SPECIAL should also have offset -1 and styles 255. death32c has faces with TEX_SPECIAL and offset 0, styles 0.

The only concern I have about using TEX_SPECIAL is that it's set by the bsp tool, not the lighting tool. This may be purely theoretical: are there any bsp tools that don't set TEX_SPECIAL? 
nice catch, those water faces in death32c have the TEX_SPECIAL flag set on their texinfo. So I agree there should be no need to have special handling for styles = (0 0 0 0) and lightofs = 0; seeing TEX_SPECIAL is enough to indicate that they are meant to be rendered fullbright. 
Lest my questioning be thought of as criticism, I'm actually really happy with the outcome of this. I was able to simplify a bunch of horrible code and the case where one liquid type is lit but another unlit just falls out naturally from it.

It's rare in Quake that the right solution turns out to be so simple, but this is one of those moments. 
@pritchard (@mh @mankrip @ericw) 
Pritchard, awesome beta testing work you did in identifying the situation causing the problem.

I've identified and solved the issue.

@mh @mankrip @ericw - pretty cool discussion sorting out the inner mysteries of lit water. It's nice to see lit water look like it getting closer to go "prime time" from the bsp editor to the compiler tools to the engine. 
I guess the only real outstanding questions I have are (firstly) relating to dynamic lights.

Specifically: should unlit water surfaces receive dynamic lights?

Now, I would LOVE to put dynamic lighting on all water surfaces, lit or not. But it's admittedly easy for me because I've decoupled dynamic lights from lightmaps - it's just commenting out one line of code. (This also made it easy for me to add dynamic lights to BSP brush models.)

The other one is interaction of lightmaps and translucent water.

I've pretty much decided that translucent objects of all kinds (water, glass, etc) don't get lit - they're translucent so light goes through them rather than reflects off them. So instead they're drawn fullbright but with translucency. 
I think this has been brought up before, and I stand by what I said back then. Lighting translucent surfaces is the way to go. I think it would look more accurate, considering that surfaces which are semi-opaque (i.e. 99% of water/brush alpha uses) will still catch/reflect some light in real life.

Also, having to choose between lit water and transparent water would suck. 
This may be purely theoretical: are there any bsp tools that don't set TEX_SPECIAL?

The only one I know of is the -splitspecial flag from TreeQBSP (which is in tyrutils, as well as Bengt's TreeQBSP). TxQBSP (as well as id qbsp) always set TEX_SPECIAL for texture names starting with * or sky in map.c:FindTexinfo.

I guess if someone happened to compile a map with TreeQBSP/tyrutils and used "-splitspecial", and then used whatever light tool was used for death32c.bsp, we could have false positives again, but it seems pretty unlikely. 
The SQLauncher is AWESOME.

I've been renaming all my map titles in the Quake folder to the actual name of the maps, and I can just use SQLauncher to play them. It takes a bit more time renaming everything, but it's much neater. And you will actually the map title.

Quake Injector is a bit buggy, I just prefer to download maps from Quaddicted one at a time so I know what I'm getting. 
The SQLauncher is AWESOME.

I've been renaming all my map titles in the Quake folder to the actual name of the maps, and I can just use SQLauncher to play them. It takes a bit more time renaming everything, but it's much neater. And you will actually the map title.

Quake Injector is a bit buggy, I just prefer to download maps from Quaddicted one at a time so I know what I'm getting. 
mh: should unlit water surfaces receive dynamic lights?

In the software renderer, that's impossible; surface caches needs surface subdivision.

ericw: I guess if someone happened to compile a map with TreeQBSP/tyrutils and used "-splitspecial", and then used whatever light tool was used for death32c.bsp, we could have false positives again

It wouldn't be a false positive. It would be a true positive, because the lack of the TEX_SPECIAL flag would make the light compiler treat liquid surfaces identically to regular surfaces. The only problem would be the lack of backlights, which can be solved by recompiling the lighting alone, without modifying the BSP data. 
Specifically: should unlit water surfaces receive dynamic lights?
I'd say it's up to each engine. I'd personally leave unlit water without dynamic lights.

I've pretty much decided that translucent objects of all kinds (water, glass, etc) don't get lit - they're translucent so light goes through them rather than reflects off them. So instead they're drawn fullbright but with translucency.
I'm with Pritchard, IMHO semi-transparent glass and lit water should still get lightmapped. Fitzquake 0.85 does lightmaps on func_'s with the alpha key < 1, though I'm not sure how many maps make use of lightmapping on glass, Fifth & I exploited it in ad_tfuma.bsp for example:

The logic, I guess, is that you can see shadows on dirty, scratched up windows.

It wouldn't be a false positive. It would be a true positive, because the lack of the TEX_SPECIAL flag would make the light compiler treat liquid surfaces identically to regular surfaces.
Ah right.. in that case, even the vanilla id light.exe would generate lightmaps for the water/sky. I guess a better question is, how many released maps (e.g. in quaddicted, or idgames) used TreeQBSP's -splitspecial option, and thus have lightmaps for their liquids? This would be a time when it's handy to have a mirror of quaddicted and run a script across all of the maps.

I'm guessing the answer is "0". 
Wow Yeah 
translucent water *has* to get lightmapped. In fact, the translucency is going to be essential to sell the lightmapping as convincing, otherwise water is going to look like pea soup. 
If you can see the surface, then it reflects light. A certain amount of light passes through it, but not all of it.

Besides, like I said earlier, translucent objects (or any objects, really) glowing in the dark doesn't make any sense in a lot of cases. 
Feasibility Of An In-fighting Slider 
Wondering if this is even possible from an engine perspective? One of my answers in sock's recent survey post:

5. Are you put off by certain monster (horde) setups?

No. I don't love excessive in-fighting though. It's frustrating and I wish modern source ports could have a "slider" for in-fighting. Perhaps: "never>rarely>normal"  
That would get very buggy very fast. Play a map like ad_tfuma, it opens with a bunch of infighting. If that was disabled it wouldn't be the same. 
Infighting doesn't come from the engine anyway, it comes from the QC. It would be totally inappropriate to put any kind of control over it into the engine. 
I was asking if it was feasible.

re: ad-tfuma Not sure if it would keep you from playing the map though? Also not really necessary in AD as mappers can add a key to suppress infighting. So it would really just be for vanilla Quake. As I asked: Wondering if this is even possible from an engine perspective?

mh - why would it be "inappropriate" to add this feature to an engine? 
The Infighting In Ad_tfuma 
is planned and set up using triggers.

I'm not sure why you would want to alter this behaviour as this is my vision for the map. 
the logic of the game is in QuakeC
the monsters are in QuakeC
the infighting rules are in QuakeC

the only thing that the engine can do is put the slider in the menu 
I mentioned above this would be for vanilla Quake not AD and it's just an inquiry. Not trying to destroy your art. ;)

@topher yeah I get that's how it works. It was more of an academic question. Wondering if you could modify QC behavior through the engine. Apparently not. 
my guess is that it's possible but it will be hacky, bug prone and harder than modifying and recompiling a new progs.dat 
Wondering if you could modify QC behavior through the engine. Apparently not.

Well the engine can change the QC, but that's not really the point. The logic that deals with infighting is all in the QC, so all you could really do in the engine is do something like a truly disgusting hack such as preventing self.enemy from changing on an entity if certain conditions are met. However, you could only reliably guarantee it working for id1 (the assumptions you make in the engine to make it work for id1 wouldn't necessarily be valid under any other mod), and any other mod being run under it could break in all sorts of subtle ways. 
mh - why would it be "inappropriate" to add this feature to an engine?

First read Kinn's answer just above - that covers the technical reasons why.

Then read Fifth's answer because it covers the gameplay/modder perspective.

I know you said that you were asking about vanilla Quake, not AD, but it's still relevant. Infighting is a designed behaviour of vanilla Quake - it's even mentioned in the Quake manual:
Q: Did I really see two monsters fighting each other?
A: Probably. Some monsters hate one another almost as much as they hate you. You can use this to your advantage (exercise left up to the reader).

Infighting is game logic and the correct place to modify game logic is in the QC code. The engine should not try to inject modifications to QC code. I'm actually shocked and appalled that this even has to be explained. If you want to modify the QC code, the correct thing to do is... modify the QC code. Make a mod with reduced infighting and play that instead. 
IMO This Should Be A Progs Thing 
If you really want such a feature then make your own progs or throw money/sexual favours at someone to do it. 
I'd do it if you threw money at me ;)

I actually previously modified this behavior in FvF. I think my monsters only have a 50% chance of getting mad at each other if they hit each other by accident. If they get hit intentionally by another monster, then they immediately retaliate (they just check to see if the owner of the attack is a monster, and they sometimes ignore the attack if it was not intentional -- if the owner of the attack has you set as its enemy, then it was intentional and you return the favor). This cuts down on the monster infighting, so they can focus more on killing the FvF players >:D But it's still fun to try and get the monsters to fight with each other instead of them all turning their attention on you!

Buy yeah, this is not something the engine should really be tinkering with.

Except MAYBE as a secret hidden setting which is defaulted off; like a new, harder difficulty mode or something. But I think there are plenty of other issues Mark V can be addressing before adding something like that.... 
AD Does Have Something Like This I Think 
I could be mistaken but I think the infighting behaviour is slightly different in AD and they don't instantly change target unless you do a certain amount of damage. 
could someone sent a config with basic graphics to to improve the fps (dx9_mark_v.exe)?

My notebook isn't very good, onboard video and etc.
what's the command for save a config? 
Config (dx9_mark_v.exe) 
My email:

How can i put the Time (with high size) on the center of the screen?

Tks everyone! 
We need more women in Func_. 
The only major default thing that might help FPS is to disable mirrors (which really should be disabled by default):

r_mirroralpha 1

To always show the clock, set:

scr_clock 1

(Baker, the help info for scr_clock is incorrect. It says 0 = deathmatch only, and -1 = never. That info is reversed).

I think the only thing you can do to make the clock bigger is to make your HUD bigger, like:

scr_scaleauto 0
scr_sbarscale 2 
Onboard video is actually capable of running fast without needing to compromise on quality. The problem isn't onboard video, the problem is how the engine is coded.

One of FitzQuake's claims is "if you can run glquake, you can probably run Fitzquake". Unfortunately that means that it tends to brute-force certain things on the CPU where a more elegant, faster approach often exists.

MarkV has inherited that tendency, so hence it suffers from the same problems.

No amount of "go faster" config options can fix that; it needs a complete rewrite.

It's a fallacy to think that the older API is faster with low-end hardware. Low-end hardware these days supports shaders and VBOs; really old low-end hardware still supports shaders and VBOs. Shaders and VBOs allow a faster renderer.

I recommend that you run QuakeSpasm and run it with all extensions enabled; odds are that it will run substantially faster than DX9 MarkV, even on Intel hardware. 
Config (dx9_mark_v.exe) 
Thank you Gunter!
With the command r_mirroralpha 1 improved something.

My notebook is a Lenovo E520 - I5.2410 CPU 8gb ram, 128gb ssd with Intel HD Graphics 3000.

Thank you mh too!

I downloaded the QuakeSpasm, but the QuakeSpasm FPS is similar than MarkV FPS (200..300). what do you mean "with all extensions enabled?". Could you send to me some config?

Thanks in advance! 
With an Intel HD 3000 that's going to be the best framerate you'll get. The only option you have is to lower your resolution.

"With all extensions enabled" means don't disable multitexture, don't disable combine, don't disable shaders, because hardware will run better with these enabled and QuakeSpasm is more sensibly coded than most.

If you're doing nothing to disable these then you don't need a config, just keep things the way they are.

I'm currently working on an engine that will probably run twice as fast, but it's not suitable for general use yet. 
Has anyone seen baker in the past week or so? :/

In other news, has this "transparent models" issue been seen before in any other engines, or is it unique to markv? Noticed it while playing today and I wasn't familiar with it at all beforehand. 
YouTube's video encoding is bad for analyzing such things, but it seems that there's a conflict with the skybox renderer, maybe related to the Z-buffer. 
@Infighting Questions 
Thanks everyone for your answers. It really was just a curiosity and I learned a lot in just these few answers. The reason I asked here is that Mark V seems to be the engine with the most "out of the box" and unique features. I will look into a progs version. Maybe something exists or can be gleaned from AD dev kit. 
Ya know, if you want to play Quake with the monsters being smarter, more dangerous, and not in-fighting as much, you should come play FvF ;)

We usually gather to play on Sunday nights....
Ok.... Another complaint about the secret cfg files overriding expected behavior:

I installed a clean copy of Quake and Mark V into a completely separate folder ("Quake1"). I ran it and got everything set up how I wanted it for THAT folder only.

Then when I went back to my original Quake folder ("Quake") and ran Mark V, the resolution settings I had made for the separate folder were loaded... (perhaps other settings too).

I do not like that, no I do not.

All cfg settings need to be kept separate for each folder, and for each mod.

This goes back to the stuff I was commenting about in #1276 with ideas for a better setup with these config files -- too much behind-the-scenes stuff not matching user expectation. It would be better if the Mark V config files were saved alongside the standard cfg files, and were user-accessible. 
Source Ports Should Write Their Own Config? 
I made mention awhile back about the overwriting of my configs and the "secret" area as well.

What if custom engine wrote their own "branded" config.cfg? EX: markv_config.cfg, fte_config.cfg, qs_config.cfg etc etc

That way no one engine writes over another's config file.

Also, there really is no need to complicate such a simple execution of saving a players configuration settings like this:


Especially given most are not even aware of it and simple browsing of folders doesn't even reveal it. 
All I want is a way to save video settings and only video settings. Having a mod load in 640*480 and move all the windows on my 3 displays one display across (apparently... Idk, it just gets weird) is beyond frustrating. I guess I should just force my res through launch args but still... 
Launching in 640x480 fullscreen should never happen these days either. 
Has anyone seen baker in the past week or so?

Real life. ;-)

You might have noticed "update sometime in the spring", "update sometime in the spring", "update sometime in the spring" ... haha.

Yeah, let's just say I have some action-packed awesome fun battles going on in real life, the kind of scale that makes my eyes light up for battle (heheheheheh).

And that's where my attention is going to largely be quite a bit for the foreseeable future.

But back on topic ...

Here's something to look forward to in the spring!!

Mark V - Mouse Driven Menu Video

Mark V - TouchPad Tap Fire/Drag Look

That plus whatever mh cooks up and whatever bite I have time to take out of Spike's Quakespasm Spiked apple. I still want to get 4 Player support going ... I hope that happens. I've got that itch. Question will be time.

I always read all the posts. I said spring because spring is vague is allows lots of room for interpretation, hehe ;-)

/But yeah, expect me to not consistently be around. But it doesn't mean I don't care. When time comes, I'll deep probe all the feedback. When the time comes ... 
Just Glad You're Still Alive 
I'll be thinking of your persistence in 3 weeks when I'll have 2 XBox controllers on a specific weekend and digging into XInput tutorials.

A year ago, I would not think I would be doing such a thing. ;-)

Sometimes I also question what reality I am living in where I can actually do these things on a whim. A few years ago, I was quite the novice and I still don't entirely understand how I acquired the level of expertise I now have nor what induced me to make a software renderer version nor how I did the majority of it in 3 weeks. It's like "Flowers for Algernon".

I blame hanging around mh and Spike.

5 foot away, there is a beer that needs drinking. I now must attend to this urgent matter ...

/End slight ramble. But incredible things are in the pipeline for the next Mark V. 
4 Player Splitscreen With Pads 
Is literally a dream scenario for me. I host regular game nights and buy a lot of MP games for it. Being able to make death arenas for my friends would be epic 
4 Player Splitscreen With Pads 
Is literally a dream scenario for me. I host regular game nights and buy a lot of MP games for it. Being able to make death arenas for my friends would be epic 
4 Player Splitscreen With Pads 
Is literally a dream scenario for me. I host regular game nights and buy a lot of MP games for it. Being able to make death arenas for my friends would be epic 
Sorry for the spam. Currently at work posting from my phone 
I'd Say That's Some 4-player Splitscreen Posting Right There 
Won't Launch On Mac 
I have the same trouble others mentioned with the app not launching on Mac. My Quake folder is in Applications, and has the id1 folder in there alongside Mark V Quake. When launched, I get a dialog that reads

"Your Quake folder should contain a folder named id1 with pak0.pak and pak1.pak.

Opening folder ..."

and then I get

"W_LoadWadFile: couldn't load gfx.wad

Game data files are required to run; usually this means you need Quake shareware or registered version.

Is Mark V in the proper folder?


Other Mac Quake files work (Fruits of Dojo, Tenebrae), so I'm confounded. 
Won't Launch On Mac (Sierra) SOLVED 
It looks like the problem is with the Sierra Quarantine Attribute

Followed the instructions here, and all's working now. 
Suggestion: something that saves your most recent previously-used resolution.

So like, if I was in 1024x600 Full-Screen and I used the menu to change to 800x600 Windowed, when I press ALT-TAB it should take me back to 1024x600 Full-Screen (it takes me to 800x600 Fullscreen).

I note that this already works in the other direction -- starting in a Windowed mode and changing to Full-Screen in the menu, then using Alt-Tab will toggle me correctly between those two modes.

I'd like an actual permanent saving of the previous mode used (when it's a change from full-screen and windowed -- like save it in a CFG file) so that this behavior will persist even upon starting a new game. Then I could easily toggle between the windowed and full-screen modes I want to use, automatically. 
Hopefully in the next release, there will be better rendering for transparency... 
Freshly Installed The Latest Mark_V 
on C:\Quake and the music is working on the game again. It doesn't like being on D:\Games\Quake for some reason.

Music is on mp3. I have an E:\ blu-ray drive and an F:\ backup external. 
MarkV Crashes On Model With High Vertex Count... 
...despite being well under the vertex limit.


I posted a thread addressing the issue over at Quakeone, R00k sent me this way to get a hold of you. Did all the troubleshooting I could initially think of. Thought you might find this interesting: 
When this model is converted to strips and fans it comes in at 4284 vertexes, which overflows an internal buffer that's particular to MarkV and was introduced by the shadow code I contributed.

@Baker: increase MAX_LERPED_VERTS to 8192 seems to be one way of handling this because it's consistent with the other counts in gl_mesh.c; at least it means that if a model crashes this it will also crash other engines. 
Thanks for the reply mh. I had a feeling the culprit was right in front of me while scanning through gl_mesh. I'm more on the QC side of coding though, so I wasn't entirely sure what all I was looking at. 
Is 320x240 Stretching In Hardware Mark V Possible? 
I just tried out Arcane Dimension for the first time, and I'm just blown away by it. I really want to play through each and every level of that mod, but there is something preventing me from enjoying it.

Up until now I've used the winquake version for playing quake, and while that is perfectly fine for the official quake content and my own maps it doesn't get along with high-caliber stuff like AD very well. On one hand there are graphical issues with transparency that are to be expected, but the performance also takes such a drastic hit from all the cool effects and increased polycount in every level that it's just not playable any more.

The funny thing is that the obvious solution of switching to hardware mark v actually makes things even worse. Because unless I want to stare at a blurry mess, I need to render in my laptops native resolution of 1336x768 instead of stretched 320x240, which more than nullifies the benefit of hardware rendering in terms of raw performance.

Why is stretching only supported in the software version? I know that most gl-based engines only support 640x480 as the lowest output resolution you can select in the menu, but it's clearly possible to render the actual game in resolutions much lower than that since you can adjust the screen size in the menu to achieve just that. I took a screenshot of the smallest screen size in hardware mark v at 1366x768, which results in the actual rendering resolution only being slightly larger than 320x240. If you would implement a feature that scales this window to fit the screen borders again, that would have the same effect as the stretching feature in software mark v, right? Is that how the feature works in that version?

I can't judge how much work implementing this would be, or if it's even possible at all. It seems like it should work to me, but there very well might be hard limitations preventing the feature from being in hardware mark v in the first place that I'm unaware of. I just want to let the devs know that this feature would be huge to me and everyone else who loves chunky pixels coupled with smooth performance.

I'm surprised so little people seem to play quake this way to the point where there is pretty much no support for it, software mark v being a rare exception. Most players seem to prefer resolutions that utilize every pixel of their screen, but I just can't enjoy quake that way. It has nothing to do with nostalgia in my case, I missed the pixel-period of gaming by quite a bit since quake is actually slightly older than me. It just feels so much more alive in low resolutions. It has to do with how everything is constantly changing shape as you get closer or farther away from it, for example how particles blend seamlessly with the chunky environment, choppy animations seem to flow naturally, flames look like hand-drawn sprites at some distances or how you sometimes can't even tell what monster is waiting for you at the end of a dark hallway. Viewing lava and water at an angle also look incredibly organic due to this, even though they're just a single texture tile repeated over and over. If you look at all these things on a high resolution with interpolated textures and lerped animations, that magic feeling completely fades out of existence. You suddenly see everything very clearly for what it actually is: simple brushes, blurry textures, and crude animations. It feels like looking behind the stage even though you're actually still looking at the stage. That is apparently just what happens when you force a game two decades old to conform to today's graphical standards. It should look objectively better due to the modern improvements, but it just doesn't, not to me at least. I don't want to bash on everyone how enjoys quake at normal resolutions though, even if I'm coming on pretty strong here. I'm really happy that quake has evolved into something that can be so many things and has an engine for pretty much everyone and their personal preferences, and I'm thankful that even less popular ones like mine are represented to some degree in the community and in mark v, even if just in the software version.

I'd happily do the work of porting the feature myself, but I lack any kind of knowledge that goes beyond the very basic level of fiddling with quakec and have no idea where to even start tackling things related to rendering, making this plea to devs my best shot at getting the quake engine of my dreams for now. I'm gonna keep learning more about quake development and programming in general though, it's just going really slowly since I'm far from being a John Carmack and feel like I'm up against something my puny brain can barely comprehend whenever I look through the source code.

Guess that concludes this wall of text, thank you for sticking with it me the end. :) 
This makes me want to try playing at that resolution. I hope you get your wish for increased support! 
Isn't It 
just a matter of turning on "pixels" mode? Forgot how to do it. 
setting these cvars:

r_lerpmodels 0
r_lerpmove 0
gl_texturemode gl_nearest

should make MarkV/Quakespasm closer to what you want, other than the resolution.

Yeah, this is a good request. So to summarize, the ability to render at a res like 320x240, and then scale (unfiltered) to a higher resolution (lcd native res). 
It Already Does This 
there is a gl version of Mark V winquake which has resolution scaling.

I didn't read the wall of text, maybe I'm missing something? 
I tried it and I got a headache :( 
I Can Relate 
I read the whole text and @killpixel, yes, boristhesp1der did try running Mark V in Winquake mode. But that didn't run fluidly in AD. He's looking for a Winquake alternative that runs AD fluidly while playing in a Winquake 320:240 resolution. This is essentially what you wanted to say @boris?
320:240 is my thing as well, at least when I play the original maps from ID. I use the Mark V Winquake for that because it supports folder-music instead of CD. As for modern maps I use Quakespasm with
gl_texturemode GL_NEAREST_MIPMAP_LINEAR because everybody knows that GL textureinterpolation looks rubbish with Quake's low-res look. 
The GL Version Of Winquake Didn't Run Fluidly? 
bummer. Well, he could try Darkplaces. HEAR ME OUT.

there's a retro shader for DP floating around. along with that try these:

r_viewscale .5 (or .25)
gl_texturemode gl_nearest force
r_lerpmodels 0
r_lerpsprites 0

should give him a fairly retro look until he find a more faithful alternative. 
The funny thing is that the obvious solution of switching to hardware mark v actually makes things even worse.

This is the way things are going to be so long as MarkV uses glBegin/glEnd code.

In an ideal world scenario: MarkV would move to vertex array and VBO code, the D3D version can be scrapped (because bad GL drivers are no longer an issue once you start coding sensibly to begin with) and better GL ES compatibility would come about as a bonus.

Resolution scaling won't help much with this. It will help with fillrate but with glBegin/glEnd code it would still be pushing the same amount of vertexes and draw calls irrespective of resolution, which is where the real bottleneck is.

Call to action: get on Baker's arse and get the glBegin/glEnd code killed. 
Since rendering is the current topic, what are the chances of getting proper transparency depth in Mark V?

It's thankfully not too obvious in my map yet but it is pretty annoying. 
@boris - I've been impressed by your ability to self-solve issues (main reason why I am posting since I'm mentally not here, yeah you really impress me). Open GL can't really scale pixels when rendering, although since I'm not AAA+++ in rendering someone may mention a frame buffer trick or shader trick with 6 asterisks next to it.

@pritchard - you didn't state the problem and I'm not level 25 at mind reading, only level 22 although I aspire to be level 25 some day. If it is depth sorting, the answer is yes! because that is on my list.

@mh - "glBegin/glEnd" It kills my soul somehow. I've actually not eliminated glBegin/glEnd for Open GL ES. I created an extra renderer Open GL ES "wrapper" that throws them in VBO. ;-) That being said, yeah I agree in principle. (Insert: I'm probably 6 weeks from doing an update even though technically I have one ready, is there is an update to remedy alpha entity for D3D? No need for an immediate reply, just planning ahead a bit).

@adib - "just a matter of turning on "pixels" mode? Forgot how to do it." --- It's in the video options menu.

@fifth - When Spike sees what I did, he'll fucking hate me. Spike's skill > Baker. Baker's creativity > Spike. I admire Spike. I plan to smoke him a bit. It's not all what your powers are, it is also what you can do with your powers.

@Spike - "oggs" --- In real life, no one has ever heard of an "ogg". It's a technically inferior poor man's mp3 used in a few Quake engines --- no where else in any game or any medium is an "ogg" a format a ordinary user has ever heard of. The mp3 patents have expired. Ogg have no future.

The Unreal Engine doesn't support ogg.
The iPhone can't play an ogg.
The Anroid phone doesn't do oggs.
There is no future for ogg.

The question isn't why DarkPlaces doesn't do mp3. No actually that is the question.

I like it when someone complains about the lack of ogg support in Mark V. When the next Mark V comes out, I expect mega-tons more complaining.

Complaining is awesome. Because complaining is the backbone of progress. 
that makes OTP and Shambler the most progressive people on this forum... ;)

Nah seriously, can't wait to see what stuff gets added this year. I agree about Ogg. I used to be a fan when the MP3 patent was restricting people but it's served it's purpose now. 
Keen Beer Moment 
Yeah, there will be "mega-tons" more complaining.

Because the next release Mark V will be the first true "5 platform" engine. The iPhone/iPad and Android.

And for anyone who has watched any of the videos, yeah Mark V just happen to run on a mobile platform --- it will run fucking awesome on a mobile platform -- in a way no one has ever done.

And it will be a stealth release.

A. Like the past versions of Mark V, I will make nominally a zero effort to promote it. I'm not looking to mainstream Mark V, this engine is meant for those few of us left that enjoy Quake for what it is.

B. iPhone App Store. Yeah, I'm not doing that. Someone with a Mac doing a self-compile and share amongst friends is how that is going to work -- in a best case scenario.

/Six to Eight Weeks Probably a Ground Break Release. Six to Eight Minutes -- my ETA for a beer run. Ill-advised post? Aren't they usually? Haha. Cheers! 
Pre-Beer Run: @ Fifth 
Shambler is a complainer who has put blood and sweat and intellectual sophistication and effort into his passion. I once got into an argument with Mugwump and he said "You are the opposite of Shambler" and I was like "Well, I hate to say this but I probably agree with him on nearly everything ... my only difference would be that I place a high value on diversity".

/I now resume my end-of-night beer run. 
I Often Share The Same Views 
but it's usually the way things are said rather than what is said that can be irk-some. :P

I think if you're doing mobile platforms it will be interesting to some but control is definitely going to be the biggest hurdle to overcome. 
I Was Going To Buy Myself A Gamesir G3 Bluetooth Gamepad 
So another reason to get it sooner. 
is there is an update to remedy alpha entity for D3D?

Remind me again of what the issue was? There's quite a bit of chatter about alpha stuff in this thread, with the most recent I recall being depth sorting issues, which aren't API-specific, so I'm unclear on this. 
Thanks For The Answers Guys, Really Appreciate It 
Kind of a bummer that scaling on hardware is out of the question though. I'm still gonna share the mockups I made though, so you can actually see what I had envisioned for yourself.

I just scaled screenshots from regular mark v down to different "integer fractions" (sounds weird but I don't know the proper term for that, I mean scaling in such a way that the resulting resolution contains no decimal numbers in both axes) of 1334x768 to make them look software-rendered. The result is actually pretty different from the real thing for a number of reasons, the most obvious being atmosphere. Coloured lighting and fog really make a world of difference, and this screenshot alone doesn't even do that statement justice.

In the unlikely case anyone is actually interested in this, I noticed a few interesting things making these mockups. Take the skulls for example, which change size in software mark v depending on your scaler. Candles change position and also get a different model on hardware/software. The skill pillars and everything at their distance looks noticeably worse at 3x in reality because software quake starts to blur out the textures at a certain distance from the player, which is unfortunately not quite far enough away for the transition to happen seamlessly. (Fixing that would be a fun project, eh?)

You'll notice that as the scaler increases, there start to be more versions of the same mockup with numbers attached to them. Those signify how the picture was scaled from the original, which can make a world of difference in the end result. 1 means scaled down in 1 step from 1344x768, 2 means first down to half at 672x384 and then to the end result, 3 means first half, then third, and then end result, etc. Most of the time one step looks the best, but sometimes multiple steps actually preserve some details that would otherwise be lost, like the metal edge on the lower step of the stairs. I also had this anomaly for the 6x scaler where no matter whether I scaled from 1x or 2x, the result was exactly the same down to every last pixel. That doesn't happen in any other scaling scenario. Thought it had something to with scaling from an even to another even scaler at first, but it didn't work for 4, 8, 12, or 24. I used GIMP to scale the whole image without interpolation, so If anyone can explain what happened there I'd be interested to hear.

On somewhat of a related note, and since problems with transparency are hot topic right now, I'd like to present you the following:

Is there a way to get software mark v beefed up to deal with this? I don't know if the crash is actually caused by those transparent textures, but that level (foggy bogbottom) runs (for a few seconds at least) far worse than all the others and is the only one filled with them, so it's probably not that far fetched. 
Hardware Scaler 
is a feature I wouldn't mind included if it was ever possible. I like the blocky aesthetic 
Take the skulls for example, which change size in software mark v depending on your scaler. Candles change position and also get a different model on hardware/software.

Heh, the candles don't change because hardware/software - they change because the candle entity is deliberately set up to spawn a random version each time (they come in many variations of tall/short/thick/thin)

The skulls changing size though is some funky shit - why is that happening? 
For what it's worth, hardware resolution scaling is possible. Never said that it wasn't.

You do need render-to-texture to do it with best performance, which means OpenGL 3.0 or GL_EXT_framebuffer_object.

A slower GL1.1 path involves a glCopyTexSubImage call.

The point that I need to be absolutely clear about is that MarkV's bottleneck is elsewhere, so hardware resolution scaling would give marginal improvements to it. With e.g. QuakeSpasm it would be worthwhile for cases that are fillrate-bound, but MarkV isn't fillrate-bound. MarkV is CPU-bound. 
Wait A Minute, What Do You Mean By Cpu-bound 
Is regular Mark V also rendered on cpu? I just assumed a gpu was a requirement for opengl. So Mark V essentially emulates gpu-features on a cpu? Is that correct? I don't know enough about this stuff...

That certainly would explain why performance is so bad. Apparently my poopy laptop isn't at fault after all, I just tried running those levels in quakespasm and they run at a stable 60. I hadn't even considered that to be a possibility, mostly because my laptop struggles to run just about anything that came out in the last 15 years. 
By CPU-Bound, mh means (I think) that the performance limiting factors in markv are operations that are always done on the CPU in all games.

I'm no graphics programmer, but as I understand it, the CPU has to explicitly ask the GPU to draw each frame. If it takes too long, it won't matter how fast your GPU is because it's just sitting idle a lot of the time.
Quakespasm sends it's draw calls in a different way to markv which means that the GPU can always be busy, or at least busy more often to the point where upgrading your GPU will make a difference.

I might be wrong about all this so take it with a grain of salt. 
Thanks Pritchard, that explanation seems a lot more likely than mine. The difference it makes on my system is batshit crazy though, that's why I thought it had to be cpu rendered. While mark v sometimes dips down to less than 10 frames in busy areas you won't even notice as much as a hiccup in quakespasm.

I guess I'll have to switch engines for now, I'm gonna miss you zoom button... :( 
Pritchard has the right of it.

When drawing objects, every single component of every single vertex has CPU overhead in MarkV that doesn't exist in QuakeSpasm.

For any given scene this overhead is based on the number of polygons and number of vertexes in the scene, so it's fixed irrespective of resolution.

Small scenes - like in ID1 maps - are barely affected, which is why it won't be noticeable if all you ever do is e.g play DM3.

As the polygon count goes up the overhead gets more and more. 
Baker what features and stuff do you think you might want to implement in Mark V's next release?

(Crazy and Stupid) Ideas:
Atleast try to support orl's Zeangala map or what ever its called.Who knows,someone might make an adin1 like bbin1
Create feature like in reQuiem
(Might need to check this one)
Music command like in QuakeSpasm
Some proper coding!

So far I know 4 coders doing engine stuff
Re: Post #1504 
Does anyone know why the skull models change size between the different resolutions? That's some crazy beans... 
Sort of, at least. In a proof-of-concept way.

The video makes it look pretty crappy and stuttery, but it actually runs and feels awesome. The only real downside to this method is that you have to be incredibly careful not to make any sudden mouse movements, that causes the borderless window to stop capturing the cursor for a fraction of a second and the magnifier will register that movement, jerking the viewframe in whatever direction you happened to be aiming.

Keyboard aiming it is then! I can handle that. Probably. 
That Looks Mighty Sexy 
You could always use a joypad? 
Feature Request 
So you mentioned that 4-player splitscreen is a thing you want to implement in the future? How about 4-player splitscreen that also allows people to join from the internet?

I have been playing a bit of the remastered Turok 2 from Nightdive and this has the same feature. It's a good way of getting people online and playing! 
You could always use Audacity or any sound tool to export to mp3. 
... is also good at that: I created some custom sounds and background loops a while ago with it.

It is not a freeware, but it has a lot of interesting features. 
Feature Suggestion For More-legible Text 
How about a Text Contrast adjustment that will only affect the text (maybe like the texture baked-on gamma/contrast).

The dull text can be hard to read in front of all the other dull colors in Quake.... I don't want to universally ramp up the contrast for everything, so it would be nice if I could just adjust the text contrast alone. 
Kustom Conchar, Hudnum, Conback 
I was running an ancient version of dp then fte before mkv. in those I was using a conchar file that had black outlines and cleaned up characters, the diamond grip numbers, and conback from qtest. I had obtained these from quite some time ago all for clarity and legibility sake. Is there any way to have mkv load external wad assets, or does it perfer certain fyle tipes such as pcx? 
Mark V only supports .tga, uses the DarkPlaces way of naming replacement textures.

For instance, throw this file in quake\id1\gfx folder (conchars.tga).

Random comments: Gunter should be using a custom charset ;-) He could adjust the contrast in an image editor and self-serve. 
If your custom gfx are in .lmp format:

DP/FTW will use a loose id1/gfx/conback.lmp (conchars, etc.) in preference to the one in id1/pak0.pak, but vanilla engines including MarkV require you to put them in a pak file (e.g. create a pak2.pak) in order to override the stock ones. 
Thank Yah 
Everything was in a portable network graphic format so I just used gimp to patch them over to targa. I also increased the color saturation levels of everything and added black borders to the hudnumbers as well. Another thing I noticed after this was if you disable the start demos it just dumps to console, is there any way that it could pop the main menu up as well? I also saw a sort of custom start demos command but I couldn't get it to operate. 
Akira, just put "menu_main" at the bottom of your autoexec.cfg file if you want it to pop up automatically upon game start.

Wow, that custom conchars.tga is definitely high-contrasty-more-legible in the game... buuuuut it doesn't look like Quake, heh.

I guess I can mess with the contrast and make my own custom conchars, but it would still be nice to have such a feature built in. 
this is the one i use, and Gunter will approve! 
edit: what you CANT see by that image is that the characters have a thin black outline around them.
Unless I selected the wrong file. Or just look in Qrack's pak0 for charset-3. 
Not bad... (had to convert to TGA for Mark V, but it works). That's more Quake-like than the one Baker linked, but I'm very picky in that regard, heh, and it's still not quite right.

I came up with this one by just ramping the hell out of the brightness/contrast so the text really stands out, but it's otherwise still the original Quake characters: 
Scr_clock Setting 
Just a heads up, Baker. Looks like the cvar scr_clock still allows the game time to be drawn when set to -1 if playing DM (it does disable in SP).

Wouldn't normally bother me but it overlays on top of the player colors (the mini-scoreboard when viewsize is set to 120). 
EDIT: sorry, I meant when viewsize is 100 or less, in regard to the above post 
Using The Dx9 Render 
I've come across a few bugs. The first one is in mutiplayer the ping command doesn't seem to work, I tried ping 100 and ping +100 but I don't see any changes on the scoreboard or latency. It seems to be in there though as it doesn't come up as an unknown command. The second is single player that when you die and instantly hit space to respawn your view remains sideways, I'm not sure if it has any relationship with quicksav or being splattered. The last one I've had happen a couple times first on some map from 1996 then in ad monsters spawned like brushes I was using quake injector. 
1) There is a loadgame + death bug reported by Pritchard. Will be fixed in the next release (already fixed in unreleased code). Results in the deadness issue you outlined above after loading a save game.

1) ping +x is not supported (ability to lag yourself). Feature exists in ProQuake/DarkPlaces/Qrack, but adds some complexity/ugliness to maintaining the network code. Possible it may get added at some point. 
is there any portal culling for VIS like in DP? 
Doesn't have such a feature, which AFAIK is intended for real time lighting.

Arcane Dimensions quake.rc has r_useportalculling 0 and Map Jam 8 users needed to turn off r_useportalculling to avoid issues with DarkPlaces.

Arcane Dimensions finds it necessary to turn off r_useportalculling in the quake.rc file for gameplay or visual compatibility reasons. 
yeah, "r_useportalculling 2" breaks map if you have some Warnings/clipped portals during VIS. It's very annoying, but 50% of fault lays on mappers side ;)

I was just curious if there are any VIS improvements in your engine, or do you plan any?

As we know VIS in Quake is very primitive and does it's job poorly, so you have to do tricks etc. to limit r_speeds. 
The idea the engine would do the same thing as vis (which can take untold hours to run in some circumstances), and do it better and do it instantly on map load doesn't make sense.

I'm just saying ... if the engine could do that, why wouldn't you take those calculation and throw them into the vis tool instead?

Yes Quake vis sucks terribly, especially at open maps. Kills frame rate, makes demos huge --- like the 10 GB "I played Arcane Dimensions!" demos, makes QuakeC slows, makes map uncoopable with enormous network traffic.

The correct solution is improvement of map compile tools.

/Maybe you should get together with other interested parties and raise a $2500 bounty and try to induce someone who writes tools either in Q1 or in Q3 or at id Software or for another game engine to get Quake vis right or vastly improved.

/One idea. I'm often wrong about these kinds of things. 
I agree Baker, the only problem with vis, IMHO, is the thing where certain uses of func_detail can cause vis to see through your map where it shouldn't. I'm not sure exactly where the problem lies (qbsp or vis) but I'm sure it's fixable.

Unless the problem I mentioned leads to exaggerated PVS in AD maps in a lot of places, vis is not really to blame for large demos in AD and the large unreliables, that's just the particle system based on entities and lack of use of static entities combined with protocol 666. 
Yeah, my main complaint are open spaces. I know how to optimize vis for indoor maps.

I did hedge maze and of course everything is rendered, because of open space above it... I'll have to add some obstacles to separate sectors better, or try some hint brushes, but I think hint won't help in this case.

Best option would be occlusion culling like modern engines do, but of course it's impossible with BSP.

Anyway thanks :)

Btw. how different is Q2's VIS? (except doors blocking it) and how much we can borrow without a need to upgrade BSP ? :D 
ericw, you've done awesome work with the tools so this isn't directed at you. It isn't your responsibility to fix vis. You are a volunteer. This isn't a reflection on people that do the great work on the tools.

But yeah ...

vis is certainly to blame. It is supposed to block faces and entities from being drawn. That includes things like AD particles.

/I don't like thinking about it because it is very disappointing. Nor do I seek to bring it up. Kreathor brought it up, haha. He's the bad guy.

Dead horse, I don't wish to beat it. I won't be bringing up, and I didn't raise the topic this time either. 
Nor do I seek to bring it up. Kreathor brought it up, haha. He's the bad guy.

Yeah but I haven't brought it to blame you guys, but to ask if there are some better solutions on the horizon and what can we do to improve this situation.
I saw that Mark V has some nice features, so I thought I'll ask if there are some features supporting VIS...

Speaking of raising a bounty I'm in, but...
Considering I'll give $100 I'll have to find other people willing to pay $$$ to get $2500 in total, which probably is impossible, so I think it's time to finally dive into code and see what we can do in that matter. 
Nah It's Cool 
Reporting problems is only a good thing in my book.

Wow, ad_mountain's vis looks really broken. Assuming the player was in-bounds and then you used lockpvs and noclipped outside?

The ARWOP screenshot doesn't look too bad to me.. assuming the player was at the start position when pvs was locked? Also I am 99% sure ARWOP predates func_detail being used commonly so it would be immune to the bug that can cause total breakage (vis seeing into entirely separate areas).

The last one of ionous/pulsar's map, I'm not sure there is much unneeded stuff, that's a big open arena type area.

Another point to remember at least with Quakespasm, it has the anti-flickering patch so if an entity exceeds MAX_ENT_LEAFS, the server will always send it. So testing in Quakespasm, large bmodels that exceed max_ent_leafs will always render, and it'll look like VIS messed up but it's just a server quirk. 
So testing in Quakespasm, large bmodels that exceed max_ent_leafs will always render

Yeah, I wasn't trying to draw attention to the bmodels.

Although those aren't Quakespasm screenshots Mark V uses the same mh/spikey solution. 
@kreathor. Mark V supports external vis which allows, for instance, true transparent on id1 maps without vispatch (files on the Mark V page).

Mark V supports sv_cullentities 2 -- which on poorly vised maps can cut-down on network traffic substantially and (sadly) increase rendering speed.

sv_cullentities from essentially borrowed from FTE (although I may use R00k algo?) and DarkPlaces has a similar feature.

It also has r_lockpvs and r_lockfrustum borrowed from DirectQ which mh said he borrowed from Quake 2. 
Cull Brushes 
I think I mentioned before that there should be some kind of brush that mappers could place that allows more freedom over culling.

Unreal Engine used to have "visibility culling" that you placed a brush to give hints for vising purposes. Maybe Quake has something similar (is this how hint brushes work??). 
I would assume that if they're supported at all, hint brushes work like described here:

I do wonder if using such brushes would improve maps... It's another layer of work on top of what is already required but with some bigger maps it could be worthwhile. 
Mark V supports external vis which allows, for instance, true transparent on id1 maps without vispatch
Thanks, I'll have to check this feature out

I do wonder if using such brushes would improve maps... It's another layer of work on top of what is already required but with some bigger maps it could be worthwhile.
If you do it correctly then yes. Problem is if you have big open spaces, then it won't help you much... although in my case I used it to cut portals behind big building standing in center of open space.

I like this "tutorial". Explains it properly: 
What did more modern engines such as Source do to improve their VIS? Half Life 2 has plenty of huge open spaces that run well. 
Half Life 2 (Source) is using PVS and occlusion culling for outdoors. 
So how is PVS (Potentially Visible Set) different from VIS? The Valve Dev wiki describes PVS as a collection of visleaves which might be visible from a given location. Isn't that just how VIS works? 
VIS is just a tool/process of creation of PVS, so to be 100% correct with nomenclature, we shouldn't use it to describe PVS ;)

Anyway we are OT a little, maybe we should move with this conversation to Mapping Help, before Baker gets mad :P 
Source Engine 
For the curious:

By the way, Source uses vvis.exe. 
Old Mirror Control Complaint 
I needed to look at a modified FvF player model in a mirror today, but could not do so because Baker took away the mirror control from the user....

"The Id1 Mirror Texture Only Works With Id1 -- It's Intended Behavior
if someone is playing Soul of Evil or Travail or something and some random texture is pointlessly a mirror because it is window02_1, that would be annoying as hell ... "

But r_mirroralpha is a user-controlled variable, and if a user wants it on, it should be on, no matter what mod they are running. It should also be defaulted to "off" ("1"), so if it IS on, then it's definitely intended to be on.

I had to load up FTE to look at myself in a mirror in FvF, and even that engine wouldn't let me activate it in Multiplayer mode, telling me it was a cheat. Boo! (I'm the server operator -- I am the one who should decide what is or isn't a cheat on my server, and I don't feel mirrors are a cheat). But at least I could use mirrors to look at the modified player.mdl in FTE Single Player mode.

I dislike when engines decide for me what settings I am allowed to use in what modes. 
I may end up coming up with a method to allow a gamedir mod to enable that as choice. 
Does Mark V supports scrolling textures? What's the name convention? 
Yeah, type "find scroll" in the console.

It's only in the GL build. 
sv_cheats 1; restart;
then you can do whatever you want.
and so can other users on your server, so have fun with that.
unfortunately nq doesn't do serverinfo, so that'll only work with an fte server.

use mirror_* for mirror textures in future. those should always be mirrors, and need not be considered cheats. window02_1 on the other hand is present on many maps, and in many of those it potentially exhibits serious graphical glitches that allow it to act as a wallhack or whatever. so yes, its generally considered a cheat unless the mapper explicitly intended it.

for similar future needs, you might want to consider using chase_active or equivalent (most engines support it to some extent), or maybe try fte's splitscreen.
its generally easier to look at it from other angles then. 
His server coops existing maps. He doesn't have any choice in what the texture names are so he doesn't have the option to change the texture names to mirror_ * 
I've tried to test it by entering "r_texprefix_scrollx wizmet", but it didn't work. I'm using the version 1.36. 
That feature was slated for removal, looks like is broke. I probably was working on mirrors and removed it, but forgot to nuke the cvar and friends.

It works in this ancient build binary + source.

The reason that feature is slated for removal is largely because:

1) I can't imagine a scenario where it could be turned into a standard.
2) This method has no ability to control the speed.
3) You can do animated textures in maps using the +[texture name] animated textures method in regular Quake and it works on everything, although it is jerky and has a 10 frame limit.
4) Low interest in porting scrolling to WinQuake, hehe.

There's also probably better ways to do it too.

Was a nice experimental feature back at the time, I just wanted to see what it would look like. 
Retroquad uses the [ and ] characters to prefix parameters for scrolling.

[ is negative
] is positive

The first of them in the texture name indicates horizontal scrolling. The second one indicates vertical scrolling, and it's optional.
The second one must be followed by a number indicating the speed. The first one only must be followed by a number if the second one is omitted.
If the speed value is omitted in the first one, both will use the same speed:
]1 horizontal scrolling, 1x speed
[1 horizontal scrolling, -1x speed
]0]1 vertical scrolling, 1x speed
[]1 diagonal scrolling, -1x horizontal & 1x vertical speed
]1[2 diagonal scrolling, 1x horizontal & -2x vertical speed

Retroquad's texture naming parser can also recognize parameter prefix characters anywhere in the texture name, allowing for multiple effects to be combined. The water in this video uses 20 textures named from *watersa]0]1+00 to *watersa]0]1+19 . The parser reads it as:
*water it's a water texture
sa the texture's individual name
]0 zero vertical scrolling
]1 horizontal scrolling at 1x speed
+00 to +19 animated frame index

The only thing I couldn't decide is whether the speed value should be in units per second or in loops per second. In the first case, big textures would need big numbers to fully scroll, and in the second case, small textures would need fractional numbers to scroll slowly. However, the first case also makes it easier to sync multiple scrolling textures with different dimensions.

The reason for all these is to make texture naming as economical as possible while still being flexible, since vanilla Quake only allows 15 characters per texture name. 
4) Low interest in porting scrolling to WinQuake, hehe.

Getting it to work properly in the software renderer takes a lot of work, so it's understandable.

A cheap way would be to scroll the texture per-texel in the surface cache. WinQuake uses a similar method to scroll the sky overlay, which is why its movement is so jerky. This would only look good on fast scrolling textures, but at least it would work. 
Your video certainly looks very nice. 
By the way, Retroquad animates sky & liquid texture frames at 15 fps, rather than the default 5 fps of regular animated textures. Alphamasked "fence" textures are animated at 20 fps. This was hardcoded just for that demo, but a standard for custom timing of texture frame animations would also be a good thing.

However, the 15 character limit for textures makes it a pain to add more customization. The name "*watersa]0]1+19" is 15 characters long already, and even if we remove the "sa" characters from it, there would be no room to define a 15 fps interval, which would require a special character plus two numeric characters (e.g. *water]0]1+19,15). 
By the way, sorry for hijacking the thread, but I'm just trying to encourage more coders to implement such features, and maybe define some standards for them. 
Engine issues and engine support of mapping enhancements are always on-topic. Not sure what you are apologize for.

Your results look nice and are smooth.

It seems wrong to put the timing in the text name, yet with Quake we do water, alpha masking, animated textures, etc. by the name .. so ...

The naming convention you are using seems quite sensible. 
In my config file, I use:

r_texprefix_scrollx z_exit

...just for the nifty effect (scrolling EXIT signs).

Though in some places where the mapper uses the texture somewhere else (like the start of terra4) it looks... odd. Like only the fullbright part is scrolling, and not the rest of the texture. Not that I'm complaining -- I like experimental features to play around with (as long as they default off!)

And yeah, I used chase_active, but I wanted to see myself from the front too. Mirrors were (well, they should have been...) the quickest way for me to do that, heh. I did not know about the various FTE features (splitscreen, eh?). 
Oh, something else....

I found that my player.mdl in \fvf\progs\wasn't even loading in Mark V, because there is a player.mdl in the fvf pak0.pak file.....

But the replacement player.mdl did load in FTE when running FvF.

I believe, no matter what the original default was in this case, that if a user has replacement content in a folder, unpacked, it should override anything in a pak file.

FTE seems to have made that choice, and it's a good choice.

I remember the complaints about "toxic settings" in an autoexec or other file inside a PAK file, and how that completely takes control away from the user (and placing those settings inside a pak is like the worst case scenario). Well, giving preference to any unpacked files, rather than what's in a pak file, would fix that issue too.

It seems obvious that if a user places some files into folders in their mod/id1 directory, they want to use THOSE files rather than anything that might be in a pak. And a pak is the hardest thing for a user to actually modify... so it's hard to work around. 
If You Don't Like Mushrooms, Don't Order The Pizza With Them ;-) 
Is your current mission to make FvF no longer work with traditional style engines?

If you want the best of both worlds, do what Arcane Dimensions does and simply not use pak files at all!

Then you won't even have the issue you are describing, haha ;-)

Do you see what I mean? You are mixing pak files and free standing files, but no one is making you use pak files at all! That's a choice.

The logical thing is to not use pak files if you don't like Quake's loading order.

Sock never has this problem because he doesn't use pak files.

All you have to do is make a FVF2 folder with everything unpacked, and you can play around as much as you like.

You could be living the high life in 5 minutes! 
It's not an FvF issue. It's a Quake issue.

The same problem exists if someone wants to use a replacement model in their id1 folder. The pak file overrides the unpacked replacement stuff, and that's not what should happen, because if a users puts a new model in his id1\progs folder, he WANTS to use THAT one. Why make it more difficult for him?

Would your suggested solution here also be to unpack all the id1 pak files, then remove the pak files, so only the unpacked files exist in id1, so a user can then use replacement content?

Or make them run a separate mod just for 1 replacement model?

What a hassle. FTE does it correctly, in my view, and allows the user-content to take precedence. Can you explain why is it better for pak files to take precedence? They are the most difficult for the user to modify. I can understand why they may have made it that way back in 96 -- maybe they didn't want the user to be able to easily mess with Quake.... But we are way beyond that now. People created programs to get to the goodies in those pak files. There's no reason to make it so difficult anymore for people to drop in replacement things.

When a mod has a lot of files, sticking then into a pak file is the most convenient and tidy way for a modder to package the mod. If a modder chooses not to do that, it may be for the very issue I'm describing here!

Of course a pak file does take control away from the user, though, which is mostly fine, because that's what mods do -- they change stuff. But then if a user WANTS to change something himself, it would be nice if he could easily do that -- like in this case, if he just wants to replace a certain model by dropping it in (a player created a new player.mdl just for FvF).

In summary:

giving precedence to unpacked files
pros = More convenient for the user to drop in replacement content. Protects against toxic settings in a pak file overriding user cfg files.
cons = None ?

giving precedence to pak files
pros = None ? Slightly helped id keep Quake from being altered back in 1996?
cons = prevents easy drop-in replacement content. You have to use a new pak file instead. If a mod contains toxic settings in a pak file, there is no way to prevent them from being initialized.

Am I missing something? 
If files in a folder override pak files, why have the pak files at all?

Quake for 20 years has had pak files have the precedence.

FVF is fully under your control. If you don't like the behavior of pak files, do them free standing files like Arcane Dimensions.

Arcane Dimensions, because it uses no pak files, doesn't have the issue.

If you don't like the behavior of pak files with your mod, then don't put the files in a pak.

1) Doesn't require anyone to do anything.
2) Compatible with every engine! 
...Quake for 20 years has had pak files have the precedence...

To me this reads as:
...Quake for 20 years has done things the wrong way...

It seems pretty obvious to me that whatever is included with the game (pak0.pak, pak1.pak) should be overridden by any new content.

It's 100% true that if you really want to solve this problem in your own mods which use their own folders, you should not use .pak files. There's no changing the way that some engines will behave at this point.
But why make using them so difficult in engines which are under active development? pak files keep things neat and make it harder for unwitting users to break your mod and so on, but the penalty a mod author incurs when using them is unnecessarily great. 
Where do you stop?

DarkPlaces loads every single .pak file found in a folder. And loads .pk3. And loads the pak files in alphabetical order. And supports a rainbow of file format from .tga to .jpeg to .png and probably others like .dss. And a rainbow of model formats.

Others want things simple.

Like the Quake way. 
Spike will say with pride that FTE loads external replacement textures from, I believe, 132 different possible folders -- supporting all the various replacement texture schemes. There are also different replacement model schemes.

A conservative engine wants 1 folder where something goes and one set of rules where that set of rules = QUAKE.

There isn't a right or wrong. Just an approach.

A conservative engines wants to stick with simple. 
It's Quake.

For every one person who wants something done one way, there's going to be five others who want it done five different ways.

The only thing you get by asking multiple people is multiple answers.

The closest thing to any kind of community consensus is "do it the way [Popular Engine X] does".

Gunter in particular has a very bad habit of "what I want for my mod is more important than anything else", then causing drama and outrage over it. I'm not certain that's useful feedback.

Quake already has an established way of allowing standalone content take precedent over pak files - put it in a gamedir of it's own. Multiple gamedir support is trivial to add to engines (and far more useful than arguing the toss back and forth over things like this).

A general-case solution that's more useful to everyone is always better than a special-case solution that just keeps one person happy. 
The PAK file precedence is part of Quake's copy protection. One of Quake's selling points was: if you want to play custom content, you must buy the game.

PAK0.PAK has its CRC value verified by the engine. If the proof-of-purchase file (from PAK1.PAK) isn't found in the path, Quake refuses to load anything but the unmodified PAK0.PAK file, which contains the shareware episode.

The PAK file precedence also served to prevent users from creating custom maps using the same names of the original maps and complaining that the original maps didn't work anymore... And to prevent users from going full "FreeQuake" and replacing the episodes 2-4 with custom maps.

id Software already had people selling shareware Doom CDs full of custom content, and they decided to prevent that from happening to Quake. 
Cracked Quake Torrent When? 
Is there any particular reason why this behavior should be continued today in engines, aside from respecting id's desire to, y'know, actually sell a game and make some money from their hard work? In the modern world of filesharing, it's such a lackluster form of copy protection that it may as well not be there at this point. 
DarkPlaces has its own set of special rules for content, which you have to learn. Many modders for DarkPlaces struggle to make Quake compatible mods because they have habits that don't work with Quake. 
(you Knew This Was Coming! :D) 
"Where do you stop?"

You stop at making unpacked files take precedence over pak files. That's it. Don't use a fallacious "slippery slope" argument like, "but if I make a reasonable change, then I'll also have to make every unreasonable change everyone else wants!" This has nothing to do with supporting all the formats Darkplaces or FTE uses. You still haven't explained the benefit of leaving it "the way Quake has done it for 20 years?" That's not a reason. How many other non-optimal Quake behaviors have you already changed?

"It's Quake. For every one person who wants something done one way, there's going to be five others who want it done five different ways."

Well, so far you've got more than one person wanting unpacked files to take precedence, and NO ONE wanting it the other way, other than people just saying, "that's the way it has always been" without providing any benefit for that approach.... How many other non-optimal Quake behaviors have you already changed?

Will anyone step forward and say they prefer pak files to take precedence, and give an actual functionality reason for that?

"Gunter in particular has a very bad habit of 'what I want for my mod is more important than anything else', then causing drama and outrage over it. I'm not certain that's useful feedback."

Oh, bite me, mh :P

I just said this isn't an FvF issue -- it's a Quake issue. This would be better for everyone. I have laid out my actual arguments for why, and you have not provided a single counter argument to support your position other than, "I don't like when people want different things and I don't like Gunter because he always out-argues me" ;)

"A general-case solution that's more useful to everyone is always better than a special-case solution that just keeps one person happy."

I completely agree with you, mh! But that supports my (and others') position in this case that the behavior should be changed, because it would indeed be a general solution that would be useful to everyone!

I am dramatically outraged that you would think otherwise!! :D

Can you explain who it's useful for to leave pak file preference in place? Modders who want to inflict unavoidable toxic settings on the user?

I'm aking the same question as Pritchard here, "what benefit is there to keeping this behavior?"

Nobody is answering except to say, "it's always been that way and I don't like the complicated things Darkplaces does."

We're not taking about Darkplaces. We're talking about this ONE behavior. That's where it stops (in regard to this issue). This isn't a change that's going to cause any compatibility problems either....

Please describe the benefits of pak file preference. mankrip did a pretty good job of describing the benefits id saw back in 1996.... Now what is the benefit in the modern day? Isn't the whole point of engine development to improve on the original things that might not have been optimal for the users? I mean, why didn't we keep id's original network code? ;) Would it still serve any useful purpose today, or would it just make things more difficult for the user?

In regard to why I, as a mod author, use a pak file to distribute the FvF client files? Because it's the most tidy, convenient way to distribute a mod, instead of using multiple files and folders. AND it also keeps the user from easily being able to nose around in the files to swipe them for their own use! Heh. So yeah, a pak file still serves as a slight (very slight, really) deterrent for pillaging my content, however, I don't mind if the user wants to use other replacement content on top of mine, and I see no reason to make that a difficult process for them.

Again, this isn't just for FvF -- it's for anyone who wants to use replacement content for Quake with or without mods.

If you're looking for some form of consensus, why not run a poll on Quakeone? Then maybe someone would give an actual functionality reason for preferring pak file precedence.... 
You are new to a discussion about this topic.

I've read or even participated in this same exact discussion 6-8 times, including a couple of times at Inside3D and a couple of times at QuakeOne.

I used DarkPlaces before I ever engine coded and experienced firsthand the pros and cons of the functionality. I also like DarkPlaces as a total conversion engine and both Mark V, and before it, ProQuake acquired several gems from DarkPlaces.

It is safe to say my opinion of that DarkPlaces feature is due to knowing a lot about it works.

Typically, the those arguing for the DarkPlaces way of doing things is inexperienced with using the the feature, and unable to describe the downsides because they don't have the experience to understand the other side of the coin.

And perhaps I'll try to explain again. But probably not today.

Seems like no one is reading or making an effort to understand what I am trying to communicate in my replies.

I may be typing this post just "for fun" as it seems the other ones went unread.

But I hope it does get read ... 
OK, I'll bite.

The upside of having loose files take priority is that the user can easily replace PAK file content.

The downside of having loose files take priority is that the user can easily replace PAK file content.

Think about that - and if you don't have a Zen moment when it becomes clear, you haven't thought about it enough, so think about it some more.

This isn't just about copy protection, it's also about protecting users from malicious (or just plain old badly designed) mods and from themselves.

Whether you like it or not, the way Quake has done it for 20 years is the EXPECTED behaviour. Mods are made and released on the assumption that this is the way it behaves, experienced players run Quake on the assumption that this is the way it behaves, experienced players help out struggling newbies on the assumption that this is the way it behaves.

If it's in a PAK file it takes priority. This isn't about advantages of one vs advantages of the other. PAK files taking priority may even be the inferior option but that doesn't actually matter (I have an opinion too but it's irrelevant). It's about what everybody expects to happen.

You may have a different expectation but don't be so arrogant as to presume that your expectation should overrule 20 years of everybody else's experience. 
The way Quake works, if you have a mod with a pak0.pak in the folder (let's say -game zer) you have 100% assurance the mod will behave properly.

With the DarkPlaces way, a user will say "I don't know what is wrong? I have pak0.pak in place, but some weird model is showing up!"

Later they will say ... "Oh, sorry. I was doing XYZ and forgot to delete it."

The DarkPlaces way takes away the security of knowing a pak file containing a mod is a complete and full assurance of proper installation and running. 
I should add.

I do understand your frustration to a certain extent. I am the person who fought, and lost, the stuffcmd wars a few years ago, and stuffcmd is actually potentially dangerous to your PC, never mind just being a squabble-fest over file loading order. 
just stop using paks. you complain that paks taking precedence makes it hard for users to replace files, but you forget that any paks make it hard for the user to know which files they need to replace (and the form of that data too).

that's not to say that I agree with Baker, frankly I see his argument as user-hostile that further discourages people from grouping their content thereby making it MORE likely that people will be stuck with content that they forgot to delete on account of not being able to separate it so easily.

quakeworld downloads often REQUIRE files outside of paks, or at least maps.
The singular exception is when you have md3s or q3bsps that depend upon shaders and external textures that the client won't know to auto-download. In these cases, pk3 is a superior format that offers compression and is easier for people to open. Essentially, such content should be treated basically like q3 content is treated. But until then, just don't use paks. 
PAK files also serves as a versioning system.

If your mod is fully contained in a PAK0.PAK file, you can make an update for it by storing the updated files in a PAK1.PAK file. And then, you can revert to the previous version by simply removing the PAK1.PAK file. I've actually done this in one of my mods, because it gives the advantage of knowing that the PAK0.PAK will likely always be the same, no matter the version of the mod.

Loose files doesn't use a cascaded versioning filesystem, so they require you to remove all previous versions of the files, which makes it impossible to rollback a bad update.

Anyway, a command-line parameter to control the precedence could be nice for development purposes. 
Why Is This Getting So Much Attention? 
Clearly it makes no sense to change this behaviour except to keel to the whim of a single individual. 
We are reading what you write, Baker, but you're just talking vaguely about Darkplaces. I don't use DP. I just happened upon the functionality in FTE, and I liked it -- actually, I didn't even realize it was different; I just knew that FTE did exactly what I wanted/expected it to do -- it used the player.mdl file that I dropped into a folder.

Now you're saying that pak files are good because they let the modder know 100% that the mod will work for the user, but you've previously been talking about how Arcane Dimensions installs everything unpacked, so it doesn't have the issue of pak files overriding user content.... It's like you're telling me I should do it two different ways! Why can't I have both the convenience of putting my mod files in a pak to ensure easy/correct installation, and also have the ease of letting more tinkery users drop in their own content if they want to?

Sure, they might mess things up, but this is the same issue as any other piece of software you give to a user. The user might mess things up. If they do, they can just delete and re-install the thing....

What I'm now hearing from you and mh is, "protecting the user from himself."

Like if the user installs some replacement content, then later derps out and forgets he installed some replacement content, and can't figure out why there is replacement content in his game....

Would not the same thing apply if he were using extra pak files?

Is Quake 1 really a game for derps? Is that the kind of user you are designing Mark V for?

Everyone derps out sometimes, but unpacked replacement content would still be easier for a derp to find/remove than stuff in a pak file, because it's all easily visible unpacked. In a pak it's hidden.... "What is this pak4 thing I have in my folder? I do not know. And why is my player model so weird?" vs. "What is in this progs folder? Oh, there's a player.mdl in it. Oh! That's why my player looks so weird!"

So, mh says for both pro and con, "it makes it easier for the user to change things."

I don't know why you're not having a zen moment about that yourself.... You strike me as the kind of person who would use linux because you'd hate Microsoft always "protecting you from yourself" and not allowing you to change things you want to change.... This reminds me of an old commercial:

So do you think it should be easier or harder for a Quake user to change things? Apparently "harder?" So you're a Windows guy, eh? :D

(I'm actually a Windows guy myself, but I'm a superhacker, so I make it do what I want ;)

Ya know, the whole reason that Quake is still alive after 20 years is because it was relatively easy for users to modify stuff.... Zen moment? Should it be easier or harder for users to modify stuff in Quake?

You also throw in that it's about protecting from malicious/badly designed mods... Uh, isn't that backward? Unpacked file preference would help protect from bad mods, because the user could easily see/change unpacked files or replace stuff in a pak file with their own stuff (a bad autoexec in a pak file, for example).

As far as "expected behavior," well, it's "expected behavior" (how it has "always" been) that you must put the Quake CD in the drive to play the soundtrack. But now we can drop mp3 files into a folder and play the soundtrack.... That "expected behavior" was changed to make it easier for the user. This is the same concept: let the user easily drop in files for Quake to use. Should we not allow that because some derp might drop in the wrong mp3 files and then wonder why Ace of Base is playing when they start Quake? :D

And I have to ask, "expected behavior" of whom, really? Certainly not any new players, or other people who have never messed with this stuff in detail. Heck, I don't regularly mess with it in detail, and I actually expected a player.mdl to be used just by dropping it in a folder! Then I was like, "Wait, why is this not working? Oh crap, the pak file overrides it."

So I ended up having to stick my single replacement model into a pak file.

What a hassle. I can't imagine that's good for anyone, no matter what they expect.

And being that many experienced users will be using other engines like Darkplaces and FTE, well, their "expected behavior" would not conform to the 20-year-old way either.

So maybe some old Quakers are "expecting" it, but I bet if you gave them the option, they would prefer it to work in a different, more convenient, way.

Actually, Baker, if you have links to the multiple discussions of this issue you've had in the past, I'd be glad to look them over to see what else I may be missing.

mh, I'd probably be against you on the stuffcmd issue, heh. It is a useful tool for modders -- aure, abuse is possible, but I use it to bind the FvF chat impulse so players lower their gun and blow smoke while chatting. But I think Mark V has some cfg protection for stuff like that. 
"just stop using paks."

Sounds so easy, but in practice that means I'd have to completely unpack my id1 pak1 and pak0 files. That's a mess of files! (I'm not just talking about my mod, but every mod with a pak, and also standard Quake.)

And just because I might want to use a replacement player.mdl ?

Heck, it's actually easier to complain a lot about it and hope Baker might consider changing it ;)

(But really, it's not just to make things easier for myself, but for other people as well). 
Low Brow Vs. High Brow @spike Mostly 
There are low-brow engines and high-brow engines.

Low Brow Engine - Your TV remote has 4 buttons (Mark V)

Favors an uncomplicated and reliably smooth and enjoyable experience and will sacrifice options, capabilities and preferences to get there.

Assumes the user knows nothing, has guard rails. Caters to the user that knows nothing -- protects them. Most features are obviously exposed, few features beyond core feature set.

When no one has any questions or problems, the Baker feels like "Mission Accomplished!" It's reliable and intuitive!

High Brow Engine- Your TV remote has 106 buttons (DarkPlaces/FTE)


Caters to advanced users. Plenty of settings. Plenty of capabilities. Support for cutting-edge techniques. Boundless depths, options, abilities.

Assumes the user knows everything and caters to the user that knows everything. Has layers and layers of features beyond the obvious ones.

When a user has something sophisticated they want to do and realize that FTE can do it, Spike feels like "Mission Accomplished!" It helped someone with sophisticated needs execute their idea!

(This is why Spike and I seem to argue a lot about some things, but agree about others.) 
"Clearly it makes no sense to change this behaviour except to keel to the whim of a single individual."

Uh, no.

I've laid out clear, concrete reasons why it "makes sense," which have nothing to do with my whims.

And I'm going to count at least 3 people here that might prefer it the way I am advocating for. Make that 5:

mankrip (for a command line parameter to allow the option)

And I will count:

(their creators obviously preferred this functionality)

You see me arguing for it, but I am arguing as "the user" and not just for myself. This would make it easier for every user.... It's just that every user doesn't read this forum. Do as I have suggested -- make a poll on Quakeone where there are more users, and see what everyone else actually thinks. 
Count me in with mankrip re: the command line switch to change the behavior. Why not give the user the option? I don't see the downside. 
I hadn't really considered the "versioning" aspect of pak files, but it certainly does make it easier when, on the rare occasion, I update the contents of the FvF client pak file, to know that all the user will have to do is replace their pak file with the new one and they will be correctly updated. If I were handing them the mod as unpacked files, that could be messy and tricky if I ever removed some of the files.... I'd have to give special instructions to delete certain files during the copying of the new files.

So that's another reason why I use a pak file for FvF -- easier/more foolproof updates for the user.

And I too would be happy with a variable to alter the file/pak precedence. That would still make it easier for people, because I could tell them, "you need to set this variable to let your replacement model work correctly." 
A command line option doesn't seem objectionable. I'll consider it without making a promise as to when.

So it is very likely to happen, unless it somehow interferes with something else. Which doesn't seem likely.

Having the option available would be nice, there are sometimes it is nice to change things on the fly easily.

I just don't like that as normal default behavior. 
Excellent. Thanks for considering it.

I'd also hope it will includes a console variable for easy setting, even knowing that would be something like, "this setting will not take effect until you restart Quake/the map/whatever is required."

I wouldn't dare suggest a menu setting, knowing how much you hate menus ;)

But then again, a menu setting would make it easy for the low-brow derps who Mark V is intended for!

*Throws an FvF ninja bomb and runs away* 
I Wouldn't Have Submitted 
I'm disappointed Baker. 

Nice denial of service you have going there.

You see Gunter - you need to think beyond what you immediately want. 
Yes, I already agreed that abuse was possible. I just said so.

But do you remove all the potential valid, good uses of the command because of hypothetical bad uses? (Has your example ever actually been used in a mod?)

Hey Baker, I think mh is asking you to prevent screenshot from being used in a stuffcmd!

Mark V already protects your cfg file getting messed up by stuffcmds.

I can't think of a legitimate reason to allow stuffcmd screenshots.... So that's something that could be prevented.

But removing the whole stuffcmd functionality would be throwing out the baby with the bath water. 
There's no simple way to implement a cvar for it, because config files are only loaded after the filesystem is initialized. It's impossible to make a cvar change the filesystem initialization behavior.

Now, if such a cvar would be used to change the filesystem behavior on the fly, that would open a can of worms, specially on engines that supports changing the game directory on the fly: Set a mod dir, change the precedence, and add another mod dir; the precedence of the previous paths gets screwed. 
And that's why you wouldn't make a good engine coder.

In the end, Baker is interested in improving his engine for the users, and not just winning an argument for the sake of winning an argument.

Actually, that's why I post here too -- not to "win arguments" but to improve Mark V for the users, of which I am one!

My ideas of what might be an improvement may not be the same as other people's ideas, so we argue about it, but it is not personal, not even with mh for me (he's done great things for Mark V), though sometimes I can't tell if he gets caught up in just wanting to win the arguments or not ;)

In the end it would be silly to stubbornly refuse something that several people are stating a preference for, if the only reason is "don't give in to Gunter." Baker is not that petty!

And I'm certainly glad other people do speak up to state their preferences here, so that mine is not the only voice. 
I Dunno Man 
It's not about whether I would make a good engine coder. I probably wouldn't but not for the reasons you gave.

It just appeared, from an observers POV, that you basically bullied and harassed Baker into adding a feature after he gave you plenty of well-reasoned answers as to why it wasn't a good fit for the engine.

I mean, I have asked him to include stuff from time to time but I am in awe of the relentlessness of your stubborn pleas.

Maybe I am just better at taking no for an answer. 
There were wins here.

Gunter did argue annoyingly hard.

Then again, he did eventually suggest a viable solution -- which no one has ever done before -- in the idea of making off by default but with ability to opt-in.

mh signaled he had complicated feelings on the subject and I've used DarkPlaces before for some deep modding where the functionality was helpful.

I've also seen DarkPlaces beg and scream for help because they messed up something so terribly bad and no ones wants to reply to them because usually it's a super-newb who barely can find their Quake folder so they get the "leper treatment" or insightful advice like "delete your Quake and reinstall".

So ... I think I'll have a beer and hope to laugh about this in the future. ;-)

/Gunter has found some very, very obscure bugs in the past. And spotted inconsistencies few would notice, allowing them to be resolved. 
You surrendered like a Frenchmen! D:< 
"Gunter did argue annoyingly hard."

I do everything annoyingly hard!

(That's what she said!) 
Fifth's joke was better. 
I shall prepare a PowerPoint Presentation to prove it was not.... 
Is 64-bit Linux support coming? That would be awesome. 
There is a Linux version available on the Mark V page for those interested in provided feedback and willing to experiment.

A few people have said it works very well. One person had some audio issues with their sound system. Tested on Ubuntu, told it works fairly nicely with Debian.

Your mileage may vary. 
No makefile for linux. :( 
I may have missed something in the avalanche of posts, but when Gunter started talking about having to unpack the id1 pak0.pak and pak1.pak files I started to wonder if there's a fact being overlooked...

The pak file precedence over loose files only applies within a game directory, right? I believe it is the case that a loose file in a game (mod) directory takes precedence over any file in id1, regardless of whether the id1 file is in a pak or not, correct? Is everyone on the same page about that? 
Post #874 has compile instructions. 
@ Johnny Law 
I believe you understand correctly how it works.

But say you want to only replace the player.mdl when paying standard Quake... with the one contained in this pack:

That becomes rather annoying to do, since it's not as simple as just dropping the replacement model into progs\id1\, because the pak file will override it.

So you end up having to create whole new "mod" folder just to use one replacement model, then you have to create a batch file to run quake -game whatever, or you have to type "game whatever" in the console if your quake engine supports it....

What happened with me is that a player took that model and applied the FvF skins to it, so I wanted to try it out. The problem is that FvF already contains a reskinned player.mdl in its pak file in my FvF mod folder.... So again it was not so easy to just drop in the player.mdl and try it out.

So Spike suggested "stop using pak files" and that's why I described having to unpack the id1 pak0 and pak1 files too, because even if I'm not playing FvF (or any other mod with a pak file) I'd still have the same problem if I were trying to just replace the player.mdl (or some other model) for standard Quake. 
OK I'm going to try this one more time.

The way Quake has always loaded content goes like this:

- Gamedir 1/PAK files/Loose Files
- Gamedir 2/PAK files/Loose Files
- Gamedir 3/PAK files/Loose Files
- Etc.

(And yes, even stock ID Quake can load more than one extra gamedir; try -rogue -hipnotic -game XXX").

Here is the Quaddicted Single-player maps archive:

This is a repository of content all authored under the implicit assumption that certain Quake engine behaviours are consistent.

I say "implicit" because I'm absolutely certain that none of these authors (or at best very few of them) ever sat down and actually thought about this. But nonetheless the assumption is there, so please don't try to play silly buggers about it.

Change the content loading order and do you know what is going to break in those maps? Because I sure as hell don't. So they'll have to be tested, somebody's going to have to go over them and check that there's nothing in them that breaks.

What you have is one case, and it's not even a gameplay case - it's a test case. And you're behaving as though you believe that one case should take priority over everything else. You're jumping up and down shouting "I WANT I WANT I WANT" like a child, and not showing any awareness whatsoever that there is a whole body of existing content and Thou Shalt Not Break Existing Content.

One test case in FvF does not get to take priority over the body of existing content.

Feature requests are always more likely to be listened to and taken seriously if the person making the request gives some indication that they've thought it through and that they understand the implications. I'm not seeing that from you. 
I don't think anyone has put much thought into that compatibility angle before.

Considering the volume of single player releases, it would require an enormous amount of effort to find the ones with conflict situations. 
This is the kind of thing I've been bitten by before.

Even what seems like quite simple changes, say something related to behaviour of the viewsize cvar, can explode spectacularly if a mod uses it in an unexpected manner.

I think the key phrase there is "in an unexpected manner". The definition of an unexpected manner is that you actually cannot predict in advance what the impact is going to be, so it's no good someone asking for a list of disadvantages to a proposal.

"When in doubt do what ID Quake did" is a good maxim for certain classes of changes. With the SP community having converged around FitzQuake and derivatives, "when in doubt do what FitzQuake does" is also a good maxim.

We're not just talking about engines either. I've seen enough content made with buggy tools that just happens to work because engine behaviours or quirks accept it. I've been in a "put the bugs back" situation more than once.

The onus is on the person asking for a change to demonstrate that the change is benign, or at least that's the way it should be. Changes to very fundamental behaviours of core subsystems should always be approached with extreme caution. 
Ok, I see it is IS personal for mh. I think he just dislikes me because I consistently out-argue him. Well, he's going to like me even less after this.

mh, you are just being a crybaby now, but let me address your actual "arguments."

"The way Quake has always loaded content"

Yes, that's been pointed out repeatedly. But as Pritchard said, that's like saying, "Quake for 20 years has done things the wrong way" Or, if not strictly "wrong," then certainly in-optimal.

"Change the content loading order and do you know what is going to break in those maps? Because I sure as hell don't."

I do know: Not a single damn thing. Nothing. Do you know what kind of contrived situation would have to exist for the loading order to break map packs? The mod would have to install both a pak file AND unpacked files with the same names, yet with the files in the pak being the only ones that are supposed to be used, because for some reason the unpacked files with the same name are not the same files....

Seriously, HOW ELSE could the file load order mess up a map pack? You probably can't even come up with a realistic situation where it would, without your user do really weird stuff (which could happen no matter the load order). Maybe if the map installs as a pak file in your id1 folder and you already, for some reason, have different maps with the exact same name unpacked in your id1/maps folder??

The fact that you don't see it wouldn't cause a problem except in an extremely contrived circumstances shows that YOU are the one who isn't thinking this through.

Your flimsy argument amounts to trying to whip up fear of a boogeyman which would never actually occur unless you intentionally tried to make it happen. "But something might break! You just don't know!! Think of the children!!!"

You're grasping at straws.

Seriously, are there any maps/mods on Quaddicted that say, "this will not work with Darkplaces or FTE for some reason"? No? I'm not surprised.

"What you have is one case, and it's not even a gameplay case ... One test case in FvF"

Uh, no. I said it could impact anyone playing any mod or standard Quake if they wanted to easily use replacement content. I've pointed that out repeatedly. Do you not comprehend?

"Not even a gameplay case?" What? This isn't some hypothetical thing I came up with out of nowhere -- I never would have brought up the issue if it had not IMPACTED MY ACTUAL GAMEPLAY. Do you not comprehend?

You characterize me as crying like a child, but it's you, mh, being the crybaby. You're just being ANGREH. You don't have actual good points to support your position -- just hypothetical boogeymen which it's clear you didn't even think through (or you would have realized how ridiculously improbable it would be to actually break any of the maps from Quaddicted).

"When in doubt do what ID Quake did"

See, that's rich, because in the past when I have argued for using Quake's Default Behavior instead of some change Baker has implemented (centerprint position, or start map guessing), you have thrown the same whiny bitchfit over it. So it seems it doesn't matter whether I'm advocating for Default or not -- you're just against whatever I suggest.

(Normally I like Default presentation to the user, but this is behind-the-scenes, to make replacements easier)

"Feature requests are always more likely to be listened to and taken seriously if the person making the request gives some indication that they've thought it through and that they understand the implications. I'm not seeing that from you."

I can only laugh at this :D

You're not seeing a LOT of things, mh.

So don't even worry about it. If some weird, obscure issue pops up because of this change, you can bet *I* will be the one to find it! I'm the one who has been finding the weird, obscure bugs that result from the changes Baker has made, because I have an extreme eye for detail and a meticulous mind for thinking on many different levels. So just because you "sure as hell" can't see what might beaffected, don't worry -- I can. ;)

Now, was any this necessary, mh? Nope. Baker already decided to leave the default behavior in place and add an option for the user to change tit. Yet you still felt the need to make a fuss and post at me with silly arguments and insults, because, apparently, you are a sore loser. And like FifthElephant, you just didn't want to see me get what I want.

Now, I normally do not post at people in such a demeaning manner as I have at you here, but this is certainly how I respond when someone insults me the way you decided to. So, if you don't like this, then refrain from making such petty characterizations of me in the future :p and then I will stick to addressing your actual arguments as I normally do.

Baker, don't let the "compatibility scare tactic" dissuade you from this -- you know if it produces any unexpected negative issues, I WILL find them! ;) 
mh is relating his experiences involving the development of DirectQ. He is not referring to you at all.

I watched some of the DirectQ users "carp" on mh with insisting DirectQ must do certain things.

Something unseen here is that very few engines end up surviving compatibility.

I could tell you things that crash qbism super8 hard. I could tell you things that don't work right in FitzQuake. I can tell you things that don't work in Quakespasm.

mh and I work well together because we view compatibility as #1.

/So please leave mh alone. I already said what I plan to do. 
Might add that I also know single players that have problems with Mark V's automatic impulse 12 support. If you are serious about compatibility, you know your own engine's weaknesses as well. 
Seriously, are there any maps/mods on Quaddicted that say, "this will not work with Darkplaces or FTE for some reason"? 
Remove: "single players"
Substitute: "a couple of (rare) single player mods"

/Premature submit strikes again! 
Now, was any this necessary, mh? Nope. [...] And like FifthElephant, you just didn't want to see me get what I want.

I wish someone wanted my naked body that hard. Now I'll feel jealous of Baker too. 
@Baker "He is not referring to you at all."

Ah, well, then I must have misunderstood when he used my name ;)

But it's no big deal for me, really. I approach internet arguments like a Quake Deathmatch: whether you win or lose, it's all for fun, and it's not worth getting legitimately upset over. :D

@mankrip Yeah, I guess I really should have specified I was talking specifically about compatibility with Darkpalaces due to the unpacked file preference is has. I have no idea about all the many other differences in Darkplaces, and what compatibility issues they may cause.

Actually (side story), I remember several years back I tried using Darkplaces for the FvF server, but I encountered compatibility issues.... I think I emailed LordHavoc about it, and it was something about either checkbottom or some other way to see if something was on the ground, and what I was doing in FvF wasn't working in DP. LH said that code never really worked right in standard Quake or something.... In any case, I went back to proquake server, and I don't know if the problem would have been fixed by now or not.

So yeah, I understand compatibility issues are indeed important, but "compatibility problems have been caused by other things" isn't a valid argument in this specific case. Do we never try to change/improve anything due to fear of incompatibility? No, but of course, we do tread carefully. 
"I wish someone wanted my naked body that hard."

Well, just make a quake player.mdl with a skin of your naked body, and it will be REALLY EASY for people to drop it into their game once Baker makes the setting available!

(And NOW I see the downside!! What have I done!??) 
Ok, now that this is all settled ...

It's June. It's great weather and sunny ... 
It may be sunny now, but not for long!

Anyone else going to catch that full eclipse in August?

It is passing DIRECTLY overhead for me -- I am right in the center of its path.

I guess all those sacrifices to Shub-Niggurath are having an effect! 
I'm in the southern hemisphere, and it's winter now; no snow, though. 
"But it's no big deal for me" - Gunter after 3 scroll pages of bitching.

Please don't include me in your diatribes either, I was poking fun at you light-heartedly. Baker clearly got this. 
Ok, got it. You are allowed to "poke fun" at me, but I'm not allowed to mention what you said. That's a reasonable expectation. 
Might be time to move this to the beef thread as Pritchard has suggested. 
It's not an "internet argument" though. You don't seem to understand that, but it's not. This isn't an argument where somebody wins and somebody else loses. 
Then I'm not sure what it's about for you, mh.

From your first post on the matter ( #1574 ) you decided to assault my intentions and motivations and mis-characterize me in a poor light.

Even on a side issue you felt the need to make it about ME rather than what I was saying ( #1595 ), but I continued to address the argument rather than the arguer.

Then after the issue was settled (Baker decided to leave the default as-is, but to add a setting to change it -- a win/win situation) you again decided to post and complain and VICIOUSLY assault my character and motivations.

THAT is the point it became an "internet argument."

Now, I want to clarify: only my last post was what I was referring to as "an internet argument" in regard to having fun winning or losing -- normally when I say "argument" I am using the formal sense of the word: arguments and counter-arguments and making points in a discussion. But an "internet argument" (I probably should have said "internet squabble" or something) is more like a flame war.

Yeah, at that point it's more about "winning," but if you look back up to my post #1598 you will see I said just what are you saying now -- the point of me posting here is not about winning or losing, it's about helping to improve Mark V (and this feature will be an improvement to Mark V). I even said in that post that it wasn't personal with you.

If you believe in your position, you make good, valid arguments for your position. You don't start questioning the character of the person who is not for your position.

Now, I am a Quake player, after all, so when you fire enough rockets at me, I will fire a BFG at you ;)

This was the FIRST time I have assaulted your character in all of these Mark V discussions, but it is certainly not the first time you have questioned mine and cast me in a negative light.

If you want to avoid this again in the future... just stop doing that. Let your (formal) arguments stand on their own without making it personal. If your arguments are sound, then they are sound and they should hold up on their own no matter who you are arguing against. So how about you stop casting aspersions on my character?

Anyway, it STILL isn't really personal for me, despite me firing a BFG at you.

So let's be friends! 
Theres A Reason Why The Quake Mod Scene Is Dead 
Hi, I'm using the Mark V 1.36 source port and when I enter the exit portal of Gloom Keep, the game often (about 5 out of 10 times) crashes back to desktop with the "Mark V has stopped working" notication. This happens both with the regular gl version as well as with Dx 9. Is this a known issue? 
I can't remember if I have it fixed in the unreleased version or not. I'm thinking it is fixed whenever the next update will be released (date unknown).

That was a fun mystery, engine coding-wise.

When you go through the exit teleporter on Gloom Keep, there is a world brush model that has never been seen before and isn't visible in that frame either, but due a mirror surface in the area, the model comes into visibility but hasn't been precached.

I have to assume that since I know so many details about the circumstance that I have rectified the situation in the in-progress version. 
Thanks for the answer. I deactivated the mirrors via the console command mentioned above and now it works fine. 
UI And HUD Aspect Correction 
Since this problem appears in a bunch of modern ports I will repeat my post of half-a-year ago

Quake is originally designed for 320x200 resolution to be run on 4x3 displays (just like Doom). This means, that whole screen should be stretched vertically. The original game nicely adjusts viewport so that actual gameplay window is always at true aspect no matter what resolution is set - 320x200 will look exactly like 320x240. But the UI is not. It is designed to be stetched, so it only looks right on 320x200 and 640x400 resolutions and is "squished" on every other.

So what's the problem? Mark V removed id's aspect corrcection and treat every resolution identically. Setting up 640x400 and 320x200 result in stretched in height gameplay window.

The ideal solution would be to add an option to make correct UI scaling. Here's some example shots of original winquake and Mark V scaled to 4x3 and upscaled 
Nice to mention this, it's one of the most overlooked things in custom engines.

But I'd like to add that Quake is actually inconsistent when it comes to video aspect, because the 3D renderer was coded for a 320x240 4:3 screen (square pixels), while the 2D renderer (and artwork) was made for a 320x200 4:3 screen (non-square pixels).

Doom's "3D" renderer was indeed coded for non-square 320x200 4:3 pixels, IIRC, because it didn't support other resolutions (before WinDoom). Quake was the first id engine with multiple resolution support, so it's quite poorly coded for it in some areas. 
I'd be cautious about how this change would look in a hardware accelerated engine. On the surface it seems easily achievable by just rescaling your ortho projection and 3D viewport by the appropriate amount, but there's gonna be a whole lot of edge cases with texture filtering that will need to be worked over. 
But I'd like to add that Quake is actually inconsistent when it comes to video aspect, because the 3D renderer was coded for a 320x240 4:3 screen (square pixels), while the 2D renderer (and artwork) was made for a 320x200 4:3 screen (non-square pixels).
the only thing is that it wasn't. original software renderer actually could do a valid 3D picture with virtually any resolution and pixel aspect, and if you choose 320x200 (640x400) you will get just right picture in every aspect (no pun intended) 
Milkey Wilkey 
The particle renderer, which is part of the 3D renderer, was explicitly coded for 320x240, with double height scaling for 320x480.

The underwater warp is also inconsistent across screen resolutions and was coded for a 320x240 video buffer, as explained in this standardized test. It also means that it's impossible to always get a fully aspect-correct image in ANY resolution in the original renderer, because while the HUD only displays properly in 320x200, the underwater warp's waves only displays properly at square-pixel screen aspects (320x240, 512x384, etc).

The original software renderer is not consistent even across multiple HUD sizes.

The software renderer also screws up skies and particles when the FOV changes.

But most people never pay enough attention to notice all the problems in the renderer. 
I... uh... um.. er.... :u

Ok, yeah, I'm bringing up the contentious topic that we just put to rest, but bear with me... you will NOT see the ending coming!

Ok... So, I was considering what mh was saying about "expectations" that people supposedly have about the loading order for content like models, in regard to the pak files vs unpacked files having preference (default from original Quake is pak).

Previously I pointed out why this isn't just for mods (mine or anyone else's) -- it's also for standard Quake if you want to use the player.mdl from this pack:

I looked at the readme file included with that, and it just says, "To use these new models place the 'progs' folder inside the 'Id1' folder in your Quake directory."

Ok, so it's apparently not the model creator's expectation that pak files should take precedence, so he must have been using one of the modern engines that changed the behavior.

So then I did a web search to see how other people might answer the question, "how to replace player.mdl in quake." The first link that pops up is a Quakeone forum post (naturally) where someone was asking just that: "Easiest way to replace player model?"

On page 1 of that topic, someone mentions creating a mod folder and dropping the file in the progs folder of the mod, and another person mentions something about looking in the pak file.

Then at the top of page 2 of that thread:

the guy is told, "Yes. You can just create a "progs" folder into id1, drop the model into and you're done."

Ok, so again, expectation seems to be that just dropping in the unpacked model should work, and the final post in the thread has the guy saying he did just that and it works... with DirectQ....

Yes, that's the kicker. The guy asking the question said he was using DirectQuake (he said that on page 1 as well).

DirectQuake is mh's own Quake engine, and IT HAS UNPACKED FILE PREFERENCE. :u

I decided I'd better test this for myself, so I found and downloaded DirectQ (for some reason it's not that easy to find), version 1.8.8 (because 1.9 crashed for me), and sure enough, it's just as simple as dropping the unpacked player.mdl into id1/progs/ and it works in DirectQ!

So... like... um.... Do I need to repeat that? mh has been BLASTING me for daring to ask for a feature THAT HE ALREADY PUT IN HIS OWN ENGINE :u

So yeah, Baker, please import this wonderful feature that mh was wise enough to implement in DirectQ :D

I have admitted that I've been wrong about things in the past. DirectQ was riddled with mistakes, I freely admit it, and that's one reason why it's no longer developed. You don't get to score points that way I'm afraid. 
...back To Sanity... 
I'm more inclined to believe that the 2D GUI gfx were actually designed with a 1:1 mapping of texels to pixels in mind, rather than any specific resolution. 320x200 is just an accident of history.

I did code up aspect adjustment just to see how it looks and as expected it's pretty crap when texture filtering kicks in.

It might be OK as an option but otherwise I'd leave the default alone. 
I'm more inclined to believe that the 2D GUI gfx were actually designed with a 1:1 mapping of texels to pixels in mind

Look at the pentagram icon. It should be a perfect circle, which only happens at 320x200. At 320x240, it becomes oval.

Also, the console background itself was obviously made with a non square pixel aspect in mind, and it has text pasted over it by the engine. With square pixel aspect, that text's aspect becomes different from the aspect of the rest of the engine's texts.

The help screens, which were made to cover the whole screen, are also 320x200.

And lastly, enlarging the 2D art vertically when using square pixels makes more sense than reducing the 2D art vertically when using non-square pixels. If the 2D art was reduced vertically, the help screens wouldn't cover a whole 4:3 screen. 
By the way, non-square 2D pixels should be optional, because several mods uses custom GUI artwork with square pixel aspect.

When rewriting the GUI renderer, I'm going to make it use an optional non-square scaling enabled by default. 
I think about the 2D rendering differences.

As there is no separation between the software renderer vs. the Open GL build -- it is FitzQuake calling the shots and saying what to draw and the location -- using a canvas system that WinQuake never had.

The source code in Mark V doesn't actually trace back to WinQuake, not even for the WinQuake build.

Which is way different than mankrip's engine or qbism super8 or engoo.

It is also why Mark V has immensely more versatile video capability than any other WinQuake. The video code is literally 100% FitzQuakian.

Shorter version: Eventually the aspect ratio thoughts will happen once the engine eventually settles down where there aren't "big leaps forward" looming. 
Eventually the aspect ratio thoughts will happen once the engine eventually settles down where there aren't "big leaps forward" looming.

Same thing here about colored lighting. It would be a pain to implement it now, only to rewrite everything when the new color transformation system gets implemented. 
Just to clarify what I mean: here's som screenshots with various combinations of aspect correction and texture filtering.

The "200 Height" shots are using the old 320x200 resolution but at a 4:3 aspect.

Pay particular attention to the menu slider bars. This is what I mean by a 1:1 mapping of texels to pixels. 
Oh, yeah. Now I know what you mean.

When you said "1:1 mapping of texels to pixels", you didn't limit the meaning to square pixels. A 4:3 320x200 screen will have non-square pixels, but the texels also have the same non-square aspect, so the screen will display the texels in a square ratio to the pixels.
A 4:3 320x240 screen multiplies the rows to compensate for the "non-square texel to square pixel" aspect when necessary.

Yes, such scaling generates notable artifacts at lower resolutions, which is another reason to make the 2D aspect correction optional. But at higher resolutions, the artifacts becomes unnoticeable. Also, some custom texture filters may help. 
You don't really get to do custom texture filters with hardware acceleration though. Well you can, but you have to write them yourself in fragment shaders so a lot of popular engines don't get to play. Otherwise texture sampling is fixed functionality.

Forgot to mention - one thing I really like about Quake's 2D graphics is the fact that they're so crisp and clear, and this is as a result of the precise pixel work that went into creating them. It's something that you might not notice at first, but any kind of texture filtering on them blurs out a lot of the fine detail. 
Texture Filtering 

Would be nice for some maybe to have a gl_hudfiltermode convar. 
Really Though 
If there was a Quake engine that supported temporal antialiasing (TAA), then texture filtering would be completely unnecessary. 
I've cropped your unscaled screenshot to 320x200, and did some tests using The GIMP:
320x200 source

320x240 mockup, nearest scaling

320x240 mockup, bilinear scaling

Bilinear scaling in The GIMP shows that it's possible to scale Quake's 2D GUI in a way that looks good. It may be complicated to get that same quality using hardware rendering, but it's definitely possible. 
Tool_inspector, Why Are You This Way? 
Mark V Question 
How can I keep Mark V from messing up my Quakespasm cfg? I switch back and forth between these engines and right now I exec a specific config for QS after using Mark V but it's still a bit messy. I gather that this is some kind of anti-cheat thing from some research here.

What am I missing? How can this be more seamless? 
two separate quake directories.
alternatively change all your config.cfg files to readonly so that nothing can overwrite them. 
Meh. Well, at least I have options. 
I gather that this is some kind of anti-cheat thing from some research here.
I don't think it's anti-cheat, what happens is when you exit an engine, it overwrites config.cfg with only the cvars / keybindings that engine is aware of.

So it's more of a limitation of the original quake config system, when extended to engines with diverging sets of cvars/keybindings.

I'm not too familiar with what has been tried to remedy this. 
Would be nice if the engines had their own sub config.cfg for the "new" non-vanilla id, non-standard cvars it has implemented.


...and so on. That way we could keep my vanilla config and each engine looks for that and then loads theirs. Even if there is overlap the engine in question would ignore the others. I assume it's not this simple and would require co-operation to make it a "standard." 
No, it actually is that simple. It's something like 4 lines of code. In Cmd_Exec_f detect config.cfg and write in the engine cfg, in Host_WriteConfiguration write out the engine cfg.

I have no idea why it's not done. I'd love to see it done. 
and write both a config.cfg and config-engine.cfg with the same contents, as encouragement for other engines to follow suit... well, that and so new engines pick up usable defaults too.

however it would also need to be gamedir aware for all those mods that came with a config.cfg provided, so they don't read settings from id1/config-engine.cfg in preference to those in mod/config.cfg.
if engines had done the same with config.cfg vs default.cfg, we wouldn't have mods doing the stupid thing of including config.cfg files!.. 
Is the most recent MkV release capable of running "The Forgotten Sepulcher" from Arcane Dimensions v1.6? 
The main engine-breaker in Sepulcher appears to be the leafs count; this is used for several hard-coded arrays in the engine and even the extended max in Fitz or earlier versions of QuakeSpasm is insufficient for Sepulcher, which needs 73755 leafs.

Personally I think that engines should be dynamically allocating these instead of using big static arrays, because otherwise it's an arms race: an engine will bump the max, a map will overflow it, an engine bumps it again and so on.

Anyway, the latest MarkV bumped MAX_MAP_LEAFS to 65535 for the Rubicon Rumble Pack, so it too is insufficient to run Sepulcher. 
Other Ad_sepulcher Limits 
1375 models
368 sounds
193 lightmaps (assuming 128x128)
2877 static ents
4743 efrags

For QS I made efrags dynamic, and was going to do the same with static ents (although 3k is about the upper limit with protocol 666 because of 64k signon) 
Sky Visible Through Water 
Very nice engine. Just one thing. When you set the water to be opaque like the original, the sky is partly visible through it in the hardware renderer. But not in the software renderer. This seems to be the only noticeable discrepancy between the two, apart from affine mapping not being possible in hardware either. How hard would it be to fix this? 
Here is me on E1M2 looking at the sky with opaque water using the hardware renderer. The sky isn't partly visible.

Hardware renderer, opaque water, looking at sky -- none seen

Maybe a screenshot of what you are referring to would help? 
I believe he's referring to the same issue some of us have reported before: shadows and the sky are visible through models (and water surfaces it seems) in the DX9 version. (see #1098 #1206 -- mh knows about it: #1109 ).

I jumped in the pool on e2m1 and saw the effect he's describing. 
Hello i have problem with Dissolution of Eternity HUD.
"The armour / ammo icons displayed do not match the actual armour or weapon you have equipped."
This person has the same problem,he is using a PSP port,im using a Mark V.Is the problem on my side or Mark V? How do i fix this? 
What command line are you using to launch it? 
Using -hipnotic the command line? Yes/No?

Probably your problem. Let me know.

@gunter - ok, r_shadows 3 option. Maybe a week later after his post I realized that was likely the issue he was experiencing. 
I meant -rogue, not -hipnotic.

No More Vsync In Mark V WinQuake? 
WinQuake runs with constant stutter but I couldn't find any way to turn on vsync. Can anyone help? 
I don't know of any WinQuake that ever vsync since that is a Open GL feature.

That being said, if you really want a WinQuake with vsync ... here is a slightly older beta with vid_vsync 0|1 capability:

It is the WinQuake-GL.exe in that .zip that has vid_vsync because it renders the buffer to an texture and then draws it on the screen through Open GL. 
Thanks Baker, I found that build last night and it's fantastic for playing Quake as authentically as possible.

Is there a reason why this .exe is no longer included or being worked on? It's really the best of both the GL and software modes, since it has no graphic glitches and z-fighting like the GL version, while retaining it's best features such as UI scaling and vsync.

It just makes no sense to me at all. 
The regular WinQuake can hit higher frames per second, doesn't matter much for small resolutions but if someone decides to max out in a very large resolution there is a gap.

It is actually maintained because the Linux and Mac versions of Mark V WinQuake are WinQuake-GL builds, I just don't put a Windows one in the Windows .zip because it would confuse most people. 
Are you planning to put WinQuake_GL.exe's in future builds? 
I could make it available somewhere on the page in the future when new releases happen. 
Also, there have been two longstanding bugs to do with monster spawns that have been around since the original WinQuake - one in e3m3 where the fiend spawns midway in the air in the circular lava room when the final bridge activates and another in e4m7 where the zombies spawn after killing all the underwater zombies in the first circular room. In both cases the monsters are stuck in the air after spawning when they should fall to the ground/water and start attacking. Could you look into fixing these issues? 
Are you sure that these are engine and not QC bugs? My recollection is that they happen in all engines, not just WinQuake. If QC bugs it would be inappropriate to modify this behaviour in the engine. 
There's definitely source ports out there that fix these issues, but I admit that most I've seen don't.

Why would it be inappropriate to modify this behaviour in the engine? They are gameplay bugs after all so shouldn't they be fixed? 
If the bug is due to bad QC code or mapping errors, then changing the behaviour of the engine to work around the bug does carry a risk: some mods may be using this behaviour of the engine intentionally to create a desirable effect. The fix for the bug in vanilla will break those mods in your engine. Which isn't to say that it's never the right choice to make those kinds of change, but you have to be thinking about the potential cost as well. 
QuakeC is game logic in a progs.dat, found in Quake pak0.pak. It exists outside the engine and is the game logic program. It can be compiled with a QuakeC compiler like fteqcc.

Some people (like preach) are really into QuakeC, he is the main author of Quoth and was involved in Arcane Dimensions.

Concise version: QuakeC behavior isn't related to the engine. 
Quake Info Pool - Currently not researched Quake bugs

"Right in the beginning on E4M7 some Zombies start spawning after you kill the ones in the water. If you stay under water as you kill them, the new ones will spawn above you, and fall down into the water. However, if you kill the ones already there under water, and get back up on the ground level, the Zombies will spawn in the ceiling, and just hang there."
Reported by Alexander "Prodigy" Møller
Demo is available for download (

QIP lives! 
I bet it's a bug in the map itself. Some trigger misfiring or something. 
Quake has a lot of silly mysteries/annoying things. It probably is a map design flaw.

Video examples:

Can't imagine how this one is possible.: 
The zombies' teleport entry points in e4m7 are just too close to the ceiling.

But if you have an online server with a sys_ticrate of 0.1 then they fall just fine, because the server doesn't check their position fast enough to know they are stuck before they fall far enough to not be stuck. sys_ticrate .05 or faster and they get hung up.

It can be fixed directly in the map or with QuakeC by altering the locations of the teleport points. 
Sounds like a mapper or advanced user could make an external .ent file if that is what is going on. 
Hey, *I* am an advanced user!!

Uh, is tool_inspector broken? it seems broken (in both GL and DX 8, 9). I had to go back to version 1.27 to make it work again. It did not work for me in 1.28

Ok, here is what the zombie problem is, I believe:

In triggers.qc, info_teleport_destination function raises ALL teleport destinations by 27 units upward. I think this is to get them off the ground a bit, to make sure monsters don't get stuck in the floor, hah. Well, the problem is that it causes the zombie teleport destinations in e4m7 to move too close to the ceiling. Though oddly, it's not completely consistent that the zombies get stuck. Sometimes they seem to fall just fine in single player, other times they may get stuck.... Maybe it has something to do with whether they are moving or seeking a target or something when they teleport in. Or it could even have to do with the FPS you are getting in Quake....

Yeah, that might make sense -- if you are getting really high FPS, then Quake checks sooner to see where the zombies are, and determines they are partially in the ceiling. If you are getting a lower FPS, then the physics check doesn't happen quite as fast, so the zombies fall down a bit and free themselves. That may explain why the original Quake people didn't catch the problem; they weren't getting a really high FPS back in the 90s!

But that's just a guess on my part, knowing that Quake physics are dependent on your frame rate.

In any case, lowering the teleport destinations should fix the problem.

So load e4m7, then type in console: copy ents

Go paste those ents into a text file: \id1\maps\e4m7.ent

Go to line 883, 889, 895 and change the "origin" Z values from 136 to 100, just to be safe. Save the file. Problem solved.


The problem is solved!
We solved the problem...
So ev'rything is awesome!
Problem solved! 
Yes, you are certainly an advanced user, haha.

You might consider uploading that file to somewhere for jayoo.

If you do, I'll mirror a permanent copy of the file.

ericw may interested in it as well.

/Yeah, Pritchard pointed out I messed up the inspector. 
As a quick double-check, playing it with a sufficiently low host_maxfps should be enough to confirm the theory 
That sounds like a very plausible cause Gunter (though I am far from an advanced user!).

I'd really appreciate it if you could run me through the steps to fix this and the other instance of the bug I mentioned.

Thanks for looking into this everyone! 
I'd really appreciate it if you could run me through the steps to fix this
He did just that in post #1686... 
I'll give you some pointers since you are passionate about this stuff.

That being said, after this initial information I'll leave it to others to give you tips or answer any follow up questions you have --- mostly because I'm largely "engine-only" and this is more QuakeC (gunter/preach) and mapping territory.

In that Mark V 1.25 or up to 1.27 in the Open GL version ONLY, there is tool inspector.

Activate it by typing tool_inspector 1. Type "impulse 9" and switching weapons with change information.

For the map you want to fix, like Gunter said, load the map and type "copy ents" in the console. Open a decent text editor like TextPad or NotePad++ and paste that text into the editor. Then save the file as c:\quake\id1\maps\e4m7.ent.

From the information for tool inspector (you may need to type like "edict 3" (where 3 is an entity edict number) in the console, you can find out enough information to locate the mapping entity information in the .ent file.

Doing anything with this information, it is very helpful if you are a mapper (what this site is all about) or QuakeC master (gunter is).

But what Gunter did was edit some spawn point coordinates.

A .ent file is an external entity file recognized by all modern engines (DarkPlaces, FTE, Quakespasm, Mark V, others), it overrides the maps information.

You might struggle with this at first if you aren't a mapper.

Happy hunting! 
Yep, setting host_maxfps 16 or slower does indeed make them fall down, even if they are currently stuck.

But even host_maxfps 20 is making them stick....

Ah... that's why they were falling last night on me -- I had tool_inspector enabled, and that was killing my FPS, haha.

And as I have pointed out, sys_ticrate of .1 makes them fall correctly on a server, and that's the equivalent of 10 "server frames" per second, isn't it?

But in the end, it's a bad interaction between QuakeC and the map itself.

The instructions I gave should be pretty simple to follow to fix it with an .ent file....
Though it would probably be better if someone really wanted to test to see EXACTLY how far the zombies need to be moved down to still fall correctly.

Don't look at me; I don't care that much. I run my server with .1 ticrate ;)

Guhhh... who am I kidding? Now that I said it, I can't not do it... heh.

Oh, well, it looks like they only need lowered by 3 units to work correctly (from 136 to 133).

Do I really need to upload the .ent file somewhere? I've already done all the hard work and told people exactly how to fix it! ;) 
I Didn't Know QS Supported .ent Files 
I thought only the spiked version did. Thanks for the info, Baker. 
I managed to fix the issues. Still need to trial and error the E3M3 fiend spawn position but the zombies in E4M7 were an easy fix. Thanks again! 
OK, after much messing around with an .ent file for E3M3, I'm unable to find the "info_teleport_destination" for the fiend who spawns stuck in midair. I've determined that the line 2164 corresponds to the fiend in question, but there are no matching teleport coordinates to the "target_name".

Maybe I'm missing something obvious so any help would be appreciated. 
Perhaps I should try reading instructions more carefully in future...

I used tool inspector to find the offending fiend's actual target_name and changed the teleport coordinates to fix the spawn.

e3m3 Line 1244 "origin" "-832 416 140" 
Mark_v And The Demo Fov 
heres the demo of two bots dueling each other on zed2 - the vondurs property

i'm using mark_v to record the demo, and my fov is something like 135/145

but when i try to replay the demo something's strange has happened to me, using mark_v 0/99

the latest ad_1/60 engine(quakespasm-admod) has been playing the demo ok 
The Demos 
you cannot change the fov value while watching the demos in mark_v 
Downloaded zed2.bsp map and played your fbots20.dem.

Changed fov several times ok, didn't experience any problems.

I believe you, but I can't reproduce what you are experiencing but maybe something will come to mind eventually. 
take a look at these screenies
yeah i can change the fov value, but the viewing perspective is a very weird in mark_v 
My initial guess works like this:

Mark V has angle smoothing, which is not obvious in single player. An online player can immediately tell.

It looks like Frogbots use some sort of QuakeC evil to move the camera around (jerky style) that isn't compatible with camera smoothing.

I didn't invent camera smoothing and in fact several engines have it, Quakespasm isn't one of the engines that have it.

It is possible you found a special case no one noticed before. 
Crash When Trying To Play Demo 
I get a consistent "Mark V has stopped working when trying to play a demo. Doesn't seem to matter what, but specifically now I am trying to play jam 9 demos.

Windows 10, 64-bit using latest MarkV release.

Happens in any version (DX9, 8, markv.exe)

Let me know what else I can provide! 
Scratch That 
Ugh annoying when the solution comes to you moments after finally giving in to ask for assistance.

I attempted to switch to jam 9 using the game command in markv. But running a shortcut with the -quoth -jam9 is what worked. 
Happens. Glad you figured it out. 
Hey Baker, 
there's this Admer guy at QuakeOne having trouble running Mark V. I told him I'd drop you a line, so for troubleshooting purposes you might wanna check posts #55-58 here.

Also, a few posts above those, Dutch states that he's experiencing a notable performance drop with the latest DX9 exe. 
I look at issues posted in this thread by the individual having the issue. There is a link to this thread on the Mark V page.

Keeps everything organized. 
Dutch probably made some setting that harms his FPS. Like r_shadows 3

He should try a clean install.
Same with the other guy who it won't run for -- completely new install in a new, clean Quake folder. 
Looks like an experimental map (an awesome looking one at that).

If that map gets released I'll see what is going on.

It could be one of a million things (vis, a texture, a skybox, external textures, a lit file, entity error, parsing issue, a texture name, a setting in Mark V even.). 
Hello, Baker. I'm the guy who can't run Mark V.

I tried what Gunter said, but the same problem still happens:

- I open the .exe
- RAM usage is at 9628KB
- After 15 seconds, the RAM usage jumps to around 46MB (I'm assuming it loads some game files)
- The .exe simply exits without a warning

In short, it won't run at all.
Sometimes, this happens: 
Yeah, it was a clean install, straight outta the box. New directory and everything. No old cfg files, lifted it all off my quake CDrom from '96. It's probably the r_shadows cvar. 
There should be a qconsole.log file in your Quake folder after you start Mark V.

Can you paste the text of that? 
That Microsoft crash report, could you post the text of that as well. Often the crash report text can indicate where something crashed.

What version of Windows are you using?

And I assume you are using current version of Mark V? 
Dutch, if you happen to be testing in the Start map, make sure to set r_mirroralpha 1 to disable mirrors. Mirrors are enabled by default (really shouldn't be). They are bad for my FPS.

I don't think any other FPS killing settings are defaulted on. r_oldwater 0 is another one that harms my FPS, but that isn't set by default. Assuming the secret hidden cfg file isn't retaining any non-default settings when you do c clean install....

You couldn't possibly be using a slower/older computer than I am (XP Netbook!).... I get between 40-75 FPS on the Start map, depending on what the lava balls are doing, as long as I don't have too many extra features enabled.

Hm, and if you happen to be running in a window, and you have some other program on screen that is drawing stuff, that could cause a problem too. I have a program called BitMeter, and it will destroy my FPS if I have it showing while running DX Mark V in a window.... 
I'll see about the crash report later today, because I'm currently using my phone. I remember it was referencing 3 files located in Appdata/Local/Temp.

My OS is Windows 7 (32-bit) and yes, I'm using the current version of Mark V, or at least that's what I think.
I've downloaded it here: 
Slight correction: Windows 7 SP1.

I copied the 3 files in another folder:


Should I send the .mdmp file? I'm a noob at debugging. 
I am on Windows 7, although not 32-bit.

The quake\id1\qconsole.log would be helpful. It is the log file Mark V writes out. 
Here are its contents:

Command line: [ ]
Log file: C:/Games/Quake/id1/qconsole.log
Sat Sep 09 18:17:08 2017
Mark V Windows (Build: 1036)
Exe: mark_v.exe (1327 kb)
Exe: 22:32:27 Jan 19 2017
Caches: C:/Users/kliker/AppData/Roaming/Mark V/caches
UDP4 Initialized: INADDR_ANY,
IPv6 Initialized: [fe80:0:0:0:a59f:53f6:4528:9fe7%41]
Exe: 22:32:00 Jan 19 2017
256.0 megabyte heap
1) Do the WinQuake or Direct3D versions run?
2) Is there an opengl32.dll in your Quake folder?

I know Quakespasm runs on your machine, so it shouldn't be an Open GL issue although Mark V uses some Open GL capabilities that Quakespasm doesn't.

If there is an opengl32.dll in your Quake folder, you should delete that. But since DarkPlaces seems to run for you, I can't see how you could have a (toxic) opengl32.dll in your Quake folder. 
Baker, compile a debug build for him, keep hold of the exact pdb file that msvc generates when compiling said debug build.
Send him the debug exe, get him to send you the resulting .mdmp file.
Open the mdmp in msvc.
Then you can see the stack etc, and inspect many of the variables that might be relevant etc.

That or rip the stack trace code out of FTE's win32 port. That would allow him to simply paste you a whole list of function names which is usually enough to figure out where it crashed (although not always what actually went wrong).
This of course requires no pdb files, so hurrah for that, but it won't show line numbers etc.
Still, if you expect your code is going to crash then its quite handy... 
Ywah, the strangeness/uniqueness of Admer's problem is has been making me think about improved crash data.

Can't do anything tonight, but I'll ask you questions tomorrow or Monday about what you are referring to in FTE. 
1) Yes, but they crash the same way.
However, the WinQuake and DirectX versions don't give any crash reports. That only happens with the original Mark V .exe. :P

2) I'm sure there is, I'll still check to make sure.

Mentioning OpenGL reminded me of something:

My GPU only supports up to OpenGL 2.0. This gave me lots of compatibility issues with programs that require OpenGL 2.1. 
1) No, they crash almost the same way.
(I misread what you wrote up there, sorry) 
If WinQuake or Direct3D are crashing, your OpenGL drivers aren't involved in this. Neither use Open GL. WinQuake doesn't use anything at all ;-)

So it is something else.

I never actually suspected a drivers problem, mostly wanted to rule it out. It but seems unlikely.

I have couple of suspects.

I imagine in the next 72 hours or less, I'll make a special build with some of Spike's inventiveness, and then exactly what is going will be clear.

Thanks for the feedback ;-) 
Well, I was wrong. There was no such file as opengl32.dll in my Quake folder. :P 
WinQuake LIVES 
Been looking for an update of WinQuake and so happy to see you giving it some love, Baker! The original software renderer is still very charming. I love that washed out shading, you can't replicate it in Quakespasm.

Tried loading Arcane Dimensions with this and was surprised to find out that it mostly works. The engine even auto converts the full color skyboxes to 8 bit! However some textures with alpha channel are broken, the fog in ad_necrokeep looks especially bad, and ad_swampy crashes when you get to the main area. Anyway, what I'm getting to is, any chance your version of WinQuake could be fully compatible with Arcane Dimensions? AD is probably the best benchmark for the modern map packs, so it'd be a good milestone to achieve, I think. 
I am sure Baker will eventually provide builds for *all* MkV builds that fully work with latest AD additions. Maybe even Ter Shibboleth. These days, mappers are doing everything to push Quake map specifications beyond any previously known limits. I hope that eventually we'll have a solution which won't require updating ports over and over again to make maps work. 
Fog in custom Quake maps is usually too subtle, to disguise the fact that it's not volumetric.

Custom Quake maps can "fake" volumetric fog by making some areas small enough for the fog to not show up, and making other areas large enough for the fog to cover them. Combining this with strong shadows in the small areas and very subtle shadows in the large areas makes the global fog seem to have different densities in each area.

The thing is, subtle color translations are very difficult to pull off in 8-bit color palettes. Large areas of the screen ends up being rounded to similar color values, resulting in huge color banding if not dithered, or heavy graining if dithered. This gets even worse when the raw color of the fog doesn't exist in the Quake palette.

Making fog look good in 8-bit color renderers requires design restrictions that the mappers won't adhere to. Just like transparencies usually looks awful in 8-bit color, fog and colored lighting will usually look awful too.

A fun thing is that the same principles applies to regular lighting. Vanilla Quake maps features mostly strong shadows, because subtle shading has lots of banding in the software renderer. But newer Quake maps usually disregards this limitation, because they're usually only designed for hardware renderers. Most of the awfully looking maps from the 90's usually failed to understand this limitation too. 
Another reason for the subtle fog in custom Quake maps is to disguise the fact it's not spherical. Thick flat fog looks bad when turning the camera. 
Transparency In WinQuake 
I've done some more testing in Mark V WinQuake and turns out the water/teleporter transparency (r_wateralpha) actually works, via dithering. I suppose the same effect could be applied to the fake fog layer in ad_necrokeep. It just seems like the engine has no support for alpha channel in textures, e.g. various trees and vines in AD and Jam 8 are broken, with solid white where they should be transparent. 
Put these guys in the maps folder and you'll have transparent water on the stock id1 maps

External .vis files for original Quake maps

They should work in DarkPlaces as well.

The original Quake maps don't treat water as transparent.

Alpha masked/alpha transparency doesn't work in the WinQuake version for brush models at this time (tried it maybe 4 different times, something I'm not understanding about the WinQuake depth buffer or draw process prevents me from getting the job done in this case.).

It actually works for .mdl models, but few maps use that although it might be visible in Arcane Dimensions in some cases. 
Alpha masked/alpha transparency doesn't work in the WinQuake version for brush models at this time (tried it maybe 4 different times, something I'm not understanding about the WinQuake depth buffer or draw process prevents me from getting the job done in this case.).

The BSP renderer sorts depth by edge at the spans level, rather than at the pixel level. To avoid this, I've tried partially reinitializing the BSP renderer upon rendering each alphamasked BSP surface, but this resulted in massive slowdowns. Now I only reinitialize it once for each BSP entity containing alphamasked surfaces. Qbism did something similar in Super8, IIRC.

Quake's spans-related code needs a lot of work. It's non-intuitive and has bugs such as this.

I don't fully understand it yet either, but I'm sure the reinitialization overhead can be eliminated almost completely. I should only manage to do so after fully rewriting it, though. 
Thanks for the link. Looks like a good read.

I had determined that some sort of reset was required, but either I did it in the wrong place or performed it incorrectly. Or the third possibility of something I am not considering and wasn't on my radar.

Some day in the future I'll make another attempt. Last time I almost got "serious" (I was piece by piece reimplementing qbism super8 in WinQuake until I isolated what I didn't understand), but then something more shiny to me pulled me away (probably something Spike did in Spiked Quakespasm like single port server).

Network code to me > everything else ;-) 
One more thing, does WinQuake Mark V support any kind of HUD scaling? Integers like 2x, 3x etc would look quite good even in software rendering I'd wager. The usual scr_*scale commands don't seem to work. 
In the video menu, stretch is as close as it comes, emulating 320x240 or 640x480 as best it can depending on your current display mode.

It isn't exactly the same thing as scaling the HUD, and for most people it is probably "good enough" -- although as a purist I don't feel it is good enough.

But since it would be quite time consuming and effort to implementing true scaling (aka FitzQuake) in the software rendering with the appropriate alpha masking support, such a thought sits somewhere closer towards to the back of list rather than the front.

Keep in mind a trule scaling solution needs to handle all 2D graphics like the menu, scoreboard, etc. otherwise it would be quite silly. 
Hmm, seems like the original renderer is pretty limited.

For the record, I've tried Qbism, and it does have HUD scaling and alpha channel support for textures, but I get heavy FPS drops in Arcane Dimensions, when there are any alpha channel textures in my line of sight.

Could we do this another way around and emulate the original paletted 8 bit look in OpenGL? In particular the lighting color map. 
Crash To Desktop 
....on trigger_changelevel - is this a known issue or could it be my map?

It's happened multiple times and on demo playback as well. 
I know exactly how do it. It isn't a question of that at all. The question is, of the things I can do, would I find that interesting enough to want to do before the 25 things that do interest me. If you understand.

Ask Spike or mh or ericw or metlslime or qbism or mankrip, part of an engine coding for a leisure activity is wanting to do the task.

@dumptruck_ds .. don't know. If it progresses to become a released map, I'll make a mental note of it after it is confirmed it doesn't crash any other engine. 
paletted look with gl = fte with r_softwarebanding 1 (or just use the softwarey preset). 
re: the map. tested on Quakespasm-admod last night and it was fine. I will do some further tests with other clients this evening and report back but for now at least that engine behaves as intended.

My trigger change level is made up of some weird shapes as you can sort of see in the screenshot. Not sure if that could be a cause or not. 
it seems the tool_inspector is broken on your latest release v36

also i've got a new video card gtx1070, and noticed a very weird video gliches with the fog enabled

there's no such gliches if i'm using quakespasm engine tho 
There Ain't No Gliches Either If I'm Using Dx_9 Engine 
Yeah, Pritchard reported the tool inspector issue a while back and then a couple of others later on.

I saw the glitching in your video. Could you give me "viewpos" coordinates and map name (or as an alternative the demo which gets me the same information).

I'm guessing since it only happens in certain frame, it occurs when a lavaball pops into view.

Quakespasm and Mark V and Mark V D3D all draw very differently, so the different behavior isn't unsurprising.

I'll make a note to try to recreate the next time I have my hands on a NVidia card machine. Since NVidia updates the drivers all the time, it is a possibility that this is a driver issue that will go away in a future driver update, but I'm not going to make that assumption.

Thanks for the high detail issue report. 
Yeah, After I'm Getting The New Card 
i've updated nvidia driver to the latest version

this glitch is only happens when the fog is enabled, disabling the fog removes the problem
would you mind if i'll send the map
to your mail? 
Spy, you know I think you are awesome.

I am email free! And I love it!

If it needs to be done privately, I guess you could send a private message at 
i cannot reach you at

btw, fitz08, has the very same issue 
I deleted some private messages over there, you can try again (but really since they upgraded the forum there, I don't know if that was problem or not) or upload to Quaketastic.

My gut instinct is that I think this is a driver issue that will magically disappear at some point once nvidia does an driver update or 2 on your machine.

They probably introduced some sort of stencil bug they introduced since ...

1) It doesn't happen in Quakespasm which doesn't use stencil by default.

2) It doesn't happen in the Direct3D version.

3) Didn't happen on your previous machine, no one else has reported a glitch like that. 
Hello, it's me again. :)
I've tried out a few older versions of Mark V, and the problem is still the same.

Now I'm starting to think that it's definitely up to my hardware. Certainly my GPU, because the drivers are so poor. Yes, the latest ones are from years ago.

In the near future, I might install modded drivers to see if it helps. Intel GMA 965 is a special snowflake among the 9xx series, haha. 
You might try the sdl_mark_v_gl.exe in this beta ...

Will it work? Who knows!

Had several beta testers with really, really bad/old computers, some which can't run Open GL but the Direct3D works and getting terrific fps.

Worth a shot anyway. 
Yes, the Intel 965 is pretty damn special - it was Intel's first hardware T&L part, the drivers are absolute cack and the hardware itself is actually slower than the prior (software T&L) generation.

As far as I'm concerned: weirdness, crashing, general bad stuff - that's expected behaviour under OpenGL with this part. 
I've tried out the SDL .exe, and just as I thought...

There's no hope. My GPU is the lottery in terms of incompatibility. :P
I'm not giving up yet, though.

I'll just wait until I build my new PC by the end of this year. Modern hardware will definitely handle it better. :) 
1036 Is Giving Me Problems 
Wonder if anyone else is having issues running it. I'm testing a map so haven't had time to really document things but it seems to stutter quite a bit after running for a few minutes. Can't even finish a play-thru.

Before I dive into reporting wondering if anyone else is experiencing the same behavior?

SO far it's just the main mark_v.exe

dx8, dx9 and winquake are behaving. 
Found A Really Weird Bug 
The following bug happens in all current versions of Mark V:
- Quick save and quick load at least once.
- Die and press space to restart the level.
- You respawn with death camera (slanted view).

Also, all versions of Mark V are stuttering for about 3-5 seconds every time I launch the game, sometimes also with cracking sound, usually when loading the first map. It's like it's caching something really bad. My machine is pretty modern, so it shouldn't be related to specs. The game is very smooth after it's done that initial bout of stuttering.

Also please consider adding support for OGG tracks. it's more common than MP3 nowadays and seems to be standard for Quake. Also PNG instead of TGA as well, most HUD/GFX graphics seem to be using PNG.

P.S. And maybe don't try to re-route when an opengl32.dll is put inside the Quake folder. I'm just trying to use a wrapper for some extra graphical effects. This one in particular. It works great with Quakespasm. 
The death cam respawn was reported (by me :D) a while back.

I don't think that ogg is more common than mp3 now... in fact i'd say it's even less common than it used to be, now that the mp3 patents are starting to expire.

I think the reason to avoid loading opengl32.dll is this
Well, I've got about a dozen Quake soundtracks (id1, hipnotic, rogue, shrak, malice, impel, xmen, n64 etc), all of them in 256 kbps VBR OGG, de-emphasized where necessary. I'm pretty happy with this collection as it stands and don't feel like repeating the process for MP3. I've read about Baker's reasoning on how MP3 is faster to access, but I'd still like an option for OGG support. And who knows, we might all switch to FLAC at some point.

Yeah, I get the reasoning behind avoiding opengl32.dll, in the old vanilla installations of Quake (and other games from that era) it's a 3dfx wrapper, which causes problems on modern systems. But I feel like the current solution of removing the option of using any wrapper at all is a bit too heavy handed. 
In theory MarkV already has .ogg support provided you have a DirectShow-compatible codec installed. As a rule of thumb, if you can play it in Windows Media Player, you can play it in MarkV. I know that for a fact because I'm the original author of that code.

In practice MarkV is hard-coded to only search for files with a .mp3 extension. Supporting .ogg as well should be just a matter of adding support for the other extension, but I didn't originate that part of the code (or at least I don't recall doing so) so I can't say what kind of work would be involved in this change. 
Ogg Vorbis Is History, Use Opus Like QS 
Ah, ogg files.

Supported on Windows, the Mac, the iPhone. Widely used in the commercial games industry and in the music industry. Supported by the Unreal engine and the Source engine.

Oh wait. That's mp3. None of the above support ogg.

My Android phone can play ogg. If you open an ogg file in Google Music, it will convert it to mp3 and then play it ;-) That's Google's idea of ogg support.

Ogg fits in nicely in the category containing 8-Track, BetaMax, Laserdisc, Zip drives, the Zune, PlaysForSure, HD DVD, Windows Mobile, Windows Phone.

Short version: Oggs? Fuck, no! Plus you don't even know why you are using ogg, Quakespasm supports mp3 -- so what was it that made you think "ogg" to begin with? Answer: You don't know, because no one using ogg ever knows why they are using ogg, especially because in the real world, no one is ever doing oggs because nothing supports them.

/Against my better judgment, I click submit! 
In practice MarkV is hard-coded to only search for files with a .mp3 extension. Supporting .ogg as well should be just a matter of adding support for the other extension

Thank a lot for this tip, turns out Mark V DOES play OGG if you just open the .exe in a hex editor and search and replace all instances of .mp3 ASCII text with .ogg. Really makes you wonder, why not just add literally 3 extra characters to the source code to enable OGG support? It really seems like Baker's got some personal agenda against it, since literally every other modern Quake engine supports OGG, because why not. Oh well, I suppose there's no need to discuss this further. 
The Smell Of Napalm On The Forum 
There's something wonderful about reading Baker raging against ogg, and then immediately afterwards reading about how despite Baker's strong desire to prevent it by explicitly coding it out, someone has hacked it to work with a find+replace.

It makes you wonder what ogg did to Baker - murdered/kidnapped family I guess - in the past to make him think "I have this perfectly good DirectShow support in my engine. I should ruin it and only use it for mp3 format music to ensure that my users have to work harder than with other engines!" 
Doesn't Sound Complicated At All? 
Implement a generic audio library and comment out ogg from the list of supported formats. 
why not just add literally 3 extra characters to the source code to enable OGG support

I obviously can't speak for Baker but this wouldn't be just 3 extra characters. It's only 3 characters if you directly replace the existing .mp3 support with .ogg support, but of course you then lose .mp3 support.

Adding multiple file format support would involve enumerating files of multiple extensions, sorting them into lists, making decisions such as which format has priority over others (not so clear-cut - how do you decide between a high bitrate inferior format vs a low bitrate superior format?), and how to handle the inevitable crazy-assed situation where someone has multiple formats in the same folder (some of which may even be multiple versions of the same file in different formats).

I absolutely do think that people should make the effort to do all this, of course. But it would need some guidance as to what the end-user expected behaviour is. Multiple end users pulling an engine in different directions is something I can personally vouch for as never ending well, and it would be nice to see players striking up a discussion among themselves about how they'd like to see these kind of decisions work out. 
Funny thing is, OGG is actually already listed in Mark V's file extension look up table:

But there must be some code that explicitly ignores or forbids it. Seriously though, just why. It's a relatively popular file format for video game audio.

To enable OGG support find the above bit in a hex editor and replace mp3 with ogg. Simply renaming your OGG tracks to MP3 should work as well, I guess. 
I'm confused... Isn't engine inter-compatibility something to strive for? Considering that all other engines support the format AND the fact that most soundtracks available online are in .ogg, it strikes me as odd that Baker would want to force the user to convert the files in order to use them with his engine. Plug'n'play, man, plug'n'play... 
Probably doesn't want bloat. 

Ok Baker, I NEED ogg support!

I tried the hacks mentioned above (either renaming my ogg to mp3, or hex-editing mark_v), then, after installing the ogg directshow filter ( ), Mark_V does play ogg.... and it loads in a FRACTION OF THE TIME as an mp3 file of the same file size!

Do you remember a while back, me going through a LOT of testing because I have an issue where loading an mp3 file causes Mark V to freeze up while the file loads? (mentioned in #651 above)

After some encoding gymnastics I managed to get that loading time (during which everything freezes up) down to only like 4.2 seconds for track04.mp3.... Well, I converted it to an ogg of the same bit rate and file size, and it loads in only 1.23 seconds!

So... yeah. That would be the reason to allow ogg files to be found by Mark V (since it is already capable of playing them).

You really don't have to do all the complicated stuff mh mentioned. Just state, "Mark V supports the following formats, in the following order of preference: mp3, ogg."

And let the users sort their own files and formats and bitrates. 
Indeed, there's no need to compare bitrates or anything, just let it read formats A|B|C in the priority of A, B, C. And the game folder should take priority over id1, e.g. say you have OGGs in id1 but e.g. Travail comes with an MP3 soundtrack, disregard the OGGs in id1 then, unless there's not enough tracks in the game folder, in which case read the missing ones from id1. I think that's how Quakespasm handles it anyway, correct me if I'm wrong. 
is there a way to set the fog value via an cfg file or fog depends on qc? 
@ Spy 
Just use an external_entity file(yourmapname.ent) Put the fog command in there. 
I Don't Quite Sure What You Talking About 
why would i put the fog command in the external ent file? and where exactly should i put it?

i'm using the fog value via the worldspawn. AD mod supports this and shows fog correctly, but it seems kinn's old mod (bastion/marcher) doesn't support fog from the worldspawn, as there's no fog after loading map.

i'm just wondering :) 
The worldspawn "fog" key is handled by the engine, it should work in id1 with MarkV (and most engines). Maybe bastion/marcher is resetting it via QC. 
@ Spy 
My answer was for the simple question of setting fog values via an external(.cfg) file, now I see your problem! 
i have a map with a worldspawn settings something like
fog_density x
fog_colour x y z

and after loading this map in AD the fog appears correctly, then i put the very same map in the id1/maps folder and run it from the vanilla game
there's no fog at all
until i manually set the fog numbers in the console, what gives? 
those are AD-specific fog keys.
Try: "fog" "density r g b" 
Have You Just Tried... 
"fog" "Density R G B"

All on one line for stock id? 
Try: "fog" "density r g b"

i put this line fog 0.015 0.35 0 0
into an *cfg file without the quotes, but no avail. 
Sorry, put it in worldspawn, not a cfg file :) i.e. the worldpawn key is "fog" and the value is "0.015 0.35 0 0" 
yay, it's working this way. silly me. Thank you Eric and damage_inc 
Hey, I require help
Whenever I try to launch any of those 2 executables using:
./mark_v_linux or ./mark_v_winquake_linux
I get following error:
bash: ./mark_v_winquake_linux: Permission denied
Double-clicking doesn't work either

On manjaro, hope anyone can help 
chmod +x mark_v_winquake_linux
Has done the trick for me, it works now! 
Marcher / Bastion Imps Sprite Issue 
I was playing back some demos of Spy's work-in-progress map in 1.36 and the final frames of the imp fireball (the impact only) show up as non-transparent. If this is not a known issue, or repeatable I can try a screencap to make this a bit more clear. Works fine in other engines. Notably Quakespasm-admod 
Kinn Sprites 
I've ran into this.

Which sprites are you using?

Kinn original: uses black for transparency requires enfine with support for .png override textures (e.g. Darkplaces) and additive mode.
AD: Not sure.
Keep: I converted all mine to use pink transparency for full support on all engines. 
It's actually an older map of Spy's that he's working on getting ready to release pretty soon. Not sure what assets he was using.

@Spy are you using the same assets from the original Bastion/Marcher maps? 
@dumptruck_ds Kinn Sprites 
Mark_V enables external textures by default, so set external_extures to 0 and reload the map

or just delete all of *.tga files from the sprites folder, they are absolete now 
Mark V's adaptive FOV calculation method seems to be quite different from QuakeSpasm and original FitzQuake. I need to increase FOV by about 6 to get the same field of view as in QS (using a 16:9 display). Of note, QS just does vert- when you set scr_sbaralpha 1, while Mark V does hor+. Not sure which method is preferable, however, it's possible that Baker based his adaptive FOV calculation on specific scr_sbaralpha and viewsize values. In particular, setting scr_sbaralpha 1 and viewsize 100 gives about the same FOV as in QS with full screen view point (that is scr_sbaralpha 0). But nowadays most people are probably playing with the transparent HUD, so this just results in smaller FOV. 
Good News! 
I have finally come across a solution to my problem. It turns out that I actually didn't have pak1 and pak0.pak. I thought I did, but I didn't check my ID1 folder. Long story short, I found something which contained both pak files and copied them over.

I love it. It runs like a charm:

I'm so sorry for wasting your time over such a dumb mistake of mine. 
>uses markv
>looks like glquake 
Missing PAK files was the problem?

How does that happen? If I remove my PAK files and try to run Mark V, I immediately get a popup error message saying it can't find the pak files.....

Maybe corrupt pak files? 
My laptop is 10 years old, I'd rather not...
Also, it's my first time using this sourceport, so I haven't tweaked all of the settings yet. Though, I'd love that to change. :)

Funny thing is, there were no .pak files at all in my ID1 folder.
The .pak files' contents were actually extracted to my ID1 folder, but the .paks themselves weren't there. Interesting. 
Interesting! You may have found "an issue."

I tested with unpacked pak files, and Mark V does indeed just crash without any meaningful error message.

These alternate engines I tested work just fine with unpacked pak files:

fitzquake 0.85

Unpacked pak files should be an acceptable setup... so... Mark V should be able to handle that.

Anyway, if you're interested in tweaking Mark V with all kinds of setting which make it look better (in my view), I have a page with downloads and settings to alter:

Then come play FvF :D
Any interest in bumping Mark V's limits to make it Sepulcher-capable? cf. comments 1661/1662 above.

Also, can anyone say "sepulcher-capable" five times fast? 
@Johnny - Some day ... whenever I do the next version of Mark V, which doesn't feel soon. 
So It's Dead Huh? 
And just when I finished compiling a nice list of bug reports and suggestions. Disappointing. 
Gotta love the internet.

So Baker writes "not yet but I will" and you interpret that as meaning "it's dead", eh? 
What's this I hear about Quake finally being dead? Oh well, it was fun while it lasted. I guess we can all move on to Unreal Tournament now. 
You Mean UT2k18 Aka..... 
....Quake Chumpions lololzor 
@iriyap, @adamer 
I think you've posted some well thought-out comments, including some refreshingly detail oriented ones. This thread is intended as permanent record of feedback so none of the information is lost.

NightFright could tell you stories, there is an obsolete older Mark V thread here with 2500 posts and his observations about obscure mods + crashes, a few which have led to improvements in Mark V and also Quakespasm -- over time ... it was not quick at all! Ironically, maybe 2 which ericw pointed out solutions, ericw didn't actually do them in Quakespasm until way, way, way later.

In free projects the author is always vastly outnumbered and with limited time and a real life.

@adamer - I'm glad you determined what was up with that (your pakless setup). Sure, in theory it "should" work (except it doesn't in Mark V) and it sounds like it works with other engines, but in practice an actual Quake install whether from Steam or the CD or shareware has pak files -- so yeah ... I'm glad that mystery is solvd.

@QMaster - re:Marcher --- I like the attention to detail/testing/thought it sounds like you are doing with your Uber mod. 
Unfinished Business 
I hope that one day I can do another test run as intense as the one I did before that big Mark V update back then. ^^ IIRC there is still at least one issue kinda pending with the final map of Malice when fov changes after reloading the game. It must have to do something with the boss attack and how the port handles the short-term fov changes. It was supposed to be fixed, but a few months ago I managed to get the problem again/still. Need to see what became of it. 
is the mod adjusting the fov or is it standard quake
oh reread the post i guess its an evil thing malice does
mods shouldnt ever change the users fov. could bean easy fix 
In case you decide to pick up your work at some point in the future, here's my final bucket list for the current version of Mark V. Some bugs, some missing features, and a few things that I think would be beneficial to implement.

- BUG: death camera doesn't reset if you quickload at least once, die and press space to restart the level from scratch.
- BUG: game stutters for a few seconds at launch (or every vid_restart), sometimes leaving the audio permanently cracking.
- BUG: parallax skies are noticeably darker than vanilla GLQuake.
- BUG: vid_multisample does nothing.
- BUG: r_bloom makes textures look grainy, maybe the bloom pass is set to nearest neighbor?
- BUG: adaptive FOV is smaller than it should be, I need to set my FOV to about 96 to get the same FOV as 90 in QuakeSpasm and DarkPlaces (using a 16:9 display). Basically FOV 90 should adapt to FOV 106 in 16:9, not 100.
- BUG: TGA alpha mask isn't properly supported, e.g. font replacements have white outlines.
- No protocol 999 support, crashes when loading Orl's maps like Ter Shibboleth or oms3_2.
- Remove the whole "opengl32.dll found" shenanigans, in this day and age it is most likely a graphics wrapper like ReShade, not the 3dfx driver from the original GLQuake package from 20 years ago. Don't make people hex edit your .exe to get some post-processing effects going on.
- Unlock the OGG support for external music, Mark V already supports it internally, why comment it out on purpose?
- Add optional HUD filtering, nearest neighbor looks bad at non-integer scaling values.
- Add PNG support in addition to TGA.
- Add the "N64 style" minimalistic status bar layout as seen in DirectQ/qbism/RetroQuad/etc. Crazy convenient.
- Add (integer) HUD scaling for the software renderer.Some info on this:
- Add alpha/fence texture support for the software renderer.
- Switch the software renderer from 8-bit to 16-bit to have enough colors for colored lights and proper transparent water. This is what RetroQuad is doing. Or Half-Life for that matter. 
Baker, do you have some public repo for this project, or just this zipped sources? 
4 player coop with quake spasms controller support is my only wish list item 
- Switch the software renderer from 8-bit to 16-bit to have enough colors for colored lights and proper transparent water. This is what RetroQuad is doing.

It isn't. Retroquad renders everything in 8-bit color, using 8-bit tables to access a single 8-bit indexed color palette. The tables are generated from 24-bit color data upon booting up the engine.

Retroquad doesn't use 16-bit color anywhere, and it doesn't do any direct-color transformations in realtime. 
Baker, do you have some public repo for this project, or just this zipped sources?

The source code is in .rar format. ;-) 
FQ And QS? 
Silly noob question time:

Can Fitz Quake happily coexist in the same folder so as to share the same Id1 folder and the like? 
Mark V and Quakespasm. 
Of Course 
I have been putting Mark V, Quakespasm, FTE, Darkplaces etc in the same Quake installation for years and see no problem other than the save game incompatibility between Darkplaces and others, which is in itself easy enough to fix manually. 
Cool Beans. 
That's good news. Thanks for the reply. 
Broken Links On Home Page 
Hey. Just thought I'd let you know that there are a couple of broken download links on the Quakeone/markv page.

The Undergate download is broken and so is the Frogbot mapset.

I presume it's something to do with the 'updates' that went on there a while back... :) 
Also: Why Doesn't This Autoexec Not Work? 
joystick 1
joyadvanced 1
joyadvaxisx 3
joyadvaxisy 1
joyadvaxisz 0
joyadvaxisr 2
joyadvaxisu 4
joyadvaxisv 0
joyforwardthreshold 0.15
joysidethreshold 0.15
joypitchthreshold 0.15
joyyawthreshold 0.15
joyforwardsensitivity -1
joysidesensitivity 1
joypitchsensitivity 1
joyyawsensitivity -1.5
joywwhack1 0
joywwhack2 0

bind "AUX5" "+jump" // jump on L1
bind "AUX6" "+attack" // fire on R1
bind "AUX30" "impulse 10" // cycle on dpad-R
bind "AUX32" "impulse 12" // reverse cycle on dpad-L 
Can you define "not work"? 
I create an autoexec.cfg file with the above text in it (a standard vanilla Quake cfg for controller support).

Mark V doesn't recognise it properly. The console says the engine loaded the autoexec file but the controller doesn't work at all in-game. No response on any button press or joystick movement.

It used to work in older builds of Mark V and Fitzquake. Just not Mark V 1.00. 
Check your syntax. Unless I am on crack many cvars need the quotes. 
I don't not know why it doesn't not work. I mean, the autoexec itself works -- it's just that I seem to recall that joystick support was simply disabled at some point in Mark V.... So yeah; it used to not don't work and now it won't don't not work.

Baker will have to make it so it doesn't won't don't not work when he gets back to working on Mark V again. It's as simple as that.

There is a workaround though -- you need to use a program that turns your joystick into a keyboard emulator. Something like JoyToKey or Xpadder. You might need to look for older versions of those programs, if the newer versions are no longer free. AutoHotkey can probably do that too, but is a bit more fiddly.

Good luck getting your joystick to stop won't don't not working. 
Linux Build And Music 
Is it possible to play background music with the current Linux build? Can't get it to work. 
it only supports cd audio on windows, and directsound is of course windows-only and artificially limited to just mp3. 
Yeah, the joystick code in Mark V is not quite correct.

If you dig deep in the OLD Mark V thread (Google up FitzQuake Mark V), a user with a joystick kindly posted instructions on how to make it work well.

I don't have a joystick, so I messed something up when I was trying to be "cool" or something.

/Mark V supports mp3 music on Windows and the Mac (and in my private experimental build, on the iPhone as well), but not Linux mostly because I didn't have time to get that up and running when I was making the Linux version. 
Someone should donate a cheap dual-analog usb gamepad to Baker so he can test this stuff.... You can get them for like $5-$10 on ebay.

Or if you wanna get more fancy, get a Logitech F310 gamepad ($10-$15), which has a switch on the back that lets it change between using XInput/DirectInput, for thorough testing.

Currently Mark V reports that it detects when a joystick is connected, but can't seem to detect any input from the gamepad, using either input method. 
Where Can I Get The Most Recent Version 
of winquake_gl? the latest packages don't contain it. Is there an archive somewhere? 
My Bad 
just found the archive


Within the next week, I expect to release a new version.

1) Optional Mouse driven menu video. The video doesn't do it justice how convenient it is.

When you have mouse driven menu, you use the menu about 8 or 9 times faster and it becomes far more convenient. You just click away.

The menu looks like the Quake menu is 100% the same keyboard menu, it just is mouse capable also.

2) Fix tool inspector glitch, the save game glitch Pritchard pointed out.

Time has not been one of those things in much supply lately. 
I'm very excited to try this new version out. Looks very cool and I LOVE that Levels menu. +1 GG and all that. 
what's the lowdown on glwinquake? is the most recent winquake gl and not labeled as such? was it discontinued? 
Controller Support? 
Just wondering if controller support will be re-implemented in the upcoming release. :) 
Another Thing 
I think sv_aim belongs in the preferences 
It's a subtle distinction, but sv_aim is a server-side cvar whereas the options menu is client-side.

What that means is that a nonlocal server could override if it was set from the options menu.

What it also means is that a client may not actually have permission to change it.

So on that basis I disagree; it shouldn't be in the options menu. 
I love the new lightning-bolt effect in Mark V, but i also love the classic particles in the other weapons.

Is there a console command that changes only the lightning-bolt effect? :/ 
OGG support please! (For reasons I mentioned above in #1767.)

And this would apparently be a really simple fix, since Mark V already plays OGG format -- it just doesn't bother to look for OGG files ? 
Does MarkV play ad_sepulcher?

How about adding lit support for the Winquake port? 
Mark V - Build 1050 - Ultimate Mouse Driven Menu Edition 
Direct X 9 - Mark V 1050 - Windows | Source

* Fully mouse-driven menu yet it is the classic menu.
* Tool_inspector works again. (Pritchard)
* Load game + death bug fixed. (Pritchard)
* Numerous other small enhancements/tweaks.

Special thanks to Pritchard in particular for bug reports and so it took this long for some of them. And probably Gunter when he isn't annoying or ticking off MH. Thanks to all other providing feedback, bug reports, suggestions, criticisms. And perpetual thanks of course to MH, Spike, ericw and metlslime.

I had hoped to get this out a day or 2 ago, but I wanted to get the mouse-driven menu tuned to exacting specifications.

Also mouse-driven was very, very, very hard to do. The Quake menu code is some of the ugliest in existence.

@killpixel, c0burn - I expended all my energy getting this across the finish line. It was harder to wrap up than I expected. @ Tribal - yes, and maybe Gunter will make himself useful and tell you how (type "find qmb" in the console and it tells you different cvars to turn stuff off) -- because I'm a bit sapped.

(mh note: scr_sbaralpha doesn't work with DX9 -- tried some tweaks/hacks but still failed -- and is the sole deficiency to what otherwise should be a rock-solid release. If some time in the future you had some time to check it out at a time of your convenience, that would be cool. No rush ;-) And thanks for your contributions!). 
btw, thanks!

@1830 unnamed guy - "I think sv_aim belongs in the preferences"

Well, it is in preferences!! Haha. 
Thank you!

You're awesome =D 
"And probably Gunter when he isn't annoying or ticking off MH."

I don't think that ever doesn't happen.

It looks like the previous issue has been fixed where you could see "the sky" through entities. It doesn't seem to happen any more. (#1665)

You can still see shadows though entities but only if you have set r_shadows 3 (I know those are experimental shadows though).

I have a transparent fake player guy inserted by the ent file, and he is only transparent if I set gl_fullbrights 0. If I set it to 1, he's solid. I'm sure I've mentioned this before. Ah yeah, looks like it has to do with fullbright textures (#1082, #977). That probably wouldn't be the same issue with the scr_sbaralpha.

gl_overbright_models 1 can also allow weapon models to be properly transparent when you have the ring, but not the transparent entity guy. 
@ Tribal

Yeah, as Baker said, you can use "FIND QMB" to see all the QMB effects. If you really wanted only the lighting effect, you'd have to have "QMB_ACTIVE 1" and "QMB_LIGHTINING 1" but have all the others manually set to 0!

I would suggest doing "FIND QMB" then type "COPY" to copy all those variables to the clipboard, then paste them into a text file and edit the file to remove unnecessary text and change the values of everything to 0 except the things you want. Save it as a cfg file then you can just exec it. 
Gunter +1. He might know the engine better than myself, haha. 
Let's man up. Besides I am feeling the code rage ...

March 9th. New feature.

I shock your world. SUBMIT! 
Marking The Calendar 

Thank you!

It works like a charm =D

Tho only thing weird is when I set the command "qmb_blood" to 0 it doesn't change the blood to particles, it mixes red particles with blood sprites o_O 
Hey, you're right. "QMB_BLOOD 0" doesn't deactivate the QMB blood.

You found a bug for Baker to fix!

You're an honorary Junior Grade Gunter now!

Find about 500 more bugs and you can almost reach my level ;D 
scr_sbaralpha doesn't work with DX9 -- tried some tweaks/hacks but still failed

Had a quick look over the code; you don't seem to be setting glTexEnv (GL_MODULATE) when drawing alpha pics in the status bar (compare with the setup for Draw_ConsoleBackground). In theory that shouldn't work in GL either, so I guess you just got lucky that drivers accept it, but you really should fix it for both. 
Yeah, Confirmed 
That fixes it.

Interestingly, it's also a bug inherited from the original FitzQuake code, so it's been around for a while. 
Hello and thanks for the this great engine!
I was making some tests running custom code for a mod and using "eprint" to debug some entities. However, this is making Mark V run unplayable with very low fps. I think it might be a bug, because other engines doesn't have that problem.
Also, loving the mouse features.

Congrats On The Release Baker 
Mouse Driven Menu 
feels really good, thanks! 
Finally fired this up today. It's great. The mouse menus are very nicely engineered. The engine is snappier too I think. GG 
@mh - oops! Thanks! I'll see if I can fix. I'm glad you are always in "rendering godmode" because I shift and fade focus. Haha!

@ericw - Thanks, obv! If you weren't around, I think I might feel alone because mh and Spike seem to know everything and it feels like only you and I have to scale up and grow, haha!

@dumptruck - Yeah, time and energy expended to make it perfect. Meticulous.

@hipnotic rogue re: joystick - I care about joystick. Right now, I'm not zoned into that but have "THE QUAD" running in some other departments and I need to kill the monsters my QUAD can nuke quickly as I don't have unlimited time.

@fifth - Thanks! I haven't forgotten about about joystick/four player. I need to level up to that point, killing some zombies immediately in my sight that I can kill. I want to see if I can reward Spirit emotionally. Spirit has made big sacrifices to build something awesome/nigh impossible and in my heart I want his ideals to come true. Plus when I see people stressing Spirit out every once in a while or accusing him of not doing enough, I just don't think that should be the reward for building something.

@epiolon - '"eprint" to debug some entities' Ah, I'm not Mr. QuakeC so I figure that is QuakeC printing of some sort .. perhaps a more QuakeC dev can translate to what causes your issue. 
I think we need to blame Gunter that you found a QMB cvar bug. I am really disappointed that Gunter let that slip by his bug testing.

I expected more from him, haha! 
Eprint Behaviour 
Standard Con_Printf will do a full screen update.

This is really useful if you're printing some text and you want to see it on the console right now.

It's painful if you're doing lots of small Con_Printfs to print, say, an entity, because each entity printed could trigger tens of screen updates.

If you have console logging to file always on it's also going to be constantly hitting the disk - again, tens of disk writes per entity.

Changing ED_PrintEdict to use Con_SafePrintf can help with the first. For the second you really need to do what the doctor said when you told him it hurts everytime you do this. 
I look into that, I get your drift. It isn't priority #1 on my list, but yeah message received. 
Addendum: Despite 12 beers to end a wonderfully chaotic weekend, sounds like an easy fix.

March 9th surprise is going to be a total blast! 
Con_Printf's screen refresh kinda sucks.
1) its slow!
2) ANY prints inside the drawing code results in recursion, and then more recursion, and then eventually CRASH! catching out many newbies.
3) if your drivers are tripplebuffering then its going to show the wrong print last, which makes it really misleading.
4) a number of frameworks don't allow you to swap buffers yourself making it a complete waste of time.

If you trust the engine then its redundant anyway - win32 engine devs are probably better off using OutputDebugString, while unix users will have working stdout. Its really only dos that 'needs' prints to be displayed onscreen NOW.
imho just redraw the screen only when developer is set (and when not recursing), then users can won't be sitting around waiting for the loading screen.

The one exception is with the connect command, but imho that should be made to be non-blocking anyway.

in the mean time, disable vsync. 
I will avoid using the function for now.
But seems like there's no vsync option on Mark V (and i usually disabled it because of input lag) 
if you do "find vsync" don't you find vid_vsync?

Maybe it should be a menu option!!

*hears Baker frothing at the mouth* 
Hey, I gotta leave a few bugs unreported so everyone else can experience the thrill of ... reporting bugs!

Hm, it looks like I did mention in #653 about blood and fullbright, which you looked into but couldn't exactly fix. mh mentioned there's a 1 and 2 setting for QMB blood. I had suggested adding some standard particles into the QMB effect to allow some fullbright to still happen.

Tribal mentioned: "when I set the command qmb_blood to 0 it doesn't change the blood to particles, it mixes red particles with blood sprites"

I am not at my Quake computer at the moment -- I'm wondering if maybe you did mix in some regular particles for the 0 setting, instead of disabling the QMB effect.... If not, you should have a setting that does do that! I guess qmb_blood 3, if both 1 and 2 are already used. What is the difference in them? 
MarkV seems to have console debug logging enabled by default, so it does hit the disk for every Con_Printf, meaning that debug printing of entities will be incredibly slow. 
Glad to hear you're still working on the split-screen.

No idea if borrowing the controller code from QS is possible but I'd say it works best there by default.
I'd say that having multi-controller support/setup would be best placed in the multiplayer setup menu.
Would be awesome if going into the multiplayer setup menu also dropped straight into split-screen and each player could adjust their own character colour, name and bindings.

I suspect it'd be a huge undertaking in code but would be super awesome for couch gaming, something that would probably go down really well for those who launch through steam etc. 
So Where's This 9th March Surprise ;) 
RIP Baker. 
That's The Surprise 
He vanished. Not exactly what we all thought or needed, but definitely a surprise! :P 
I Predict STILL Hungover. 
It seems that QMB_BLOOD 0 causes all kinds of particles (not just blood) to be a mix of QMB + Standard particles -- my blue water splashes and grey chat smoke, for example (I use lots of particles in FvF).

Also, OGG support, please! 
Update! Part 1 ... 
No I didn't vanish. Despite my stupid drunk posts, which when I get the time I intend to apologize to snug for ... I had some "coder frustration overload" + way too much beer.

Which is a nice reminder of why to patient, humble and kind. Coding is like a deathmatch against unmovable objects. You lose. A lot. Sometimes hard.

It is not fun to lose, nor lose hard. And I did not take it well that particular day. 
Update Part 2 
I missed the target date of March 9th.

I expected rolling over the coding problems and instead got socked with several deep and severe issues. The issues kept building and building.

Eventually, I toughened up and geared up for a brutal fight. One which I won 3 hours ago.

24 hours: Version 1.70. Part 1 of 2.

Both Part 1 and Part 2 are going to change things quite a bit.

And I'm not going to ruin the surprise, but a couple of developers likely suspect what's up. 
Add: Many people may think Quake is dead.

It isn't. Quake isn't dead. It is asleep.

In the next 24 hours, we will not be waking up Quake.

But it will be great eye opener of precise the manner of which it can be done! 
He goes from "drunken poster" to "vague mystical guru posts."

Either way he's working on Mark V, so it's good. 
I Think... 
I also need to get drunk. Otherwise I am not able to understand these mysterious announcements... xD 
In the next 24 hours, we will not be waking up Quake.

Quake will be waking us up. Showing us that what we thought was reality, was in fact a dream all along.

Looking Forward To It 
Really enjoying 1050. Although I am getting a water warp message in developer 1 even when there are no liquids in the map. 
Mysterious...I'm Intrigued 
Will It Run 
... all maps of the latest "Arcane Dimensions", that's what we are all wondering about! :P

But seriously, right now I wouldn't know how you could significantly improve Mark V beyond its already impressive feature list. Baker implemented pretty much anything I asked him. Sure, OGG music support would be nice, but Baker's teaser indicates it's gonna be a lot bigger than that. 
I Dunno, Ogg Would Be Huge 
OGG support, please!

Hey, how does everyone else pronounce this engine's name?

I was on Discord talking with a guy who is doing some Quake streaming on Twitch ( and he was saying "Mark 5" but I always say "Mark Vee" ... :? 
Mark Five 
V Is The Roman Numeral For 5 
I was born in MCMLXVIII 
Yeah, V is the Roman Numeral for 5, but with Mortal Kombat X, for example, X means 10, but the official pronunciation is "Ex" (says Eb Boon:
X is 10 because V is 5 and X is an upside-down V with another V above it. 5+5=10. 
This is a case of video game marketing and communities ignoring an ancient numbering system from one of the most powerful empires in history.

Who wins this one?

Mark V Build 1080 + Touch Screen Support (iPad/iPhone) 
Download: Windows | Direct X | Linux | WinQuake (Plus a WinQuake GL for KillPixel and a couple of others)

Source code: here iPad/iPhone source code is in there.

* Full multi-touch iPad/iPhone source code for an experience rivaling Minecraft for the iPad in user-interface.

** Drag look just like Minecraft
** Adjust sliders in the Quake menu by touch
** Optional support for bluetooth keyboards like the $7 ones at Walmart that support iPhone and Android.
** Tap fire. Double tap on the Ogre to fire at him if you like.
** 5 taps to host a "New Game" (cooperative).
** At the moment, it is the WinQuake build, can't muster up the stamina for the Open GL at the moment.
** Thanks to Mark V LAN discovery borrowed from Spike's fine work, "Join Game" for a LAN game is a breeze, just like Minecraft.
** Any map that works in Mark V, works on the iPad. But the iPad gets lower frame rates than a desktop, so standard Quake maps are plenty fast but it is likely that a 400 monster map with open spaces would run unacceptably slow.

* Mouse-driven menu on Linux and in WinQuake

* Touch Screen mode that I hope works on, say, Fifth's Surface Pro. All builds have a touch screen option in video options. Unfortunately, I do not have Surface Pro so there is not multitouch support, I would not be able to test it.

* Direct3D sbar alpha works thanks to MH's tip.

I may or may not take a quick stab at an Android port. If I were to do such a thing, it would likely be basically done in a 48 hour period. My main concern is that I think for Android I was use SDL2 and if I recall, SDL2 had a sound lag issue for me on Android -- and if it sound lag, I would be irritated.

This is Part 1. Part 2 comes in a few days, has nothing to do with mobile devices.

@Tribal - I took a quick look at the qmb_blood option, isn't quite the quick fix I had hoped. Thanks for the bug report. 
The LAN discovery feature is good news! As for iPad support I am... bemused but entertained? :-) I am inclined to steal my wife's iPad mini to check it out, altho looks like I'll need to figure out how to build it? 
I've Got A Surface Pro 2...can Test Later 
But I can't think of a use for multi-touch unless the Win10 build also has the touch controls for movement. 
Impressive. Congrats.

And I was concerned with your health... Coding and drinking doesn't go well for me, so I never drink. 
"Unless the Win10 build also has the touch controls for movement."

It does!

Video Options -> Touch Screen

Without multitouch, you can only touch one thing at a time, which sucks compared to the iPad version where you can press 3 things on the screen at the same time.

@johhny - To build for an Apple device, you have to have a Mac. My source code is friendly, you literally click "Build". But the sticking point is having a Mac. Plus, iOS has some new red tapes that iOS 9,8,7 didn't and the project probably doesn't meet those red tapes so you might have small chores like making a 98x82 icon and a 196x163 icon and 10 other pesky nuisances like that.

That being said, playing on the iPad version is un-fucking believable. When I got the multitouch interface working right and then loaded it up, I was not prepared for the level of awesome. 
Thanks! Nah, my health is 2x awesome.

I encountered Level 92 frustration developing this version, it was so frustrating at one point.

I had to get real tough and prepare for a dog fight in the mud. Obviously, I rose to the occasion. Besides, can't have mh or Spike thinking I'm not hardnosed like they are, haha! 
multitouch is surprisingly useful for touchscreens even if not explicitly needed by the app's UI, just for example having it not ignore a second tap because your finger from the first tap hasn't fully lifted off the screen yet, or, not completely ignoring everything you do because your hand holding the edge of the tablet is slightly touching the screen edge. 
Techical Note @ Qmaster 
On an iPad, you can touch 16 things at the same time.

If mh reads this, he may recall I implemented his "single point of checking mouse state per frame" mouse input paradigm long, long ago in Mark V. This version of Mark V extends that philosophy to the touch controls activation/deactivation and it was at first a major nightmare, but then it collapsed in simplicity and beauty after a dozen revisions. 
I have the multitouch tracking everything.

The user interface only acknowledges one press per button where the whole screen is a separate button.

To access the menu, you press a transparent triangle hint in the top left corner.

A funny thing, I was thinking of you off and on while writing this. To the best of my knowledge, you and Sleepwalker are the only other 2 that I know for sure is familiar with the ins and outs of the Apple interfaces and while well conceived, they required quite a bit of learning to use properly. 
But There Will Be 
... a new OpenGL build, right? That's the one I am religiously using! 
Is there something that the DirectX 9 doesn't do or some specific reason it doesn't meet your needs?

The DirectX 9 version is, in my view, absolutely superior in every way.

It is:
1) Does everything that the Open GL does (99.9% on that).
2) Vastly higher frame rates that blow away any other Quake engine except DirectQ and only eeks out a small win against FTE Open GL (FTE Direct3D likely beats Mark V Direct 3D because FTE has better rendering code). MH's extreme craftsmanship of the Direct3D 9 wrapper allows Mark V Direct 3D super-speed despite the fact I should rewrite the underlying rendering to probably get another 75% to 100% speed gain.
3) Bad Open GL drivers? NVidia doing a wacky update -- Direct 3D is immune! Can't happen. So stability + reliability +++. I get a bit tired of NVIDIA doing some update and it breaks something in Open GL, but the Direct X cannot be updated by NVIDIA (this is my understanding at least, and I think I am right).

Those are my thoughts. 
What does your Linux version use? I'm clueless on this stuff but hope to have a Linux machine up sometime soon. Also any clue as to why I am getting a waterwarp size is 1024 message in developer 1? No liquids? 
Hmm. Lots of duplicate symbol errors when linking the iOS build, conflicts between input_surface.o and various other .o files.

My first guess was that it might have to do with eval_flags/eval_frags being declared as int rather than extern int in progs.h, but changing that didn't help anything that I could see.

Will give it another whack later. 
Waterwarp Size Is 1024 
I think that message comes from code I wrote. I'll review it hopefully tomorrow and see what the cause might be. 
I use Ubuntu but the Linux binaries works on a fair number of other Linux distributions, or so different Linux users have said.

@ johhny - if I recall, there are 288 source files but if sometimes seeming randomly -- like maybe if it targeted the simulator or a generic device? -- XCode would try to compile 568 files. I plugged in an iPad and targeted that and it works fine. I am using XCode 8.2, I think the current version is 9.2 and since it seems like every XCode upgrade introduces some quirks/inconveniences to tackle, I put off upgrading a bit. Short version: Couldn't quite say, 
OK. I'm targetting simulator at the moment. Will wait until later when I can plug in the iPad. 
@johnny ... be sure create a folder called id1 in Documents on the iPad and throw pak0.pak (and pak1.pak) in there.

I can't remember the method to put files on an iPad offhand.

Note to self: Use Mark V http download offer to download pak0.pak or something on startup if it doesn't exist in the next revision. 
Direct X V1.80 Build 
I have taken a quick look at the Direct X build and it seems to look and behave just like the OpenGL one, so I stand corrected with my prejudices. I cannot say much about speed differences, but it feels smooth alright.

Still missing my favorite gl_nearest_mipmap_linear option, but besides that, it's all fine.

Is this build capable of running all the new maps of Arcane Dimensions now, btw? 
I need to add Sepulcher support. It is on the "todo" list.

My first priority is getting new unreleased capabilities off my hard drive and into reality.

Then I'll be adding things like Sepulcher support, etc. 
Go to Video Options -> Pixelization.

I'm 99.9% what you want is in the DirectX 9 build.

Let me know. 
waterwarp size is 1024

This is just a notification that should only happen at startup and when/if the video mode changes. If it's happening more often (every frame) it's a bug. It's nothing to do with water surfaces but is rather used for the underwater warp effect.

It happens even if the current map has no water because the next one (or the previous one) might.

The alternative is to destroy and recreate the texture each map, which could lead to extreme video RAM fragmentation, or to create it on-demand which (in addition to fragementation) could cause runtime hitches and stalls. So I decided instead to burn a little extra memory in exchange for performance.


This should be fully supported; I've reviewed both my original wrapper code and the MarkV implementation and can confirm that. 
I actually checked explicitly for that. The only options for the pixelated look are gl_nearest and gl_nearest_mipmap_nearest. Just like in the previous (OpenGL) builds.

Smooth mipmaps transition ftw! ^^ 
It should be settable from the console though. If something's missing from a menu option it's nothing to do with the API used. 
Egads. I version 1.36, I had gl_nearest_mipmap_nearest. Then I knew it needed to be the "other one".

So I switched it to gl_nearest_mipmap_linear. Then I forgot I did it.

Then I worked the todo list and switched it to the "other one" again and since it was gl_nearest_mipmap_linear in the source, I changed it to gl_nearest_mipmap_nearest. 
Then basically you switched it twice so it was effectively as if you had never changed it?

Well, now please just change it ONCE again and I can die happily. ;) 
I'm trying to cause this developer 1 + r_waterwarp message, but not having any luck. 
Line 812 of gl_texmgr.c is where it happens. 
Mark V - Buiid 1081 
Direct X | WinQuake - Windows rebuilds
(killpixel's winquake gl in there too)

Got rid of dumptruck's warp message printing in developer 1 and another message that was spamming some, gl_nearest_mipmap_linear replaces gl_nearest_mipmap_nearest and fixed noticed the menu being drawn during QuakeC or demo playback or disconnect go to console. 
That was a really fast fix. Thanks a lot, Baker! Another proof that Mark V should be anyone's favorite vanilla-style port since it's handled so well! :) 
thanks for the update! 
Thx Boo 
Crash Report 
Mk V DirectX 1081 crashes to desktop without error message (just the usual Windows notification that the program "stopped working") when trying to use the remade ogre model by Chillo:

Download (1.0 MB):

Tested in E1L2, crashed right away. The model is quite big, but I dunno if that's what's causing the crash. 
What engines is it known to work in? It looks like DarkPlaces and DirectQ.

Mark V supports 3984 verts, the maximum possible in WinQuake according to a note by aguirRe.

If it works in Quakespasm, for instance, let me know. 
It also works in my original FitzQuake implementation that I built the D3D wrapper on. 
Quakespasm Test 
Model loads without issues in latest Quakespasm 0.93 x64 build. According to QuarK, it has 1290 triangles. 
Number of triangles in a .MDL file can be very differrent to number of triangles in an engine. Most engines will unpack them to strips and fans for drawing whih can change the counts quite dramatically.

Basically, it's completely unsafe to limit the verts in a GL engine to the same limit as is used in software.

@Baker: running a debug build should tell you exactly where this crashes. 
Another Model Issue 
Another of Chillo's models, the Shalrath, gives an error message when trying to load the model:

"Skin taller than 480"

Package with model (shalrath.mdl): 
Ignore my last report. Just took a look at the Shalrath skin file, it's obviously a placeholder. It's just still about that ogre model, then. 
Another Crash 
E4M6 crashes with the Authentic model improvements pack. This used to work with previous (OpenGL) builds of Mark V.

Download model pack:

I could not identify which of the models is causing the problem. 
Map Crashes (summary) 
There are more maps that crash. I checked all maps of the original campaign and the model improvement pack does not work in these levels:

E4M6 (as reported above) 
These maps likewise work fine in my original codebase.

It's obviously a model that's common to them all overflowing an internal buffer that's differently-sized in MarkV. 
Found It 
I found the model that causes the problem. If you remove the Fiend model from the improvement pack (demon.mdl), the maps stop crashing.

This leaves two models to be investigated, demon.mdl from the existing improvement pack and ogre.mdl from Chillo's release. 
The only thing I can find as a possibility is mipmap generation for non-power-of-two textures.

In my original code I let D3D take over mipmap generation, whereas MarkV retains it's own mipmap generation.

These models have unusual texture sizes: odd numbers, not multiples of 4, etc. So when you go down a miplevel you need to be aware of whether you are going down exactly to half size, or if rounding down is involved, and depending on how the engine handles memory allocations for this, it may trigger a crash. 
Well, curiously the models won't work with Mark V 1.36, either. I just tried. However, they should since I remember playing through the entire game at least with the demon model since it is already in the improvements pack. 
If It Helps... 
I just tested various DX9 builds from previous Mark V releases. The last one that works with BOTH models without crashing is 1.27 rev. B:

Starting at 1.28, the crashes start:

Hopefully that narrows it down for Baker to find what's causing this. 
Time To Dust Off The Surface... 
That is a high quality investigation, thanks for the detail that should make tracking this down easier.

I guess I'll do an OpenGL in the next one *only* for the purpose of trying to nail down what is going on with this.

I *do* want to know what the differences are and unwind this small mystery, but also I want to get some more new stuff out. I want to get new concepts off my hard drive and into reality.

Speaking of which. I expect a new version with something quite new in 24 hours. Maybe 36 to 48 hours because I had to kind of fork the codebase and need to "unfork" it to get the source code tidy.

This isn't the "big one". The "big one" is still a few days out. 
@fifth - Really? 
I thought you used your Surface Pro all the time. 
Map Hard Crashes 1.81 
I am testing maps for dm4 Jam on Mark V 1.81 One of the maps uses a trigger_once to trigger a map hack using an info_null using W_FireLightning

The engine freezes and I have to Ctrl+Alt+Del to kill it. Here's the map and source. It's the large trigger once immediately after the info player start.

Map plays on most recent versions of DarkPlaces, FTE and Quakespasm 
In Order To Avoid Misunderstandings 
These crashes with high-poly models occur in both DX and OpenGL builds starting at 1.28, doesn't matter which one you use.

This also explains why I remember the new Fiend model working - last time I launched Mark V was well before summer 2017. 
I rarely use it tbh, I may use it more since I get extra long lunches now and could map in them.
It has some issues with keeping charge and the keyboard isn’t great so this is why, plus I have a decent PC anyway 
I remember finding out that the skin loading code for either SPR sprites or MDL models in vanilla WinQuake has a bad pointer arithmetic. I really don't remember exactly where it is though, but its badly offset by a very small value, something like 4 bytes. I remember being surprised that it didn't cause any crashes. 
Dear Spike, gamers, programmers and Quake fans. Could any of you lend any knowledge about multiplayer capabilities for FitzQuake Mark V? Does one need to setup static ip, forward ports and establish DMZ for good old coop with a friend over the internet (local server)?
I found Mark V enging is very good and i love it. But Quake without coop is not complete. 
Port Forwarding?? 
As far as I know you simply have one player start the game as a host and the other type in the IP address of the host in the join menu, same as usual. 192.168.whatever.whatever.

On Windows you can do Winkey, type run, hit enter, type ipconfig, hit enter then look for ipv4 address. 
You're assuming a LAN game tho. Cadaver747 sounds like probably he's talking about co-oping over the internet?

Baker would of course be the best guy to ask about Mark V's port usage. I'm pretty sure I recall that he's included some of the fixes done in a few modern NetQuake engines so that it only requires its single listen port (26000?) to be forwarded. 
for engines using a single server port, just reconfigure your router to forward that sepecific port (26000 for nq servers, 27500 for qw servers) to your machine, then eg google for 'ip' and give that to your friend to connect to (don't depend upon windows - it'll show you addresses that are only valid on your lan, which is not what you want).

for other engines, you'll need to set up dmz stuff crippling your router's nat+firewall stuff, as get your friend to do the same.

all quakeworld servers+fte+dp+qss+markv use a single port for connections. the rest all suck big hairy donkey balls (including quakespasm) at least for internet coop.
this is not the only reason that most people favour quakeworld for online play, prediction is another significant factor...

sidenote: with the exception of non-fte quakeworld, the above engines all also support ipv6. assuming your isp isn't dragging their heals and generally being lame then ipv6 makes things cleaner by removing the need for NATs. You'll still be firewalled by any good router though.

lazy people: if your router follows certain ICE-friendly rules (eg most home routers but few business ones), you may find that just setting sv_public 1 on your server is enough (the heartbeats should automatically open your firewall/nat).
the other person can then use their client's menus to find your server according to its hostname cvar - if they can spot it. This should be true of FTE+DP+QSS, but I don't think mark