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
The Beta Testers +++ 
That was faster than I expected. I haven't even finished my beer.

This is an incredible community and it showed as I got very close to getting things release quality -- tons of beta testing help with great detail, made it so I could solve remaining issues quickly!

Ericw provided a key assist with something I was struggling with regarding the German keyboard.

I hope Gunter (co-op server operator) sticks around sees how great this place is! 
Nehraha Fog 
Thanks for putting the nehahra fog in! 
I read the thread for every issue ever reported.

Might as well do everything right, even if it meant somewhere in the world, a puppy must die.

Better engine coders than myself would have Quaked in fear.

Me? I just wanted it to work perfect so I could finally play it ;-) And when I got it right a couple of weeks ago, I played it for 3 hours. 
lol If you want Mark V to be able to play everything, you can try to support that old version of Industri. The Maps are nice even if the shadows can't be supported 
Great that you decided to resume working on this before next year after all! Just hoping that it isn't the end of the road yet. I am still dreaming of vanilla-style underwater warping! :P
Anyway, thanks a lot for your continued work on this port and your determination to turn it into the best way to play Quake for fans of its retro look (while still offering/allowing many nice visual enhancements)! 
The engine crashes for me somewhere half way through ne_ruins second level, shortly before or after obtaining the gold key (not in a specific area). I recall this issue existed in previous versions as well, since the mod demands a very specific amount of edicts or something.

Other than that, the engine seems to be really awesome, I especially appreciate the faithful software renderer with proper resolution upscaling. Thanks a lot for all the effort! 
In Malice, +attack doesn't move the probe. Quaskespasm has the same problem.

The probe is an inventory item, it can be found at the end of the first (tutorial) level.

It works in vanilla Winquake. 
LAN Co-op Example 
Co-Operative Play Example

Computer 1:
- Type "install travail" (Downloads from Quaddicted)
- Type "game travail; maxplayers 4; coop 1; teamplay 1; map start"

Computer 2:
- Type "install travail"
- Type "connect lan"

BOOM! Your done. And you have a per-player monster kills scoreboard. Mark V clients auto-switch gamedir and detect LAN severs.

Maps without co-op spawns --- for the first 5 seconds after spawn, players are transparent and can walk through other players. Feature can be turned off via sv_coopenhancements 0.

The Undergate is an example of a map without co-op spawns. 
@pathogen, Dwere And (mandel If He Ever Sees This Thread) 
@mandel if you see this thread -- dwere had an issue with cl_autodemo. Mark V now defaults it to 0, but you may need to set it manually. Mark V has had autodemo on for years and about no one had a problem with it, but nevertheless now defaults off.

@dwere - Malice. Thanks for the info.

@pathogen - Mark V uses 8192 edicts. I've played ne_ruins through to the end multiple times, but not lately. Sounds like something to check out when the time comes for the next version. 
Another Thing With Malice 
Unknown command "+zoom_key"
Unknown command "-zoom_key"

The alias works fine in id1 and Nehahra, at least. 
If a mod has its own default.cfg, the alias is not created.

It was only meant to smash the horrible F11 "zoom_in" alias in original Quake that wrecks your fov and sensitivity and replace it with something very nice.

/Another thing to possibly do when the time comes the next version. 
Hit The Mark 

I wanted to give this release a try since I see you have been on a developing frenzy. This is from someone who only used QS.

First of all I love the support and auto-scaling for 3440x1440 resolution. The "Levels" selector built into the menu is really sleek. The mirror support is something really novel as well! I'd like to convince my brother to play some coop with me sometime to try it out all of the features.

I am just having an issue with playing external music. I was thinking I need the same setup as QS (id1/music) but nothing plays regardless of external_music being set to 1. I have the .ogg NiN track so I don't know if that has something to do with it but please advise.

Thanks again for your support and I think I will play around with more of the features and I may set this to my default engine. :) 
.mp3 should work, same as QS otherwise. 
Mark V only supports mp3.

Mark V uses system methods to play MP3 that take advantage of hardware accelerated decoding of mp3 built into your processor.

Intel processors, AMD processors, the iPhone, Android phones all provide hardware accelerated MPEG-1 decoding (mp3 is part of MPEG-1 specification). Plus the mp3 decoding patents expired in September 2015. 
Alright, mp3 I went ahead and grabbed the mp3s of the soundtrack and converted my two custom tracks to mp3 and there we go!

Wow, it literally is instant playback! I am used to the 2 second delay. Thank you!

Demo playback and also the selector is incredible and rewind/fast-forward controls...delicious! 
I'm glad you are enjoying it, I put my all into trying to get it from beta quality to release quality, not easy considering the feature set that I wanted.

/Mirrors aren't novel if someone sets up an angled mirror and an observant player notices a secret item or X to shoot. ;-) 
It may be why Mark V can stop/pause/restart music instantly and engines using a software decoding library cannot. 
Clear Water 

You are right about the mirrors haha...I like that idea!

You did well with this release, I am really happy with the features when comparing to my other default engine of choice.

Underwater (slime, lava as well) is very clear and has barely a tint to it. I see that you could alter the percentage via r_watercolor but if I change the number it just becomes completely clear. I did a search on the older Mark V thread and saw Gunter discussing it but I did not see a solution. :O 
Mark V default blends should be same as Quake.

In the menu there is an option to set them to light or normal.

You should probably do resetcvar r_watercolor because changing that isn't something so easy to do.

/Changing the number requires 4 numbers, red green blue alpha. It is sort of an advanced feature for a mod that wants different underwater colors. 
Wow, right there in the menu I had set to lite for whatever reason...yeah Quake default setting looks perfect.

I also performed the reset as well. Thanks, I think that should keep me quiet for now!

On a side note, the tool_inspector is amazingly helpful for mapping! 
I also made the screenshots PNG, you noticed.

That way you can instantly post them without mucking around with opening a graphics editor or such. 
If you want to do something fun, do this ...

Install DivX/XVid codec pack download page

1) Record a demo ("record mydemo")
2) Type capturevideo_console 0 (prevents console from being captured)
3) Type "capturedemo mydemo"
4) Type "folder" ... you might need to ALT-Enter to windowed mode first.

Upload your video to YouTube.

(*) Link to codec pack is now page too. 
Oh yes I did notice the native PNG, that is a nice quality of life change!

When I enter capturedemo, Mark V crashes. I can see that it makes an incomplete .avi file however.

I have the codec installed, so not sure! :O 
Could you enter "capturevideo_codec divx" before doing capturedemo and see if the problem remains.

I use capturedemo all the time, this will allow me to determine if the automatic codec selector is the source of issue. 
Yep, still the CTD even after setting codec to divx manually. 
Thanks, I should have this addressed, need to knock off one more thing before updating. 
Version Update (build 1000) 
Mark V download has been updated

(New update shows build 1000 when "version" is typed in the console).


1) Increased max model vertexes/triangles to match Ben Jardrup's Enhanced GLQuake/WinQuake limits of 3984 and 4096 to support more replacement model content. (Gebloner)

(The vertex limit is the highest number possible for WinQuake asm according to a comment in that engine. Both of these limits are about 2x the old ones.)

2) Fixed loadgame issue when demo playing (zbikey)
3) +zoom_key always available now. (dwere)
4) "capturedemo" to AVI video should be fixed. (Bloughsburgh)

Extra files:

The Mark V page site now has extra downloads on it.

1) DivX/Xvid Codec Pack link for video capture (the capturedemo command) for compressed AVI video.

2) Frogbots -- truly awesome bots and has support for 120+ maps due to incorporating code Trinca wrote.

3) Correct Nehahra fmod.dll for xm music (2004 date). The Quaddicted Nehahra .zip has a bad fmod.dll in it (2001 date), I've been told.

3) Color lights and transparent water (.lit/.vis) files for Quake and Mission Pack maps assembled by NightFright.

The .vis files make it so no vispatching is required to have proper transparent water in Mark V (DarkPlaces/FTE supports them too, AFAIK).

Mark V has automatic detection of transparent water in maps so releases like Travail -- with no transparent water -- render nicely regardless of r_wateralpha setting.

@Bloughsburgh .. you should type "resetcvar capturevideo_codec" in console to restore it to automatic codec selection ("auto"). 
Possible Feature? 
A lot of driving games, and the new duke 3d port on steam, have a re-wind feature. So instead of saving the game you just rewind to a 'safe' point... I'm always forgetting to save and I hate starting from the beginning 
Mark V can already help with the "Oh no! I forgot to save situation" ...

If you die and forgot to save, type:
1) load a0 ... 1 minute before you died
2) load a1 ... 3 minutes before you died
3) load a2 ... 5 minutes before you died

Wrote feature because one time died 2/3 through a great map in one of the early mapjams and it took me 45 minutes to get to that point. (sv_autosave - defaults on for precisely this reason)

/Admitted the rewind back into demo and play it would be cool. I can think of ways it might be possible to write such a feature (inserting savegame info into the demo occasionally -- perhaps in a way a non-supporting engine would just ignore). Maybe at some future time I might think of a way to design such a thing. 
I Didnt Know Or I Forgot 
about the a0-2 save situation... Would be nice to have some kind of option in the load menu for this? :) 
Small Typo At Quakeone Page 
There's a small typo on the Quakeone page ( If you'd care to fix it, it's as follows.

"Spike solved added BSP2 to Mark V"

Remove solved.


Thanks to everyone for the effort put into the engine, coding, testing, extras and so on. I appreciate your work very much. 
Cool Page 
Nice 90's vibe.

Hey why does Spike and NightFright get capitalization but others like Fifth, Gunter and Qmaster don't. Just nit picking. And Fifth is missing his Elephant.

Love all the new features. Will have to use this for coop sessions from now on. 
Not In It For The Glory Or Recognition 
Just want to help shape my favourite fps game :) 
Hello Darkness 
You are on the ball baker!

Capturedemo works as expected with the exception of two things:

1) There is no music recorded (Due to how mp3s are read from the game maybe? Not a bug?

2) I just get the sounds of the demo and no video but a black screen. No idea if this has crossed the border of a "It's on my side" issue. 
Hey why does Spike and NightFright get capitalization but others like Fifth, Gunter and Qmaster don't.

I've always given my name without caps, here and elsewhere. 
Bugtester names are case-sensitive, just like function names!

Since we're moving to a new page, I'm gonna transplant a few items of feedback/wishlists which still apply for me (some recent and some from the past) to this new page. And I'll throw in some new things to be thorough!

Old feedback page, as reference for those who didn't come here from there:

Baker, bolt1.mdl is still in the noshadow list.... Just delete it. it doesn't exist in Quake.
I've been reporting this issue since March 2014 :D

Ya know, I think you should stick all the Windows downloads into a single zip file (GL, Win, and DX). That would just seem more convenient for everyone (you only have to make one zip, and we only have to DL one zip).

I think pq_download_http_locs should default to OFF. The other auto-downloads are things that are automatically used by quake, like maps, models, sounds, vis files (er, does it automatically DL vis files? It should do that, and maybe colored lit files too!) -- all those things will automatically enhance Quake. But loc files won't do anything unless people actually want to set up the binds to make use of them, so for the majority of people, you're just downloading files that aren't wanted/needed and probably won't ever be used (in my case anyway -- of course, I'm disabling them now, but I still think this one should default OFF).

+zoom_key -- I think you are setting the sensitivity too low when this is used. 1/10th standard sensitivity seems better (10%). Looks like you're using 6.25% Do any other users have an opinion on the sensitivity?

There's an issue with the Winquake version if you run in a window with the vertical resolution set the same as your screen height. Like if I run in an 800 x 600 window on my 1024 x 600 netbook. The HUD is chopped off at the bottom of the screen.

Setting alpha by an .ent file works for me now in all versions. Very cool! I really wish there were more options for me to play with it though, like a list of entities or frames that should always be drawn at a certain alpha. I mentioned that in #1365 on the old page.

FTE has a nice feature when you are in the menu and the focus in on either the "brightness" or "contrast" slider, the "menu background darkening" of your game screen goes away. It's much easier to adjust your screen values when you can see the results as you adjust, instead of having to adjust, then exit the menu to see the actual results.

When you switch a gamedir, it really should exec the autoexec.cfg file found therein. Those only run when you first start Quake, from whatever -game you have set. But if you change "game blah" in the console, then it will never get executed. And an autoexec in a gamedir generally contains the binds just for that mod which will need to be set.

I would like to be able to bind a key to turn off skyboxes, but you can't bind something with "" in it (so no key can be bound to: sky ""). Perhaps a different command to disable skyboxes would be better, maybe even sky '' or anything that can be bound to a key. Or a whole new command: nosky, or skyoff....

I've mentioend before I have a modified DM6. Mark V does not apply the usual custom textures to it, but Quakespasm does.... The texture names should all be the same.

Oh, you still need to have a name change not be committed until the setup screen is exited. Old page #1221

I will re-mention.... I feel "always run" should not default to ON. Standard Quake default is OFF, and the setting is flawed for reasons I explained on old page #1154. So, ya know, either use defaults or don't in this case:

1. Leave the default (flawed) behavior for "always run" but also leave the default of leaving it OFF.
2. Change the default to having it ON, but also change the default to fix the flawed behavior (like Quakespasm did -- preferred option in my view).

Joystick support was disabled at some point. #1352 for more interesting control options (even for keyboard).

A separate console variable to adjust ring (etc.) blends might be useful for fine-tuning.

Possible shadow hack improvement: don't draw a shadow if the entity is more than like 100 units away. That is one of the weird things about shadows. Which I know are a "hack" to begin with....

How about that multi-layer sky with transparent standard quake clouds in front of a skybox?

Old page #1321 (screenshot) fullbright textures getting ugly when contrast is applied. Just have contrast not affect them? Texture gamma option doesn't address this issue, it seems.

Oh yeah, I request removal of your anti-z-fighting hack, since it interferes with my own anti-z-fighting hack mod-side, heh. I discussed it on old page #1367 That type of moving entities around in the map should really be left at default so modders can take care of it :D

Anyway, Keep up the great work! 
By the way, as you may know, I promote the use of Mark V for playing FvF. People who I have gotten to try it have really liked it.

Even after installing all the custom textures, lights, etc, one player said: "I really like this. It still looks like Quake, but nicer."

I think that sums up the appeal for me as well -- it doesn't mess with the heart of Quake by drastically altering the look, feel, or behavior, but it subtly enhances things in just the right places.

It's still standard Quake, but nicer! 
@gunter - Sure there is no bolt1.mdl, but if someone makes a mod with one then they don't have to add it to the r_noshadow_list

re zoom_key, window .. <a href=" Bloughsburgh"see post 1546"</a> in old thread. You can change it, and I don't save users from their own choices.

If you put your textures in, say, "c:quakehd" instead of quakeid1 and set "hdfolder hd" it will apply the textures to your custom dm6, the current method prevents the textures for start.bsp (id1) being applied to a different start.bsp (Like Travails) so it is working by design.

quake.rc - apparently you haven't seen enough quake.rc files. Warpspsasm's quake.rc sets developer 1 in it, Zendar's actually sets a video mode, some of the old Quake mods set highly inappropriate things. Nothing can type "exec quake.rc" yourself.

I've read the rest of the list before. It may or may not mean anything if I do or don't do something. My focus has been mainly on getting known issues resolved.

@ Qmaster -- I think I used the first word in the sentence theory of capitalization ;-)

@primal -- Hey primal, I assume you are the modelling Primal that I know ;-) Yeah I fixed that immediately when you posted. 

Are you using a crazy big resolution when doing capture demo like 3500 x 1400 or something? I don't know if there is a Windows resolution size limit involved.

Also mp3 music, since it is being played in Mark V externally isn't captured because it isn't part of the Mark V window's sound.

@anyone else willing to do a quick test ...

Could someone else install this codec pack and do "capturedemo demo1" with a reasonable resolution and confirm that the AVI capture works properly?

I believe it works properly in the general case, it does on mine -- but I need confirmation from others. 
@fifth -- Re: Autosaves Not Being In Menu 
When Nightfright and I were testing around the time the feature was written, both of us found it annoying for autosaves to be shown in the save game menu.

Benefit for being a beta tester or reading the thread I guess ;-) 
I see the thread but I don't recall having opinions on the autodemo feature. Had to check the old thread to remind myself. Thanks. 
Does the software renderer support fence textures? 
Also Curious 
About someone else doing the capturedemo test.

I attempted with 640x480 and same deal. :O 
Baker, another possible link for the Files section would be this map pack that contains (almost) all of the maps that Frogbot supports:

(That's for Trinca's build 379 of the QW bots, I'm assuming your NQ version has a similar map set.)

Download size is about 100 MB. 
@johnny -- Great download! Added.

@mandel - Once had stated you were getting inconsistent performance in Mark V when you tried it when it was beta, just pointing out that dwere experienced that as well and setting cl_autodemo 0 solved his issue. Made autodemo disabled by default. Just wanted you to be aware of it.

@Six-Shoota - Eventually alpha masked support will happen in the WinQuake build. It's very hard to do because the code is like a maze-like. I've tried a few times before. Eventually I'll give it another try.

Still need a volunteer to test out demo to AVI movie by doing capturedemo demo1 after installing a codec pack download site ... for anyone willing to give that a try ...

Works fine for me, Bloughsburgh = black AVI with sound. We're trying to determine why it doesn't work on his machine but it does mine. 
Could you try this ...

capturevideo_codec xvid
capturedemo demo1

I have an odd suspicion explicitly setting that codec might work. 
Frogbot Support 
Is there a way this can be added through placing entities in your .map file? 
Frogbot map support was hardcoded into the QuakeC by Trinca, I don't really know how it works. But it is hardcoded into it. 
Ah, I hadn't noticed that reply in the old thread.

"aliases" in console is an unknown command. But I did "alias +zoom_key" to get the information. I see some tools I did not know about in there... valsave and mul. Neeeeeeeeat.

And I don't need a whole "exec quake.rc" -- just an "exec autoexec.cfg" which is a user-controlled file.

Uhh, when I was just going to look at the textures in DM6, I got that weird crash that Dr. Watson says is an access violation. I had not changed anything yet, and I was just using the standard id1 stuff, so it wasn't even my modified DM6.

You can see in the qconsole log that I had checked the values of developer and cl_autodemo, and they were both set, but I am not getting any autodemos. I've tested some more after that, and I am just not getting any autodemos.... They aren't appearing in id1 nor in my fvf folder when I run fvf.

Though I don't think they would have revealed anything about the crash anyway.... Here's the log file (I just started DX version in a window, started a single player game, then tried to switch to DM6 -- I THINK the same thing had happened to me earlier but that time I think I had started a new multiplayer game instead):

I can't reliably repeat the big. I go through the exact same steps again, and it loads fine.... 
Oh, and autodemos definitely used to work for me, before you disabled them by default. I went in and made sure to delete my previous autodemos in anticipation of recording the crash happening. 
re: quake.rc - just an "exec autoexec.cfg"

You haven't seen enough mods. A number of single player mods come with an autoexec.cfg, even though they shouldn't (one example among many, Once Up Atrocity .. which is awesome btw).

And they often contain things they should not. Example ...

gl_flashblend 0
r_shadows 0
scr_centertime 4
scr_printspeed 16
r_wateralpha 0.6
gl_subdivide_size 1024
r_maxsurfs 900
r_maxedges 2800

re: DX8 crash that occasionally occurs

cl_autodemo 1 needs host_maxfps set to 72 -- otherwise it won't record because the demo size could be massive and 72 fps is only correct Quake physics in single player. (todo: document that)

But yeah, I'd need the autodemo. Console log doesn't help. 
Still black video after setting xvid as the codec.

Here is what I am doing now to test:

-I made a quick 20 second demo called test.

-I run Mark V, capturedemo test

It runs the xvid encoder window, once it is finished Mark V tells me so. I exit the game, check the created .avi and I get black video with proper sounds.

I am running at 640x480 for this test. 
I'll do some testing on a variety of different machines sometime this week. And we'll see what turns up! 
re: DX8 crash under certain conditions

However, I looked at your console log and filling in my imagination with knowing your preferences ...

I have successfully recreated the crash I believe you are experiencing with the DX8 version twice.

/We'll see what's up. 
Ok, but what is the problem with having "things they should not" in the autoexec for a mod? If you ran the mod the standard way with -game mod, it would all happen.... and it will only apply to that mod, right? It's not going to alter your config files in id1 or anywhere else, is it?

If the mod author wants you to have weird settings when running his mod, and he includes an autoexec with those settings, what's the real problem? That's been a standard way of doing it for a long time. Alternately, you have to do a bunch of stuffcmds in the mod itself... but many mods don't do that, since the autoexec is easier. Heck, the good old Blabalicious Quake movie uses an autoexec.cfg to adjust your screen settings and start the demo playing.

Or maybe the mod creator included vispatched maps, and he wants you to be able to see through the water, so he included r_wateralpha .6 in the autoexec for the mod, which will get executed when people run the mod the standard way with -game mymod, sincve that's default Quake behavior.

But by using the "game mymod" command in the console, now the player will not have the mod-specific settings applied, so he probably won't be seeing the mod as the author intended (hope there aren't any important buttons hidden in shallow water...). And Blahbalicious won't play, heh.

For players who just have different keyboard configurations for different mods, they also expect the autoexec to run automatically for each different mod.

I'm just wondering why anyone would ever NOT want to do so? If for some reason they don't, they just do the default Quake thing of deleting the autoexec, or modifying it to their liking.

I guess I should just say that "game blah" should mimic the default Quake behavior of "-game blah" 
Ah, good -- the DX crash isn't just my old netbook then. Now here's hope for a fix. Nice. 
Strange things happen if you noclip out of the level that has mirrors: fps drops, you see a reflection of player in different places and some pieces of level. 
There's an issue with the Winquake version if you run in a window with the vertical resolution set the same as your screen height. Like if I run in an 800 x 600 window on my 1024 x 600 netbook. The HUD is chopped off at the bottom of the screen.
Something has crossed my mind about this: it feels like it should be normal Windows behavior. I never play in windowed mode so I'm not sure but it seems logical to me that setting a specific window resolution should work for the CONTENTS of the window, not for the window itself (that is, not counting the window's borders). If this is how Windows work, then it makes sense to have the bottom of the window chopped off. Is there a Windows expert around to confirm this? 
Some mods come with autoexecs in their PAK files. At that stage it's no longer possible for the user to control their own settings.

The intention of Quake is clear: default.cfg is for the mod defaults, config.cfg is for user-configurable stuff that is saved, autoexec.cfg is an override to both and can also contain stuff that's not saved.

Mod authors have in the past enforced their own preferences on users. You see video modes, key bindings, look-and-feel settings, all enforced in ways that users cannot control and on occasion even freely admitted as intentional by the author.

Not running the cfgs is an unfortunate compromise but seems the only sane thing to do. 
Mods using autoexec.cfg to store their settings is only somewhat standart-ish because some mod developers aren't aware of this file's real purpose. This is player's territory.

If you need to force something in your mod, modifying quake.rc is a much better option.

With this in mind, executing only autoexec.cfg is very selective. It's not even supposed to be the most important part of the settings, even if sometimes it is.

As for whether to execute things when changing the game dir mid-session, I think it only makes sense for the behavior to be consistent with what's going on during startup. If the settings are questionable - well, blame the mod author(s). 
The chosen resolution in windowed modes is for what's called the client area of the window, in other words excluding the title bar and borders. Quake on startup calls AdjustWindowRect to add on the size of the title bar and borders, getting the actual window size.

This has been the behaviour of WinQuake and GLQuake from the beginning and is expected behaviour.

So Quake is just doing what you asked it to do: Create a window with a client area of 600 high, which will get another 30 to 40 or so pixels added after AdjustWindowRect, which will then push the status bar off screen.

The solution is to ask it for a smaller window. 
MH for the win. Read his post carefully. Some mods come with autoexec.cfg in pak files and such.

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.


@ Gunter I'll soon be updating the version to build #1001 --- I believe will fix your DX8 issue. It only happened when a dynamic light was active, some lightmap fields needed cleared on map change. The DX8 wrapper reacted very negatively without those fields cleared. 
You're still executing these "toxic" settings during startup. So I'm not sure what's being achieved here. 
Little Bug 
after disabling smoothing in the preferences and restarting the game, lerp reverts to default though smoothstairs remains off. Currently using lerpmodels/move 0 in an autoxec as a workaround (which is fine, since I want smoothstairs on, anyway).

Really sweet port, getting my retro fix! 
anyway to disable/adjust mips in the winquake fork? Using pixel quadrupling and the next mip level gets drawn when you're pretty close to the surface; it's a tad ugly/jarring.

again, minor gripes. I really am enjoying this port :D 
Addressed that in upcoming build.

@dwere -- If I want to play something, I start up Quake and do "game warpspasm -quoth". And then start playing ... (the mods quake.rc or autoexec.cfg is never run).

@killpixel +10. And just at the right time too! 
I understand what you say. I implemented what was easiest to do for approximate scaling solution in WinQuake build (stretch).

But yeah, I'd like to have full resolution pixels + scaled 320x240 or 640x480 HUD/Menu at same time --- but would take 3 weeks to write so ...

... maybe in the future.

/But notice it is separate option from GL Build automatic HUD scaling. Tells you I feel how you feel. 
Yeah, just as dwere said, I was going to point out that you are still running those files when mods are started by the standard, age-old method of "-game blah."

If a mod mod comes with an autoexec, generally it is is "part of the mod" that should be ran for the mod to function (as the author wanted). Of course, there can be "bad behaviors" from this, but any part of a mod is subject to such problems.

Though I suppose true "player in control of his settings" would allow a player to choose if he WANTS to disable the default Quake behavior of running an autoexec.cfg when starting a mod.... 
Build 1001 
Build 1001

Same place as usual

1) DX8 build intermittent crash due to dynamic lights fixed (gunter)
2) Mirrors + noclip outside world slow fix (pulsar)
3) r_lerpmove/r_lerpmodels preference now saves (killpixel)

/Typing "version" in the console will show as build 1001. 
... maybe in the future.

Looking forward to it (maybe). In the meantime, this will do just fine!

But yeah, I'd like to have full resolution pixels + scaled 320x240 or 640x480 HUD/Menu at same time --- but would take 3 weeks to write so

Actually, I use the scaling because I like the look, not because I need larger hud/menu. Though, controlling those independently would be nice.

On that note, perhaps you could clarify something: I noticed that scaled pixels are square, meaning they aren't stretched to a different aspect ratio. So, when choosing scaling (320x240 or 640x480) it uses a constrained resolution/ratio that is closest to those listed resolutions? In other words, when using a 1920x180 display, your effective resolution when using scaling is 960x540 or 480x270? If this is the case, maybe it would be more clear to list the option as pixel doubling/quadrupling?

Ok, no more nitpicking, I feel like I'm sending the wrong message.

I'm off to play pixel quake... 
It was called vid_stretch in WinQuake so that's what I went with as the name. It finds the best multiple that comes closet to either 320x240 or 640x480 ... and goes with that number for stretch factor. 
Though I suppose true "player in control of his settings" would allow a player to choose if he WANTS to disable the default Quake behavior of running an autoexec.cfg when starting a mod....

Well, technically, you're in control now. You can "game gamedir" without executing anything, or you can "game gamedir" and then "exec quake.rc" after that.

Or "exec autoexec.cfg" if you know for sure that all you need is there. Executing quake.rc has a side effect of stuffcmds. 
i see. Thanks baker! 
Typical my you can divide Quake players into two broad categories: Those who know the inner workings of the game, and those who don't.

Those who know might start the game with command-line options, load new games with -game via batch files, and - crucially - will also have sufficient knowledge to deal with a rogue .cfg file.

Those who don't, won't.

There are more of the latter than the former, and this stuff is a barrier to entry. Hit one of those people with a rogue .cfg file that tries to set a bad video mode on their machine, or overwrites their keybindings, and what are they going to do?

This isn't theoretical talk either. These are real problems that real people face. Have a look at the QuakeOne or Steam or Bethesda forums - there are people who have trouble getting an engine or mod into the right directory.

These people are why the Quake Injector exists, they're why people like Spirit goes nuts if a mod is released with configs, and they're why unfortunate behaviours like not execcing configs on a game change exist too.

I would love to see it happen too. But because of rogue configs, having it not happen is the lesser evil.

After all: You are not representative of the typical Quake player. 
More LIT/VIS Files 
Here are a few more .lit/.vis PAKs to use with some Quake addons for colored lights and transparent water.

LIT/VIS for Abyss of Pandemonium, Malice & Shrak (ZIP, 16.6 MB)

LIT/VIS for Dimension of the Past, Nehahra & Travail (ZIP, 23.7 MB)

May they serve you well while exploring the power of Mark V! 
It seems "window02_1" defaulted as being a mirrored texture?

IIRC that's leftover from Carmack's original glquake as a hack to play with mirrored surfaces, but maybe shouldn't still be in the engine? I mean, if we're going to just have "mirror_" be an identifier for mirrors, maybe just stick with just those and not also include a separate other texture Carmack picked long ago. 
Yeah, defaulted as an homage to the original GLQuake release (0.95? 0.98? I can't recall which one.).

You can turn it off. Set r_texprefix_mirror "" and it's done.

Now that I think of it, that needs to save to config so someone can turn it off. 
Possible Enhancement Of Setmusic Cmd 
As far as I can see, only the stained glass window in the intro map will turn into a mirror automatically. I dunno how to change the other windows.

A potential feature request:
In the old Mark V thread, Baker mentioned a setmusic.cfg which allows music tracks to be remapped. I was wondering if it could be enhanced so that it also works for specific maps, like setmusic <map name> <track name>.
Why I am asking for this: There are some addons in which authors erroneously use track01 in their levels (which doesn't exist). With an external cfg file which is automatically parsed, it would be possible to fix such glitches without having to mess with the map files. (There are more ways to use this, just pointing out one of them.) 
Throwing this out here, not sure if it is a thing or not.

Sound seems to have noisy feedback on louder noises (Grenade, lots of monsters attacking at once.) I thought this was from the audio set at 11k (I realize that may be Quake default) but is there a way to change it? I tried changing sndspeed to 41k and it sounded like the audio matched what QS detects but it just sounds more hollow.

I'm more really asking because QS does not have this audio noise issue whatsoever. 
There are some addons in which authors erroneously use track01 in their levels (which doesn't exist). With an external cfg file which is automatically parsed, it would be possible to fix such glitches without having to mess with the map files.
...Or you could add an extra track01 to your music folder? Perhaps one from NIN's Ghosts I-IV, or something entirely different if you want. 
Maybe, But... 
... then it would always play the same track since all maps are set to track01. What I would want is to make all maps use different tracks... 
You can put a map in a folder like a mod and add its own music subfolder. 
Not Just The Intro Map 
I know an Arcane Dimensions map built by a very handsome young lad that has random mirrors in it now because of the feature "texures specifically named 'mirror_*' are mirrors... and arbitrarily 'window02_1' as well"

I'll just recompile the damn thing with the texture renamed I guess. 
oh, in less salty feedback on mirrors, may want to consider doing some sort of fade effect when a mirror becomes active? The pop in when it switches between mirrored and non-mirrored can be quite noticeable. 
Sound Crackling 
I'm glad you pointed this out, I was beginning to doubt my own ears. There definitely is a kind of audio problem, a crackling like sound that you described. Quakespasm is fine now but had the exact same problem a couple of years ago, very annoying. 
Set The Alpha 
To something less mirrory like 0.6 
Of course I'm almost always going to push for keeping Quake's default behavior when that behavior isn't flawed, and in this case it is not -- it's just some mods that can be "flawed." Though you have to realize, the whole concept of running a mod is that you are handing over control to the modder to change a lot of default things.... But yeah, placing an autoexec in a pak file is really bad form, but how many mods is this actually an issue with?

In any case, I think as a minimum (mainly for "those who don't know the workings of Quake"), changing game directories should produce the same reminder text that Quakespasm does:

'enter "exec quake.rc" to load new configs.' 
Regarding Waterwarp Effect 
Mh had actually already pointed out some options regarding how to pull off the original underwater warping effect in the old Mark V thread back in 2012.
I dunno if all of his suggestions turned out to be impossible to implement, but maybe they deserve a second look.

(I know, I am kinda nagging with this, but it's one of the very few things that Mark V could still do better. :P) 
if switching gamedirs results in a different quake.rc, default.cfg, config.cfg, or autoexec.cfg file, then save the config, then (effectively) switch the gamedir, reset all cvars to their defaults and exec the new quake.rc. when saving configs always save to the same location as the shallowest of those 4 files.

mods that fuck up your config to enable things that increase sw-rendering capacities will still apply for the new gamedir, but will not be able to affect other gamedirs any more thanks to the reset thing.

the mod will still pick up your normal config.cfg the first time you run it, but thanks to it declaring itself as a special snowflake, further changes to your regular config.cfg won't continue to impact it, and vice versa.
if a mod wants/needs to be special, let it. and if its just a map pack then it really shouldn't need to have its own config file either.

that's how fte handles it, except without the auto-saving-your-config part, because that's considered an explicit action in most quakeworld engines.
that said there are still some things that I could improve... like userinfo changes spamming the server. :s 
Did You Guys See This Tweet That Scarecrow Retweeted?

I want to see what mankrip and spike can do with this effect =D 
Serious Sam did that well, I really enjoy that effect.

I think killpixel was showing some of that type of stuff in the screenshot thread? 
I Ran Thru This Thread 
Is autodemo disabled by default in the latest version? 

@Baker "cl_autodemo 1 needs host_maxfps set to 72 -- otherwise it won't record because the demo size could be massive and 72 fps is only correct Quake physics in single player. (todo: document that)"

But what would be the problem if you have a lower FPS set, as I do (and probably anyone else who uses vid_vsync)? Sure, physics might be wonky in Single Player, but... that's not exactly a reason to prevent autodemos if the user wants them, at a lower FPS.

I'm playing with zoom aliases now. I think r_viewmodel_fov should default to 0 (standard Quake behavior) rather than 90. Yeah, it improves the look if someone sets a higher fov, but it makes it look weird when you zoom in with a lower fov.

Standard Quake is the opposite, looking correct when you zoom in but bad when you set a high fov.

So, I prefer standard Quake behavior, especially when I have set "weapon draw = quake default" in the menu.

An optimal way to do this might be to have 2 separate variables:


Then you could set the max at 90 to never get the weird effect when zoomed out, but the viewmodel would still be allowed to be pulled back when you zoom in (which looks correct).. unless you wanted to clamp that too with the min setting to not go below. 
@scampie - Re;mirrors 
I'll make the cvar that control "window02_1" only apply to the id1 folder.

I'm hardcore and already had realized that even as a setting it would default on for people using -game. 
Autodemo By Deafult Was Nice Feature 
maybe you can bring it to the preferences in menu? 
72 Fps 
Weird, I always set fps to 150. Monitor is 144hz though, need that max fps 
I know which mappers reside in Asgard and know you are one of them, I've read this site regularly and know, for example, you used to run the speed mapping session.

Let me assure you that if for instance that if you have something to say, I am always listening.

I'm a very conservative engine developer despite also adding player-oriented features.

When I started engine coding, Ben Jardrup helped me several times and would explain the compatibility mindset to me. 
100 Fps 

I never encountered any physic issues so I just kept it at my max refresh. :O 
The Framerate Physics Stuff 
I'm quite interested in why the framerate changes the physics. I wonder if it is the physics stuff being calculated every frame, rather than every 1/72nd of a second.

If that is the case is it worth trying to keep the framerate at a multiple of 72 to be safe? (144 if your monitor can do it). 
@pulsar, Bloughsburg, Gunter, Fifth, Nightfright 
autodemo -- pulsar, I'll spend some time thinking about right way to handle to.

sound 44000 - bloughsburg, I remember some of the sound mixing discussions about that. I'm adding that to my list and will eventually happen.

@fifth - Not sure what you are wanting. Quake physics are still 72 fps and although fps independent physics is on my eventual to-do list. If you set 144 hz in your video card and vid_vsync 1 and host_maxfps 144 in the console, do things work as expected?

@gunter - at a higher fps, the demo files could become huge. Maybe make cl_autodemo 2 option -- record an autodemo regardless of the fps. gun fov 90 -- people love the feature, you know how to disable it.

@nightfright - at least for now, Mark V is a pure Open GL 1.2 engine for maximum hardware compatibility for any machine Windows XP or higher. MH needed a glsl for that in Remake Quake engine.

The track by mapname thing, I will think about and have an idea on a "correct solution" which would give you the same ability to control it but does not work in a way similar to what to you suggest, but I would need to put some thought into it so is more likely a future version item.

@nightfright part 2 ---

I'd recommend creating a Wiki page at listing extra replacement content paks and I'll put a link to that page on the Mark V page -- that way if new content becomes available it can be updated and available to users without me continually editing the Mark V homepage.

Be sure to upload mod enhancements to Quaketastic (see Func screenshots thread for username, password if you don't already know) beause Quaketastic files are preserved forever at the Amazon/Government funded site (!!)

/I think that's most of the replies, I read Spike's thoughts on gamedir change and @snaut yeah that's cool. 
I've always thought that the engine ought to be able to cap the framerate of the demo independently of the actual client framerate -- When I recorded demos for rubicon 2 I intentionally set host_maxfps really low to get a smaller demo file, but it would be nice if it was an automatic feature.

But, I never did the research into what kind of problems would have to be dealt with to make the demo playback correctly. For example obviously the dropped frames might have important events in them, you'd need to save them and put them in the next demo frame so they are not lost. 
Spike actually has a separate thread (or similar) in FTE to ensure 72 fps even if the client goes under 72 fps.

In 2014, I made a run at acquiring DirectQ's fps independent framerate, but noticed a little jerk in DirectQ when using +turnleft and +forward at same time -- so I moved it to the back of the queue for future consideration. 
I suspect Spike might suggest that the best to get such a result might be having the "server" record the demo instead of the "client" --- in a properly client/server separated engine (like how the Quakeworld engines have complete client/server separation). 
Never knew it affected demo filesize. I always play at 144 fps and never noticed any bugs 
two things:
1) use a decent network protocol that doesn't resend everything every single packet. get AD's particles under control by harassing sock into using clientside stuff instead of network abuse.
2) screw threads, just don't send packets to the server quite so often. from what I remember the only real challenge is figuring out how to deal with impulse;wait;impulse scripts. one way is to just not wake up from waits while connected with an impulse still pending. obviously if there's any hacks internally directly linking both client+server then you'll need to fix them, otherwise independant rendering/server isn't really any different from a public server or demo. drop the server's rate to 10hz and you'll get quake2! 
Yes to all of that ;-)

Btw, offhand do you know about about the bloughsburg/zbikey sound crackle @ 44 hz. I don't touch the sound mixer often -- and such a conversation wasn't recent so I can't recall the details immediatelly. Is that the true hz is 48k issue? 
@spike also -- while I'm thinking about this -- your single port rewire of reading messages -- I haven't investigated so is probably non-issue, but in my head I was thinking "make sure that can't skip a player impulse". I think QSS queues up +jump and such.

/Again, haven't had time to focused on deep examination of that, so quite possible I'd see something obvious that I'm not thinking of at the moment. 
I have no audio crackling / distortion, everything sounds fine for me.

Those who are having glitched audio, might help track down the problem if you type 'condump', and paste this section from your id1/condump.txt:
Sound Initialization
Set primary sound buffer format: yes
Using secondary sound buffer
2 channel(s)
16 bits/sample
11025 bytes/sec
DirectSound initialized
Audio: 16 bit, stereo, 11025 Hz
Sound sampling rate: 11025

Also - congrats on the release, Baker :) 
Thanks ericw! At more than one point, didn't think it would ever happen. 
qss's single-socket stuff just switches from looping through each connection and then handling the messages to checking the socket(s - ipv4+ipv6+ipx) and then parsing them within the context of the player with the same remote address.
there's no extra buffering there that wasn't already there, certainly not in the client-side stuff. inputs are handled the same way as they always were.

if you're getting crackles mid-sound then rewrite your resampler. resampling 44->48khz will probably screw up the waveform if you have 44khz frequencies. most people can't hear those anyway.
be aware that the vanilla resampler uses 'nearest filtering', which has somewhat obvious deficiencies...
on the other hand, pops when you override another sound could be fixed with a gradual fade-out instead of suddenly dropping down to 0. 
Count me as another person who is very glad this release happened, and it happened now instead of later in 2017!

"gun fov 90 -- people love the feature"

Well, people love lots of things, but that doesn't mean Quake's default should change, heh. I mean, lots of people probably love r_viewmodel_ring 1, but it's defaulted off....

From looking at the old thread, the people who are using r_viewmodel_fov are not using your default value anyway.... They are using 110 or 130.

And of course, they are using it when setting a higher fov. It's good for that. I like it for that too. Too bad it doesn't work ONLY for that.... Lower fov's make it weird.

So yeah, I'll disable it. I have a section in my fitzquake.cfg file for "Restore Quake Defaults." The section is actually not too long (about 7 behaviors), which is a very good thing. But I'd be more happy if it was completely unnecessary to restore any Quake defaults!

Now, it's not always bad to change a default, but you have to be certain there is definitely no negative impact from the change.

For example, I couldn't see any negative impact of defaulting r_viewmodel_ring 1. It's a cool setting, and everyone should use it... but I would never actually argue for making it a default... because it's not Quake's default! Heh. But of course, I would't mind if it was made default either, unless some unforeseen negative impact arose.

Of course, sometimes the "negative impact" is simply that it doesn't look the way people are used to, and they don't like that... sooo... in the end (as you say), you gotta be really conservative about changing defaults. Err on the side of caution. 
Last Remaining Unacquired JoeQuake Feature Coming 
In this engine, one thing I've tried to do is absorb as much of the feature set from other engines with great contributions that aren't developed any longer like Enhanced GLQuake/WinQuake, ProQuake, JoeQuake.

But it is currently lacking one of the most prominent features of JoeQuake as an option (will off by default), which are the optional particle effects system (QMB particle system by Dr. Labman).

It'll need some rigorous testing when it's available in a few hours. 
Rigorous is my middle name.

Well, not literally. That would require some really weird parents.... 
Sound Dump 
Here you go! This is with me changing sndspeed to 44100

Sound Initialization
Set primary sound buffer format: yes
Using secondary sound buffer
2 channel(s)
16 bits/sample
44100 bytes/sec
DirectSound initialized
Audio: 16 bit, stereo, 44100 Hz
Sound sampling rate: 44100 
QS Dump 
Oops, and here is QS:

Sound Initialization
SDL audio spec : 44100 Hz, 1024 samples, 2 channels
SDL audio driver: dsound, 65536 bytes buffer
Audio: 16 bit, stereo, 44100 Hz 
Is there any feature left in ProQuake still that hasn't been subsumed by Mark V? 
ProQuake / JoeQuake / Enhanced GLQuake Comparison 
I'm just going off current memory.

ProQuake + JoeQuake in Mark V
1) Ping in scoreboard.
2) ProQuake enhanced client
3) ProQuake enhanced server *limited* to Spiked Quakespasm levels due to acquiring QSS single port server capability.
4) ProQuake 16-bit aim available under protocol 15. (Spiked Quakespasm has this too).

1) Mark V downloads depot http download missing maps, sounds, models when connected to ProQuake or DarkPlaces server, but not when a Mark V server or Spiked Quakespasm server.

(* because Mark V is likely to have in the future peer-to-peer TCP/IP transfer of "gamepacks" -- think "" due to conversations with Spike on how to do download right. On a LAN in particular, transferring "" (83 MB) happens in the blink of an eye. Since Spike has already written .pk3 support for QSS, and since .zip and .pk3 are same thing ... it is also likely in future Mark V will never decompress a Quaddicted download at all.)

And has all other ProQuake features except ..

2) Does not have ProQuake iplogging (check to see someone if someone is imposter). Not compatible with IPv6.
3) Cannot run ProQuake QCCX mods.
4) Typing matrix in console displays a Matrix movie full screen character effect.

1) Mark V has .dz playback built-in even on Mac, does not require any extra dzip.exe or anything. (Speed Demos Archive speed runs)
2) Mark V Has scr_showspeed - display speed on screen.
3) Will have QMB particle system tonight
4) Doesn't have cl_bobbing (items can bounce up and down)

Enhanced GLQuake/WinQuake
1) Mark V should be able to play Q-Rally with sv_gameplayfix_setmodelrealbox 0. Maybe other rare (Spike says poorly coded) old stuff that needs it.
2) Mark V can read protocol 10002, allowing Mark V to play Warpspasm start demos.
3) Mark V, developer 2 displays extra warnings from that engine.
4) Mark V does not support 32 or 64 player scoreboard.
5) Mark V does support sprite32, even in WinQuake version.
6) Obv, Mark V can play Nehahra.
7) Mark V, unlike other FitzQuake forks except Spiked Quakespasm, can serve protocol 15 game. 
Zoom Zoom! 
I really like the manipulation of console variables via mul, valsave, valload....

Here are my newly Mark V-enhanced zoom aliases, for anyone who wants to try them.

The mouse wheel zoom is my favorite -- you can zoom in and out to different levels (even out to chase mode) with the mouse wheel. I've used it for a long time, but now it is better due to being able to save any fov before messing with it, and use math to change the sensitivity. If someone wanted to expand on this, you could make even more zoom steps, or even more zoom steps backward in chase mode with chase_back values.

(to use these, you'd want to paste them in a .cfg file to exec)

// mouse wheel zoom

alias zoom_out_full "mul sensitivity 2; bind mwheelup zoom_in_half; bind mwheeldown zoom_back; fov 50;wait;fov 70;wait;valload fov 1"
alias zoom_out_half "mul sensitivity 2; bind mwheelup zoom_in_full; bind mwheeldown zoom_out_full; fov 20;wait;fov 30"

alias zoom_in_half "mul sensitivity 0.5; bind mwheelup zoom_in_full; bind mwheeldown zoom_out_full; valsave fov 1;fov 70;wait;fov 50;wait;fov 30"
alias zoom_in_full "mul sensitivity 0.5; bind mwheelup wait; bind mwheeldown zoom_out_half; fov 20;wait;fov 10"

alias zoom_back "chase_active 1; bind mwheelup zoom_standard; bind mwheeldown wait"
alias zoom_standard "chase_active 0; bind mwheelup zoom_in_half; bind mwheeldown zoom_back"


Here is a single-key solution that still allows different zoom levels. Sometimes you may not want to zoom in ALL the way, right up the monster's nose. With this you get an alternating zoom level each time you press the key.

// single-key multi zoom

alias rekey1 "bind r +zoom1"
alias rekey2 "bind r +zoom2"
alias +zoom1 "mul sensitivity 0.5; valsave fov 1; fov 70;wait;fov 50;wait;fov 30"
alias -zoom1 "mul sensitivity 2; fov 50;wait;fov 70;wait;valload fov 1; rekey2"
alias +zoom2 "mul sensitivity 0.25; fov 70;wait;fov 50;wait;fov 30;wait;fov 20;wait;fov 10"
alias -zoom2 "mul sensitivity 4; fov 20;wait;fov 30;wait;fov 50;wait;fov 70;wait;valload fov 1; rekey1"


Baker, your +zoom_key alias is rather non-optimized. There is no need to change the sensitivity with each step of the zoom (it all happens so fast, only the beginning and end sensitivity matters). And actually there's no need to save and load the sensitivity value at all -- you can just use the math to change it and restore it (X * 0.1 * 10 = original value).

And there's really no need to use math on the fov for each middle step of the zoom either -- those steps are just there to provide an animation for the zoom effect, so they work fine at set values. Again, only the beginning and end values are important.

So if I may, this would be a much cleaner, optimized version of your +zoom_key:

alias +zoom_key "valsave fov 1; valsave r_viewmodel_fov 3; r_viewmodel_fov 0; mul sensitivity 0.1; fov 70; wait; fov 50; wait; fov 30; wait; fov 20; wait; fov 10"

alias -zoom_key "fov 20; wait; fov 30; wait; fov 50; wait; fov 70; wait; valload fov 1; valload r_viewmodel_fov 3; mul sensitivity 10" 
Add .. Mark V Vs. ProQuake Pt 2. 
1) Mark V does have ProQuake/JoeQuake/DarkPlaces bestweapon command .. bind x "bestweapon 8 5 4 3 2 1" ... will select best gun with ammo available.

2) Does not support pq_moveup (swim up as fast +moveup).

3) No ProQuake 4.93 server browser pressing F5, but instead Spiked Quakespasm server browser.

/Shorter version: For various reasons, Mark V won't likely appeal to most ProQuake users and almost all of them would probably stick with ProQuake because they aren't playing new single player releases and most probably only play dm3 24/7/365 or the start map or e1m7 in RuneQuake. 
Inherent Malice Problems 
Malice has items that modify the player's speed. One of them allows the player to go as fast as 600. Features of this kind are realized by modifying client settings (like cl_forwardspeed) every time an item is activated or deactivated, which leads to problems with savegames.

Perhaps what's more important is the way the mod sets sv_maxspeed to 600. I don't know why, but it does that at the beginning of each level, but not at the game startup. The symptom is: starting Malice and loading a savegame gets you a standart speed cap if 320.

My limited understanding suggests that an engine-side solution to a problem of this kind won't be pretty, but I thought I'd mention these anyway. 
Yeah, that isn't related to Mark V as I think you know.

They could have benefited from some of the things Preach has Quoth do upon save/load, but Quake was new and no one developed Preach's Quoth trickeries.

/Quake's save games don't actually save enough information. And never have. 
Capslock key not bindable? ("not a valid key")

Can it be?

I guess you might have to disable its standard function so that it's not actually setting Caps Lock every time someone used it. Just do that if it's actually bound, but if not, let it be standard Caps Lock.... Or just disable it completely. Who needs Caps Lock in Quake?

Hm, looks like Proquake just disables it... but... still won't let me bind it as a key ? 
Oh. Why is that? Is the CapsLock key just something Quake can't handle? I thought with all your extra keyboard code, it wouldn't be a problem.

It's a shame to have an unusable key right there next to WASD, where everyone's hand will be. 
Joking around aside, I spent quite a bit of time studying input API on various systems and in Windows. And with system methods and SDL input methods.

Caps Lock is a real PITA in a number of the above scenarios.

I don't want the input code as a nightmare when I go to do Mac or Linux, so I don't want any differences in the keys behaviors.

An analogy:

Mark V's GL and WinQuake and Direct3D builds are a breeze to maintain because it's common code for about everything.

... Unlike what original Quake did where they were very separate.

By having unified input code (which is tough) ... when I finally do Linux, for instance, I won't have to deal with a lot of irregularities. 
Well, Grumpy Cat makes any thread better.

One last report, then I retire to my crypt for the night.

scr_sbaralpha got borked at some point.

In DX, it just doesn't make the HUD transparent at all.

In GL, it does make the HUD transparent, but if the value is below 0.7, the console background becomes invisible.

I've been looking through the "find all" list. I notice pq_fullpitch is in there as "external server hint." Is that just so you don't get errant messages like "unknown command pq_fullpitch" when you connect to a server that makes the setting?

If that's the case.... When I connect to the FvF Proquake server, I get "unknown command cl_fullpitch." So could cl_fullpitch be added in there too? Very minor issue, really.... But It looks like Proquake has both those commands. 
I noticed the external texture sbar alpha thing with the dx build when I was trying to unravel your dx8 issue. The invisible HUD below 0.7 is probably due to alpha masking test 0.666 in FitzQuake. And cl_fullpitch thing bothers me some. I'll eventually address all 3 of those small little oddities. 
Door Unlocking/opening Sounds 
In Shrak v2.0, they also fixed an issue in vanilla Quake, and I am not sure if it is fixed in Mark V. From the Shrak readme:

"id included sounds for unlocking the door as well as the normal 'door opening' sound. But because the unlocking and the opening happened at exactly the same time, you never heard the unlocking sound." 
Software Quake Underwater Warp 
This probably got lost in the old thread, but it's perfectly possible to do in GL 1.2 and no shaders needed.

Draw the regular 3D view.

glCopyTex(Sub)Image it to a texture.

Then draw that texture back using a grid with warps at the vertices.

This is similar to stock Fitz/QS "framebuffer water warp" but kind of in reverse. It should even be possible to reuse much of the code, maybe tweaking some parameters.

Of course the larger texture size needed for this implies a higher GL version, but that never stopped people with external textures or skyboxes.

You can also hack something up by playing around with the projection matrix. In addition to the FQ stretch & squeeze, mix in some rotation. It can look good and it has minimal performance hit, but here you need to derive the frustum properly from the view and projection matrices rather than calculating it separately. IMO you should be doing that anyway, likewise with vpn/vright/vup, which also come straight out of these matrices. It's always good to clean up Quake's "calculate the same thing in different ways and in different places" crap. 
Sounds like a QuakeC game logic fix -- so it should work in an engine. 
That was @nightfright obviously 
Quick Question 
Could anyone confirm if stainmaps Quake default setting is OFF? 
Default Quake doesn't have stainmaps, so it is indeed OFF. 
+1 For Fixing The 0.666 Alphmasking BUG 
I fixed it in rubicon 2, the solution was to use a different channel for the second sound I think 
Created a page on the Quakewiki for external .vis and .lit packs, and put a link to that page on the Mark V page.

I separated out one (Abyss of Pandemonium) as an example and uploaded it to Quaketastic and put a link to it. See the first page in the Func "Screenshots" thread for the Quaketastic username and password.

This way new .vis and .lit content files can be added and updated. 
QMB Flame Test 
Video - Flames using QMB particle system

The QMB particle system is now working.

It'll be in the preferences menu and off by default. 
I have some extreme nitpickery to report.

Messing with the fullpitch stuff, I see that Mark V says these value mimic normal Quake:

cl_maxpitch -70
cl_minpitch 80

Buuut, they don't.
These values do:

cl_minpitch -69.93
cl_maxpitch 80.17

So it seems Mark V's pitch is very close to 0.17 lower than it should me.

How do I measure this? Well, start up a new multiplayer game, set gl_texturemode gl_nearest to get a nice sharp pixely look, and look all the way up or down. Looking down, set fov 30 or so and find a nice spot on the floor where you can mark your crosshair position. Do the same by looking up as far as you can with fov 10.

Repeating this (take screenshots if you like), you can see that in original Quake and Proquake, the position is identical, but in Mark V (and I think earlier Fitzqauke) it's off by a bit, unless you make the settings I posted.

Though neither of those cl_maxpitch values will be without issue when connecting to a Proquake server which disables fullpitch.

Upon connecting to FvF, for example, I find my value is altered to:

"cl_maxpitch" is "79.9969" (altered!)

Setting anything above that value causes the weirdness when you try to look all the way down and your view is jerked back to a legal value.

Though with the server sending the setting to me automatically, that's not really an issue.

On a less nitpicky note (though some will disagree!), this is one of those settings I have in the "Restore Quake Defaults" section of my MarkV.cfg file.

The Quake defaults should be respected and left as the defaults here. Fullpitch is for people who want an altered-from-default functionality.

Gosh darn it, back when I was a kid, we couldn't look all the way up and down, and WE LIKED IT THAT WAY!!


cl_minpitch -700
cl_maxpitch 800

Is pretty funny to play with! 
Original Pitch Limits 
You are very likely correct about the original pitch numbers because of how client/server read and write those numbers and various roundings that happen (floating point imprecision and conversion to integer types of various sizes).

I remember having to do some fighting with those numbers when test against servers that require original pitch limits or they will fix your angle for you, which is an unpleasant experience. 
I just noticed an interesting interaction between shadows and transparent water.

It looks like the water is being drawn on top of the shadow instead of the reverse. So if the r_wateralpha is 1, you don't see the shadow at all. If the r_wateralpha is .1 then you see the shadow pretty well with a very faint water surface on it, and r_wateralpha 0 makes the shadow fully dark (using r_shadows -1).

This may be related to the issue NightFright reported on #697 of the old thread (and that issue still occurs, by the way). 
Intermittent Lag Spikes (winquake) 
they seem to occur around every 30-60 seconds and last for about 3 seconds. the fps doesn't drop at all. It's like micro-stutter with input lag. I initially thought this had something to do with the seemingly random autosaving (didn't know winquake autosaved randomly until now) but loading the autosaves after a lag spike doesn't show a correlation.

this is on a relatively powerful pc (4970k, gtx980, ssd, etc). Still poking around for a solution... 
Shadows + water looks fine to me. screenshot.

Is this DX8 or a special circumstance or combination of settings? I believe you, but need more information or an example -- post a screenshot?

/Note: I expect to change r_shadows -1 to r_shadows 2 in next version. Follows more closely to the way other cvars work like r_lerpmodels (0,1,2) 
Are you using host_maxfps 72? 
No Sir 
144. going to test with 72.

im dumb.

Both GL and DX.

I think you are getting the shadow effect there, but it's not very noticeable because your shadow is fully in the water, and the area is dark. Notice you see the water texture on top of your shadow, but your shadow should be fully dark if you are using r_shadows -1

Stand somewhere so your shadow is partially over water and partially over solid ground, and alter the water alpha settings to 0, 1, and somewhere in between. Try the little square thin water place on e4m2 or just stand on the upper level of e1m3 so that your shadow overhangs the edge above the water.

Or the Start map, just stand so your shadow passes over one of the cracks in the floor with water below.

Uhhh... I wasn't going to post a screen because this should be easy to reproduce, but what the heck is happening here?

Some kind of anti-wallhack thing? sv_cullentities is 0. If I set gl_clear 1 then that area becomes grey. This in in DX. Looks like in GL, the area is grey even with gl_clear 0. 
Oh, chase_mode 1 is what's causing that weirdness.... I know that's an "experimental" feature... but that's an ugly effect, heh. 
Because Chase_mode Is Experimental And "for Fun" 
You are using chase_mode and I told you it was experimental ;-)

Sometimes chase_mode can't work perfectly for a few different seasons --- remember the thing about saying how complex camera code is in modern games?

In your screenshot, the camera and the player are in different visibility leafs.

The player can't see those walls, but your camera view point can.

Only one solution for you: Type r_novis 1 + sv_novis 1 and pay the price for the server sending 100% of all entities and the client-side just assuming every wall in the map can be seen. 
Yup, r_novis 1 clears it up. But I'm not leaving that on. Of course, normal chase_active 1 doesn't have the problem, but I like the neat feature of having my crosshair remain accurate in chase mode (that's all I really want), so I'll deal with the occasional ugly effect and keep using chase_mode 1. 
It can actually even happen with standard Quake chase_active with all default settings pretty rare.

Maybe at some point I'll do some sort way to make the crosshair appear in chase_mode. 
Feature tweak request:

If your bestweapon is currently selected, then have the bestweapon command switch to the next item in the list.


bestweapon 8 5 4 3 2

Normally this command will switch you to weapon 8 (assume you have it).

But if you have weapon 8 currently selected, have it switch you to weapon 5 instead (or 4 if you don't have 5, etc.).

Activating it again would switch you back to 8.

So effectively it will toggle between two weapons -- your best and second best, as you define.

In this example it lets you toggle between your two best close-range weapons. I would find this quite useful, and better than doing "nothing" if you already have your bestweapon selected. 
Gosh darn it, back when I was a kid, we couldn't look all the way up and down, and WE LIKED IT THAT WAY!!
No we didn't, it's always been annoying. 
if it's there, I'm having trouble detecting it at 72fps since it's a slideshow at that point.

I don't notice any physics issues at 144. I'll live with the lag if the fps increase is indeed the cause :/ 
This may or may not help you ...

What would be different about your powerful machine that would make it have an input lag issue that doesn't appear on far lesser hardware?

I mean Mark V --- even the WinQuake version -- runs great on some real clunkers.

Try running on a different computer. Then think about yours.

In my experience, people who beastly machines usually over-configure something.

/If you ever do figure it out, let me know. 
@kp --- Add ... 
Mark V does simple Windows input just like Notepad (no kidding). Doesn't even do DirectInput. Did you have something "amped up" going on with your mouse, or really fancy settings for your mouse or set a polling rate or anything.

/I hope whatever it is comes to light. 
@kp - Part 3 
A cursory check -- the Windows message queue appears to holds 10,000 messages, according to what I found on stackoverflow.

I don't know what your mouse polling rate is, but if it is set real high, it is possible your mouse might be overflowing the Windows message queue.

Which according to these sources, would stall it. 
killpixel, I don't suppose you are using skyboxes? If so, try disabling them. I am playing with the GL version and getting reproducible stutters when using skyboxes, but there are other settings or something involved which I am trying to nail down....

Here's what I do to reproduce the stuttering: In a new instance of GL, single player, go to e4m5 (notarget), load a skybox, walk down the hall and turn right and walk out to the nails, it stutters in up to 4 spots (the same spots), I think as each section of the skybox loads.

It happens every time with my full setup running (from my FvF folder), but I can't get it to happen reliably when running clean out of id1.
I'll try to narrow it down....

Also: GL + fog 0.025 + r_skyfog 0.05 is being wonky for me. Not all maps and positions, but I think I can see the seems in the skybox appearing sometimes:

I was getting some weirdness in the upper level of the sky even with skyboxes disabled too, again when the fog settings were on. GL version only. 
Your link is broke, btw.

you are using skyboxes

Nope. I play with classic sky 24/7/365. Unless --- the map sets a skybox.

Note: r_skyfog 0.05 isn't so much for users to play with, but rather so mappers can tune the appearance of how they want the fog to look in the maps they are building.

Common values are 0, 0.25, 0.5, .75, 1 and really if you are using something much different than those values it wasn't designed for that.

I don't know what r_skybox 0.05 would look like, but it is an illogical value to set because someone would basically be using 0. So just use 0. 
Your link is broke, btw.
No it's not, I've just viewed it fine. 
/kp (killingpixels) is using WinQuake version btw. He likes pixels ;-)

@gunter ---

Just tried your E4M5 setup.

Since it shows so much sky -- and maybe you are using fog --- with your netbook that area is going to be a performance challenge.

Even worse, because if you are using the Open GL version, it's going to stencil draw the sky and I suspect your netbook is going to hate that with a huge amount of sky drawing. The DX8 version doesn't support stencil, will be much faster. You could add -nostencil to the OpenGL command line.

I don't know what size skybox you are using, 512x512 ? 1024 x 1024. But by comparison, the Quake sky textures are 256 x 128.

So you have a special scenario and combination of settings that are going to be particularly rough on that netbook in that area. 
thanks for the ideas, baker. currently looking into anything I can think of.

I run a very lean setup that is judiciously (neurotically) tuned. Without going into detail, its not an infamous xxxgamerkid rig. However, that doesn't mean I haven't missed something.

My current polling rate is 500hz, I'll experiment with lowering it. I'll also see how it runs on my laptop.

I have a suspicion it might be my keyboard. Last week, I took a gulp of water that had a beetle in it and ending up soaking my keyboard. Sometimes some keys will register multiple hits. I wonder if it's sending some sort of input/signal I'm not seeing.

@gunter - thanks for the ideas. the quake setup is 100% vanilla. I'll probably even disable music to see if that changes anything. 
I took a gulp of water that had a beetle in it and ending up soaking my keyboard

You should have eaten the beetle. Good source of nutrients!

In countries where nobody wears clothes, they might even argue over who gets a tasty beetle!

Besides, by eating the beetle you are exerting your dominance over the rest of the food chain -- and sending a clear message to any other beetles observing. 
-nostencil does fix the weird sky glitch that I was trying to post a picture of. Yeah, imgur seems to have developed a DNS problem shortly after I uploaded that image -- I can't access the site at all, but apparently some people can. The glitch I was talking about is easy to produce at the start of e4m7 with skybox + fog + skyfog with any values set other than 0.

However, -nostencil doesn't get rid of the stuttering. I can reproduce the stutter on e1m1 too.

Also... Single Player -> Levels -> Select a level, does not reset variables such as Deathmatch, as happens if I instead select "New Game." Maybe it should, since this is the Single Player menu?

And... I think r_mirroralpha should default to 1 ("off"). It's a fun thing to play with, but can cause a performance decrease (pretty significant in my case).

It looks like I'll be sticking with the DX version anyway, as it performs better for me. 
Beetles aren't the kind of bugs I like finding.

Maybe the spirit of the beetle is haunting you now and causing the problems.

Think about it -- to him that cup of water is like a well he fell down and drown... just like The Ring! 
Mark V - Build 1002 
Download same place as usual

No QMB option just yet.

New Feature - Not fond of ...

1) Typing cvar without value in console shows help.
2) This can be turned off "con_verbose 0" (saves to config, of course)

I don't like it printing help because I prefer lean and mean console. And some of the descriptions are too long for my liking (short is best). However, someone who does not know too much about Quake it will help.

People that don't like it (me) can turn it off. Plus once someone has things setup, you aren't doing that often anyway.

New features

1) Mirrors only to Quake (gamedir id1) or intended map (*). (scampie)
2) cl_truelightning. Eliminate lightning beam "stutter". Defaults on.
3) Type cvar in console, show defaults value too.
4) r_shadows 2 is dark shadow.
5) Random rarely used cvars from JoeQuake/ProQuake added (cl_item_bobbing, pq_moveup) for thoroughness.
6) cl_autodemo 2 = autodemo no matter the fps
7) If recording demo, pressing TAB shows name in top left.
8) Slightly better "read settings very early" behavior.

I'm hoping #6 and #7 somewhat addresses the change in cl_autodemo to off by default by those who prefer this feature always on (pulsar, fifth, etc.). On a healthy computer and 72 fps, recording a demo is not exactly taxing behavior -- people have recorded demos while playing since 1996.

* Worldspawn key "mirroralpha" "0.5" for example causes textures prefixed "mirror_" to have mirror effect. Setting r_mirroralpha 1, turns off mirroralpha.

/Typing "version" in the console will show as build 1002. 
Baker, Ahoy 
Could you add the teamplay scores to the scoreboard sheet
there is an ancient engine by tonic(?)glsq.exe
that actually does this thing(very handy when playing vs frogbots)

at this moment that engine refuse to run on my current rig , so there's no example screenies 
I think I like the con_verbose 1 (information is good), but I would really suggest reversing the order of what is printed; when someone types just a cvar in the console, they are wanting to get its current value of the cvar. So the current value should be the last thing printed, because your eye automatically goes to the last thing printed in the console when you are looking for the output of your request.

I do not like cl_truelighting. In fact, I think I GREATLY dislike it, heh. The lighting gun does not fire in a constant stream like a water hose; it fires in rapid pulses, like a lot of separate lighting strikes. This effect makes your visual indicator inaccurate and misleading. This may make a bigger difference online, but test it for yourself in single player by setting your host_timescale 0.1
You can now clearly see that your lighting bolt fires in pulses; the sound effect is now spaced out so you can clearly recognize this -- the stain maps on the wall also will demonstrate clearly where you are actually hitting. The sounds and stains will line up exactly with where you see the bolt strike if you have cl_truelighting 0. this is the correct effect -- the lighting gun fires in rapid pulses. But if you have cl_trulighting 1, you only see a "laser beam" effect of where your gun is pointing rather than the actual beam that is hitting the wall, when and where it is actually striking. So... "true lightning" is actually "false lighting."

I have no use for this deceptive effect. Throw it away, or disable it by default! heh

Disable it by default, and if someone tries to enable it, print a warning, "Are you SURE you want to enable this awful, deceptive effect??"

Hey killpixel, have you tried the GL or DX versions to see if you get the lag spikes in those versions?

You can change settings in them to make them look all pixely too, like:

gl_texturemode gl_nearest

and other stuff....

Uhhh, Baker, I know you're messing with particles... it seems the Grenade and Rocket Launcher have lost their particle explosions.

And my Fvf chat bind is no longer working for the ` key when I bring down the console.

I use:

bind ` "impulse 39;toggleconsole"

bindlist shows it is still set, but it doesn't seem to trigger the impulse. If I bind another key to that, like "w" then it works as usual. 
in the quakeworld community, truelightning is otherwise known as fakeshaft.
and it breaks mods, so should normally be disabled by default if you care about maps+mods rather than trying to be a replacement proquake.
assuming baker implemented this too, try a fractional value. that should smooth it a bit while retaining a bit of its snappyness so you can still sync it up. 
Spike - That's Just 5 Types Of Wrong 
cl_truelightning was written by Joszef, the author of JoeQuake -- the engine used by speed runners.

It just uses the player origin as the starting point.

It sure as hell doesn't break mods, doesn't support fractional values, isn't server side.
And it existed long before anyone in QW ever made such a thing. 
I can't add teamplay scores to the frogbots scoreboard in the engine because it requires QuakeC support. However, since you've modified the frogbots source yourself, you may be able to implement this in the mod by examining the only open source mod that I know of that leverages the feature source code.

/Contrary to impression some people get, my QuakeC skills are about cut-and-paste newbie level except I can see function operations from the engine side and I mentally have a catalog of modifications and what releases do what.

@gunter - kp wants the real deal, he likes the software Quake look. He knows about GLQuake texture filtering command.

@Spike - p.s.: guess which engine does not have such a feature -- it's modern ProQuake. I was a beta tester for JoeQuake, I sure knew about the feature. I've always considered truelightning a single player visual enhancement.

Hence, gunter who plays co-op online is the only person who will complain about truelightning, that's the only time you wouldn't want the effect.

It's like animation smoothing for the lightning gun. 
it's just depends of the color of given team,

the red team gives its own score points and so on

not related to fb(qc whatever) at all 
re: RL Particles -- I'm on it. I was going to try to get a 2nd update in about an hour after that one. Thanks for heads up.

re: toggleconsole ... With international keyboard support, binding to the USA tilde key has no effect.

It is now key placement specific behavior hard-wired in the engine to support that the key below ESC activates the console no matter if the keyboard is German, French or Brazilian. 
You should have eaten the beetle. Good source of nutrients!

hindsight is 20/20... next time

@gunter - yeah, I've tried the other versions, but only briefly. I will revisit that.

My quakespasm setup is as you suggest. However, Mark V has two key features: indexed colors and resolution scaling. That aesthetic is my jam! 
Ah, I see. At some point, I'll look at the frogbots mod and see if I can causes it emit teamscores to achieve what you want, but using what I consider the "correct design" way.

I like knowing the team score. Admittedly, when I am playing frogbots, I'm generally playing free-for-all style, so didn't think of your idea. 
i'm aware of thr team x leads by x frags 
i'm gonna resurrect my old rig to give you a clearly view of my desired wishes

thanks for your reply 
/Contrary to impression some people get, my QuakeC skills are about cut-and-paste newbie
level except I can see function operations from the engine side and I mentally have a catalog of modifications and what releases do what.

Mister B, you're underestimate yourselves and your skills 
"true"lighting -- actually, playing coop online won't be the only time I'd complain about it, heh -- it feels wrong in single player too. It is NOT the same as animation smoothing -- you are drawing the actual "projectile" that comes out of the lighting gun *in the wrong place*. I can tell this even in single player, and it feels wrong and fake, like I know that lighting bolt is a harmless illusion instead of an actual bolt that is striking where it appears to strike. The bolt just doesn't feel "real" anymore -- like real electricity is a series of rapid flashes, not a steady laser point beam.

though I do wonder how it could possibly "break mods..." unless slow motion was in play or something.

toggleconsole/international keyboard -- err... this breaks compatibility then. Can it be disabled?

New report -- during the "congratulations" screens, pressing TAB causes the text to disappear, but not the "congratulations" banner (this is in "DM mode" that FvF Quest runs in, when normally TAB should show the scoreboard). It doesn't actually show the scoreboard, it just makes the text vanish. Proquake didn't do this.

Also, I guess I'll note that centerprint text still appears behind the standard menus (this is altered behavior too).

And, should not "Weapon Draw" in the menu be defaulted to "Quake Default" rather than "Fitzquake?"

Heck, "crosshair" in the menu should probably default to "quake default" too, even though the actual Quake default was "no crosshair" ... but everyone uses crosshair. 
Mark V - Build 1003 
Download same place as usual

- Fixes rocket explosion a missing particle.

This is a correction of the 1002 build.

/Typing "version" in the console will show as build 1003. 
I will put in a an option to disable the hardwired tilde key behavior in one of the upcoming versions.

I'll have it so if in_keymap is 0 (turns off international keyboard support), tilde behaves in the old way. 
The lighting gun does not fire in a constant stream like a water hose...

I hate to get all "Quake Manual" again, but...

Thunderbolt: Try it. You'll like it. Use the same technique as watering your rosebush. 
Lightning Beam Interpolation 
Adding to what mh said:

QuakeC is trying to get the beam position to always be starting at player origin.

The problem is, it is only updating 10 times per second because QuakeC is 10 fps.

The implementation of rendering the lightning beam as if real-time (an illusion) on the client side is merely doing what QuakeC is trying to do, but can't.

/I mean jerky sky scroll is how original WinQuake works, but Mark V straightens that out too. Same can be said about FitzQuake 0.85 animation interpolation. I don't see Jerky Lightning Beam being something that was a design plan, but rather a side-effect of a technical limitation of the speed of a 1990s computer. 
I'd be inclined to go slightly further with this: Lightning angles are another of those framerate-dependent client-side behaviours, so they should be simulated at a fixed rate instead. 
Extra Transparent Water + Colored Lights Available 
NightFright went all out!

Take a look!

If you want transparent water without vispatching (.vis) and colored lights (.lit) for Add-On Mission Packs ... see this ...

- Nehahra
- Beyond Belief
- Abyss of Pandemonium
- Several more ...

There is a link to that page on the Mark V site next to the Transparent Water/Color Lights (says "More ...")

/The .vis files work in DarkPlaces and FTE too, some others like Engoo. 
Could you explain that in a bit more detail ... 
Extra Thought On Lightbeam Smoothing 
I suspect I'll make it work like this:
0 = off
1 = single player only + if you are playing bots [ in engine terms] (because in my view this is the only correct use of feature)
2 = always 
If you look in CL_UpdateTents you'll see that lightning angles depend on a rand: ent->angles[2] = rand()%360;

So if you run at 20 fps this angle changes 20 times per second.

If you run at 72 fps it changes 72 times per second.


So this angle is framerate-dependent.

A possible solution: create a lookup table of angles and index into it by some function of cl.time; probably also need to use the temp entity number so that not all bolts get the same angle.

Ent->angles[2] = angletable[(Cl.time * 72) + i]

Something like that. Forgive capitalization & typos, on a phone keypad. 
I actually remember that line from the manual about watering the flowers, heh. However, you could still water a rosebush with a sprayer that spurts water 10 times per second ;)

Ok, there is no limit in QuakeC about running things more than 10 times per second. You can easily make thing do stuff in much smaller increments. I actually have some test code I sometimes activate for fun that lets your weapons fire INSANELY fast. 10 nails per second is the standard rate of fire of the nail gun too, but I can modify it to fire a bazillion nails per second if I want.

Screenshot of me firing a bazillion nails per second:


The reason the guns don't fire any faster than that is not because of any QuakeC limitation -- it's because if it fires any faster, it would be too powerful in addition to burning through your ammo way too fast.

Of course, the standard .05 ticrate of Quake would tend to limit things from happening more than 20 times per second when playing online.... not to mention a bazillion nails onscreen would cause lag, heh, but it's not at all a QuakeC limit.

The lightning gun could easily have been made to fire/strike much faster than 10 times per second, but that would require it to do less damage per strike among other things.

Now, the firing origin of the lightning bolt, by default, DOES stick to the player. You can see this in chase mode (use host_timescale .1 or slower). The end point of the bolt, however, sticks to where it HITS. There is no QuakeC limitation causing this behavior -- this IS the intentional and correct behavior of a rapidly-pulsing lightning gun.

You're trying to fix a problem that does not exist.

If id wanted the end point of the bolt to stick to your crosshair position, they could have done that, just as the start point of the bolt sticks to your player position in chasecam.

Oh, and I found a mod that "breaks" because of "truelighting" ... My mod! FvF! heh... Ok, "breaks" is an overstatement, but the Mage class has his own, slower-firing, lighting attacks, and this makes them look very bad. Well, it's the same kind of "bad" as for the regular lightning gun, but it is just more noticeable because the Mage fires his bolts more slowly than 10 times per second....

Anyway, if you want an "eycandy" effect like this, fine, but default OFF please. And be very careful about adding stuff like this -- junk like this is the whole reason many people dislike the majority of other Quake engines -- it changes the gameplay feel or look too much.

A smoother-scrolling sky? Sure, that's just a visual thing that makes no difference in gameplay feel. Smoothed monsters look much better than jerky ones too (though some people prefer a "retro" feel). But the "jerkyness" of the lighting gun is not merely an animation issue -- it's actually showing you precisely where the bolt is striking as it pulses 10 times per second. 
Double Post 
Excuse the double post, but it's probably worth mentioning that in my own code I use 36, not 72, and talking a bit about why.

I take issue with the common statement that Quake is designed to run at 72 fps. If you look back at the time it was developed, while there certainly was hardware that could run it at 72, most hardware couldn't. Especially in the typical configuration, which was playing the DOS version on Windows 95.

Most people were playing Quake at 20 fps, 30 maximum, and while id do design for the future, they also design to get a good game on current hardware.

So I'm more inclined to say that Quake was actually designed to run at 20-30 fps and that 72 fps was nothing more than a framerate cap, "so packets don't flood out", according to the comment in host.c

The number 72 is significant: it would have been a typical refresh rate of a typical CRT monitor from the time.

Hence for certain framerate-dependent effects (rocket trails are another, rocket trails aren't actually a smooth trail at all but rather clumps of particles with each clump spaced out & intended to represent a puff of smoke) it makes more sense to run them at a slower rate. 36 is just a nice even reaction of 72 (24 would be another) but there's no actual technical or analytical basis for it. 
Oh, and I found a mod that "breaks" because of "truelighting" ... My mod! FvF! heh... Ok, "breaks" is an overstatement, but the Mage class has his own, slower-firing, lighting attacks, and this makes them look very bad.

Looks like defaulting it off then, it is.

I did do testing against a few mods looking for differences, including the Zerstorer funky chain lightning gun.

After not being able to locate any instances where it made any meaningful difference.

So off will be default value in next version.

Was trying to address the common beginner complaint "Why does my lightning act jerky".

So question will remain, but answer will be "try setting cl_truelightning option to 1". 
Typing "sky" in the console does not report the help information for that command.

Thinking about the lightning bolts, the animation really isn't ideal, which is why beginners may ask why it's so jerky.

The bolt is misinterpreted as a solid object that can be swept back and forth to touch things, when it's actually a series of very fast point-to-point pulses, like a stun gun ( reference: )

Perhaps an easy hack to improve the animation so that it more accurately reflects the function would be to only draw the lightning entity for no longer than 1/20th of a second (it will currently stick around for up to 1/5 of a second if you don't fire a new one every 1/10th). That way the first pulse would vanish before the second pulse appeared, making it clear that it's a separate pulse.

It would indeed create a more functionally accurate, rapid zap-zap-zap-zap effect instead of the look of a jerky sweeping line. And it seems like it might be an easy thing to do in the engine....

More complicated effects would involve the lightning bolt actually appearing to leave the gun and flash forward very very fast. The beam would still be instant, but the visible lightning in the beam would appear to move forward very fast.

Animation tweaks like this I could get behind, because they would accurately reflect the function without ever drawing a bolt as hitting positions it doesn't actually hit.

I think I may go play with some QuakeC and see what kind of funky lightning animations I can make. I'm getting crazy ideas, hehe. 
The end point of the bolt, however, sticks to where it HITS. There is no QuakeC limitation causing this behavior -- this IS the intentional and correct behavior of a rapidly-pulsing lightning gun.
I personally like my lightning bolt to stay in my crosshair but fom a logical perspective this makes sense. If you watch real-life electric bolts, you can see that when they find a "target" they tend to stick to it for a moment before jerking to another point. 
Sky is a command, it isn't a console variable.

Commands are things like "map start" or "status" or "load mysavegame" or "noclip". They might not even need a parameter.

If you do "find sky" it shows things related to sky, for example, and it says "command" in the value column.

Yeah, the difference between a command and cvar is not necessarily clear to the user.

Like how "name" is a command but the value is a console variable _cl_name 
Ok, this turned out kind of cool....

I added my new lightning gun animation test to my little camtest mod:

I didn't change the actual functionality of the gun at all -- just the way the lightning bolts are drawn. I think now the way they are drawn more accurately reflects how the gun actually functions. And it just feels POWERFUL! Somehow that "trueshaft" felt impotent, because it was waving all over the place but not hitting everywhere it waved. Don't you hate it when your shaft just waves around and feels impotent? heh.

Well, Dr. Gunter's Shaft Enhancer is what you need!

Rum the mod, give yourself a lightning gun (give 8) and a cell or two (give c 1) -- you only need one, I made it not use up any ammo for testing -- and go to town. Find some monsters to light up. The effect is more intense on a dark level, like maybe e4m7....

Tell me frying monsters with that thing doesn't make you feel like the friggin' god of thunder! hehe.

Yeah, the lighting passes through walls... It's just a quick hack, and currently would probably not work for online play (I'm using those very tiny time increments that are fine for client animations). The stainmaps don't like it either. Also try host_timescale .1 if you wanna look at it in slowmo.

In any case, THIS animation (though primitive) feels right, and accurately reflects the function of how the gun actually works. 
Having good times playing with this so far. I know you don't like menus but I really appreciate the extent to which you've menu-ified some of the settings.

A minor ask:

I've noticed on my system that the video stretch setting defaults to "640x480 Nearest" on first run.

Can the default for that be "None" instead?

That way if a naive user comes to the video settings and just changes the resolution, they'll get what they're expecting/intending instead of getting 640x480 stretched out to that resolution. 
The default value was supposed to 0 (none). The stretch item in the video menu is obvious. So ... yeah, exactly, next version and all that jive.

I know you don't like menus but I really appreciate the extent to which you've menu-ified some of the settings.

Haha, yeah. I'm very judgemental about menus.

Brevity is soul of wit.

Where bad design exists, it expresses itself in the form of menus. 
LIT/VIS Uploads Complete 
I have now finished uploading my complete collection of .lit/.vis files for classic Quake addons.

Check out all 32 uploads here.

Fire up Mark V and enjoy! 
Lits for Malice are a little weird. For the most part they're reasonable, but it seems that some of the textures emitting colors shouldn't really emit anything. Like warning stripes. 
That's The Thing... 
...when using automated tools. The only handmade ones are from Quake and the mission packs (not done by me, btw), the others were generated with automated tools. One would have to edit the .lits to remove those which don't make sense, I guess. In most cases, it's still looking better than without colored lights, anyway.

If anyone has the time and motivation to go through all the (formerly) commercial/community release lits to eliminate bad color lights placement, feel invited to do so. 
In the recent DX version, the illusionary guy from the .ent file is no longer transparent (he previously was). He still is transparent in GL and Win. And of course, DX still doesn't do the transparent HUD. 
Copying Settings From Id1 Config.cfg 
Is it possible that screen resolution is not automatically copied from id1 config any more when launching addons in other directories (e.g. c:/quake/nehahra) for the first time?
I am in windowed mode and have to reset my addon screen resolution to 800x600 from 640x480 even though it's changed in id1 config already. 
A final tweak of my test lightning gun animation -- it won't pass through walls now and it interacts (heavily!) with stainmaps.

Download and give it a try, people.
It's just a tiny mod.

After playing with it for a while, I realize why it's so much more satisfying than the default lightning beam: the visual feedback lets you see that you are POUNDING the monsters 10 times per second with zaps of lighting rather than just focusing a beam on them which doesn't give good visual feedback of the hits/damage it's doing.

And it's just so much more satisfying to pound a monster with 10 lightning bolts per second!
It just FEELS more damaging.
The "truelighting" effect waters this down even more, giving even less correct visual feedback of the pulsing of the lighting strikes.

Again, I haven't actually changed the function of the lighting at all -- this is just visually illustrating how the lighting gun has always worked.

The flashing lights I added may be a bit much (and may cause seizures!), but gosh darn if it doesn't make you feel like you're unleashing a massive, powerful Tesla Coil on those sorry monsters! 
Malice Again 
There are two blue mechanical enemy types in the game, and they both seem to consist of two models - upper and lower. The upper model is often invisible in Mark V (GL and software), Quakespasm, and enhanced GLQuake, but not in enhanced Winquake. 
Audio Formats Supported By Mark V? 
Hi, I'm loving the engine so far (Former user of Quakespasm) and I was wondering what other audio formats are supported other than MP3? 
#206 It's Not Mentioned In The Doc? 
I think it's MP3 only 
RIP me. I guess I'll just wait for more audio formats to be supported or just use a CD. 
What's Wrong With Using .mp3? 
@crusoe ... Mp3 Only 
Post #14, #16

Mark V uses system methods to play MP3 that take advantage of hardware accelerated decoding of mp3 built into your processor.

Intel processors, AMD processors, the iPhone, Android phones all provide hardware accelerated MPEG-1 decoding (mp3 is part of MPEG-1 specification). Plus the mp3 decoding patents expired in September 2015.

... why Mark V can stop/pause/restart music instantly and engines using a software decoding library cannot. 
A polishing/tuning update probably within an hour.

1) Decided against printing console variable descriptions when typing a variable name in the console. Will revert to old behavior by default. Most of the important stuff is in the menu, someone new can always ask if they don't discover the "find" command first.

2) The lightning goes back to old behavior by default, someone can just turn it on if they like.

Nothing else of interest except QMB support will be in the next as an option which defaults off.

@dwere -- Probably a Malice content error that doesn't work Open GL engines. At some point I'll give it a look over to see why that would be the case. You said it shows in Enhanced WinQuake (but not Enhanced GLQuake) ... if you checked, does it look ok in Mark V WinQuake as well? But either way, at some point I'll investigate out of curiosity. 
@gunter - DX8 Build - Transparency 
In the recent DX version, the illusionary guy from the .ent file is no longer transparent (he previously was).

Triple check up close and personal. I just replicated a test to make sure, and in the test alpha entities are rendering in DX8 fine. But sometimes you have to get close and look hard to notice the transparency.

DX still doesn't do the transparent HUD.

That's on the to do list, I haven't forgotten. It will at some point be addressed. 
@gunter - Dx8 Build Transparency Part 2 
Seems that .alpha entities in DX8 are a bit less obvious than OpenGL, possibly due the lack of the combine capability in the DX8 wrapper.

Will investigate at some point to see why, but remember it has to use an alterate rendering pathway for this scenario (the one that metlslime) -- so may be little recourse. It already isn't drawing quite the same as Open GL, because it can't. 
Mark V's read early of the video mode "read early scan" only checks in the intended gamedir.

I guess I'll expand the "read early scan" to also include id1 if in a gamedir. 
You said it shows in Enhanced WinQuake (but not Enhanced GLQuake) ... if you checked, does it look ok in Mark V WinQuake as well?

Strangely, no.

A minor nitpick: the engine crashes with a generic error when provided with a wrong (non-existent) directory after -game. Noticed by making a typo. 
I had made an initial attempt at adding combine modes to the D3D wrapper but backed out of it on grounds of code complexity.

The irony here is that all multitextured bleeding in D3D is the equivalent of GL combine, but GL API quirks (specifically use of "selectors" rather than being "DSA"-like; in GL you set the current this, then the current that, finally the actual state, which has to track those current selections, in D3D it's all a single line of code) made everything messier than I was happy with.

Nobody should read it as "D3D can't do combine" because it can and does. It's a deficiency in the wrapper and complexity in translating code between one API and the other. 
That's a pretty good bug report. Just added a proper "folder [name] doesn't exist message". 
can't seem to get nehahra to work right, mainly it's opening scenes just never play (and in turn it won't start) and it's throwing gl fog errors. I tried with the latest version in all three renderer types, using the quaddicted zipfile. Am I doing something wrong? is there more steps to this than just -game nehahra? 
Mark V - Build 1005 With QMB 
Download different place than normal, on slow internet connection and can't get uploads to work except at

New Features
1. JoeQuake QMB particle effects option. video
2. "in_keymap 0" honors tilde key bind (gunter).
3. -game invalid dir warning (dwere)
4. Console default values are engine default
5. Normal lightning beam default again, instead of realtime simulated.
6. Console variable in console old behavior restored.
7. vid_stretch defaults 0 in software renderer (johhny law)

I'm having difficulty uploading on a slow connection -- go figure.

Typing a console variable name in the console no longer prints the description (at least by default). There are reasons this is undesirable.

in_keymap 0 turns off international keyboard support (mostly) and therefore tilde key position is known and can use old behavior.

@nightfright - Checked an the read early behavior in Mark V is actually correct and reads both gamedirs if a gamedir is used.

/Typing "version" in the console will show as build 1005. 
game nehahra -nehahra

Otherwise won't work right. 
Download With Caution! 
I've never used that site before and attempting the download, my browser flagged the download as possible malware.

My (remote) internet connection is so slow, it is virtually impossible for me to conduct any research with any kind of speed.

Maybe this warning is bogus, maybe it is real. I don't have a way of checking this out on this slow internet connect.

I would not think that Google would list a file upload site that is known to add malware as the #3 search result, but maybe they do. 
Also, the first cutscene starts with a black screen. It's perfectly normal and you just have to wait a little. 
Possibly Infected MkV Download 
Firefox is flagging the file as potential malware. Scanning with my Kaspersky shows no threat. Virustotal yields a positive (1/54, Invincea --> 
1005 And Tilde Key 
Looks like 1005 broke the tilde/console key again with German keyboards.

My config.cfg settings:
in_keymap "0"
in_system_enhanced_keys "1"
Why Not Use Quaketastic 
For your uploads? 
Potential "Beyond Belief" Issue 
In the final level of "Beyond Belief" (bbelief7 | The Unholy Alliance), just when Cthon dies and is about to fall back into the lava, Mark V crashes to desktop with a "Host_Error: recursively entered" message.

Can anybody confirm? Using latest Mk V 1005 build, GL version (mark_v.exe). 
Only happens when using Seven's BB enhancement mod.

From qconsole.log:
Host_Error: ED_Alloc: no free edicts (max_edicts is 8192)

Game is apparently running out of edicts when Chthon falls back into lava, bleeding. 
DX transparency -- Looks like gl_overbright_models 0 borks it up (makes it opaque) in DX. It also slightly alters the appearance in the GL version.

Wanna crash Mark V on startup? Just put scr_showpos 1 in your autoexec.cfg ;)

@NightFright, I think you want to set "in_keymap 1" 
Console Key Fixed (again) 
Yepp, already figured it out. It's actually set to 1 by default if you delete your config.cfg and let Mark V create a new one.

I dunno if my report about the max_edicts issue is relevant. I actually thought there is no limit for this any more. Last thing I read was that Mk V tries to detect the required amount automatically. Maybe it's not working reliably in all cases. 
If Seven's Beyond Belief is endlessly creating new edicts, it is a flaw in his QuakeC.

DarkPlaces is just hiding the problem by endlessly allocating edicts, but given enough time it would eventually run of memory.

8192 edicts is a whole ton of edicts, even Rubicon Rumble doesn't even half of that.

And Beyond Belief is a 1990s era work that runs in original Quake with a 640 edict max. 
Were you using in_keymap 0 on purpose or on accident?

If it was intentional, was there something you preferred about in_keymap 0? I use USA keyboard so have to listen to experiences of others on this subject to learn.

@fifth - After trying to upload 15 times, I just wanted it upload (was minor nightmare, would upload 50% or 98% and bail -- wasted a lot of my time). Either way, I'm no longer on a remote internet solution so I'll be able to upload ok again.

Probably an update in next hour after I knock off the scr_showpos with no map issue that gunter pointed out. 
Mark V - Build 1006 
Download at normal location:

A minor touchup to the 1005 build and distributed the usual way now that I am not on "bad internet".

New Features - (from previous build)

1. JoeQuake/QMB effects option in preferences menu video
2. "in_keymap 0" honors tilde key bind (gunter).
3. -game invalid dir warning (dwere)
4. Console default values are engine default
5. Normal lightning beam default again, instead of realtime simulated.
6. Console variable in console old behavior restored.
7. vid_stretch defaults 0 in software renderer (johhny law)

Touchups in Build 1006

1) Fixed scr_showpos bug. (gunter)
2) Made freezeall work in deathmatch if maxplayers 1 for debugging.

This is a correction of the 1005 build.

/Typing "version" in the console will show as build 1006. 
D3D Combines 
A possible solution would be to drop in some native D3D code instead of using the wrapper. That way you could get the combine mode properly set up, get improved performance and code simplicity.

Of course the down side is that you'd be losing the flexibility of going through a wrapper - you've now got native D3D in key parts of your codebase.

That might not be such a big deal. IIRC FQ only needs this in 2 or 3 places and the only combine mode it uses is modulate colour 2x. 
I kind of like the QMB particles.
Feedback for that:

Missing blood trails on gibs... unless a zombie is throwing them? Or unless they hit the ground maybe? Or.. unless they are moving very fast... Something is different. The chunks just aren't bleeding right.

Flame effect doesn't work on new torch projectiles (FvF fighter/ninja). Eh, not a big deal. The old flame model still appears.

Lightning is too blue -- needs to have bright white in it to look electrical.

Oop. Crashed with AddColoredParticle: Invalid type (2) in FvF with mage/monk/cyborg weapons (they use red/orange/white particle explosions)

The grenade and rocket launcher explosion effect is anemic. Not enough force or intensity compared to the standard particle explosion.

The scrag projectiles are way overdone -- they look like green lasers. Decrease intensity. Vore ball too.

Explosion sprite is completely gone (invisible), but frames of it are used for several FvF guns. The new effect only appears for the Quake guy's stuff.

The, uh... yellow particle field effect is gone (runequake uses it for spawn shield, FvF for BFG explosion).

Chaingun weapons do not leave sparks on the wall like the shotgun does, just a few grey particles instead which don't show up very well..

Would it help if I gave specific code for the various particles I'm talking about? Not sure if you can/will make any tweaks to the effects.... 
QMB Effects 
@gunter - Made what JoeQuake had to offer available as-is.

The rocket and grenade trails I feel work generally work nicely.

Example: qmb_trail_scrag 0 (doesn't fit in, does it?)

The menu only sets qmb_active 1 or qmb_active 1. If you individually turn off or change the others, they stay as is. "find qmb", you can locate things to turn off. I made every individual effect on|off via cvar. It is possible I look back at this thread for ideas on tuning for say a future version 2, but someone really into effects needs to be using Qrack, DarkPlaces, FTE or an effects oriented engine.

So you can do: bind x "toggle qmb_active".


Main goal was full set of JoeQuake, Enhanced GLQuake/WinQuake and ProQuake feature set.

To keep alive their unique contributions ... for those that liked those engines. Jozsef had some great contributions (author of JoeQuake).

@mh - I agree with some of that, but main purpose the DX8 build serves to me is to help people with bad Open GL drivers. Having 98% is pretty good deal. Eventually problem will be solved by Gunter spilling drink on his laptop ;-) Haha 
and this is why scriptable particle systems are so nice. :)
That way you can tone them down or just avoid disturbing reinterpretations of the original intent of the effects. 
Yeah, in JoeQuake trails were all or nothing.

You couldn't turn off, for instance, just scrag trails (radioactive green).

The FTE particle system -- even the subset in Spiked Quakespasm -- offers the user to be fully in driver's seat. Versus where effects are hardcoded into the engine. 
I just downloaded and tried JoeQuake, and the colored particle explosions work in it.

As mentioned, they crash Mark V.

I can disable them by qmb_explosions 0

If you wanna see lots of effects like this, just connect -- the mage uses lots of things in his various spells (vore balls, knight spikes, and lighting bolts), and the cybrog, monk, and cleric all toss around weird things too.

But of course, if you have qmb_explosions 1 ... Mark V will crash if you use monk or mage GL or RL weapons, or cyborg GL. 
I'm combing through this and auditing a couple of things.

Do you know of a colored explosion in either regular Quake or a mod I can locally run?

A situation where I can't savegame, then loadgame rapidly to tune isn't all that ideal.

I have the gib trails fixed. 
Nevermind, Quoth uses them ;-) I'll test Nehahra too (has an even different explosion). 
Was a simple typo. Resolved.

Thanks for the testing, gunter. You argue hard, but you bug test hard! 
Ya know, I don't think the effect is used anywhere in standard Quake.... It's just one of those unused effects.

Here, I updated my little camtest mod to include colored particle explosions:

Just set scratch3 to any number from 1-255 (actually, you can probably set it higher, but you may get weird results, like black particles.... 12 is a good number to use -- it's bright white), and your rocket launcher will make colorful explosions. 
Ok, sometimes the torches in the Start map turn white (untextured) when QMB stuff is enabled in DX. I can't reproduce it reliably, but I've seen it happen twice. Once I see it, a restart of Mark V clears it up (or turning off the QMB effects).

Also, I have a little blue particle water splash effect in FvF, but sometimes it's turning out as an orange/yellow spark/explosion effect.... Can't reproduce that reliably either.... 
Mark V - Build 1007 
Download at normal location:

2 bug-fixes related to QMB -- gib trails, colored explosions. (gunter) 
I could really use a setting to always draw the standard explosion sprite even if QMB explosions are enabled (several FvF weapons make use of the sprite)....

Heck, I might even like having both the normal explosion particles and the QMB explosion effect both enabled at the same time. That would make the explosions look intense!

qmb_explosions 2 ? 
qmb_explosiontype 1 ... keeps the sprite. 
Rocket Light Color / Explosion Light Color 
I noticed when adding in QMB, setting qmb_rocketlightcolor ... 0 = normal, 1 = red, 2 = blue, 3 = red + blue

qmb_explosionlightcolor works possibly identically. 
Hm, qmb_explosiontype 1 keeps the sprite, but gets rid of all particles in the explosion (no QMB particles, and no regular particles either).

And standard QMB_bubbles are invisible when I play online, but they are visible when I am playing my own local multiplayer game.

But, qmb_trail_spike produces the underwater bubble trail both online and not. 
@nightfright, Dwere ... Keyboard 
@nightfright, dwere ... (or others)

re: keyboard

Do I need to do anything with in_keymap 0, or is in_keymap 1 fine for both of you?

Need input on this issue, since I am USA keyboard user and not super-familar with keymapping likes/dislikes/etc, other than listening to conversations in the past when I implemented a somewhat similar solution in a different engine. 
Oh, qmb_explosiontype 0 makes both the sprite and the QMB explosion particles. A setting of 4 does likewise.... Maybe 4 is not valid, and it's just going back to the "0" setting. But 5 hides the sprite again, hmm.

I'll keep testing and see if I can tell a difference in other settings.....

But 0 is just what I needed. 
bubbles: invisible online, visible offline

Are maps vised? This is all client side. If your server isn't sending the sprites to you because the maps aren't water vised, you don't receive them.

By definition, since QMB is client-side .. there can be no behavioral difference, so it has to be what the server is sending you.

Bubbles are sprites, not particles ... subject to same "can you see them test" on server as a weapon, player, healthbox.

qmb_trail_spike produces the underwater bubble trail both online and not

The spike bubbles are a client-side manipulation where they are emitted as particles, but no real sprite ever existed.

However, subject to the same conditions as first case.

If the server doesn't send you the nail spike, no trail would be emitted.

It probably just seems different because you were underwater at the time? 
re: Explosions ... Just remember, for the purposes of this version if it behaves exactly like JoeQuake is implemented correctly.

(Doesn't mean I won't consider it for a future version 2 --- I agree with what you say about the weirdness of sprite + QMB explosion sprite but no particles --- but testing JoeQuake it works that way too ... seems unusual, but by that metric, it is implemented correctly.) 
I don't know why, but it's definitely not showing the QMB bubbles when I'm connected to the FvF server -- the ninja actually throws out a row of bubble sprite bombs, so I can do this even out of the water. They are visible when locally running my own game, but invisible when connected to the FvF server. qmb_bubbles 0 makes them come back as the usual sprites (HQ replacements, actually).

Hm, there's something odd happening. I ran my own dedicated proquake server and connected to it with Mark V, and the QMB bubbles show up, but they move very choppily... like, uh, non-interpolated motion or something.

Ok, I reset the level on the FvF server and now the QMB bubbles show, but again, very choppy movement. The regular bubbles move smoothly....

Connected to a different (non-fvf) server and got same result.

Well, more testing will have to wait till tomorrow. If you wanna compare, connect

I left it on e4m3 where there is a nailgun right in the start room. Just select ninja class and use that gun to throw out a row of bubble bombs, and see how different it is with qmb_bubbles on or off.

Or go jump in a water pool....

The nail trail bubbles move smoothly. 
Record a demo of it (tell me the clock time I should look at). I'll play it back. I can't debug connected to a server, I stop execution to examine, I'd lose connection.

I have a working theory that goes like this: there may be something in the renderer that isn't being reset to base state.

Would seem to be a fit for what you describe, but isn't necessarily the case.

But if it is a renderer state issue, I may not be able to replicate it easily because it depends on a very large number of factors.

With a demo of where you say you have the issue, my first goal would be replication (which could be the hard part! Could depend on your settings, like even things like overbright or gl_fullbrights or what things you have turned on or off or what external textures, if any are loaded and what entities are on the screen).

/Whenever I end up doing a future incremental upgrade (like a 1.1 or what not), I would likely implement a state manager and this could never happen. I already have a different engine with a state manager (Engine X, which is a few years ago) and it unearths lots of scenarios where the states are not reset. 
I haven't tested 1006 or 1007 yet, but in general, the only thing I noticed was the tilde key. I am playing Quake mostly with numpad keys (the block on the right keyboard side) which isn't affected by these changes.
Will try with the newer builds soon, but basically, the default behavior should always be the tilde key for console. 
Bubble demos:

The bubbles are weird.
I get the same result in JoeQuake.

They work fine and smooth locally, but when connected to a server (even a server running on the same computer), they are very choppy, or if the level has been running a long time, the bubbles just don't show up at all.

The effect is seen in the demos based on the settings you make while watching it. 
Typing "pak help" in the console crashes the winquake engine for me. 
I thought maybe the difference might be that a proquake server would be protocol 15 and a local multiplayer game would be 666... But nope, that doesn't seem to make a difference.

Also, I tried running a dedicated Mark V server. DX or GL versions seem to start up and do stuff, but then the window instantly closes....

So I ran Mark_V_Winquake -dedicated, and the server window ran fine.

But then doing "connect local" or slist or find local multiplayer game in the menu does not work in my Mark V client.

connect [local ip address] works fine. 
@coburn, @gunter 
@coburn -- there are a few interfaces for internal things that aren't meant for users (just for me for testing) that I need to make unavailable. You found one of them.

Mark V has the ability to read, write, edit pak files for future hub system for single player that want fully re-entrant maps (that requires no special QuakeC support!) -- so it needs to save the state of several maps.

Not meant to be available to the user.

@Gunter: connect local doesn't work

It's "connect lan" ;-) 
gl_overbright_models 0 makes my gun opaque instead of transparent when using r_viewmodel_ring 1 
"connect lan" doesn't work either.... "no lan quake servers found"

Connect [lan ip on same computer] does work. 
@gunter - Part 2 
Let me know if "connect lan works" on Windows XP. Mark V acquired Spiked Quakespasm's rewritten networking -- it uses some Windows networking capabilities that weren't available until Windows Vista, and uses a fallback on Windows XP.

If don't know if you are using Windows XP SP1 or Windows XP SP2 (or whether it SP2 makes a difference in this case). 
@gunter - Dx8 No Overbrights = No .alpha Support 
@gunter - gl_overbright_models 0 + no alpha transparency ... yeah, in DX8 version there is no GL combine capability. Needs to have overbrights enabled for the transparency to work when no combine extension available.

The rendering code is a complex twisty path. 
@gunter --- -dedicated issue with GL fixed.

Bubbles -- hmmmm ... interesting. Those are in fact bubbles1.dem --- are those bubble sprites for 100% sure? I'm digging into this, but s_bubble.spr is blue, right? 
@gunter - Re:gray Particles With QMB On ... 
I know what is going on with the gray particles not appearing. Need to decide best way to address or maybe even make an extra qmb_ option to control behavior.

One way or another, later today you'll have those gray particles back. 
Windows XP Service Pack 3

Uh... what grey particles? Oh, was that about the chaingun weapons? It would be nice if they made sparks like when a nail hits the wall.

My ninja bubbles are definitely sprites (I did the standard water drowning bubbles in the demos too). I usually use a replacement sprite texture though. Actually, I mentioned in the past, the replacement sprite texture that is included in the Quake Retexturing Project comes out as invisible in Mark V DX, so I had to alter its opacity. In any case, I've tested this new bug just using the standard bubble sprite too, so it's not the previous issue (qmb_bubbles replace the sprites anyway). Yeah, s_bubble.spr is pale blue, usually. When I watch bubbles1.dem I can toggle qmb_active 1 and the bubbles instantly go invisible, but they re-appear as soon as I set it back to qmb_active 0.... In both DX and GL versions. Were the qmb_bubbles invisible for you in the bubbles1.dem? And did they appear to move really choppily in bubbles3.dem?

Oh my... yes, I can imagine the twisty mess of code that's doing transparency in DX, because I'm getting strange results. But transparency DOES work even with gl_overbright_models 0 ... depending on... circumstances.

For example:

r_viewmodel_ring 1
external_textures 0
gl_fullbright_models 0

grab a ring (e4m6 has one at the start) and your gun will be opaque... But not the axe. The axe is alwys transparent. But no other gun.

Unless you activate external_textures 1 (and you actually have replacement textures). Then all your guns are transparent....

Setting gl_overbright_models 1 also makes everything correctly transparent.... 
Re: Bubbles/QMB 
Maybe there are a few separate particle scenarios. I'll check each one out. 
For clarity, can I get demo name + time into the demo for each separate issue so I don't miss one.

Like bubbles1.dem @ 18:45, etc. 
@gunter - .alpha Entity (.mdl) + DX8 
Here is what I'm going to do ...

If an alias model (.mdl) has .alpha (transparency) ...

I'm going to force fullbright + overbright off for the rendering.

That will make your DX8 transparency look pretty much the same. Will probably add an unsaved cvar to disable the behavior, merely for possible future rendering testing purposes.

But this will effectively remedy the DX8 .alpha entity "looks less transparent than GL, and if overbright_models is off isn't transparent at all if overbrights off" issue. 
The demos are very short, and it's all the same issue -- qmb bubbles being weird. Though there are two different, related weird behaviors.

The issue starts out as the qmb bubbles moving very choppily, and after the map runs for a while, they just become completely invisible. This only happens when connected to a server.

I tested these demos on my older WinXP laptop and I see the same result in both DX and GL.

bubbles1.dem -- shows the qmb bubbles being invisible. This should be dramatically obvious -- just watch it with qmb_active 0 (or qmb_bubbles 0) and you will see that the ninja throws a row of bombs using the bubble sprite. Then turn on the qmb bubbles... and you won't see them anymore.

bubbles2.dem -- just shows that the qmb bubbles work correctly when not connected to a server.

bubbles3.dem -- the qmb bubbles are doing the choppy movement. It's like the engine is struggling to render them or something.... Again, just watch with either qmb_active 1 or qmb_active 0 to see the difference -- the standard bubbles move smoothly. Hmm, I wonder if maybe the qmb bubbles look choppy because they are invisible PART of the time....

Wait a minute... I wonder if this has to do with ticrate... let me test.

Yep, that's it! Mark V's rendering of the qmb bubbles is somehow affected by server ticrate. I can imagine if that gets out of sync, it could be drawing them invisible when it should be drawing them visible, or something....

The standard bubble sprite rendering doesn't suffer from this - they seem to move smoothly.

Yeah, when I'm connected to FvF with a .1 ticrate, the qmb bubbles (only) seem to move as if I'm playing locally with host_maxfps 10

Adjusting the ticrate to .05 or .01 smooths out their motion.

Ohhh, another possibility: since QMB is replacing the bubble sprite with an EFFECT, perhaps the movement of that effect is not subject to motion interpolation, which is why it seems to jump along at the ticrate instead of moving smoothly?

That wouldn't quite explain the complete invisibility though.... And other effects seem to move smoothly.... Like the underwater bubbles from explosions or nails -- they move smoothly. 
Re: QMB + Historical Particle Inconsistencies 
These things you are discovering me always aggravated me about QMB back in earlier times.

I'm going to see if I can fix them by rewriting the code to be more precise about what happens.

I may be able to fix the bubble lerping interpolation too, great job thinking about that -- makes a lot of sense.

The problem with how QMB was written is that it wasn't too friendly with what modders like to do and somewhat inconsistently changes the modder's intended particles, and in a way that appears random.

Time to replace that with some sensible consistency that can also be turned off ;-) 
@dwere - Malice Monster That Doesn't Render In GLQuake Engines 
dwere, what Malice monster is the one that you are saying is multipart and only renders consistently in WinQuake and Enhanced WinQuake, but not even Mark V WinQuake.

Is it monster_banshee?

I'm having difficulty locating one in game? Is there a certain map it appears on.

Want to inspect that. 
"and somewhat inconsistently changes the modder's intended particles, and in a way that appears random.

Time to replace that with some sensible consistency that can also be turned off ;-)"


I added a new short demo to the zip called splash.dem, to demonstrate an example of just what you are talking about, involving a blue particle water splash effect I made. Hopefully this is one of the issues you can address:

Just watch splash.dem with qmb particles disabled, then watch it with them enabled to see..... 
@dwere -- Malice Multipart Monster 
If the monster in question is a banshee.

On map d12, I am at 2812 -668 -104 and looking at one. You can type setpos 2812 -668 -104 after loading d12 to teleport there.

It looks fine in the opengl version and the winquake version.

Is it a different monster with issue. Or a specific map. A save game or demo would be useful, I can't seem to recreate the issue. 
@gunter --- when you were doing the auto-connect test earlier were you using port 26000? Doesn't change that the Spiked Quakespasm networking code prefers Windows Vista and later operating system for best results and certain enhanced features, but server auto-detect requires server using port 26000. 
Is it monster_banshee?

Yes, it's one of them. The other one is called "Takahiro Rider" (don't know the internal name).

Off the top of my head, a banshee can be found on d8.bsp. Cheat yourself keys to speed things up, go to the yellow lift. You'll end up in a big square room. The banshee mech is gonna be revealed when the middle section opens.

Sorry, should've told that earlier. 
The ones in d12 work for me, but on d8 it appears without head most of the time. 
Haha ... yeah that doesn't look right. The top isn't there. 
Yep, default port 26000

I don't suppose these monsters you are looking at have skins with alpha transparency? That caused my replacement bubble sprite to be invisible.... 
@dwere - Malice Multipart Monster 
You can type sv_novis 1 for that map to make even the top part of the monster visible in that room.

The upper model (banbody.mdl) is highly unusual as it is highly above the model centerpointer ("the origin" in QuakeC).

On the server side, I think it thinks that part of model is in the ceiling.

A can't change how server side visibility works, it would potentially bust modern compatibility with modern map releases.

Mark V WinQuake tries to handle it like the GLQuake engines for consistency.

/At some point, I might do some more thinking since technically "WinQuake is, by, definition actual Quake" -- but in practice, the GLQuake engines have been the dominant ones for 15 years -- which is why I made Mark V WinQuake handle things like a GLQuake engine. It isn't immediately clear if there is any change that could resolve this without breaking something else as a side-effect, but many times after thinking about things for a few days I might get an idea.

I was hoping using NightFright's Malice .vis files might fix, but it didn't. 
I See 
Well, thanks for looking into it anyway. 
I also experienced this back then when I was testing Malice by myself. However, I was focussing on the showstopper bugs that had still exited back then.

In case you don't find a way to solve this, it's not the end of the world imho since the addon itself remains quite playable. Which is quite something. 
I've already outlined possible solutions.

I do not like incompatibility.

I want the engine to be able to play everything the way it is meant and the way it worked with original Quake.

I'm hardcore about that. 
The qmb lighting bolt has transparency problems with vid_hardwaregamma 0
The lower your txgamma setting, the more noticeable it gets. Or maybe just modifying the setting makes it stick out more....

Just shoot some lightning and do a freezeall and you'll see what I mean.
Actually, now that I'm looking for it I can see it faintly when using hardware gamma too -- it's just more noticeable using txgamma.

But the view blends... the view blends look PERFECT when using txgamma.... Not too dark, not too light. I guess gamma adjustments really mess with those. 
... and I'm REALLY picky about my view blends.... But these look JUST RIGHT. 
The axe is alwys transparent. But no other gun.

Axe is the one gun without fullbright pixels, so probably follows a different codepath that doesn't use the fullbright mask. 
What metlslime said.

@gunter ... since you can find moving sprites (I honestly don't know of any moving sprites in any mod except yours, makes lerping of sprites real hard to test), the QMB bubble's lerping in next build will be test candidate.

If you say it works, fine -- I'll apply lerping to all sprites. 
I honestly don't know of any moving sprites in any mod except yours, makes lerping of sprites real hard to test
Go into the water in e1m4, the air bubbles coming from the doorway on the right side are moving spirtes, I think? The player makes them when choking, too. 
steam & flame in rubicon 2 are sprites. 
@dwere - Malice Multipart Model Solved. 
@ericw -- e1m4 .. keep forgetting about those bubbles.

@dwere - sv_setmodelrealbox 0 -- before map load gets the job done.

Is no doubt an ok setting for playing the entire Malice mod. Like "game malice; sv_gameplayfix_setmodelrealbox 0" in console which reverts to ancient style WinQuake culling boxes.

sv_gameplayfix_setmodelrealbox defaults to 1 (1 = FitzQuake culling/physics box, 0 = WinQuake culling/physics box).

That banbody.mdl model is pretty awkward, I don't if it thinks it is in several visibility leafs or just all the ones it thinks it is in are wrong or what. 
Mark V - Build 1008 
Download at normal location:

1) Removed all the internal testing commands except "dir" (c0burn).
2) DX8 build: equivalent .alpha appearance for .mdl (gunter)
3) sv_gameplayfix_setmodelrealbox 0 improved for Malice (dwere)
4) Sprites like E1M4 bubbles are now lerped (gunter).
5) QMB bubbles should behave like normal bubbles. (gunter).
6) Autosaves are named auto_save_0.sav to 2
7) GL/DX8 version can do -dedicated again ok.

/Typing "version" in the console will show as build 1008.

@metlslime - the more sprite examples the better. ;-)

@gunter - Pay close attention to sprites and if you could, could you give the WinQuake build a look too. I don't expect problems, but without a lot of live testing, I'm always suspicious of any change.

@dwere - This Malice multi-part model on d8 map is a great compatibility test case. First example I know of where FitzQuake bounding boxes cause unwanted culling. It is extremely rare and due to that, hard to find any examples at all. Conversely, Mark V WinQuake adopted FitzQuake bounding boxes as part of first version because it solved a glitch in the X-Men mod where items disappeared if you stood in the right place.

sv_gameplayfix_setmodelrealbox ...
0 - WinQuake (-16 xyz to 16 xyz)
1 - FitzQuake (measure model, default)

For Malice, set sv_gameplayfix_setmodelrealbox 0 before loading a map or save game and everything should be great with any multipart models.

Next update will contain:
1) Alpha channel support for 2D replacement textures, current support is alpha mask only (yes/no).
2) Rewire QMB to be more consistent with particles and be able to turn precise particle behaviors off. (+ alpha channel issue with txgamma) 
4) Sprites like E1M4 bubbles are now lerped (gunter).
5) QMB bubbles should behave like normal bubbles. (gunter).

Uhhh, the first thing was never a problem. It was ONLY the qmb bubbles that were being weird. All other sprites were always fine and smooth-moving. So I don't know what you fixed, but you might wanna un-fix it to be safe, heh.

The second things is definitely improved. The qmb bubbles now move smoothly, BUT the "sometimes invisible" issue still remains. I tested on the actual server and in the previously-recorded demos I made. So, if you watch bubble3.dem now with qmb bubbles, they will move smoothly. But with bubble1.dem you will see no bubbles at all....

This is a tricky one. All I know for sure is that if the level has been running for a while, the qmb bubbles are no longer being drawn. Resetting the level brings them back.... I'm going to try this locally by leaving Quake running for a while to see if it is just an issue when connected to a server.

Hm, things now render transparently no matter what the gl_overbright_models setting is, BUT now gl_fullbrights affects them the same way:

gl_fullbright 1 = most weapons opaque (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.

Also, toggling external_textures does not affect sprites (like the bubble and light ball sprites in id1\progs\) until level change. 
Mmmkay, verified: after running a map for 35-40 minutes, qmb bubbles become invisible.

Tested on e1m1 and reproduced. Go stand by the mega health and jump in the water and drown a little bit. Watch your QMB bubbles pop out and float above you.

Now sit there and idle for 40 minutes... You don't need to do anything else in Quake. Now jump in the water and drown a little more, and you won't see any bubbles unless you disable the qmb effects.

Oh, you don't wanna sit there for 40 minutes to test this? No problem! Just set host_timescale 100 or 1000 and run the clock up to around 40:00 and you get the same result!

Isn't that weird?

Ah, it's easier to test by going to e1m4 in single player, noclip, notarget and go stare at the bubbles underwater. Mess with your timescale.... I have found that the qmb bubbles go away like clockwork at: 34:08

QMB Bubbles: "This level is taking too long! I'm outta here!" 
34'08" = 2048 seconds, or 8*256. Sounds like a pretty significant number to me. Does it give you guys a clue? 
Ooo, good catch. I never would have considered that.

Hmm, I have no idea what the engine code looks like, but just making a complete guess, perhaps if there is some property of the qmb bubbles being set by:

time / 8

then once time gets to 2048 or higher, that calculation produces a number of 256 or greater, and that might be "our of range" for some Quake calculations....

Like particle color generally ranges from 0-256, but it wraps around so that 256 is treated as 0, 257 as 1, etc. 
Build 1009 
Temp Build before I continue trying to clear queue ...

- DX8 .alpha fully addressed now?
- Removed sprite lerping, since it produced no rendering difference.

/Temporary middle point before build 1100 
@gunter - Live toggle of sprite textures --- would be too time consuming (15 hours), mostly because I never thought of sprites when writing the live external textures toggle. Maybe someday.

I'll see what is going on with 34:08 too, while I'm getting QMB pacified. 
The scr_showpos 1 crash on startup has returned....

Hm, I have to set either gl_overbright_models 1 OR gl_fullbrights 0 to get transparency.

And the transparency looks very different depending on which one I set. With gl_overbright_models 1, no matter the fullbright setting, things look much less transparent.

Hm, yeah, it's like the gl_overbright_models 1 effects is being drawn on top of the gl_fullbright 0 effect.

On the positive side, I like having all the exes in only one zip file to download, instead of separating them like on the Mark V web page ;) 
scr_showpos 1 crash on startup has returned

Are you sure? Can't reproduce. Does "version" say build 1009?

If you are getting it, what method are you using to set it? Did you add to command line or autoexec or config.cfg? 
I think you packaged an older version, build 1002.... 
DX8 .alpha 
The difference between different combinations overbright_models on/off or fullbrights on/off doesn't relate to the model drawing in 1009.

It is a difference in how the map itself is draw, and what draw method is being used for drawing the map.

And gl_fullbrights affects what rendering path is used for the map.

The .alpha entity looks the same, but what it is drawn over is slightly different. 
Ok, real Build 1009 in the zip (instead of 1002, however that happened). 
DX transparency is all good now!
And consistent no matter what combinations of settings I use. 
Awesome. I wanted to permanently bury all the small items before reworking QMB some because it may be slightly complex. 
I just wish there was some way I could make use of transparency.... Such a cool effect, but mostly unused. 
{Fence texture based low-lying fog for graveyards. 
Winquake Suttering Cont. 
I think it's cpu related.

Also, the stuttering doesn't occur at relatively regular intervals like I first thought. Generally, the more action taking place the more laggy it gets. Sometimes, the game will launch in a laggy state and have to be restarted.

Also, I have it capped at a 60fps (72 felt like 15).

All software/hardware cpu power management settings, c-states, EIST, turbo mode, etc. are all disabled. Disabling OS core parking helped quell the stuttering, but it's not a total fix. This is on a 4790k at stock speeds. 
On your beastly machine, it's only input lag right? I might be able to do something about that if it is just input lag. 
Re: Bloughsburg + Video Capture 
Frag me --- that download I linked for the codec pack is 983 MB of bloatware + cruft + corporationary non-sense.

It wasn't like that a couple of years back.

Going to link a codec pack is **just the damn codec ***
input does lag somewhat when the stuttering occurs, but that isn't the main issue. visually, it looks like frame loss (like down to 10-20fps or so) but the fps counter doesn't budge. I've also experienced total loss of sound on one occasion, I don't know if it's related. 
And on this Windows 10 laptop I'm testing this out on, it doesn't even make the codec available as far as I can tell.

What nonsense. 
What does the Open GL version do? If the Open GL version doesn't have this kind of issue and the WinQuake one does, that tells me something.

Huge difference on how they update the screen.

On the Mac version of Mark V, it actually uses the Open GL method of drawing in the software renderer. 
no issues withe the gl version. Also, the stuttering occurs when viewing demos as well, this might rule out input being the culprit. 
Sounds like the buffer transfer of WinQuake is the culprit. What's your display resolution? 

I didn't mention this earlier because I have to do more testing, but the screen stretching may have an impact... or maybe it's more obvious when enabled, I'm not sure yet.

Looks like some of the flame polygons aren't being removed when the particle flame is enabled. 
You noticed ;-)

It's a temporarily measure that is supposed to be hard to notice.

QMB needs a flame.mdl without a flame. I can't roll up flame.mdl and include in the binary because flame.mdl belongs to id Software and is not licensed as open source.

My temp measure was to shave off verts above a certain point until I determine best way to have Mark V conditionally render flame.mdl in 2 different manners.

I will probably do this at some point in time by detecting unwanted verts via texture coordinates by haven't done this yet. 
If you are 100% sure GL that the GL version never has the issue, this is likely solved if the issue is buffer transfer.

I wouldn't overthink it.

I don't know when I'll have time to rework it, because it is a bit of a time consumer (might take 20-25 hours).

It's always been on my list do because then WinQuake gets Open GL's vid_vsync capability. 
That being said, you might try a lower resolution far closer to the original and it might work just fine right now.

1920 x 1080 x 24 bits per pixels is a lot of buffer transfer going on every second. Open GL was built for that. Windows API? Don't know.

Lower resolution might help quite a bit. Or might not. 
*Correction: Not every second --- 72 times a seconds or more. 
I've spent far less time in the gl version than the software version. I'll play the fuck out of the gl version tonight then get back to you. I don't want to give you false info thus sending you on a wild goose chase. I appreciate your time and this engine. I played both Beyond Belief and Dimensions of the Past with it and it was a real treat! 
I appreciate that. Wild goose chases suck! 
FYI, build 1009 does not understand the "install" command. 
Thanks for the headsup, Johnny. In this particular instance, I noticed the oversight after I uploaded it but since this is a temp build not linked as main download anyway, I figured I'd wait until I had the "non-temp build" done. ;-) 
If Mark V supports shaders, you may want to try Seven's new_torch model found here:
Looks great and works like a charm (at least in DP). 
Uh --- Mark V certainly does NOT support shaders. And certainly never will support them either.

Do you have the slightest clue what dwere was posting about? No?

Ok -- now get lost.

/You are nice guy, but my tolerance for incompetence in a technical thread is zero. Don't do it again. 
Sorry if I upset you Baker, I didn't mean to. *tiptoes out* 
I'm sorry I posted too intensely, I try not to do that, but there's no edit.

You are a good guy. 
I ran through an episode with the gl version and it performed flawlessly. It may be safe to say that this issue is winquake specific.

I'd like to draw your attention to another curiosity, not because I'd like it changed necessarily, just interested to know why it is:

I like to use a faithful q1 viewwmodel fix that tweaks some verts and alignments. As you can see in this comparison, the texture alignment appears to be off even though we know it isn't (in winquake). 
Yeah I doubted the entire Divx suite needed to be installed hah.

Anything you want me to test as far as my black capturedemo issue?

As far as the sound issue where there was noise...I think 11k has noise and 41k does not. But at 41k the sound is "airy" for lack of a better word. QS does not exhibit this behaviour but it looks like it uses different method for sound processing?

Unrelated but using your advanced demo playback features to watch retrojam5 demos is a godsend. Changes everything! 
As you can see in this comparison, the texture alignment appears to be off even though we know it isn't (in winquake).

Software Quake and GLQuake treat MDL texture coordinates slightly differently. This is a giant PITA for me, because a model tweaked for one set of engines will have broken alignments in another.

I rarely miss an opportunity to rant about it.

BTW, it's funny how even a stock id model works better in a GLQuake-like engine. 
software rendering uses affine interpolation when drawing mdls, because its simpler/faster.
whereas brush surfaces use proper perspective correction by recalculating the texture coords every 16 or 8 pixels (d_subdiv16).
(quake2 added perspective correction on its md2s. I believe this to be the reason why quake used bsp ammo boxes while quake2 was free to use md2s instead)

glquake has an 'gl_affinemodels 1' cvar setting that asks the driver to replicate software rendering's crappy interpolation. however its one of GL's 'hints', which means modern drivers just ignore it and always use proper perspective.

if you have glsl 130 (gl3), there is a 'noperspective' interpolation modifier which ensures the same appearance. 
I should probably add that I was talking about a different problem. So there are at least two ways for a model tweaked for GL to be screwed by software rendering. 
I get a very consistent crash when trying to switch back to DX Mark V after alt-tabbing away, when I am running full-screen with vid_hardwaregamma 0

It does not occur with the GL version, or when using vid_hardwaregamma 1

It also does not occur if I am just sitting in the console before loading a map.

It also crashes if I am running it in a window and I try to adjust my windows gamma settings under the same circumstances above. 
there are at least two ways for a model tweaked for GL to be screwed by software rendering.

That's both hilarious and sad :/

@spike - that is interesting. given quake's initial low resolutions and non-interpolated animations, they might as well have just used sprites. They would've been better looking and probably easier to do. I suppose they pushed the tech knowing that appropriate hardware was just around the corner. 
@kp - See Quakespasm Thread 
The skin application in GLQuake and WinQuake are different. See the argument in the Quakespasm thread (it's buried), the different viewpoints and the final consensus reached by the developer types and mappers.

@re: GL runs fine

Awesome! Provides me with a little bit more incentive to build a Windows "WinQuake rendered via Open GL" like the Mac WinQuake Mark V. 
WinQuake rendered via Open GL

that has a nice ring to it. aside from the mac version, is that a first of its kind in terms quake ports? 
As someone who is exceedingly detail oriented, I give myself an F-- on the DivX download.

I'm very upset that I didn't investigate the current download (I trusted them!).

That download is complete trash, I just assumed since I always used that page that the downloads were quality and not corporate bloatware.

I am sorry.

When I release Build 1010, I will be updating the Mark V page with 2 proven reliable codecs (Google WebM) and the *real* XVid minimal (fast as hell).

On a positive note --- 2 Windows 10 machines --- capturedemo runs with flying colors with a proper codec installed.

/Why do some machines --- using Quake 11025 sound hz sound terrible and need 44100 just to sound ok? While other machines original Quake 11025 sounds just fine? Peeve of the day. 
Not exactly, haha. Read the "Mac Version Based On Fruitz of Dojo" on the Mark V page.

They invented it ages ago (2002?). It's a wicked idea and I've always liked it. 
@gunter -- Another DX8 Quirk, Eh? 
I'll check it out. 
@Bloughsburgh - Re:demo Rewind 
I wrote engine tutorials on demo rewind once and made working examples. qbism used it as reference to add demo rewind in Super8.

In Mark V, I went a bit obsessive and redesigned the FitzQuake 0.85 animation interpolation on just the client side to be completely reversible.

/Let's just say I like demo rewind 
@gunter - Latest Dx8 Quirk 
Can't reproduce. I used vid_hwgamma 0 and did several different things with ALT-TAB with maps running.

I use Alt-TAB and ALT-Enter all the time.

Does happen with clean install? What map is running? What mod is running? What does the Dr. Watson report say is complaint (if that applies in this case)?

I don't know too much about the internal wiring of the Direct3D wrapper.

Something to keep in mind, may or may not apply here, the Direct3D wrapper has been in use for ages in ProQuake (and it got a lot of use for "Open GL crashes/bad drivers"). I think I always kept the -gamma texture command line parameter allowing opt out of hardware gamma.

I'd recommend "developer 2" and then upload qconsole.log and maybe I'll see something. What I do know is this ... if vid_hardwaregamma 0 is in config.cfg and you start Mark V, Mark V never so much as touches system gamma even once.

Does this happen when you start game in id1 when there is already vid_hardwaregamma 0 in quake\id1\config.cfg. 
@gunter - Dx8 Quirk ALT-TAB Part 2 
In windowed mode, with vid_hardwaregamma 0 and gamma set, I can't think of anything obvious.

Windowed. ALT-TAB little different than using the menu or pulling up the console except the loss of keyboard focus. On Windows in really rare situations. Do you have 2 copies of Mark V open? I could possibly see something as possible there, yet I've done that a hell of a lot.

Fullscreen. There are more potential things that could happen with ALT-TAB. Are you connected to or running -FVF or can this happen with clean id1? As far as I can tell, in fullscreen mode it would always need to reload all the textures ... and this means recoloring all skins and external textures too. I've not had a problem thus far, not even connected to FVF an hour ago trying to cause a txgamma + DX8 + ALT-TAB crash and I was doing game -FVF for thoroughness.

/But you say this happens in windowed mode. It doesn't need to reload textures or recolor skins or anything in that scenario. 
This sounds like lost device handling somehow got broken.

In D3D terms, a "lost device" is what happens when you Alt-tab away from a fullscreen mode, but it can also happen under other circumstances (power-saving transitions, etc) and Microsoft don't document them all - primarily because it's actually impossible to (3rd-party software/drivers/etc may trigger a lost device for internal reasons of their own).

Changing Windows gamma while running in a windowed mode sounds like one of those other circumstances. Changing the screen resolution while in a windowed mode would be another.

The important take home is that naively detecting if an Alt-tab has happened is the wrong way to go about this. Instead you check the HRESULT from your Present call, if it's D3DERR_DEVICELOST you issue a bunch of TestCooperativeLevel calls until you get D3DERR_DEVICENOTRESET, then you release all default pool resources, Reset the device, then issue another bunch of TestCooperativeLevel calls until you get D3D_OK at which point the device is no longer lost and you can recreate the default pool resources.

Typically you'll get a crash if there is a default pool resource not released (more typically the Reset call will fail).

Hopefully that's sufficient info for Baker to troubleshoot. A good test to reproduce might be, like I said, try changing the Windows display resolution while running in a windowed mode. That should trigger a lost device, then trace through the code with breakpoints on the TestCooperativeLevel and Reset calls. 
MH: Hopefully that's sufficient info for Baker to troubleshoot.

Baker: Gunter ... MH say "don't play with Windows gamma control when DX8 version running."

He also say for best laptop maintenance, you should run laptop through dishwater once a year to clean keyboard. 
Interestingly ... 
The drivers I have on Win 7 don't seem to care if I play with the gamma in Windows while DX8 is running. Fullscreen or windowed, vid_hardwaregamma or not. 
I even changed the video mode in Windows after ALT-TAB out of dx8 both in windowed and fullscreen -- it didn't care at all and continued on.

My DirectX drivers would be quite different on Windows 7 vs. Windows XP, I would imagine. 
Ok, more testing.

Started Mark V DX clean, no config.cfg, no external anything. It defaults to a 640x480 window, and the standard demo starts playing (though I find if I stop the demos this behavior doesn't change). Then I click away from the window and adjust my windows gamma = crash. Dr. Watson says "Access violation." If you can tell anything from this, the chain of things Dr. Watson lists are:

dx8_mark_v.exe - iglicd32.dll - igldev32.dll - uxtheme.dll - etc.

Last couple lines in qconsole.log:

Accessibility keys enabled
Hardware change detected ... Gamma system set

But those things happen as I switch focus away from the window.

Repeat experiment with GL version = no crash.

Repeat experiment on older WinXP laptop, and no crash, but I notice a difference -- on my Netbook I am using a system tray icon that lets me select a pre-saved scheme for my gamma (and probably other settings). When I apply that, the whole screen flashes black for a moment. My older WinXP laptop doesn't seem to "Reset" everything like that when I just adjust the gamma. And I find that if I actually go into the video control panel on my netbook, I can simply adjust the gamma slider without anything bad happening too....

So it's not really gamma, but when my display settings get... "reset."

I find I get the same screen flash + crash if I alter my color depth or resolution (yep!).

Doing all these things on my older Win XP laptop = no crash.

Now for alt-tab in full screen testing.... I'm finding that now any alt-tabbing of fullscreen DX (not the more specific circumstances I previously mentioned) is crashing it.

And once again my older WinXP laptop handles it fine, as does the GL version.

So it seems that my netbook is doing some kind of harder reset of the display settings perhaps? Along with that stuff mh said. 
Small chance that if you turn off Themes in Windows XP, may avoid the over-protectiveness. 
Win XP Versus Win 7 
I forgot/neglected to mention - the Direct 3D driver model is very different on both OSs. Remember back in the dark days of Vista and Direct 3D 10, when Microsoft wouldn't make it available on XP? The different driver model is the reason why.

So it's XPDM (XP-) versus WDDM (Vista+) and WDDM is going to be more robust against crap like lost devices.

To make things even more interesting and fun, AFAIK D3D8 or lower don't even natively exist on Windows 7/WDDM (don't know if the same is true for Vista) - they're instead emulated through a D3D 11 layer. Likewise the old fixed pipeline doesn't natively exist anymore but is instead emulated via shaders (this is true even of D3D9 on XP).

So bottom line is that of course certain behaviours on XP and 7 are going to be different, and 7 is not a good testing platform for XP clients. 
microsoft tweaked their video memory routines for vista. before that they'd purge video memory on a whim - without even telling the gpu driver iirc. with vista, their compositor required them to not randomly wipe all gpu memory, which also means that earlier versions of d3d are less aggressive at randomly wiping memory, at least when running on vista+.
opengl drivers worked around it by retaining a copy of all their textures in host memory as well as on the gpu (which comes in useful when there isn't enough gpu ram), hence how they're able to recover properly on xp.

you can still get lost devices. opengl has an extension for it (and may still tell you about task switches so other programs can use video memory while you won't need it), and its part of the vulkan spec, but its much rarer that its fatal, enough so that you can afford the extra time taken by a full vid_restart (though you should probably not destroy the window itself).
typically it only happens (in vista+) when a driver is uninstalled or reset (the gpu crashed/stalled for 2 secs). Its also quite easy to crash a gpu with dodgy vulkan api use... 
To be honest, you would at this stage get better compatibility lifting the wrapper to D3D9.

I know that sounds counter-intuitive, I know that you're all about compatibility, and I know that you view the D3D wrapper as a means of providing compatibility in the face of deficient GL drivers, but using a lower D3D version is not necessarily the best way of doing this. It's not necessarily even a good way of doing it.

Take note of what I wrote above, paying attention to the part about D3D8 or lower no longer natively existing. That's hurting you and it's hurting your users.

Reality is that D3D8 was only a short-lived stopgap version between 7 and 9 whereas 9 was the mature, well-supported version that had a lifespan of over 10 years.

Lift it to 9 and you still get compatibility with XP, Vista, 7 or higher. Stick with the fixed pipeline on 9 and you'll get compatibility with hardware that even pre-dates D3D9. A lot of crap like your testing not being valid or your inability to reproduce bugs will just go away. 
Yeah, why you wanna hurt me with D3D8 Baker??

Heh, well, disabling themes seems to make no difference. But I get inconsistent results in testing....

Now it seems like if I alt-tab from just sitting in the console, it will crash, but if I alt-tab while a map is running, it works?

I was trying various things, like toggling the value of vid_hardwaregamma and sometimes it seemed like that was making a difference.... But now I'm not sure if that was it.

It works sometimes, and sometimes it doesn't.

Currently it seems like trying to do stuff (gamma change or alt-tab) either in console or with the startup demo running = crash, but if I load a map, then stuff works.

But I'm certain it has crashed before even when a map was running and I tried to do stuff....

So yeah, this is probably some back-end, obscure DX stuff which mh seems to know a lot about. 
@mh - Applied Science Vs. Pure Science 
I fall in the Applied Sciences camp (build bridges, highways). Knowledge for the purpose of building something and only for a specific goal, almost always must be part of the plan. Live by 90/10 rule.

I'm not going invest 6 months of learning Direct3D for (mostly) 1 computer that is 10 years old.

Many, many times I do fall into agreement with the Pure Sciences camp (you and Spike) ... like for instance Mark V has single point once-per-frame mouse code -- best maintenance free concept ever. It probably has 25 design principles that both of you would agree with, that I have forgotten -- like Mark V literally has automatic detection of transparent water -- not something close or can figure it out in any single frame, but the real deal. Or how Mark V does not have different source code for Winsock vs. BSD sockets (Mac/Linux) on the network side.

The Open GL is the main hardware accelerated build.

The nicest thing about the Direct3D 8 wrapper for old computers ... these old computers -- the drivers will never be updated, so the Direct3D 8 wrapper can never become obsolete.

I'm not a pure knowledge guy, I'm a "I have well-defined goals" guy. Plus I'm just one guy. My goal is single-minded pursuit of finishing.

"Real Artists Ship!"

I know that must drive you a bit crazy as a perfectionist, who is probably doubly annoyed that some of these things are your speciality (Direct3D, optimized rendering) ;-)

/And those like Gunter will be pretty happy with the results, even if he can't play with Windows gamma while the DX8 version is running. The other nice stuff (next update QMB) will make he not really care that much ;-) 
Mac Version 
Is finally being updated. 
@Baker Distorted 11025Hz 
I would lean towards it being a sound driver or Windows bug.

I hit a similar problem with SDL2, with just one of its audio output backends (xaudio2) producing distorted audio at 11025Hz; the others (winmm, directsound) were fine.

I know that's not directly helpful..
Bloughsburgh - if you are up for more testing, it might be worth giving Fitzquake 0.85 and the original id winquake.exe a quick check - both of those will also output at 11025 by default, and I expect they will have the same distortion that Mark V does, if it's indeed a windows / driver issue. 
I know that's not directly helpful..

Sure it is. Your knowledge of audio vastly exceeds mine.

Tells me I'm not going insane when I test on a random Windows 10 machine and that specific one, the audio is horrible and the others aren't. 
I tried winquake.exe and it appears to have distortion but I felt it to be less pronounced than Mark V. That could be placebo it is hard to tell.

The worse problem is the echo/airy sound when sndspeed is set to 41k. It is hard to explain through text so perhaps I will record a video and you can hear from there! 
Mac WinQuake Screenshot 
Finally got the Mac build basically caught up ...

Travail screenshot

Except I have some keyboard surprises to iron out.

Still, was a relief when I typed "install travail" and no surprises there ;-) I tried to code the downloader as platform neutral, but wasn't quite sure it would work first time, but it did which is unusual when coding in C).

Think I'm going to get back to QMB particles before I mess with the Mac input code more. Also didn't test out ipv6, "connect lan" or such and I want to rework startup. 
I doubt this is involved because you posted part of log before and it looked right, but its 44100 (-sndspeed 44100).

Just pointing this out since you typed 41k. 
Mac Version Essentially Done 
Open GL Mac with QMB option

Quake level networking and direct Quaddicted install (i.e. "install travail" or what not in console) and about everything else is rock solid.

But for some reason a couple of enhanced networking items like IPv6 had to be disabled (need to read docs, see if wrong headers or need to manually add some defines).

Also, took a pass (for now) on rewiring the keyboard input for international keyboard and never anticipated WinQuake stretch as a feature so unavailable for the time being. 
The nicest thing about the Direct3D 8 wrapper for old computers ... these old computers -- the drivers will never be updated, so the Direct3D 8 wrapper can never become obsolete.

Ultimately, of course, this is your call. I think it's a bad call, and I think your reasons for making it are actually more theoretical than pragmatic: a whole bunch of "what if"s, in other words. 
Well, I will say this. And no obligation or anything ...

If you were ever interested either in upgrading the wrapper or writing a new one using Mark V, FitzQuake 0.85 or Quakespasm as the base (*) to do Direct 3D the way you think it should be done.

Or implement water warp in whatever way you see fit ...

I would acquire it into Mark V.

If I had a huge chunk of time --- and I don't really have time to be doing even this, but it is lifting the regret of non-completion which was a large burden to carry ---

I'm more interested in the Spike-like networking things like compression, prediction and peer-to-peer downloads than I am rendering.

That's just the kind of thing I have been fond of over time as I have learned more about it.

I know you love rendering and performance in a hard core way.

So anyway, permanent offer that never need be redeemed nor made with any kind of obligation. Door is always open.

(*) Mark V is intermixed with the software renderer. It may or may not be easy or ideal as a modding base. I've also partially reorganized code to be easier to work with (from my perspective) but it also makes it harder to work with (from other's perspectives). 
Add: Part of this, to me, was reduce all the accumulated bug-fixes ever known from Inside3d, QIP, Enhanced GLQuake/WinQuake, the Quakespasm thread, this thread, plus maybe 2 others I independently discovered (lerping of brush models that get moved in Quake immediately, interpolation immediately after load game) -- into a living engine.

Plus raid all remaining features from the well established classic engines of the past.

Add some extra level of compatibility, then throw in a software renderer that can play everything ... throw in some Nehahra support and some extra level of backwards compatability for QRally, Malice, any other crazy stuff.

Then most of the very nice engines of the past, with very thoughtful and intelligent authors each with their own specialities and point-of-view (aguirRe, Jozsef, JPG the ProQuake author) ... have their additions coded in a backwards looking but future-forward engine.

/Already then! Back to coding! This lines of code aren't going to write themselves ... haha 
"The nicest thing about the Direct3D 8 wrapper for old computers ... these old computers -- the drivers will never be updated, so the Direct3D 8 wrapper can never become obsolete."

Just wondering about this -- what old computer would still be running DX8? My XP laptops are both using DX9c, and Mark V won't even run on my Win98 computer (I tried! -- Mark V only complains about needing a newer OS).

From what mh said, it seems the DX8 is already obsolete for any old computer that will actually run Mark V. I mean, I guess it works for the most part... but... I get the crashes.

But I guess it would take a lot of work for someone to change it in Mark V.... 
The neat thing is that Direct3D 8 and 9 are very very similar APIs. A large amount of the work is just changing the number '8' to '9' in types; do that and you're maybe 80% of the way there. 8 has combined texture stage states and sampler states, 9 separates them, but that's not hugely different. That's 95% of the way there, and everything else is just cleaning up. 
Tried the macOS version just now...

I have a folder named "id1" with the pak files inside it, right next to the Quake and GLQuake applications. When I run Quake it says it can't find the pak files. First I get a dialog that says this:

Your Quake folder should contain a folder named id1 with pak0.pak and pak1.pak.
Opening folder...

When I press ok, it opens a Finder dialog with the folder that does indeed contain id1 and the Quake/GLQuake apps.

Then it raises another error dialog with the usual "W_LoadWadFile: couldn't load gfx.wad" error, and also:

Is Mark V in the proper folder?

That path isn't where I have Mark V installed, and doesn't really seem appropriate for macOS. :-)

Just for double-sanity-check I opened pak0.pak to see that gfx.wad was in there.

Not sure where the problem is here. 
Ha OK, I went ahead and created a folder /Users/iOS/Desktop/Quake and moved id1 there, and it works.

From a quick code check, I think you compiled this with DEBUG active and that forced an unusual basedir. 
uhexen2/Quakespasm hit this recently:

The short version is, you have to use Finder to drag-and-drop the .app to a different directory (this clears some security metadata), in order for the application to load things from its current directory (i.e. find an id1 directory along side the .app).

Could be related.. 
Interesting! I'm on 10.11.6 though, so that's not hitting me, but might affect other people. 
MacOS Issues 
the video mode setting is not saved. At start, it is always set to 640X480 no fullscreen.
My Logitech G13 is not working, while the normal keyboard works. No error or warning message. 
---> MacOS Sierra 
Re: Mac Version 
Within 24 hours there will be a far better Mac version than the early 2015 build.

I'll double check the 2 items (folder, resolution) during testing. 
Yeah, Mark V can't do Windows 98.

Microsoft added a lot of API functions in later Windows versions for files, network, possibly video. Mark V uses a lot of those. 
Mac + external keyboard.

I've used external keyboards with my Mac for testing since a Macbook Pro, being a laptop, doesn't have a numpad, was only way I could test behavior of key pad keys.

I'm assuming a LogiTech G13 is a keyboard. 
LogiTech G13 is a small programmable keyboard. It uses Logitech Gaming Software for customising keys. The Mark V�s window version works fine with it. 
GL or DX -dedicated still crashes, but not as quickly as before....

Ah, it crashes upon trying to load a custom bubble sprite.

The following line never appears in the log if the custom sprite exists, because that's the exact point it crashes:

Warning: FindFile: can't find progs/s_bubble.spr_0.tga

Getting rid of the custom bubble sprites allows the -dedicated server to run.

Minor note: The help info for hdfolder calls the command "hd_folder"
Same with help _hd_folder 
@gunter ... nice catches x 2! 
Build 1010 with a Mac version should be available within an hour. I'll mostly waiting on my Mac to do some sort of update, and then make sure the revised code base compiles.

@johhny - in the previous version, I'm pretty sure I just did a Debug build for the Mac because was more convenient. I'm hoping there wasn't some other reason I did that, especially since QMB is slow as hell in a debug build. We'll see.

@icaro - I have a couple of theories about your Logitech keyboard. I'll explain later, but both theories mean the Logitech keyboard + Mac may be unactionable by me in the short term. I have newly written input I wrote a year ago which would likely solve issue, but integrating that would be deeper than I want to go right now because might require 50 hours to do. At some point, the Mark V Mac build actually won't be based on Fruitz of Dojo at all. But to get there would require some serious time (200 hours) because I would need to rewrite the sound output code from scratch and some other subsystem which I can't remember right now.

@gunter - next version doesn't touch QMB. I want to do that all in a single swing of the proverbial hammer. So yeah, -dedicated bubble issue with Open GL/DX8 will remain for this build. Which will have very short half-life if things go well. 
The skin application in GLQuake and WinQuake are different. See the argument in the Quakespasm thread (it's buried), the different viewpoints and the final consensus reached by the developer types and mappers.

Regarding Mark V: maybe it could be a cvar? The default value would be GLQuake-like for all exes, and toggling it would switch to software-like behavior, also for all exes.

The point is mainly to have consistency between the software and hardware versions of the port. 
Is there a particular reason that my HUD is different depending on which executable I run? Do they store different config files or something like that? 
I'll put that on the eventual to-do list. I know I'd like to see what that looks like. I can understand that since you like to remodel that you probably find it quite annoying. 
Is there a particular reason that my HUD is different depending on which executable I run

Can you clarify that? Like what executable is A and what executable is B? 
I can understand that since you like to remodel that you probably find it quite annoying.

Well, one port being flexible won't really fix the situation as a whole, so I'm not sure how useful it will be.

Still, I imagine most custom assets were produced with the GLQuake standart in mind, so having a software port that can display them correctly would be interesting.

Or rather semi-correctly, since there's also the issue of perspective correction. 
@pritchard - Scr_scaleauto 
Mark V has automatic HUD scaling, it is enabled by default and if its value is non-zero it will ignore scr_menuscale, scr_sbarscale, scr_conscale, etc.

scr_scaleauto must be set to 0 for Mark V to honor those settings.

It's in the preferences menu, it's primary purpose of defaulting on is to avoid the microscopic HUD thing that has been prevalent in FitzQuake and derived engines. 
Mark V - Build 1010 
Temp Build ...

Build 1010

Windows: Open GL | Direct X 8 | WinQuake

Mac: Open GL | WinQuake

May take a minute before the uploads are completed. 
Sorry, I should have clarified in my post. The first screenshot is from mark_v_winquake.exe and the second from the regular mark_v.exe. Both are running the same config, which is why it seemed odd to me that they looked different.

I think I've figured it out though. It seems to be because I have it set to the Translucent mode, which is supposed to be GL exclusive and just makes the whole thing dissappear in winquake, which made me think it was using the minimal style instead. 
Ah, WinQuake Mark V doesn't support autoscale at this time.

Although in video options, you can set stretch, which in some ways has a similar result.

Mark V WinQuake doesn't have the same type of translucency that Open GL has for menu items and such. WinQuake doesn't really support translucent because is 256-colors. 
It also seems that interface scaling doesn't work in the Winquake version. 
I Started Typing When Baker's Post Didn't Exist Yet 
Why is there a separate Winquake version? I'm trying to understand the use case or benefits of having it if it isn't feature complete anyhow. 
WinQuake is the software renderer, like the original Quake. 8-bit palette, pixelized rendering, chunky particles, water warping, no brush Z-fighting ever since brush models clip against world, etc.

killpixel -- and some others into the original Quake look -- is obsessed with the original software renderer ... 8-bit palette, very pixeliated rendering -- some releases like Kaahoo look obsoletely astonishing in a way that the Open GL engines can't quite do.

WinQuake/original DOS Quake don't have a way to scale 2D. But it is on my list to do so it has equivalent autoscale.

Because of the prevalence of Open GL engines in modern times, it is usually more hardcore or throwback types or those that want the "out of the box 1996-style" that tend to be aware of the software renderer.

As far as I know, when GOG site sells Quake there is a shortcut available to run original DOS Quake in DOSBox as an option.

When Sock discovered Mark V WinQuake ...

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

.. and included a link to Mark V WinQuake in the Arcane Dimensions readme for anyone who wanted to try it.

The WinQuake build is there for nostagia or as a "wish WinQuake could run BSP2 or modern maps".

/When time permits, there are few more things I want to do to the WinQuake renderer, but it's a short list (autoscale, masked textures, brush model .alpha). 
Bmodel Alpha 
That was one of the things I missed the most when trying my current project out in mark_v_winquake. I have quite a few windows in my map and they look absolutely awful when they're not transparent :(
I can live without coloured lighting, but not without my fancy see through brushes ;-; 
I wholeheartedly agree. It is something I'm not satisfied with, but also near the top of the difficulty scale to implement properly. I have 95% implementation on my hard drive, but I'm doing something wrong with 5% and I suspect a mental block is preventing me from seeing what it is -- as a result, I suspect one of these times I'll look at it and then be like "Aw hell ... how could I have forgotten that step."

But for now, lives on the to-do list. 
Temp DX8 Build Mostly For Gunter

-dedicated fix
-txgamma fix related to lightning gun

(*) The QMB particles are intended for alpha blending. Due to this texture gamma should not be applied to them, so they no longer receive gamma correction. 
Lightning Gun Sparks Test 

Testing/fixing a lightning gun beam collision issue, which before fixing did not consistently generate sparks (QMB option) ...

At 28 seconds in, discovers original E1M7 bug that wakes a Shambler used for Chthon death gib chunks. 
@gunter - A+++ Bug Report On Bubbles 
qmb bubbles go away like clockwork

Mystery solved:

Original code:
#define ONE_FRAME_ONLY (0.0001)

First, 0.0001 is an irrational number in binary. Second if someone is running 10,000 frames per second in Quake, they have far worse problems than bubbles. Third, the larger the number of seconds into a map, the more that floating point is going to truncate the current time ... potentially thinking that a bubble's time has always expired.

#define ONE_FRAME_ONLY (1.0/1024) // (0.001)

1/1024 isn't an irrational number in binary. The problem would eventually crop up again at some point (300 minutes +/- or maybe 600 or 1200 minutes+/-). It isn't uncommon for it to take 40 minutes to play a map (and some of the modern maps with 400 or 600 or more monsters ...).

There would be other ways to solve the problem, some arguably more correctly, but at the end of the day QuakeC starts getting problems with time calculations after a map has been running hundreds of minutes too.

/This is the kind of bug that could literally never get noticed. If you have QMB bubbles on, you wouldn't see them to know they weren't there. I don't think anyone ever noticed in JoeQuake. Qrack might have similar behavior. 
could you check the main menu of the nehahra mod
i couldn't select the "quit" parm from there 
@spy - Re: Nehahra Menu 
Could you list each item in the main menu of what you are seeing?

I have
- Single Player
- Multiplayer
- Options
- Credits (which goes to help)
- Quit

And quit works for me.

But if I recall there is like a "Nehahra movies" version that lists 6 items or something and has an extra menu -- I don't know what it is labelled.

Maybe you are using "Seal of Nehahra" or something?

If you can provide me a link to the download of what you have and where you got it from .. I can take a look.

The one currently supported is the Spirit repackaged one, because it is all in one zip file and easy to install.

If I recall, before the Spirit repackage, was one heck of a mess to sort out. 
Mark V - Build 1101 - Now With Mac Build 
Download at usual location:

Mac Version

- Mac Build: Open GL with QMB effects option image
- Mac Build: WinQuake software renderer image

All Versions

- Better lightning gun sparks (QMB option) video
- Improved lightning appearance @ Chthon (QMB option)
- Solved disappearing QMB bubbles (gunter)
- Solved non-lerping QMB bubbles (gunter)
- Install command returns (johnny law)
- GL -dedicated crash fix (gunter)
- Automatic saves named auto_save_0.sav, _1, _2
- DirectX 8 .alpha entities now consistent (gunter)
- Malice banshee rendering issue solved with sv_gameplayfix_setmodelrealbox 0 (dwere)
- Internal commands removed (c0burn)

Mac Note For Open GL

For the moment --- to adjust gamma typing "txgamma 0.7" in the console.

Contrast adjustment is available in the menu, haven't decided how to handle gamma slider on the Mac yet. Leaning towards 1 second delay after stop moving slider.

Mac Quaddicted Support!

In Mark V, you can type "install travail" in the console.

More important on the Mac since the Quake Injector does not run on a Mac.

/Mark V auto-completes the names of 500+ of the highest rated Quaddicted single player releases. Type install and then press Ctrl-Space (Command + space?) for list. 
i've got

- Single Player
- Playdemo
- Multiplayer
- Options
- Credits (which goes to help)
- Quit

- sp works just fine
- playdemo - behaves like multiplayer
- multiplayer - options
- options .. and so on 
I dl'd the N from quaddicted as is , no movie

and just run it via batch file "mark_x -game nehahra -noserial -nojoy -noipx -nocdaudio" 
These Updates... 
are coming faster than I can download them! xD 
Baker Is A Coding Machine 
just like Sock, in a good way 
And A Little Request To Baker 
to add a qqq command from S - as quit command 
Nehahra Menu 
Waking up a wall shambler in e1m7 is probably the good old Lighting Gun coding weirdness where the shaft appears way off in totally wrong places when hitting walls just right. So your shaft found its way into the wall box....

I know of one good place to demonstrate the glitch on DM3 -- shafting this position hits person standing to the left:

I remember years back when I was looking at this weird code, I made the invisible beams visible, and they are just crazy, heh. I didn't know what the heck they were trying to do with that code, but since the visible beam actually penetrates players, I thought perhaps they were trying to make the damage beam penetrate things as well, so that's how I fixed the shaft in FvF -- the shaft will penetrate up to 2 entities in a row and still damage a 3rd (with a decrease in damage each time 30-20-10).

This old post on Quakeone links to a very detailed analysis of the lighting gun glitch:

That's... pretty complicated stuff. The takeaway is that the lighting gun code is pretty borked, and you can end up hitting something way off somewhere else, like a shambler in a wall box. 
So your shaft found its way into the wall box....
Suddenly I pictured the image of a glory hole in my head... 
One Frame Only 
If you want a particle (or any other effect) to only last one frame, set a flag on it when spawned (you should have a "flags" member in your particle struct for this), then set it's die to cl.time + SOME_BIG_NUMBER (I like 666 for the humour). Draw it as normal. Then after drawing, check if the flag is set (and !cl.paused) and if so, set it's die to -1. Done. Works if Quake is running at 10 fps or at 10,000 fps. 
dx8_mark_v -width 750 -height 550

= borked up screenshots

Why was I running at 750 x 550?
Because you told me:

"2) Then don't use 800x600 windowed mode ;-) Not engine's responsibility to save the user from his own choices. "


Heh, yeah, that issue I was having only applies to the Windows version, but my resolution had been changed when I ran that, and that resolution was applied the next time I ran the DX one, and then my screenshots ended up being borked up.

It doesn't seem to affect GL. 
Now for the issue I was trying to report before I had to stop and figure out why my screenshots were borked up:

Mage in FvF fires 4 vore ball models for his cloudkill attack. If they hit a surface not very far away from the caster (like a wall or the floor), then you fire again (even if you wait like 10 seconds), the QMB purple trails think they started at the last position of the last ones....

Perhaps it's reading the position of the former temp entity which probably has the same edict number as the new temp entity....

Though the issue doesn't occur when a surface is hit farther away from the caster. I believe that's because the former position is too far away from the new position. Ah, yeah, if I shoot a surface far away, then run up next to it, I get the same effect. So the last position must be near the new position.

Aren't you glad you have me to report these weird things instead of having to wait 100 years for them to be found? heh 
Dx8_mark_v -width 750 -height 550 
Neither 750 nor 550 divide evenly by 4. This is significant for graphics hardware, and even more significant for Direct3D which has less software emulation than OpenGL.

Try 740 x 540. 
@spy - Create and alias. Like in your command line "<engine> +alias qqq quit". Then if you want to have something like "qqq" do quit, then it would.

Looks like there is a "gamemenu.lmp" in Nehahra, I'll make Mark V use that when -nehahra is used, will make the menu normal instead of the very weird one.

@mh - QMB uses tons of inlining and preprocessor macros and initially when I identified problem thought "yeah, let's do a boolean field" and then I looked at the code and thought "Uh ... yeah, how about let's not rewrite the whole thing over a bubble".

@gunter - What MH said about the multiples of 4. Mark V has coding in Open GL and the WinQuake version about that and in screenshots, but Direct3D won't cooperate. Also the Open GL with capturedemo has problems with width not multiple of 4. Not multiple 4 is real pita, but mostly gone in Mark V.

With the Open GL version of Mark V, you can actually add -resizable and resize the Window with your mouse. But I haven't tested it lately.

Haven't mentioned it -- mostly to keep you out of trouble ;-) 
Also: Ctrl-Up And Ctrl-Down Resize The Console 
You have to have the console open to do this. 
Mirror can be solid face only? It doesn't work if it's bmodel, like func_illusionary. Is it possible to implement? 
Let me think that through.

I can't have mirrors be a true entity that can moved (like door or wall), otherwise pre-calculated mirror visibility would be issue and even possible map compile tool support couldn't help.

However, func_illusionary can't move. Hmmmm.

However, is problem I think --- func_illusionary is communicated to client through QuakeC and isn't instantly available upload level load but is still rather early ... let me think about it.

Question: Scale of 1-10 ... how important is allowing func_illusionary to do this for what you are doing? Only ask because might be annoying for me to code, but if you are making something worthwhile ... might be worth the headache. 
that's just an addendum to spice up the super secret. I placed a mirror, compiled it and found that mirror almost asks me to try to pass through it. I compiled the new version with func_illusionary and found that the magic was gone. If it's really a lot of work than I don't think it's worth it. But if that is implemented, I think it could be used in many new maps, because people love to make fake window secrets, fake mirrors can be the evolution of that type. 
Multiples Of 4 
This is an important difference in the design philosophy of OpenGL and Direct3D.

With GL the specification is god. That means that if the specification says that something must work, then it must work, even if it's not supported by hardware. Typically this means that the driver will drop you back to some kind of software-emulated path. It's historically been a weakness of GL that you have no way of programatically determining when/if this happens. NPO2 textures were a bitch when the first GL2 drivers came out.

With D3D the hardware is god. That means that if something isn't supported by the hardware then the driver is under absolutely no obligation whatsoever to support it either. It might crash, it might give you undefined behaviour, it might give you messed-up screenshots. The downside is that historically D3D has been an unholy mess of capabilities bits and responsibility is on the program to check these and code fallbacks.

D3D does provide software emulation of parts of the per-vertex pipeline for older GPUs that don't support hardware T&L, and you can actually do crazy shit like write SM3.0 vertex shaders in D3D9 and run them on an old 3DFX. But that's the limit of what it emulates, and that emulation is provided by the common runtime rather than by the vendor-supplied driver.

That's another difference.

D3D is actually two separate components. A common runtime is provided by Microsoft, that's what you install on your PC when you install DirectX, and that's the same irrespective of what hardware you have. Then the vendor provides a lightweight hardware-specific driver. Your program talks to the runtime, which talks to the driver, which talks to the hardware. Because the runtime is common, consistent behaviour is easier to achieve. Because the driver is lightweight there's less for the vendor to screw up. There's also potentially less for the vendor to optimize, and D3D doesn't have extensions.

With GL the vendor provides everything. That means extensions and potentially better optimizations, but also means more room for driver bugs and inconsistent behaviour. The total absence of GL conformance tests for such a long time didn't help. God only knows what goes on inside some GL drivers.

None of this will help anyone fix any issues, of course, but it might help some understand why things are the way that they are. 
I'll see if I can add it. 
Good news: the new Mac build will appropriately find id1 if it is in the same folder.

Annoying news: if id1 is NOT in the folder, it will crash (after pressing the Play button to get past the args dialog).

I can send you the full diag output if you like, but here's the interesting part of the stacktrace for the Quake app:

Thread 0 Crashed:: Dispatch queue:
0 libsystem_c.dylib 0x00007fff9a93809e flockfile + 4
1 libsystem_c.dylib 0x00007fff9a939a66 fputs + 72
2 com.quakeone.mark-v 0x000000010c2d9f1a Con_DebugLog + 266
3 com.quakeone.mark-v 0x000000010c2d9a71 Con_Init + 1249
4 com.quakeone.mark-v 0x000000010c2497f2 Host_Init + 98
5 com.quakeone.mark-v 0x000000010c2d7ff9 -[QController newGame:] + 2249

And for the GLQuake app:

Thread 0 Crashed:: Dispatch queue:
0 libsystem_c.dylib 0x00007fff9a93809e flockfile + 4
1 libsystem_c.dylib 0x00007fff9a939a66 fputs + 72
2 com.quakeone.mark-v 0x000000010e15f40c Con_DebugLog + 266
3 com.quakeone.mark-v 0x000000010e15f018 Con_Init + 635
4 com.quakeone.mark-v 0x000000010e155525 Host_Init + 91
5 com.quakeone.mark-v 0x000000010e1a97f1 -[QController newGame:] + 1209

Maybe Con_DebugLog is unhappy that there's no folder to put the debuglog in. 
Different thing: I did a quick test of the install and uninstall commands.

For a separate game folder (tested using digs01) everything worked as expected.

For a "bare" map that got installed into id1\\maps (tested using czg03), uninstall didn't quite work. Output from qconsole.log:

uninstall: folder "/Users/jbaxter/Downloads/mark_v_mac/czg03" does not exist 
Thanks for giving the Mac version a test.

1) Mark V Mac not in Quake folder with id1 = console debug angry = will fix. I think at one point I decided the binary needed to be in a proper Quake folder, and then I changed my mind (or something to that effect).

2) Uninstall of simple map - Mark V plays it dumb and only looks at what is out there. So uninstall only works on a gamedir. It would have a way to know what maps are part of set and since Mark V doesn't know, it can't do that.

/In the future, it is a near certainty that Mark V won't unzip anything and just use single player releases from their zip file. This will allow future Mark V to peer-to-peer transfer a required .zip for a coop game, instead of each file. 
@johnny Re: Install 
"install" is very flexible and should be able to install most single player releases or even traditional mods via URL.

Install via URL examples

1) install
2) install

Doesn't matter how the .zip is packed, provided it has a .bsp, .pak or something that looks playable. Mark V looks at the contents and figures out how to unpack it. Name of .zip determines gamedir. So will end up in -warpspasm

Can only do zip files (no .rar, no .7z). Must be http, no ftp or https. 
New Build 
Cool lighting gun effects, I also enjoy the jerky+normal!

Capturedemo still gives a black video with sound. Upon looking at the .avi it shows that the data rate is 28kbps and the audio rate being 1440kbps. Clearly it just isn't recording video data.

You said something about this releasing having a link straight to the codecs? I came to the same site when clicking the codec link.

Sounds at 44k is still airy but that's damn possible it is how it is. Maybe it is how QS interacts with my sound driver. The more I try to listen for it the less apparent it becomes. 
@Bloughsburg - Install Google WebM/vp80 Codec 
Install this (tested on 2 separate Windows 10 machines to make 2x sure)

Google WebM/vp80 (mirror):

Source page:

But yeah, install the VP80 codec and that issue should go away.

Make sure capturevideo_codec is auto (default value), Mark V will use VP80 as first preference when looks at installed codecs.

/Says something about 32-bit only on that site, they are so very, very wrong and apparently the creator of that page is unaware of the WOW subsystem (Windows on Windows).

/I'm still mad at that DivX site. 
I haven't had time to update the page yet --- I'm hoping to clear the queue of outstanding stuff for Release 1.1 tonight.

- QMB particle rework for Gunter.
- Alpha channel texture support for 2D replacement elements
- Pulsar mirror on func_illusionary request
- Nehahra use gamemnu.lmp instead of dumb mainmenu.lmp (spy)
- Mac startup if not Quake folder (johhny)
- IPv4 address prints strangely on Mac.
- Maybe hopefully: WinQuake via GL for killpixel 
Seeing Colors

Very cool, that'd be it.

Couple of questions:

When capturing the demo, if you open the console it will speed the recording by a substantial amount. I found that whenever the console is brought down it is not recording. Intended?

Anyway to jack up the quality...bitrate? (Purple noise and general noise in video linked). Even if there is not, this is a pretty nice feature considering we have here 720p @60fps :)

Thanks for your efforts. 
@spy: Re: Nehahra Menu 
I think you might have a typo in your command line or are missing -nehahra, because I already coded for this scenario.

Nehahra should be started as:
Console: game nehahra -nehahra
Cmdline: -game nehahra -nehahra
Cmdline: -game nehahra (won't work properly)
Console: game nehahra (won't work properly)

The above should fix. 
@ Bloughsburgh - Capturedemo Working For You = Awesome 
Type "find capture" in console. If you haven't discovered this, it is super-awesome.

You'll see one of the things is "capturevideo_console"

When that is 0, it won't capture when the console is open. This is to avoid ugliness if you type "capturedemo" in the console --- you don't want 1 second of console closing in your AVI ;-)

I'm very happy it is working for you. 
Bad Unpacks 
MarkV seems to have trouble unpacking at least one release: the new RetroJam5. Example:

It unpacks everything under the id1/maps/ directory, meaning that there is now an id1/maps/maps and id1/maps/source directory. The source folder is fine I suppose, but the /maps/maps seems to be problematic. Typing in the entire path to the map works fine, but tab completion doesn't work anymore... 
Shall investigate, thanks for letting me know. 
Is there a way to skip the credits when pressing quit from the menu? It's a little thing, but after using QS for so long I'm not used to pressing another key to get out of the game. 
Type "quit" in the console or click "X" to close window or bind "quit" to F12. 
Alright then, binds it is. It'd be nice to have as a config option at some point though. 
I've the "install" so it can figure out .zip files arranged like retrojam5. In testing, never hit one setup like that, but so many packs out there.

/I always hit ALT-ENTER and then click "X" to exit. Or pull up console and type quit. Quake out of the box and most engines (like FitzQuake 0.85) show the closing credits via the menu route. 
I think you might have a typo in your command line or are missing -nehahra, because I already coded for this scenario.

yeah, i missed that additional -nehahra argument

but for some reason console barks on missed fmod.dll module, and i have one in my quake folder 
Try putting it in the nehahra folder. 
is it possible to fix nehahra's nomonsters command
there is a strong c++ guy needed tho 
nomonsters 1 - and they don't act so crazy

They still move a little funny, but not insanely funny. 
I seems like the func_illusionary mirror support doesn't work so far. I'll experiment more with that when I get from work. 
I'll be taking care of that. You need not worry about that. Haha.

Before the night ends in my time zone on the other side of the world, there will be mirrory func_illusionary.

When the guy who made Menkalinan, one of my favorite maps of all time, has an idea -- yeah, I think I want to play that map ;-) 
I thought about putting instructions on the proper way to run nehahra on the page for Mark V. Or even block / warn in the engine.

Then I decided against it.

The way I see it --- when knowledgable people like yourself encounter a small issue, it enables the knowledgeable crowd who read the discussion to help the newbies who would mess it up no matter how hard I documented it. And gets the less knowledgeable to read threads to expand their horizons.

Also: the awesome thing about func_msgboard is that the participants are expert level and through discussions in threads like this, it educates to create more knowledgeable users. 
@spy - Fmod.dll From Mark V Page 
You need that one. One in Spirit's very nicely repackage is not good fmod.dll. 
Done for next version, but no time to build on Windows and then the Mac and package and rebuild the installer version, etc. etc.

1) Mirrors for func_illusionary, mirror scanning moved to cls.signon == 2 (after all the static entities received, walks any statics too. Tested by turning an E1M1 door into a func_illusionary as a test)

2) IPv4 printing on Mac fixed
3) Mac startup fixed when Mark V isn't in a proper Quake folder
4) Autosave was saving as wrong name, fixed.
5) Installer can handle zips like RetroJam5 which had unanticipated structure.
6) Non-issue: Nehahra menu (already coded, lack of -nehahra caused issue)
7) Non-issue: Alpha channel 2D elements (already supported)
8) QMB reworked for gunter ... QuakeC originated particles either render via QMB consistently with expected appearance or if individually disabled, with QMB active, via qmb_particles_quakec 0 --- draw particle in the classic way. Results generally in a more mod friendly implementation of QMB, where its behavior is predictable.
9) Something else for the Mac. Forgot what it was.

Note to self: Update page with link to the codecs folder. Put a .txt in there that says name of parent site for each of the 2 and put the (slightly annoying) instructions to disable the XVID status window via the registry (i.e. Run regedit.exe and find key "HKCUSoftwareGNUXviDdisplay_status", set to 0.) 
Can't Keep Up With These Updates 
any eta when I get to try out splitscreen w/ controllers? 
Yes, update! We are the test gorillas who want to beat on your luggage to see if it breaks! 
If you were ever interested either in upgrading the wrapper or writing a new one using Mark V, FitzQuake 0.85 or Quakespasm as the base...

OK, I've done the initial port of the wrapper to D3D9 with a Fitz 0.85 base (actually the original DirectFitz I made years ago). This is just the "do enough to get it working" stage, but it has established that (1) the port works, and (2) it's viable to move forward from.

If you have any requests for features to add to it, now is a good time. I'm thinking glCopyTex(Sub)Image and the full set of combine modes would be good candidates. Stencil. Fix polygon offset. Texture matrix stack. Vertex arrays. NPO2. I just mention these but without commitment to do all of them. 
@mh Re:wrapper DX 9 Thoughts (1 Of 2) 
If you have any requests for features to add to it, now is a good time.

1) Enough that I can do mirrors (stencil plus depth splitting trick - split range into 0 to 0.5, 0.5 to 1) .. Despite not having stencil, in theory mirrors should work in DX8 (without stencil, so glitches particular for the sky), but the wrapper hates me when I try and it doesn't work -- probably fighting an optimization.

2) 8x multitexture (which was easy, even for me), GL_TEXTURE_MATRIX (which I have zero chance of doing myself). "Combine".

3) The feature where you copy the screen to texture (FitzQuake's oldwater). Yeah, I know you aren't fond of that one. 
Mirror func_illusionary doesn't work for me in the latest release as well. I should have mentioned that these are AD func_illusionary, though I doubt they have any difference with the regular ones. I tryied both every side mirror texture brush and one face with with mirror texture and the rest covered by skip texture. Neither of them work.
I'll try to do that in vanilla quake and let you know if it works. 
@mh (fifth Might Wanna Read) 
No obligation and separate issue - but you've written controller support before and no one else does Microsoft Direct X type of coding on your level ... and XInput is probably similar ...

I've looked at the XInput tutorials from Microsoft and my head about exploded all the monotonous steps involved and not necessarily even understanding what is going on for sure.

Multiple controller support (hell even single controller) where each controller can be read separately once per frame.

No obligation, but since that kind of thing falls in your wheelhouse, I thought I'd bring the topic up as an example of something nigh impossible for me, but that falls into one of your primary strengths categories. 
Haven't updated the version yet, got to audit the code, etc. I'll do I "New Version" kind of post after I update it. Might be 2 hours. 
I see. I've even made a special test map for it. Can upload it for you for easy testing. 
Exactly! Yeah, everyone's beta testing and the level of detail has been incredible. Best experience as an engine coder ever.

And your unique perspective as an active QuakeC coder running a server has been an invaluable contribution.

Very nice that everyone has been bringing some unique perspective to the table. 
Yes, do that! 
...XInput is probably similar...

It's not unfortunately; XInput is actually very different.

I'm not certain what tutorials you've looked at, but IIRC XInput is just 10 or so lines to initialize, then another 5 or so to read the input. Everything else is translating input data from XInput format to Quake format (i.e. button mapping, etc).

Quake's joystick code is NOT DirectInput - ignore what it says in the comments in in_win.c; it's NOT DirectInput, it's actually a totally different Windows multimedia controller API. DirectInput joystick code looks a little like the DirectInput mouse code.

I wouldn't touch multiple controller support with a 10 foot pole. You need support for multiple clients first, and that's not a light undertaking. I know you're getting requests for splitscreen, but it's not something you can just easily patch in. I think your time is better spent elsewhere. 
It's all good. I thought I'd ask.

(@fifth: eta = very murky. I will promise that it will happen at some point. Maybe spring. It's important to me.)

/Yeah, I know joystick in Quake isn't DirectInput but multimedia. 
The feature where you copy the screen to texture (FitzQuake's oldwater). Yeah, I know you aren't fond of that one.


I just need to sanity-check my bottom-left-is-origin to top-left-is-origin conversion, but otherwise - done.

An interesting FitzQuake bug arose while doing this, that's specific to a GL vs D3D difference.

In GL the current viewport doesn't affect glClear calls.

In D3D the current viewport does affect IDirect3DDevice9::Clear calls.

So in other words, in D3D the clear is bounded to the viewport dimensions.

This came up because FQ sets a smaller viewport to draw the warp images, but doesn't unset it before clearing; that small viewport is therefore the only cleared region. A "GL_SetCanvas (CANVAS_DEFAULT)" was needed in R_Clear to work around this. You could probably also put it in R_UpdateWarpTextures.

This wouldn't affect D3D10+ where the clear is done directly on a render target view, and I have no idea if it affects D3D8-. 
Odd what MH is saying, you had a video with multiple clients and splitscreen?

I don't have much choice but to wait... us non-coder guys are at the mercy of whatever you guys decide tbh. :P 
Mark V Build 1011 - Temp Build 
pulsar - this doesn't have func_illusionary mirrors. I'm putting that in separate 1012 build in case I messed up something ...

Build 1011 - Windows only GL|DX8|WinQuake

Everything except func_illusionary mirrors, in case func_illusionary mirrors explode something.

@fifth - I multitask extremely poorly. Can't get into deep discussion with MH about that without jeopardizing what I'm doing now. If I mess up 1 line of code ... you get the point. 
I also multitask poorly but am less disciplined about it, so I'm heavily dependent on people just backing off. :) 
Yeah, ...

This func_illusionary mirrors thing is cool, but has several points of modification. Don't want to unleash an exploding build.

/Ok .. concentration time ... 
Implemented WGL_EXT_swap_control - vsync no longer needs a mode change and works perfectly. 
Hah... it's cool guys, I'm probably one of the few people in the community that is even bothered about that stuff.

If I had it my way every classic 90's shooter with multiplayer would have splitscreen in it ;) 
Do you have any plans to allow for a custom crosshair graphic when crosshair = 2? 
So the difference in the QMB particles is that I can turn them off?

Otherwise previous issues still exist. 
@pulsar - carry on knowing the feature will exist in a few hours ;-)

I'm slowboating a little because I noticed some scenarios I didn't consider and uncovered what might explain why all my attempts at adding alpha masked textures in the software renderer failed while looking through the mirror code, which doesn't matter right now but has me slightly annoyed at myself.

So I'm walking through the several pieces to make sure I didn't make any mistakes. 
Already supported for crosshair 1, but I sense you may know that since you said crosshair 2.

Crosshair 1 is gfx/crosshairs/default.tga, which I am thinking is the same as DarkPlaces, but I can't really remember and I know DarkPlaces supports many crosshairs.

I never anticipated a reason that someone would want to substitute for the dot crosshair, but I am guessing you have a scenario in mind like an alternate gun crosshair or something?

/If you have a good scenario, I'll put it the eventual to-do list because I suspect even 2 crosshairs would not suffice. As soon I get pulsar func_illusionary mirrors ironed out, Mark V version 1.1 is wrapped and I plan on taking a break for a few weeks (I'm kinda burnt out). 
So the difference in the QMB particles is that I can turn them off?

Otherwise previous issues still exist.

Could you identify which ones? I thought I got them all, but maybe not? 
@c0burn - Extra Thought 
Is it just a 2nd crosshair for a gun?

If you tell me what DarkPlaces expects the replacement texture name to be, I'll see if I can add an alternate crosshair 2 to version 1.1

And I'll change the dot crosshair to be crosshair -1 (or something). 
Like version 1.1 is the one I'm wrapping up now. 
#274 above -- what should be blue particle splashes sometimes come out as orange sparks (watch the splash.dem in the zip I linked to).

Even when they are not sparks, the blue QMB particles just appear then vanish without moving outward, as they do with QMB disabled.

The other issue wasn't really about particles, but about how an effect trail thinks it started where the last one ended if you are near that position; screenshots in #414 above. I found this quirk also happens with the rocket launcher trail, but it's faster moving and harder to reproduce. Try shooting a wall (like the one in the position of the screenshots), then move next to the wall and fire your next rocket, with the point of impact of the previous rocket still in your view. The rocket trail will originate from the previous impact point. Same with the trails from lava balls and knight spikes. 
1) The QMB trails. Yeah, those sometimes they get confused. Inherited from the JoeQuake implementation. At some future date I'll fix that. It is hard to reproduce, annoys me too. It is more frequent with non-Microsoft compiler (Mac version has it happen more often).

So could be the compiler doing it. On longer term list.

2) Blue particles become orange ... yeah, I hear you. Likely similar issue to #1. Also I noticed Shambler charge up has slight checkerboarding and doesn't in JoeQuake -- tried to unearth the reason, couldn't figure it out.

Those little nuisances will dealt with at a future, but I think I inherited from JoeQuake implementation or compiler related or compiler optimization.

My mana bar is too low for me to take that on right now. 
The shambler thing doesn't actually look bad....

Wow, super ugly effect in DX with:

vid_hardwaregamma 0
chase_mode 2
chase_active 1

and swing the camera outside the wall. Doesn't occur in GL.

gl_clear 1 fixes it.

Is there any reason why someone would want gl_clear 0 [default]? 
@c0burn - 4 Crosshair Support In Mark V 1.1 
Decided to add support for multiple replacement crosshair textures.

Dot crosshair (currently crosshair 2), will become crosshair -1.

@gunter - gl_clear 0 is faster and you don't have to redraw the status bar every frame (if the status bar is solid like original Quake and not transparent or see through). 
Replacement crosshair texture names will be named


Expected 32 x 32 texture with alpha channel.

A JoeQuake/ezQuake/Qrack crosshair is likely to work if it is a .tga

I named the texture names slightly different than DarkPlaces which doesn't have the underscore, because I don't know what rules/sizes DarkPlaces expects for a crosshair texture and it may suppport things like huge sizes, which I would not be willing to do. 
Is "gl_clear 0 is faster" just academic at this point, on modern hardware? Even on my ancient netbook, I can't tell any difference in performance. 
Yeah, gl_clear 0 is rather academic usually.

@gunter - I may have fixed the QMB trails being jumpy. Maybe. Looks good so far.

Crosshairs in next version

Changed my mind. Per weapon crosshairs so if someone makes a single player release with a weapon they want special crosshair available, automatically takes effect.

Like if someone were to make a crossbow (Drake), could use custom crosshair for that weapon.

Crosshair details

// Yes, sadly it appears 24 weapons are possible. Quoth plasma gun is 24, as far as I can tell.

gfx/crosshairs/weapon_1.tga to

gfx/crosshairs/default.tga // user's crosshair

scr_weapon_crosshair - defaults on. Use a single player release's crosshairs. Set to 0 to not use them.

crosshair 0,1,2 from previous builds continue to work as-is.

I've seen some mods that do stuffcmd ("crosshair 4") and it's just bad design. What the mod typically wants is per weapon crosshair anyway.

This will let single player releases provide crosshairs for crossbows (Drake) or even a empty texture for axe (no crosshair) or maybe a funky one for a high tech weapon. 
Mark V - Build 1013 (Temp Build) 
Build 1013 - Windows Open GL | DX8 | WinQuake

1) QMB trails being jumpy possibly fixed (gunter)
2) Per weapon crosshairs replacement texture support (c0burn)

scr_weapon_crosshair, defaults on -- allows single player releases to provide per weapon crosshairs. So if a mod has a crossbow like Drake (A Roman Wilderness of Pain, Something Wicked and a few others right?) or a high tech weapon and wants a special crosshair, it can do that.

User can set scr_weapon_crosshair 0 to not use the single player release's crosshair and just use normal crosshair. Player can still use gfx/crosshairs/default.tga to have a texture replaced crosshair.

Still tuning func_illusionary mirrors -- func_illusionary mirrors is not in the above build. 
@gunter - Re:splash.dem 
Another fine catch.

When I rewrote QMB particles, I missed something. Should be able to make the behavior proper. 
If you are using using TE_GUNSHOT as a particle effect in splash1.dem, QMB modifies that into an effect. 
Mark V - Build 1014 (Temp Build) 
Should be the final temp build

Build 1014 - Windows Open GL | DX8 | WinQuake

Addressed some issues mostly reported by gunter and a few small things I noticed, like drawing external crosshairs slightly wrong.

func_illusionary mirrors is not in the above build.

func_illusionary mirrors will be in next build now that I finally have closed out all bugs reported. Needed to have a clean and stable base before putting in the complex changes for func_illusionary mirrors. 
AFR setups will generally require gl_clear 1 in order to activate properly, while other setups won't really care too much.

why numbers for crosshairs, and not filenames? 
why numbers for crosshairs, and not filenames

I'm guessing you mean model names? Like gfx/crosshairs/v_axe.tga or soemthing to that effect?

Here is just my thoughts ...

cl.stats[STAT_ACTIVEWEAPON] == (1 << i)

cl.stats[STAT_ACTIVEWEAPON] is a bit flag with 24 possibilities (but not 32? Because QuakeC is floating point, can't do unsigned?).

I used what sbar.c knows about the weapon, which is the weapon number.

Never thought of the idea of using the model name, that being said isn't it true that QuakeC could set anything it wanted as the view model weapon (including none!!)?

So QuakeC itself does not know the concept of a view weapon model, as far as I know. Someone could write some QuakeC where a fully charged weapon uses different model? 
I meant for the crosshair cvar. 
Which just reminded me. There are 25 possibilities, not 24. Because 0 is typically the axe (weapon 1). Makes Quoth Plasma gun weapon #25 (24th bit possibility) and Quoth sword weapon #13.

/Add to the model name thing ... hipnotic or rogue uses same model for a few weapons doesn't it? Like lava nails gun is same as nail gun, but different skin? Another possible example of how might be more confusing to use weapon model name -- if that is what you meant ... and might not have been. 
qc can't change the viewmodel's skin. so they're different models if they have different skins.

the exception being .viewmodelforclient, but your engine doesn't support that... yet? 
Ok, Mark V ...

crosshair 0 (none)
crosshair 1 (Quake +)
crosshair 2 (dot)

That's it. I was briefly going to change to implement to number system like DarkPlaces.

Then I thought it about some more, and decided to tie it to the weapon number instead. Beats passing around "stuffcmd crosshair 1" -- I hate stuffcmd.

Mark V crosshair remains simple system .. crosshair 0, crosshair 1 (+), crosshair 2 (dot) are only possibilities.

But if a mod contains any weapon crosshairs (scanned on gamedir initialize), it will display the weapon crosshair unless user sets scr_weapon_crosshair 0 to override. 
No extensions and still pure Quake at the moment.

At a future unknown time, I anticipate making another run at acquiring more Spiked Quakespasm's features. 
also, STAT_ACTIVEWEAPON is sent as a byte in vanilla quake, and is thus normally limited to 9 different values, only 8 of which might be present in vanilla.
but that doesn't mean that they might be set on the server anyway, or that you'll never have more than one bit set.
hacking it to support more weapons is one of the first things that many mods need to achieve. you're better off using STAT_WEAPON.
unless you're making a new addition for ezquake anyway. other engines should avoid those hacks like the plague, but its too late for poor ezquake. 
@spike - Part 2 
2nd reason I implemented the per weapon crosshair system instead.

I very well know some people will end up making per model crosshairs for certain mods because now it requires zero QuakeC support.

You could just make a crosshair for the Drake crossbow in Something Wicked and name it appropriately and do it in 30 seconds or so. 
@spike Again 

Hmmm ... looked. I can't do that.

It's a model index. cl.model_precache[cl.stats[STAT_WEAPON]]

A gun model index might be 23 or 47 depending on the precache order, as I understand it. I mean "player.mdl" and "eyes.mdl" --- if I recall are guaranteed to be the first 2 precaches (if I recall correctly, which is no sure thing).

So 1 and 2 sure can't be weapons, if I am correct above. 
(Haha ... I wish I could unpost that after re-reading ... sigh) 
(Now I wish I could unpost my wish to unpost, because I think I'm correct on 2nd re-read). 
Enough that I can do mirrors (stencil plus depth splitting trick - split range into 0 to 0.5, 0.5 to 1) ..

Stencil is done.

I suspect that depth-splitting problems are due to differences in how GL and D3D handle the depth range state. In D3D depth range and the viewport are part of the same state. In GL they're separate states. The current wrapper code just assumes a depth range of 0 to 1 when setting the viewport, so therefore viewport will overwrite depth range.

Fixing that needs some rearchitecting of the wrapper, which I intend doing anyway, so this is just an advance heads-up. 
@mh - Re: What Fifth Was Saying 
Stencil is done.

Very nice!

Fifth: Mark V already split screen

@mh ... fifth is in, in fact, correct ... haha.


I literally only need multiple controller support. I'm just pointing that out for clarity. Not trying to get you to change your mind or anything. Just wrapping up unfinished loose end from yesterday. 
@mh - Re: Mirrors 
Fixing that needs some rearchitecting of the wrapper, which I intend doing anyway, so this is just an advance heads-up.

Ah ... I see. No wonder I couldn't get it to work. 
Had controller support recently added, I'm wondering if it can be adapted into this? 
@pulsar - Re:func_illusionary Mirrors

Pulsar ....

1) Can you download this build ...

2) Alter your map in the following manner
a) func_illusionary with 6 mirror sides must go. Make 1 sided.

Here is why

It looks like all 3 of your mirrors are on the same plane. Which is fine.

But the 6-sided mirror is messing things up.

By definition, an func_illusionary doesn't block visibility. That means the six-sider is interfering with itself.

Truth be told, your map the mirrors can see each other because vis is not actually blocking them from seeing each other, but because they appear to be on the same plane that would be fine.

Mark V has r_lockpvs which if you stand somewhere and type r_lockpvs (invented by MH) you can walk around and see what walls are visibile.

Anyway, give it a try. Let me know if it works with build 1016.

/And if you could, after making those changes could you re-upload the map so I can test some more. Your test map was very useful to me including for some hidden reasons.

Extra note: really in order to run a map with multiple mirrors, a map must be vised. Yours was. And they were all on the same plane so it actually wouldn't matter. But a vised map can have mirrors not on the same plane provided they cannot see each other. 
a) func_illusionary with 6 mirror sides must go. Make 1 sided.
That's absolulely fine, the mirror in the actual map is 1 sided. 6 mirror sides were for test map only.

Let me know if I get you right: I need to correct the test map so that each mirror is visblocked from another one. Do I need to move mirror so that they are not on the same plane?

I'll download this build and make another version of the test map when I get home (in about 3 hours). 
Looks like the splash to explosion thing is MOSTLY fixed -- it still occurs at one point in splash.dem (2:44). And the blue splashes still seem to die almost instantly instead of moving outward.

I'm not using TE_GUNSHOT, just a straight drawing of several blue particles like:

particle(origin, direction, 32, intensity);

32 is the color (light blue), and I do this several times simultaneously to send particles out in different directions.

Giving each weapon number a different crosshair doesn't sound good to me. Of course, in FvF there are different classes, so each class would need a different crosshair, not each weapon -- a cyborg gun #5 is completely different than a mage gun #5. If I were assigning different crosshairs for each class and potentially for different guns within each class, I would need the stuffcmd method for precise control of what crosshair gets used.

Didn't you say there were already mods that do this via stuffcmd? Are there any mods that do it the way you are proposing? 
Pulsar, just make the middle mirror -- the one with 6 sides --- into a 1-sided mirror. Only that.

That should be all that is required. 
I've just found that can get home late today, so I can't say when it will be. But definitely tonight. 
weapon crosshairs

Yeah, that feature is targeted towards mappers and players. Kind of misses your situation as a QuakeC mod creator/server operator, I know. In proper world, a QuakeC extension would be the right tool for your needs like what no doubt DarkPlaces and FTE can do via QuakeC extensions to control crosshair on client directly.

splash to explosion thing is mostly fixed

It'll have to do for a while. I said I was going to stick with JoeQuake behavior (even if undesirable), but ended up largely discarding that to make an effort to try to fix about every issue you documented. On the plus side, skipping trails should be history, maybe in all cases. And you do at least have the option of turning off the "QuakeC particles" replacement.

And you unearthed some great short-comings on the JoeQuake QMB implementation, and precious few remain.

I did some testing on fvf yesterday and foq was there. With the QMB lightning sparks, some of the game play was pretty unreal.

You argue hard, but you sure do bug test hard. ;-) 
Just make sure you upload the changed map regardless of result. ;-) 
Quakespasm: Had controller support recently added, I'm wondering if it can be adapted into this?

Mark V does everything natively on both Windows and the Mac. The kind of things you need system access to do.

SDL2 is a wrapper, its goal is not providing system access. So a number of the nice things Mark V can do, especially on Windows but some on the Mac too, it wouldn't be able to do.

Case in point, add -resizable to your command line and you can resize the Mark V window like any other Windows application. SDL2 would not like that. I could name several other examples, but they are all very boring.

Mark V needs low level access to many things.

SDL2 makes everything easy, but puts lots of limits in your face. I'm not really a "limits" kind of guy.

/I hope that explanation helps. 
r_lockpvs (invented by MH)

Invented by Quake 2 :) 
Mark V - Build 1017 (Last Of 2016? Or One More After Pulsar Testing?) 
Download at usual location:

New ...

- Sparks? Lightning? QMB option greatly enhanced! Video
- Mac version improved, both Open GL | WinQuake (johhny law)
- Several QMB enhancements (gunter)
- Installer enhancements handles more packaging types (Pritchard)
- Per weapon external crosshair support (c0burn)
- Several improvements to DX8 version (gunter)
- Theoretical func_illusionary mirrors (pulsar)
- Mark V page links good codecs, not link to bloatware. (Bloughsburgh)

Improvements to Nehahra support and many other small polishing/ hardening modifications.

Possible final build for 2016. If no issues, this release is promoted to Mark V - Version 1.1 Final.

(*) Awaiting on pulsar's map testing results for mirrors.

MH is working on creating a heavily updated Direct X 9 version wrapper for the engine.

If you have ever seen MH's DirectQ engine -- 5,000 frames per second on 2012 era hardware -- and is still listed on Quaddicted as Spirit's recommended engine of choice for Windows ... 
Didn't forget about you --- I sort of underestimated difficulty of rolling up what I was hoping to do (didn't realize how much video code I would have to combine, hadn't looked at it lately). And also had more last minute issues to resolve than I anticipated. I'm very sorry, I was hoping for this version. 
Translucent windows don't work in Jump. Is this normal?

Also, I noticed that the Winquake version complains about gl_texturemode (it's in my autoexec) in the console. It ignores other GL-specific commands, even though it doesn't recognize them when they're being entered. 
Is that the alpha sorting issue NewHouse was talking about that affects Mark V and Quakespasm in general abuse?

It's like a 30 minute fix, but I decided to procrastinate -- because far too many things are a 30 minute fix and I've pretty burnt out and have been for a week or so.

Mark V WinQuake recognizes all the console variables that Mark V Open GL recognizes -- but in Mark V is gl_texturemode is a command just like FitzQuake 0.85, so that's why that message happens. I'll consider making that silent for the future. 
Is that the alpha sorting issue NewHouse was talking about that affects Mark V and Quakespasm in general abuse?

Not sure, can't find that discussion. The windows are translucent in QS, but they're opaque in Mark V. 
@dwere - Part 2 
Are the windows tranlucent (partially transparent) or masked textures (totally see through)?

Mark V does not support masked textures on world model, if the 2nd case. It breaks vis and several other things including (sv_cullentities).

And if it is the 2nd thing, it won't get changed. Spike and other top-tier experts know why it is improper, and I'm ok with things that are broken by improper design not working right in this engine.

I'm don't do race to the bottom. I understand that some map authors target broken engines, I'm fine with those things being broken in Mark V.

There are 1500 single player releases. 
I wanted to say it's the former, but now that I looked more closely - it's more complex than that. Though I'm not sure if it changes anything.

A window is made of 2 layers:

1. A translucent texture without any "holes" in it. This is glass. There's some space behind it.

2. An additional masked texture in front of it - to make the frame look solid, apparently. It's also translucent for some reason, though it's not very noticeable.

Masked texture is see-through in Mark V, but both textures are opaque. 
It's all good! Don't overwork yourself on my account, I'm simply a beneficiary of your time and skill. In the meantime, I'm collecting various maps/episodes to replay when the new wquake drops... it just doesn't feel right playing in anything else :P 
Ok, I've been thinking about custom crosshair possibilities.

Having a different crosshair for each gun? Boring, inside-the-box thinking.

What would I do if you gave me the ability to use 24 custom crosshair images? I'd make an interactive crosshair that would act like radar and point in the direction of the nearest enemy. 24 images would be perfect for that: 8 directions x 3 height levels (low, medium, and high) to show you the direction and relative height of the enemy.

Yes, this would require the use of stuffcmds. There is nothing wrong with stuffcmds. Sure, they can be misused (but so can anything else in a mod). But in this case, it would be a fine way for the server to send information to the client to update their crosshair image to show the direction of the nearest enemy.

However, to maintain compatibility and not mess with people's crosshairs who aren't using Mark V, perhaps the custom crosshair stuff should be moved to a new console variable, like newcrosshair.

So you could actually have both the old crosshair AND a new crosshair image active at the same time. And I could be sending stuffcmd only for newcrosshair so that it wouldn't touch their standard crosshair value, if they didn't have my custom crosshair images.

To be extra sure about compatibility for other mods that might use stuffcmd to change custom crosshairs with the standard crosshair command, then "newcrosshair -1" would make newcrosshair use whatever setting is in crosshair.

So I guess whatever you're doing with crosshair could exist alongside what I want to do with crosshair.....

Though I'm not sure how many people will actually make use of the thing you're doing (different crosshair for each gun). But I'm completely certain I would do the thing I am thinking about, if you gave me the ability to select specific crosshair images by use of stuffcmd :D 
MH is working on creating a heavily updated Direct X 9 version wrapper for the engine.

Timing is good because you've indicated you're coming to a timeout, which gives me more time to get stuck in and get things working well.

I want everybody to be realistic about expectations here though.

You're not going to get 5,000 fps from this.

Part of the advantage of going native with an API is that you can deeply optimize for the strengths of that API. Going through a GL to D3D layer means that a lot of those optimization opportunities just don't even exist. I could talk the hind legs off a donkey about examples, but it would be sidetracking too much. I just expect people to believe me when I say this. 
So because QS uses lots of external .dll files it just makes stuff easy for things like controller support?

I look forward to testing this stuff when its ready 
The Amazing Thing... 
... about this port is that it's coming without any external DLLs at all. Also one of the reasons why Mark V is my favorite. 
In that temp build func_illusionary mirror doesn't work as well for me. I checked in both test map and the real map.

Here's the new test map: 
@Baker: thank you very much for the crosshair addition, and fixing the dev command crashes! I have to admit to not even realising that MarkV supported crosshair replacements in the first place, but the per-weapon idea is very nice and I actually think my mod could make use of it. 
Sprite Bug 
I have a new bug where sprites don't appear. My explosion sprites are fine, but the waypoint sprites in my waypoint editor are invisible. Any ideas? Fine in quakespasm. 
Are the sprites bubbles?
Do you have QMB effects enabled?
Do the sprites have replacement textures with alpha transparency? 
Um... we noticed on the FvF server that e5end (from DOPA) does not appear to have properly viss'd transparent water in Mark V, but sometimes it does or used to or something weird. r_novis 1 makes it look transparent, of course.

I just tried it in Quakespasm and in Proquake, and the water looks correctly transparent in both those....

It just doesn't in Mark V.

What's up with that? Something weird about that map? 
@c0burn - Can you provide a way for me to create that scenario, I'll like to check it out.

@dwere - in the jump map where the issue exists, could you type viewpos and post where in the map the issue exists?

@gunter - is this easy to find? 
Next I do an update, I need to make it so any time somoene does a screenshot, it writes the game, mapname and map coordinates in the meta data in the PNG.

I looked at the Jump map, noclipped all around the place and can't find this location in your screenshot, but I'd sure like to check it out and see it.

So if you can post the "viewpos" coordinates I'd like to look at it.

@gunter - Justed loaded up e5end. The autotransparency detection waits a few frames before beginning to check. Something about being located above the water and immediately falling in is tricking it. 
Frankly, I don't even remember myself which window it was.

But it shouldn't matter, because all windows are opaque for me. I deleted my config and autoexec in case I screwed up the settings somehow, but nothing changed. 
Jump - Rendering Scenario I Didn't Anticipate ;-) 
@dwere - looks like its just scenario in the engine where entities that are both .alpha and have alpha masking.

I must not have anticipated a scenario where both of those would be going on with the same entity.

Excellent engine test case!

The map author did everything right and the map is very designed. I'll address that one when I resume working the end. 
I just tried it in Quakespasm and in Proquake, and the water looks correctly transparent in both those....
Note that quakespasm defaults to gl_clear 1 so HOMs render as solid grey, and transparent water on maps that are vised for opaque water will render as grey-tinted. There's nothing special in QS about detecting water vis, so it was probably rendering against the grey void. 
Gunter found a automatic water transparency start of map mistake.

Mark V waits a couple of frames before implementing a water transparency check.

In the d5end scenario, Mark V discards the fact it already has seen evidence that the map has transparent water because it doesn't start check for a couple of frames.

I probably have it ignore a flag or reset the water check data after 0.1 seconds, when it shouldn't. 
bubbles again, haha. 
dopa e5end solved.

What's funny about -- Mark V's automatic underwater transparency detection shouldn't ever fail.

But due to an oversight, I wasn't letting it do its job.

In the renderer:
1) Determine surfaces visible
2) -- If surface in your field of view? Continue ..
3) ----- Do automatic transparency check

Well, for dopa end, you spawn and fall into water and are looking straight ahead. Maybe by dumb luck the water comes into view before you hit it.

Corrected version:
1) Determine surfaces visible
3) -Do automatic transparency check
2) -- If surface in your field of view? Continue ..

It was failing in that circumstance because it was checking your view instead of your surroundings. 
Random sparks.

Set qmb_particles_quakec_count_30 0

I do not know the nature of what QMB is trying to have that do, but it appears to view a particle count of 30 as special. So I made it a cvar. I think it may have been intended to relates to the scrag attack, but can't be sure. I may end up defaulting that to 0 in the engine. 
Mark V - Build 1018 (One Last Build Remains After This, For Pulsar) 
Download at usual location:

Mark V can now be resized on-the-fly in a complete and autosizing way that hasn't quite been done in any other Quake engine, although FTE may have something close. Video/input rewritten from ground up in 2014, but never quite completed until now.

New ...

- Resize window on-the-fly with the mouse (no DX8).
- Issue with window in "Jump" by gotshun resolved (dwere)
- Missing waypoint sprite resolved (c0burn)
- Removed QMB unwanted sparks by QuakeC (gunter)
- Automatic water transparency oversight on e5end.bsp resolved (gunter)

Each of the above bug reports were very awesome. Often hard to spot, extremely rare (gunter, c0burn) or ones requiring a real eye for detail (dwere) often don't get noticed and reported for long periods of time.

Remaining: not in this build, but coming up next -- func_illusionary mirrors fix for pulsar. 
GL_ARB_texture_env_combine is implemented, with the exception of interpolate combine mode and constant color.

I'm a bit wary of default values for many of the combine states: I don't set them, but then neither does the GL spec appear to give them, so I'm interpreting that as meaning that the onus is on the programmer to be explicit.

Fixed a nasty performance-sapping bug with quad particles.

The overall performance increase is looking to be quite significant. Unfortunately I didn't benchmark the D3D8 version, but with 9 it's currently running at almost twice the speed of my initial port.

Speaking of managing expectations, it will - of course - be entirely up to Baker regarding how he wants to integrate this. I can see one of 3 options: (1) do nothing, (2) drop D3D8 and offer only D3D9, or (3) offer both D3D8 and 9. I'm keeping the same interface to the wrapper so (3) should be possible with minimal work, and I suspect that is what Baker would prefer.

Either way I'll probably do an independent release of the modified DirectFitz incorporating the new wrapper anyway. 
@mh - Unimportant List Of Things DX8 Doesn't Do 
Most of these are things I don't care too much about, but for the sake thoroughness ...

1) Multisample. Maybe useful if, say, the HUD or the console were drawn with a non-integer scale like 1.88. Or maybe not. But it's a difference.

2) Resizing window real-time. I don't remember what the main barrier was. Of even if there wasn't one in the DX8 wrapper or if it was just on my side.

3) License. It would be nicer if were GPL 2.1 or later. Or maybe even BSD or MIT license. Doesn't really matter, if I recall seemed like there was 1 thing about GPL 3.0 I didn't like, but I don't recall what it was. It's not really a big deal.

4) Built-in full window gamma/contrast. In Open GL 1.2 ... as Gunter can attest to, the contrast on-the-fly and texture gamma as the "txgamma command" isn't too bad. But since you are using DX9, might as well do it DX9 way. ;-)

5) GL hints? If DX8 doesn't do. I bet it already does.

I always thought it was great that after making very few changes to the DX8 wrapper, including a little bit of abuse to get to it to accept vsync changes (windowed mode only?), that it did not need any special treatment except in the most minor of circumstances. 
D3D supports this but last time I looked at it the initialization code was horrible. This is an API difference between GL and D3D: if you ask for an unsupported pixel format in GL, it will degrade gracefully; D3D will just fail. It means video startup can involve a lot of "test every possible combination in a loop until you find one that works", which is fun for nobody.

Resizing Window
Should be possible. I don't think there is a barrier in the API. It does involve mode changes though (when you think about it, a window resize is actually just a mode change).

I'm not a fan of the GPL in any incarnation and prefer more permissive licensing if possible. No decision but that should give you an idea of how I'm thinking.

I'd need to review how you're doing it in GL before making any comment.

D3D, any version, doesn't offer hints. API philosophical difference: in D3D you must explicitly state what you want. The D3D8 wrapper has the fog hint implemented, but no other. Some hints are impossible: e.g. D3D enforces perspective-correct texturing and gives you no control over it. 
I would probably keep the DX8 build as part of the source, but only distribute the DX9. At least for a while, then the DX8 build would likely be removed ... so if it used a compatible interface that would be great.

void VID_Renderer_Set_OpenGL (void)
.. eglAlphaFunc = glAlphaFunc;
.. eglBegin = glBegin;

void VID_Renderer_Set_Direct3D (void)
.. eglAlphaFunc = d3dmh_glAlphaFunc;
.. eglBegin = d3dmh_glBegin;

(a few oddball fake Windows functions in the mix like ewglMakeCurrent = d3dmh_wglMakeCurrent, etc.)

Note: At one point I did combined Direct3D + Open GL builds. The fake function ChangeDisplaySettings had to be renamed in the wrapper to allow both to co-exist.

I cannot recall but if it doesn't already do so, the ability to completely shutdown the Direct X without restarting would be helpful. With Mark V's video code, shutting down a renderer and switching to another one would not be hard at all.

Would be one less .exe to distribute too. And with Visual Studio /DELAYLOAD, the combo build could run even if in a no Open GL drivers scenario and default to Direct3D. 
@mh - Gamma / Contrast 
The Direct3D method doesn't need to be the same as the Open GL.

I use gamma and contrast console variables.

If vid_hardwaregamma is 1, uses the Windows screen brightness that affects entire display.

If vid_hardwaregamma is 0, Mark V reuploads the textures with the current gamma setting and then at end of frame renders a contrast polygon over the full-screen. Contrast slider adjusts in realtime, but gamma can be only be manipulated via "txgamma" console command because can be a little slow. Open GL/Direct3D8

In the theoretical Direct3D 9 case, at the end of frame vid_hardwaregamma 0 would instead call d3d9_mh VID_Gamma_Contrast (vid_gamma.value, vid_contrast.value) and it would apply both the gamma and contrast to the buffer before swap.

/No obligation, I'm explaining my concept of how such a thing would work. 
One last thing before I try to wrap up func_illusionary mirrors for pulsar ...

I would suspect that the DX9 would be the main executable for Mark V on Windows. It was only the few missing functions like stencil and CopyTexSubImage2D that caused me to need OpenGL, because I had plans for those.

Add: One more missing feature ... glLineWidth, Mark V does draw lines occasionally. Like the others, it isn't a big deal. 
Direct3D doesn't support variable width lines:

The thing here is that line width is actually not hardware-accelerated, even in GL, so D3D doesn't offer it at all. 
qmb_particles_quakec_count_30 0

This seems to work.

Maybe the thinking was, "if there are 30 or more particles, it must be an explosion," or maybe it also has to do with how my splash particles are spreading out in different directions from a center point, and that kind of looks like an explosion....

But I don't know where something like that happens in standard Quake, where it isn't already covered by a QMB effect. 
That's the new default value. Now QMB largely behaves in a predictable and non-hacky manner that is friendly to use in QuakeC. About the only exception is don't use colors 73 or 225 unless you want blood effect.

By the way, in investigating c0burn's sprite issue, solved your chase camera previous movetype_none issue. I was never able to find the issue because it was never a movetype issue but an nearly invisible typo in the engine setmodel that only affected sprites that never move.

@mh -- I'm not surprised. Isn't like there aren't other ways to do about the same thing. 
Hm, is it possible my blue particle splashes are being removed because they are created under the surface of the water? If QMB is interpreting them as explosions, it may be ... changing them.... Oh yeah, like how rocket or grenade explosions are different underwater -- they make bubbles and are perhaps a bit less explody looking.

Except in this case, it may be messing up my water splash effect because it thinks its an explosion. 
Type r_drawworld 0. Will help see what is happening. 
requiring a real eye for detail

I don't know. I just saw a vague comment about windows being awesome, but I didn't notice anything particularly special when I was playing. So I checked in QS.

Thanks for fixing it, and thanks for all your work. 
I can't tell that r_drawworld 0 changes anything at all. 
@mh -- I'm not surprised. Isn't like there aren't other ways to do about the same thing.

It can be emulated by drawing them as regular primitives but to be honest that's a place I don't want to go to. Time spent emulating a feature that's not hardware-accelerated or not in the API is time not spent on essential stuff. 
Ugly DX effect with vid_hardwaregamma 0, the sequel:

Size screen down with -

gl_clear 1 fixes it. 
OpenGL Crash After 3DFX Logo 
Hey there, congrats on the 1.0 release. I loved playing through Quake the first time using your WinQuake port. From my research that's easily the best way to play Quake as close as possible to DOSBox on a modern system. Thanks for that!

For some reason, though, the OpenGL port has never worked for me, not with the last beta and not with 1.0. It shows the 3DFX logo and then crashes ("...stopped working."). GLQuake and Quakespasm work, although setting a higher resolution in GLQuake crashes it as well. I suppose the problem is on my end, as I seem to have similar problems (Crash when setting older OpenGL games to higher resolution), but I never figured out a reason.
I'm running Windows 10 on a laptop with an i7-5500U with integrated graphics as well as a GeForce GTX 850M, latest drivers. No difference if I set the driver to use either graphics card (although that function doesn't work properly in many games). Any ideas? 
Which 3DFX Logo? 
Never saw anything like that in Mark V. 
it shows the 3DFX

Hmmm. I thought that was like a 1990s thing. Google says that company has been dead since 2002 ... do you have any junky .dlls in your Quake folder, like maybe one named opengl32.dll. You might consider deleting any .dll in your Quake folder with an old date (after backing them up, I guess).

Mark V does not need any DLLs.

Anyway, regardless the DX8 should work for you.

Maybe in a future version, I put some sort of junky old opengl32.dll (Glide?) detector.

Well, for now you can use the DX8 build. Does almost everything. Doesn't use Open GL at all.

Let me know how it turns out. 
I think GLQuake comes with some really crusty/obsolete .dlls that don't belong in a proper Quake folder. That'd be my guess.

One more reason to use MH's upcoming DirectX 9 modification as main Mark V distribution executable. 
@pulsar: Func_illusionary Mirrors 
Func_illusionary mirrors on their way within an hour or so.

In next update, any func_illusionary mirror must have one 1-mirror texture, in the case of a cube the other surfaces will not be drawn, just the mirror.

This will allow for mirror secrets.

Effectively, they will a brush with a mirror on one side, from the other side they don't exist.

Makes your original test map work.

I'm testing out some other things before I release this. 
Mark V - 1019 - Func_Illusionary Mirrors

A func_illusionary that is a mirror should have one mirror surface, the other 5 will not get rendered.

At this time, shouldn't be sloped up or down.

This test build does both of your test maps fine and a test map I made.

/This is a test build. 
It looks like this works for 6-sided brushed only. It works fine in test map, but in the actual map I have func_illusionary with 8 sides (to fit geometry) for example (one face is mirror, others are skip) and it doesn't render as mirror.

While with classic boxes with one mirror side everything seems to work fine. But it doesn't work with boxes with chamfers. 
while solid mirrors work fine on non-rectagular surfaces, I checked it. 
Could you upload that one so I can examine it? 
Func_Illusionary Mirrors Was Not Easy To Do 
Func_illusionary mirrors were very complicated to implement in a thorough way.

I discovers ton of special scenarios I had to adjust for. I kept discovering more issues that caused me to have to re-engineer them.

Any example I didn't consider is useful. 
It's Strange 
it works fine in test map with non-rectangular mirror but doesn't work in the actual map. Gotta investigate more. 
I Would Trigger Texture Instead Of Skip 
I do not know what compile tools will do to such a brush, and there are several different compilers that may handle them differently.

That being said, until something very strange is going on, I should be able to examine see what is happening. 
Upload the one that doesn't work right, it will allow me to make a list of "do" and "don't" for func_illusionary mirrors.

It is also possible what you are trying to do should work (but I failed to anticipate a situation) *or* doesn't work for non-obvious reasons that might not involve the shape. 
Ok, I Found The Difference 
func_illusionary mirrors don't work in AD. I guess it has somethinf to do with it's entity state system. You can download AD 1.5, place the test map there and test it in AD. 
@Baker, Regarding "crash After 3dfx Logo" 
Good call with the .dlls! I'm using the GOG release of Quake which includes 21 dll's. Mark V works without any of them, and indeed the opengl32.dll (dated 23.03.2015) caused the crash. Without it mark_v.exe runs flawlessly. Also, 3 dll's are numbered variants of "3DfxSpl.dll", which also cause the corresponding logo to appear. Thanks! 
Obviously, GLQuake doesn't run anymore, now, so basically that's the culprit. I always just copied the source ports into my GOG Quake directory, guess that was a bit thoughtless. Not that I'd ever want to use GLQuake... 
Clean Quake Dir 
Your best bet is always to copy the id1/hipnotic/rogue folders into a new dir with the Mark V exe(s). 
vanilla glquake likes to crash when a gl driver reports over 1024 bytes of extensions. many gl drivers (or at least nvidia) limit the number of extensions reported to anything 'glquake.exe', which means renaming old third-party engines is one way to get them working again...
vanilla also likes to misbehave without the -no8bit arg.

GOG includes 3dfx's opengl->glide wrapper, as well as nglide and its glide->direct3d wrapper. I guess markv just doesn't like it when various opengl functions are missing.
one way to avoid this issue (including the issue with the gl->glide wrapper with no glide support) is to just directly+dynamically load the opengl32.dll from the windows system32 directory.

/me starts to wonder which other engines fail to cope with it.
/me wonders what the steam version does to avoid the glquake/winquake crashes.

but yeah, if you're not going to run vanilla glquake, one option is to just remove that opengl32.dll minidriver/wrapper. 
I might be able evade the GOG opengl32.dll by checking for the existence of the .dll and if it exists changing directory to id1 when I first call an Open GL function to cause /DELAYLOAD to kick in, so it is not found and then changing back. A bit of hassle.

/Mark V hooks up all Open GL functions at startup, so while another might wait to crash until one of them is called, Mark V will crash immediately. 
@pulsar - Func_illusionary + AD 
Nothing ever gets to be easy does it?

Arcane Dimensions doesn't support static entities.

That being said, I'll make it work anyway. I'll have to do a test map, but the way I redesigned it really does not require use of static entities it is just highly preferred. 
Oh =( 
you can just load the current test map in ad 
Trying winquake build 1018 with a clean install of Arcane Dimensions, I noticed a couple of oddities... not sure if this is to be expected, especially the transparency part since that discussion got a little involved. So FWIW, FYI, etc.:

Main menu graphic has the AD logo missing:

"Vine" transparencies (not): 
(That's AD 1.5 to be clear.) 
@johnny - Arcane Dimensions Menu Item + WinQuake 
Loaded it in original id1 Software's WinQuake and it doesn't look right either.

Something about one of the Arcane Dimensions gfx.lmp files isn't WinQuake compatible.

id Software's WinQuake screenshot - Arcane Dimensions pink menu item

vines - Mark V WinQuake doesn't support alpha masked textures on brush models just yet. It will eventually, it's on the todo list. 
Have you tried the Mac versions? Are they ok for you? 
Clarification: Asking about the startup dialog on the Mac. It should work ok now whether or not binary is in the Quake folder or elsewhere. 
Nope not yet! Will have my macbook returned later tonight. 
Hall Of Mirrors - Test Map 
@pulsar ...

The above test map will be a good example to explain

- mirrors
- func_illusionary mirrors
- list of things to avoid

func_illusionary mirrors cause hard to avoid issues, but a good mapper can map around their limitations. 
Mirrors Tutorial "Video" 
He is quickly done "video" explaining how to use mirrors ... walking through a map and describing limits.

Mirrors Tutorial "Video" 
Mark V - Release 1.2 Final 
Download at usual location:

Main Features

Compared to version 1.1
- Mac version Open GL w/effect | WinQuake
- Support for func_illusionary mirrors (pulsar)
- Support for same in Arcane Dimensions (pulsar)
- QMB particle effects option
- Resizable window at any time with mouse
- Several other small features
- 100.00% resolution of all issues

Thanks to the beta testers! Gunter really went overboard and identified several things that could be improved about QMB; dwere caught a few hard-to-notice issues, in particular an obscure rendering glitch.

Thanks to Pritchard, NightFright, johnny law, Bloughburgh, c0burn, spy and several others.

Upcoming DirectX 9 Version by MH?

Probable Direct X 9 version is in the works by MH (with no obligation on his part), from brief descriptions of enhancements it is very likely to be significantly superior to the Open GL and DX8 builds and will likely replace them as default Windows build.

Func_Illusionary Mirrors - "mirror_" textures

Tutorial video Test map

Requested by pulsar. There are limitations to func_illusionary mirrors, the video tutorial shows how to work within the limits.

Arcane Dimensions does entities differently than normal for func_illusionary; those are now supported.

/Final build of 2016 
gonna try it when I get home 
Congrats Baker! 
There are a few minor issues that still exist, though they may or may not be worth addressing:

QMB Particles - All explosions are stifled when underwater. This is really not correct; explosions are not less powerful underwater, so they should not be made to appear less powerful. And I think this is the reason my splash effect is messed up; the QMB system interprets the splash as an explosion (as before, with the spark effect), and so decreases the power of the effect, but since it's not a powerful "splash" in the first place, the effect is just being stifled into nothingness pretty quickly.

The +zoom_key alias -- as a programmer, I can't see such un-optimal code and not want to fix it, heh. I did find it is better to save the values and restore them (as you do) rather than just counting on the math to take care of that, because when banging on the key really rapidly, the math can get out of order and mess things up. However, there is still no need for all the "in between" steps in the your alias. It only needs a start, and end, and an animation in between. So this would be much cleaner:

alias +zoom_key "valsave fov 1; valsave sensitivity 2; mul sensitivity 0.1; valsave r_viewmodel_fov 3; r_viewmodel_fov 0; fov 70; wait; fov 50; wait; fov 30; wait; fov 20; wait; fov 10"

alias -zoom_key "fov 20; wait; fov 30; wait; fov 50; wait; fov 70; valload fov 1; valload sensitivity 2; valload r_viewmodel_fov 3"

Pressing TAB during "Congratulations" text causes the text to disappear.

All pitch values should be .17 higher than they are. This would probably require the fullpitch adjustment to be altered down to:

cl_maxpitch 79.8269

but the minpitch value would not really need altered from -70.

With transparency in effect, teleporter surfaces always render on top of water, and water always renders on top of shadows. 
Erg. I left out a "wait" in that second alias right after the "fov 70" heh.

Should have been:

alias +zoom_key "valsave fov 1; valsave sensitivity 2; valsave r_viewmodel_fov 3; mul sensitivity 0.1; r_viewmodel_fov 0; fov 70; wait; fov 50; wait; fov 30; wait; fov 20; wait; fov 10"

alias -zoom_key "fov 20; wait; fov 30; wait; fov 50; wait; fov 70; wait; valload fov 1; valload sensitivity 2; valload r_viewmodel_fov 3" 
Oh yeah, and that old issue where your name is constantly being changed when you mess with it in Multiplayer -> Setup. It should only commit the change when you select "Accept Changes" or perhaps when you exit that screen. 
Direct3D 9 - A Possible Philosophical Issue For Discussion 
I've added 1 (one) vertex shader to it.

Now, before you start baying for my blood, there's a good and very valid reason for this. But before I give the reason, bear in mind what I said a good bit upthread about D3D being able to software-emulate vertex shaders. That means that it retains full compatibility: there's no bumping of the hardware requirements involved here.

Also - it's a single generic vertex shader that all vertices go through, so it keeps with the philosophy of "one place for everything and everything in one place".

Now for the good and valid reason. I lied: there's actually two.

First, and the biggie, is the dreaded Direct3D half-texel offset problem. If you've noticed that the 2D GUI widgets look significantly poorer quality in D3D, that's the reason why. Another symptom would be black lines around the water textures with r_oldwater 0 (you didn't see this in D3D 8 because r_oldwater 0 wasn't supported).

The thing is, the only way to cleanly and non-intrusively fix this is by tagging some lines of code onto a vertex shader. Believe me, I tried other ways, and they all had the downside of needing (in some cases significant) changes to the base engine code (FQ's GL_SetCanvas thing would have had impact throughout the codebase).

Essential reading:

Second reason: texture matrix. There are API differences with how the texture matrix is applied, and the only alternative way to work around them was to software-emulate the texture matrix and apply it before copying over texcoords. That ran incredibly slow.

Potential third reason: I only mentioned two above, but this is a potential third: there are also API differences with texgen, and if in the future Mark V ever uses texgen for anything, this is the cleanest and most performant way of bypassing them.

Anyway, I am willing to back out of this if Baker (or any other key user of Mark V) considers it too objectionable, or otherwise considers the fallback modes acceptable, but I do strongly recommend it as the best and most compatible solution. In particular I consider the half-texel offset problem completely unacceptable; while the others would have viable software fallbacks (at a performance cost), fixing half-texel offset acceptably but in a different way would require re-implementing the entire transform pipeline in software (or invasively modifying the base engine code in too many places). 
It works! Thanks a lot. 
@pulsar - Func_illusionary Mirrors 
Glad you are happy. Look forward to playing your maps!

Tried to illustrate limits for func_illusionary mirrors in the video. 
@mh - Any ideas you wish to implement even if they are Direct3D only enhancements are fine.

Many of the boundaries I set for this project have been to allow it to reach completion and keep goals in areas of my knowledge set.

Your strengths and interests in the advanced/low-level rendering are far higher than mine, use them how you see fit. Is perfectly acceptable for the Direct3D build to have extra features.

@gunter - I agree with some of those. Wanted to wrap up.

@bloughsburgh - Thanks! 
Security Cameras In 2017 ? 
Security cameras would be nice feature for base maps:

Security Cameras 2017 Demonstration Video 
Could be fun, even more so if you could have rotating cameras. Security monitors would require a "use" button, I guess. 
Security Cameras 
@mugwump - That is one of the main questions, how to expose the capability to someone making a map. On the mapping side, clearly camera entities would be involved.

And then the secondary question is should it be done through QuakeC instead. The problem I see with this is the someone couldn't make it work with stock Quake.

Most of the questions are just how to make it available in a map editor and to do it for multiple view screens - in a way that allows flexibility. 
Cant Compile This 
I tried to compile this with CodeBlocks, but im getting TONS of error messages.. Is it possible to release a non broken source?? :/ 
I use Visual Studio on Windows. XCode on the Mac. Every once in a blue moon, I may check to see if the CodeBlocks compile works, but it is rarely up-to-date.

Linux isn't supported at this, if that is what you are trying to do. 
The WinQuake Debug, GL Debug, GL Release all compile fine with CodeBlocks 13.12 Full Install on Windows from freshly downloaded source.

Although I use Visual Studio and rarely update the CodeBlocks project, it isn't often that I make changes that would cause the CodeBlocks project file to break very much.

But the CodeBlocks project has unsupported builds in it too, like the Linux build. 
I fixed it myself, it was indeed caused by an older version of CodeBlocks... However, for some reason i cant assign my mousebuttons to a key..
Is it possible to add a simple MD3 loader?
I want to use a FitzQuake engine for my game (atm im using an older Mark5 version), but i dont want to use mdl. 
Protocol 10002 Demo Support? 
I tried to play warpb_sw4848 demo from (protocol 10002). It ends around 2 min 40 sec in with the message:

Host_Error: CL_ParseServerMessage: Illegible server message, previous was svc_clientdata

Not sure if it's a bug or expected behavior. 
I had issues with demos too, if you delete the demos (and keep the lines in the quake.rc) the engine hangs up.. Very unstable... 
I only added protocol 10002 to support the Warpspasm demos that come with the game and play when you start it.

But thanks for letting me know it doesn't work with user made demos, because I didn't know. 
@steve - It's unlikely that I would add md3, Mark V follows "the path of one". One format, one name, one place for all formats and types of files. md3 has no place that in that scheme, would be a 2nd model format.

Mark V also has a software renderer that can do almost everything the GL version, but it sure can't do md3. md3 isn't a Quake 1 format, but I can understand why you would want it from a make a game perspective.

You might try to convert the MD3 to mdl with the best and most awesome tool ever created ....

Ultimately, Mark V is not made for total conversion purposes. But I do wish you luck with your project.

I'm glad you enjoy the engine.

/At the same time, please understand I am not an engine coding help forum. What you may not know is that I have had in the past literally dozens of people attempt to make me their personal coding help guy. I'm pretty good at saying no. ;-) 
Thanks For Clarification 
That's what I suspected.
Ironically, the Warpspasm startup demos get overridden by the latest Quoth's startup demos anyway :D 
the Warpspasm startup demos get overridden by the latest Quoth's startup demos anyway

I know Preach didn't do that on purpose, but that's highly undesirable. I never did any testing with Quoth 2.2 back in 2014 when I added support for the Warpspasm start demos.

I like Warpspasm enough that I may cause it to load in original form so the start demos play. 
Thx for the reply, but i think i can add MD3 myself to the old base engine i use (its an older Mark5), i mostly want it for viewmodels only because i need the "details" active on it (iron sights etc..)...

I already managed to add a working sound dsp system (based on crowbars psp engine), which is awesome btw. 
Heres A Video Of The DSP 
Wow, I'm not easily impressed but that is awesome. Do you have a link to the source for any engine with that modification?

Engoo has sound modifications, and I can't recall the name of the "open source Half-Life engine", but I'm sure it has sound modifications.

I think it would be awesome to somehow expose parts of a map, sound modifications. Quake .bsp doesn't support that. And at the moment, I can't recall exactly how Half-Life marked those areas ... probably a trigger.

I have not thought about sound for a while, but obviously since Mark V can do Half-Life .bsp (provided the textures are compiled into the .bsp) ... and .alpha entities and masked textures .. that I think of a more complete engine, although in the context mostly of what someone would do in a Quake map.

I think of mirrors, security camera, portals and such because they could add more complex and richer environments to, for instance, a base map.

Plus I have largely completed intermap travel-system which requires no QuakeC support (but offers QuakeC the opportunity to intervene).

/I couldn't say exactly when any of the above would happen because there are always so many items on a to-do list. One of the main challenges of moving an engine forward is that there are always choices and with limited time some things have trouble finding their way to the front of a queue. Case in point, splitscreen and Linux build may consume much time in future and integration of possible DirectX 9 version by MH or acquired Spike's optimized network compression. It's always of a sea of choices :( 
I can give you the sources if you want ;)
I plan to control the DSP with simple triggers and stuffcmd, it adds so much to the levels ;) 
Maybe there could be something like loc files for environmental sound effect locations. 
8x multitexture (which was easy, even for me)

I'm going to offer 4.

Here's the reason why:

Summary, for anyone who didn't follow the link, is that with fixed-pipeline OpenGL NVIDIA only offer 4 texture units. 
Yeah, I'd like to take a look at that source code. 
I can't think of a Quake scenario where anything more than 4 texture units would be necessary. I think even 3 may be enough to eliminate to the overbright pass as a separate pass in FitzQuake. 
is awesome... no idea how that could be implemented in quake maps... trigger volumes?

Unreal Engine used to allow "zones" to be created by sealing off entire rooms and areas, that was a good technique. 
@gunter: Sound Modification Zones 
If I were to add a modification to that certain areas of a map had special zone modifications zones like Half-Life (echo areas) I would probably be inclined to implement it in the following manner:

- A brush similar to func_illusionary indicates the sound region. Static entities are available to the client. A field of the entity indicates the sound modification.

- Although someone like Spike may correctly point that this to some degree does not follow the client/server model ... every modern engine already breaks the client/server model by indicating skybox and fog (and now several other keys like wateralpha and friends) in the worldspawn, which is client-side. The server has no opportunity to legitimately set those global values, and maybe for the best because those would have a delay of a split second.

I would mostly need to examine a way to make it backwards compatible to non-supporting engines.

This would also allow easy editing via external .ent files. And to possibly allow someone so inclined to take an existing map and add sound zones.

Also makes it so no complex new way of communicating sound zones to a client need be added to an engine and would be compatible with save games and everything else. 
The Engoo engine has some of sound modification capability. It's one of the software renderer engines like qbism super 8.

But yeah ... I'll do some thinking and figure out some way to support such a thing --- and in a way that is very friendly to mappers and easy.

/Isn't a soon thing but more likely a vague "probably some time in 2017" thing -- like security cameras security cameras concept video. So many items in the queue + limited time ... 
I can see 5 being used for diffuse+lightmap+fullbright+caustics+detailmaps maybe.
Or add 3 more if you split the lightmaps into their own textures.
Then add two extras if you want light directions and deluxemaps for bumpmapping.
And add 4 more if you want to ramp up specular to a decent exponent...

Although its kinda pointless to worry about it if the engine needs to retain a 4-tmu pathway anyway... or two... or one...
But yeah, more than 4 and you really should be using glsl/hlsl, trying to do everything with only an alpha channel for temp data is just unworkable. 
Yeah, eventually I do have something like a "surface effect texture" planned in my head for possible surface effects.

Might as well ask your thoughts on this question to you ...

Although not soon, I would like to use probably 4-8 QME 3.1 bit flag slots but and would like to avoid any possible with what FTE uses.

One example might be to indicate additive blending.

/I have not put much thought into this lately, but while discussion about future mapping enhancements ensues ... is fairly good time to bring up those thoughts. 
hexen2 defines modelflags up to and including 23.
1<<24 is the first undefined one as far as fte is concerned.
Not that fte implements all of the hexen2 ones, or that I'm even aware of any models that use them... but hey.

that said, for additive, you're probably better off sticking with EF_ADDITIVE=(1<<5). Yes, this can be used by mappers, and does not necessitate any wire change (read: protocol uses a previously-unused bit which permits backwards-compatibility on the assumption that old implementations can safely it).
maybe some of the other bits you're thinking of are similarly already implemented in another engine. 
Intel Video Identification Bug 
if (!strcmp(gl_vendor, "Intel"))

I see that Mark V has inherited this from the original code too.

The D3D equivalent (which is read from the driver so I don'thave control over it) is actually "Intel(R) HD Graphics" so this test will incorrectly not identify it.

Strictly speaking this is also a bug in the GL case because Intel may change their vendor string.

Change it to:

if (strstr(gl_vendor, "Intel")) 
dx8_mark_v -width 750 -height 550

= borked up screenshots


This is actually a wrapper bug, so my apologies for my previous misdiagnosis.

@Baker: in the glReadPixels implementation, "case GL_RGB" should also be using "srcdata[srcpos * 4..." because the source data will be 4-byte, even if the dest is 3.

I may have mentioned a while back that there are advantages to going native, and screenshots are one such.

Baker has implemented PNG screenshots, so in the native GL code he's doing a glReadPixels, then converting the memory buffer to PNG format (presumably via a statically linked libpng or maybe stb_image) and saving it out.

A native D3D version wouldn't do half of that work. Instead it could just use D3DXSaveSurfaceToFile on the backbuffer. Give it a filename, specify the type, boom, done, three lines of code.

I'm going to add some native exports to the new wrapper for functionality such as this. 
The DX stuff mh is doing sounds really great.

I don't understand most of it, but I hear things like "improved performance." And bug fixes are always good.

And if I'm getting the gist of things regarding more rendering passes, this might allow addressing of some issues:

Fullbright textures should not be affected by contrast -- it makes them ugly.

Screen Blends should not be affected by gamma or contrast -- I have found this is the main thing that makes them far too intense. When I use vid_hardwaregamma 0 and various values for txgamma, the screen blends look perfect, though if I mess with the contrast slider, it makes the blends too intense again.

So yeah, if that's a possibility, the screen blends should be drawn last so they are not affected by gamma or contrast.

But I have no real understanding of this low-level 3D rendering stuff. Though it sounds like there will be a great benefit from mh's work. 
Mark V applies gamma and contrasts to screenshots (only) when applicable.

For instance

1) If you are using hardware gamma/contrast, it will adjust the screenshot accordingly.
2) If you are not using hardware gamma/contrast, it will not apply it to the screenshot.

So depending on situation, writing directly to file is not necessarily desirable because screenshots could be, for instance, too dark/etc. 
Hm, there's an issue that looks similar to the previous QMB lighting texture thing with txgamma, but it appears whether or not txgamma is being used, wherever there is fog.

I first noticed it at very long range when I was zooming in, because I use very light fog, but if you set the fog much denser, like .5 and then fire the lightning gun, you will see the bad effect. 
Mark V applies gamma and contrasts to screenshots (only) when applicable.

Ahhh, understood.

By the way, here's a sneak preview of something I just did:

This was actually taken with the GL version, just to demonstrate that there's no shader trickery or suchlike going on. 
awesome! Classic water! 
Mark V seems to struggle with complex maps that are smooth in QS. On my questionable system, I mean.

jam2_mfx.bsp is a good example. Right at the start, looking towards the palace produces a very noticeable slowdown.

Fitzquake v0.85 also has this problem. 
@dwere - Vertex Arrays/ Water Warp/ IPad Version ... 
@mh - Haha, your water warp. I suspected you would do that ;-)


Especially on older hardware, vertex arrays help achieve a more reliable 72 frames per second in the BSP2 era.

I hadn't implemented yet them because there were many other things on the to-do list. I'm prototyping an iPad/iPhone version, which uses Open GLES which requires use of vertex arrays so I actually have to implement vertex arrays here in a hour or so. I'm still sticking with the "that's it for 2016", but version 1.3 will have it.

@gunter - You are probably right on blending. I'm hoping that MH will provide HLSL shader option for gamma/contrast in DX9 ... everyone has their wish list ;-) btw ... I still hate your computer, but I sure appreciate all the compatibility testing it has helped provide.

iPhone/iPad - 2017

But since I'm making a prototype iPad/iPhone version right now which will controls similar to Minecraft on the iPad which is very playable on an iPad.

(Android is more of a pain because very crude development tools which is like banging rocks together to make fire. iPhone development tools have always been very nice.)

/Any new builds will be 2017 and unsure where the priority of an iPhone/iPad version. Now that I have stable release and zero issues outstanding, playing around is a bit more leisurely. May upload a video later tonight after I get it initially running ... 
I couldn't not do water warp.

Performance. Vertex arrays help with big maps, but they're only part of the story. What really helps is draw call batching, and vertex arrays are just a tool that allows you to do batching.

glBegin/glEnd code is fine for ID1 maps but as maps get bigger this kind of code gets slower and slower.

Toss in a few dynamic lights and/or animated lightstyles (which stock Fitz also handles very poorly) and it gets worse.

Batching is all about taking a big chunk of work and submitting it in a single large draw call, instead of several hundred tiny draw calls. Each draw call has a fixed overhead, irrespective of how much work it does, and that overhead is typically on the CPU. So if you have, say, 1000 surfaces all of which have the same texture and lightmap, drawing them with a single call will have 1/1000 the CPU overhead that drawing them with 1000 calls would.

Stock Fitz would also benefit from lightmap update batching. Again it's the difference between "few large updates" versus "lots of tiny updates" with the former being more efficient. Stock Fitz also uses GL_RGB which compounds the problem by forcing a format conversion in the driver. This stuff is mostly hidden on modern hardware, but you can still find devices (and some scenes in maps) where you get an unexpected nasty surprise.

Ironically, one way to make stock Fitz run faster can be to disable multitexture. Try it - pick a scene where it gets the herky-jerkys then compare with running with -nomtex. This will cause it to have fewer state changes between draw calls so that the driver can optimize better, as well as batch up it's lightmap updates (for the world, not bmodels which are still slow). Depending on the scene, the extra passes might turn out to be a lower workload.

If the engine itself implemented all of this batching then running with -nomtex would not be necessary.

The D3D9 wrapper takes the supplied glBegin/glEnd calls and attempts to be somewhat agressive about batching them up. It converts everything to indexed triangle lists and concatenates multiple draw calls that don't have state or texture changes between them. It also attempts to merge multiple lightmap updates.

None of this is as efficient as if the engine did it itself, of course. Going into the actual GL code and doing it right from the get-go is always going to give the best results. 
Warping The Water 
Well, I wouldn't care whether "authentic" waterwarp is implemented into the DirectX or rather OpenGL build. But the one that would get it would be my personal default. :P 
@johhny Law 
I'm sizing up Requiem to see what unique things it adds for likely addition ...

I know it can create items (interesting idea), for instance. jdhack had some interesting ideas in there.

A question for you, if you know ...

I can't get Requiem to run on Linux, it says " not found". Engines like ezQuake run fine for me on Ubuntu Linux or even super old FitzQuake 0.80 SDL. Could it possibly be expecting a 32-bit .so ?

If you happen to know ... 
Well, I wouldn't care whether "authentic" waterwarp is implemented into the DirectX or rather OpenGL build. But the one that would get it would be my personal default.

What if both were able to get it? :) 
The Eternal Conflict 
That would mean you and Baker found a way to solve your epic "conflict" regarding its implementation? Sounds like a great X-Mas gift to me, actually...! 
I wouldn't call it a conflict, hehe.

The DirectX version implementing DirectX features is just natural.

The OpenGL remaining at 1.2 for broad hardware compatibility is not something very bloody likely to stop MH.

To say MH is good at rendering is like saying Isaac Newton was good at calculus or that Einstein was pretty okay at physics ;-) 
About MH ... 
There's assembly language in his shaders in the RMQ engine. 
@Baker - Gamma And Contrast 
Currently going through the MarkV code to figure how it implements gamma and contrast in the GL renderer.

To be honest, I see absolutely nothing in either that wouldn't work in D3D right now; even version 8.

Gamma just sets adjusted gamma ramps, which will also work in D3D. D3D does have it's own gamma functions too, but you're better off using the native Windows SetDeviceGammaRamp/GetDeviceGammaRamp stuff (in particular the D3D functions don't work at all in windowed modes, whereas the native functions do).

Contrast is just a load of blended quads over the screen. The only thing I see in there that may be a problem with D3D8 is commented-out code enabling scissor test. D3D8 doesn't have scissor test but D3D9 does.

For D3D9 I'm going to do something different.

I'm going to do shader-based gamma and contrast using render-to-texture. This is achievable with D3D shader model 2 shaders, broadly equivalent to OpenGL 1.5 with ARB assembly shaders so compatibility remains good. It will enable gamma and contrast in windowed modes without affecting the entire display, and it won't require gamma-and-contrast-adjusting screenshots.

The interface will be 1 function: BOOL D3D_SetupGammaAndContrast (float gamma, float contrast) which it will be appropriate to call in GL_BeginRendering. Returns TRUE if it was able to do it's thing (or if gamma and contrast are both 1), FALSE otherwise in which case you need to decide on a fallback - either route it through the GL codepath (which should also work) or do nothing. Everything else will be automagic. 
Likely future scheme, not that this would have any impact on coding anyway ...

vid_hardwaregamma (*) - following the FitzQuakian cvar scheme that I rather like such as r_lerpmodels 0 (off), 1 (best), 2 (always)...

vid_hardwaregamma (or whatever name becomes)

0 - Never. Use best available non-hardware method

1 - Windowed mode uses non-hardware method (looks better on desktop), fullscreen uses hardware method (faster and hardware method is also brighter, some displays tend towards the dark side no matter what without hardware gamma). Default.

2 - Hardware method always.

(*) bad name because also does contrast? 
Also: may notice the code is biased towards GL_RGBA and I have to switch the bytes around to be BGRA for various operations. It isn't actually an oversight or an inefficiency I didn't correct, but rather that OpenGLES only has GL_RGBA.

Just wanted to point that out because I know you may see that code and think "This is so wrong."

/The video/input/system code long ago was entirely rewritten in a way to support devices. In some of the files, there is living device code from back in 2014. 
" Not Found" 

So, my reQuiem test builds were done on CentOS 6.4. Looking at that setup now, ldd says that my reQuiem-debug.glx executable is using /usr/lib64/

rpm -qf on that file shows that it came from the package mesa-libGL-9.0-0.8.el6_4.3.x86_64

I don't remember now if that was something that I explicitly installed for reQuiem's benefit. 
Also: may notice the code is biased towards GL_RGBA and I have to switch the bytes around to be BGRA for various operations. It isn't actually an oversight or an inefficiency I didn't correct, but rather that OpenGLES only has GL_RGBA.

This doesn't actually matter at all in D3D aside from getting the byte ordering right, because you're writing the data directly to the texture rather than relying on the driver to not screw up. 
writing device memory using bytes instead of a cacheline-aligned memcpy will be slower, but whatever. modern apis just have you write it into ram and have the gpu itself move it onto the gpu's memory so there's no issues with uncached memory or whatever.
either way, d3d10+(eg gl3.0)/vulkan hardware has proper RGBA texture uploads so its not like modern gpus care. older gpus/apis will still need some sort of conversion but its okay to be lazy and submit only the lightmaps as bgra. streaming is the only time it really matters. oh noes! loading took at extra blinks-duration! *shrug* 
Compiling Requiem On Linux 
Ok .. first snag ...

#include <sys/cdefs.h> file not found

Solved with: sudo apt-get install -y libc6-dev-i386

Then next issue ...

fatal error: X11/extensions/xf86dga.h: No such file or directory

Does ... sudo apt-get install libxxf86vm-dev -y

But is already installed.

Goes to /usr/include/x11/extension ... no such file as xf86dga.h. Slight Googling turns up ... "xf86dga.h is obsolete and may be removed in the future."

Looks like future is now. See note about warning include <X11/extensions/Xxf86dga.h> instead. on that same page I Googled.

Don't have one of those sitting in /usr/include/x11/extensions either. Hmmm. Hope is not brick wall.

@johnny - I'm posting this for informational purposes. I never expect anyone in particular to assist, just fyi. I'm hoping someone reading this thread that knows what the above could be about may chime in. 
I'm working on my quakespasm-irc engine thingy, and expanding it with more streamer-features.

One thing that I've been wanting to add are the joequake demo features. Rather than reinvent the wheel, and being that quakespasm and mark v share a bunch of code already, I was wondering if I could have a look at the mark v code to steal... uh, borrow from. 
GL_BGRA was really only ever significant as an Intel performance fix, and even then it also needed GL_UNSIGNED_INT_8_8_8_8_REV (which was probably the most annoying GLenum to type) in order to get the fix; without both it still ran slow.

Both NV and AMD also ran slower without these (with BGRA being by far the most important), but insignificantly so; Intel was catastrophically slower.

This is trivially easy to benchmark. Just do a bunch of glTexSubImage calls in a loop and time them. Adjust parameters and compare.

Both GL_BGRA and GL_UNSIGNED_thing are core since OpenGL 1.2, with the latter being adopted from GL_UNSIGNED_INT_8_8_8_8_EXT in the old GL_EXT_packed_pixels extension. So if you're targetting GL 1.2 you can quite safely use them without compatibility concerns.

Since Microsoft did the world a favour by forcing the hardware vendors to standardise on RGBA in the D3D10 era, I don't believe that any of this stuff is even important for Intel any more.

Basically if it's less than 10 years old it probably has good support for RGBA (if less than 5 make that definite) so you can really just use RGBA and no longer worry about this stuff.

I obviously don't speak for mobile hardware, where the rules may be different, and anyway there are far more interesting formats such as RGB10A2 which lets you do a 4x overbright blend without sacrificing bits of precision and with only 2 unused bits per texel. I never formally benchmarked this format but tests ran well.

What's more important about FitzQuake is that it uses GL_RGB for lightmap uploads. Even in the days of robust RGBA support, that's always going to force a format conversion in the driver. Combine that with hundreds of tiny updates (rather than few large ones) and FitzQuake can still chug down to single digit framerates even on some modern hardware.

No amount of BGRA can fix that, and here's where I believe FitzQuake has done the community a disservice. There are lots of interesting things that mappers can do with dynamic lights and animated lightstyles, but because FitzQuake performed so poorly with them I suspect that much of that early potential was never realized.

NV and AMD both suffer from this, but if all you ever benchmark is timedemo demo1 (or map dm3) with gl_flashblend 1 you'll probably never even notice. Intel suffers from this AND needs BGRA/UNSIGNED_etc.

Again it's trivially easy to demonstrate the perf difference, but to robustly fix in the engine requires more reachitecting than I'm willing to do within the scope of my current work. 
If you look around in the Quaddicted engines directory, you can find older Mark V versions like this one where I marked things very cleanly ...

... for ease of porting most of the features very easily to Quakespasm.

Current Mark V isn't structured like for many reasons including that the WinQuake software renderer has been combined into Mark V, but the source is on the Mark V page. 
The True Question Is Baker... 
... how the hell did I not see the source link the first time I looked at that page... 
just looking at host_cmd.c

maybe use an external file for the bad words array rather than a hardcoded one, that way it can be user updated 
Probably at some point I'll do that.

Thinking about host_cmd.c ... I don't think I documented anywhere ...

give command extra options

give silverkey
give goldkey
give rune1 // rune1 to rune4

If you already have the gold key and wish to remove it, typing "give goldkey" will remove it if you already have it.

Typing "give" in the console will display a list of item names
Note: Did end up getting Requiem sorted out. 
QMB effects: lava balls or knight spikes do not leave trails when traveling very fast (velocity 2000) when the server is at .1 ticrate (FvF default due to many monsters and projectiles constantly flying all over the maps).

The QMB trails work fine at .05 ticrate even with the very fast projectiles (Mage's RL = Instant Fireball attack).

Non-QMB particle trails do work under these conditions, but they tend to "skip" a bit. 
Most engines assume a distance traveled per update frame of 200 units or more is a teleportation.

That's my guess without looking at the code because 2000/10 (ticrate .1) = 200

An entity that is assumed to have teleported won't be treated with any kind of continuous movement treatment. 
I saw on Quakeone, Dutch mentioned Mark V has "a difficult time playing external MP3" on his WinXP computer.

That's not very specific, but I wonder if he's seeing the same issue I reported, where there is a pretty significant delay loading the MP3s, during which time the game is completely frozen up.

We tried LOTS of troubleshooting steps in the old thread, but nothing helped for me on my netbook (though the problem didn't exist on my older WinXP laptop). The only thing that made a difference in the end was me re-encoding the MP3s with certain settings that decreased the loading delay (from 17 seconds to 4.5 seconds!). 
I've noticed that with the latest Mark V, it doesn't carry over my video settings (from id1 config) when playing a mod.

Also some occasional flickering/corruption when using GL. I know it's not helpful just to say that so I'm experimenting a bit more to see if has anything to do with my latest NVidia driver update and/or if it happens in other engines. If there's anything you'd want me to do or try that would be helpful in debugging that, let me know. FWIW, latest qconsole.log is at 
Hm. Upon startup, my autoexec.cfg sets up some aliases (or runs other cfg files that set up aliases).

But then if I am sitting on the server and I reconnect to the same server (by "connect" -- I was toggling external lit files), many of my aliases are forgotten.

But not all of them....

For example:

alias zoom_out "chase_active 1;chase_mode 1"

Is always forgotten upon reconnecting, but:

alias start "changelevel start"

is never forgotten.

This is pretty inconvenient. It means I have to re-run my cfg files when I want to reconnect or connect to a different server without completely restarting Mark V.

QMB effect difference: Particles in Quake are "fullbright" but the QMB blood effect is not fullbright.... So, in Quake you can always tell when you are hitting a monster in a dark area, but with the (more realistic) QMB blood, you can't tell.... Perhaps in this case it would be good to throw in a few standard red particles (even QMB particles are fullbright) in addition to the blood sprites (they are kind of sprites, aren't they?).

But this will fall under QMB fine-tuning.... 
alias zoom_out "chase_active 1;chase_mode 1"

Cannot reproduce.

I bound the above exact alias. Connected to a random server. Disconnected. The alias was there. Reconnected. Disconnected. The alias was there. Even connected to your server, disconnected, reconnected, changed the map, disconnect, reconnect, disconnect.

The alias was still there.

red fullbright blood - monsters in the dark

Interesting difference. Although I haven't looked into it, I suspect QMB blood is already fullbright, it just isn't very bright. Something to think about. 
QMB blood types 1 and 2 have a blend mode of GL_ZERO, GL_ONE_MINUS_SRC_COLOR, so they're not lit, they're just blended with the background geometry. 
Probably should change then. At least for the ones that aren't intended as true "ambience" and few of them are. 
Ok... There's some weird interaction of FvF + my tricky aliases + Mark V

So in FvF, when a player connects, or when a map first loads, I do:

stuffcmd(self, "re-exec\n");

Then I can set up stuff like this, in autoexec.cfg for example:


alias fogon "fog 0.05; bind f8 fogoff; alias fogset fogon; echo Fog On"

alias fogoff "fog 0; bind f8 fogon; alias fogset fogoff; echo Fog Off"

alias re-exec "fogset"

alias blah1 "echo blah1 is set"


alias blah2 "echo blah2 is set"


Yeah, I don't know how "correct" that is, but it works. It lets me toggle fog on and off with F8, and at each level change the automatic "re-exec" alias will run the "fogset" alias which will be assigned to either the "fogon" or "fogoff" alias, depending on which I last toggled with the F8 key....

But I think the problem is arising where I am assigning one alias to another alias like that ("alias fogset fogon" within the fogon alias...).

So, as I said, usually all this works fine. Every level change the fog setting will be re-applied after the level starts, or upon first connecting to FvF.

But if I am sitting on the server and I re-connect to the server, things go wrong, and ANY alias that was assigned AFTER the "fogon" command in the cfg above will be forgotten (so blah1 above will remain, but blah2 will be forgotten, as will any alias you have manually entered into the console).

OHHH, I think I may get it... or part of it....

It seems to happen upon DISCONNECTING from the server.

So this may be happening:

- All aliases are set up before connecting.
- Upon connecting, the server has you run "re-exec" by stuffcmd, which runs "fogset" which runs "fogon" which includes "alias fogset fogon" so now Mark V thinks it's a SERVER stuffed alias, so it discards it when you disconnect from the server....? Maybe?

That still doesn't explain why ANY alias set after that point (either in your cfg file or manually by console) is also forgotten....

Let me see if I can trim this example down a bit more.... The above fog setting code is actually useful (to me anyway -- I don't just do this crazy stuff for no reason!), but here's just a proof of concept to show the issue I'm having:


alias setblah "alias blah say blah"

alias re-exec "setblah"

alias blah1 "echo blah1 is set"


alias blah2 "echo blah2 is set"


The odd thing is if you remove the manually running of "setblah" from the autoexec,cfg file above, then everything seems to work, and only the "blah" alias will be forgotten upon disconnecting. Blah2 will remain. Ah, but any alias you set AFTER connecting to the server will be discarded.

But if that line is there, then every alias after that point will be forgotten upon disconnecting from the FvF server.... blah2 will be gone, as will any alias you set in the console after that point.

That's weird, right? 
QMB Effects: I think I know why my splash effects are being destroyed so quickly... and also why my chat smoke looks a bit odd.

It seems that most QMB particle effects are quickly removed if they are touching a player.

Try jumping up and shooting the floor below you with the shotguns. You will see that the particles vanish as soon as you come back down on them.

Perhaps this is an attempt to prevent obscuring the player's view with too many particles right on top of him? Though the explosion effects are what's really bad at doing that, and this doesn't work for them!

But yeah, that's messing with my splash effects, which are created at the player's location. 
QMB particle effects are quickly removed if they are touching a player

They are. In single player fire a rocket an even angle. Type "freezeall".

Now with everything frozen except you ...

Walk through the smoke, any smoke you walk through goes away. 
I've noticed that with the latest Mark V, it doesn't carry over my video settings (from id1 config) when playing a mod.

I used to have Mark V read those settings only from id1. Then someone said, I when "I play a mod, it ignores my settings I changed when I play it next". So I had to iterate through the proper Quake way.

Which might describe what is happening in the above.

To get it to be ideal (both!) would be bit involved, but I do have a plan for that in version 1.3, it's elegant and simple. It also involves some slight evil, but it's awesome kind people like and some other engine coder will say "Ah, that's ingenious."

Story for another time ;-)

my latest NVidia driver update

Let me know. Is it new for the driver or new for the version of Mark V?

They say NVidia's latest driver does flicker, but I'm not going to assume that it also couldn't be the engine's fault somehow in some rendering circumstances.

None of the FitzQuake derived engines have a state manager. Which means there can easily be an errant situation where something crazy like a glBegin without a glEnd or two of them or such other possibilities exist.

1) If the problem persists or exists without the current driver ...
2) Or if a previous version of Mark V doesn't have issue ...
3) Or if a certain map ...
4) Or certain combination of options ...

Short version is that at some point Mark V will have state manager, which would reduce the chances of the engine being at fault greatly (but a few other situations would still be possible).

Let me know if it persists and if it happens with a certain map or a certain setting on. 
It happens to me too. It has started once I switched to geforce 1060 videocard. It happens in both old and new versions of mark v on any map. I hope it helps.

And there's one minor issue about mirrors. I want to make a small map about mirrors. I placed two mirrors on the opposite sides of the room (I know it's not the way it should be intended, but it looks soo cool), you can't see them both at a time, they reflect well, but one of them turns off once I stand close the other mirror (touching it with player's back). I supposed that the second mirror somehow got in the view (but it didn't) so I placed a clip brush in front of it, so I can't get close to it. But it happens the same way once I touch that clip brush. And it always happens with only one of two mirrors (the rooms are completely symmerical), while the first one works as it should when I touch it with player's back. I tried it in two different rooms and the problem always occurs with the south mirror. The problems disappears once I get 1 unit away from the wall. 
It seems that the flame cut-off system for the QMB particles doesn't work on replacement models. I'm using this pack and the flame polygons stay:

Another minor nitpick is that only the main Enter/Return key works in the menus, the numeric pad Enter doesn't. 
@baker(proper Mirrors/portals) 
for (i = 0; i < nummirrors; i++)
scene.addclipplane(mirror[i].surfaces.backplane); //ensures the mirror can only draw what is actually reflected, and not things that cross the mirror's plane.
//fixme: set scissor region
backbuffer.clear(depthonly); //anything in the real scene should not be obscured by the mirror
for (j = 0; j <= i; j++)
mirror[j].draw_onlydepth(); //mask the depth so nothing further within the real scene can overwrite.
//fixme: reset scissor

assuming I typoed it wright and you already know which mirrors you want to draw, the above algorithm should allow you to have cubes with mirrors on each face or whatever.

if you can make the mirror-list calcs recursive like in FTE(r_portalrecursion > 1), then you can get mirrors reflecting other mirrors. Just beware that if one mirror can see two mirrors then any further recursion will likely be exponential (read: really slow). 
UI Aspect Ratio 
here's some obscure territory

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 
@mw - Winquake Stretch 
Right now, I treat Open GL and WinQuake identically (it's biased towards Open GL treatment).

From your screenshots I do see what you are saying. Thanks for providing screenshots. 
@pulsar ( + Spike) - Mirror Limitations 
At some point like what Spike hinted at, I would like to improve the mirrors.

There are certain 3D calculations, reworked drawing, even tool support (.vis) and possibly some recursion that could make mirrors better.

Blocking a mirror with a brush doesn't necessarily help because Quake map vis truly sucks and does a relatively poor job (play r_lockpvs 1 and walk around and be prepared for surprises).

I'd like to put mirrors on 2 sides of a room too.

Limits suck and you can hope for better in the future, but right now you can't have 2 mirrors that can see each other according to map vis.

And it is worse than that, because in the current implementation there should not be a location where 2 mirror planes can be seen from anywhere in the map.

That being said, it still gives plenty of freedom to do awesome stuff with mirrors --- even with current limitations. 
@dwere - QMB Flame Lack Of Replacement Support 
Yeah, I hear you.

Original QMB as witnessed in JoeQuake or similar engines, would actually override a custom flame.mdl with its own.

Allowing for no possibility of using a replacement model for flame.mdl at all.

One possibility among many is that I might at some point do the flame drawing more aggressively to not require my "sawed off flame.mdl" method --- the flame would acceptably draw over the part of the model that shouldn't be shown.

At the same time, one problem with the QMB flames method is it is tailored to pak0.pak flame.mdl. 
NVIDIA (pulsar / Johhny) 
It is probably easy to resolve in the engine.

In a few weeks, I'll probably have my hands on a NVIDIA "gaming laptop" or 2. All my machines are AMD, including the Mac ones. :/ 
Damn Baker 
I had no idea how dirty you are ;) 
Random idea: When doing a local multiplayer game in Mark V (basically a listen server), could you make it honor the sys_ticrate setting? "force_ticrate 1" or something.

This would be handy for testing how your mod is going to actually run on a server, which will actually use the ticrate settings, as opposed to just running it on your own computer, where it will run as fast as your FPS allows, which alters the physics....

This could be useful to mappers too, for testing their maps -- the gravity physics behave differently when connected to a server with a ticrate, as opposed to when you're playing it on your own computer. For example, when a mapper creates a jump that is just make-able in the "single player" (local) environment, that jump can become impossible when playing on an online server (examples: playing online -- depending on ticrate -- you can't jump up the stairs out of the shallow water pit on e2m6, or out of the lava under elevator on e3m7). In FvF I actually change the default gravity from 800 to around 700 in order to make the jumping more like it is in the local Quake environment.

Anyway, being able to force Mark V use the ticrate setting locally would allow mappers and modders to test their stuff using the physics that will apply when someone plays online. Normally to do this, we have to set up a dedicated server then connect to that on same computer.

And I just wanna make sure you didn't overlook my additional report about aliases being discarded above: #657

I understand why one alias would be discarded (interpreted as a server stuffcmd alias), but why's it also discarding every other alias which was set after that point? 
Ticrate is an endangered species to Mark V.

At some point, Mark V will have fps independent physics, Spike's network compression and, likely, prediction available as an option.

Aliases: I took a shortcut and any aliases created on a remote server are purged. Including ones typed in the console while on a remote server (and then forgot I implemented it like that). Since aliases don't save to config anyway in regular Quake, someone would manually have to add them their autoexec.cfg (or what not) anyway. So this reminds that there is a little bit of unfinished business in that sense. 
I don't suppose there is a changelog that one can keep tabs on? 
That is an interesting question. The answer works like this ...

There are 2 types of projects:

1) Outside-In. Seeks popularity and attention. Wants to be easy to follow.

2) Inside-Out. Seeks quality. Meritocracy. <----- (you are here)
Interested in high quality participants and higher levels of engagement.

Each build has a list of changes in the build post so it is documented. Making things easy to follow isn't a characteristic of an inside-out project.

So is the name "Mark V", yields useless search engine results ;-)

Pre-calculated strategy to limit participation to the most knowledgeable A+++ contributors. Even the dozen 1 or 2 post contributors have contributed invaluable knowledge and insight.

/But when the WinQuake through GL build happens, I'll be sure to let you know. 
Think I'm wrapping things up roundabout now and am getting close to a code handover. I expect to have some further work to do based on feedback from that, but right now I'm pretty damn pleased with how things turned out.

A bunch of perf testing comparing with both the original version of the wrapper (in the original DirectFitz) and that in Mark V (which I wasn't aware used a markedly different version until quite recently) shows improvements on both. It's not going to be earth-shattering with lightweight (ID1) content, but should pull ahead more as the polycount goes up.

For the record, here's what's new/changed/improved/etc:

* Combine multitexture modes.
* Fog is per-pixel only.
* glCopyTexImage/glCopyTexSubImage for framebuffer water warp.
* Half-texel offset corrected.
* Polygon offset corrected.
* Scissor test.
* Shader-based gamma and contrast.
* Stencil buffer.
* Texture matrix.
* Vertex arrays.
* Vsync corrected.

The FitzQuake codebase I've worked on also includes sample code for the following (in what I hope is going to be relatively easy to port):

* Dynamic lights on moving brush models (Mark V may already have this, I haven't checked).
* Underwater warp.

These are both implemented using Baker's standard of clearly #defining the code changes so you can quickly and easily find them all.

As a nice bonus they also work in the GL build.

So I've some work left tidying up the interface and making it more conformant with what Mark V is currently using, but hopefully sometime over the next week I'll be doing a first code drop! 
Dynamic Lights 
On moving brush models sounds interesting. 
DX9 Feature Set 
Sounds like a very nice feature set!

Is the depth buffer range ability used for mirrors included? The vertex array support will be a welcome addition, as will all of the other new functionality, of course.

I did modify the DX8 wrapper, but if I recall the changes were mostly organizational or to have more precise control over certain steps.

Dynamic lights on moving brush models

Yeah, has had that for a very long time ;-) 
Roger That 
thankee baker 
Depth buffer range should be working correctly now, yes.

Dynamic lights is just a fix for a long-standing Quake bug whereby if a door, plat, train, etc moved, it still picked up dynamic lighting from it's old position, not it's new. Check out the secret at the start of e1m4 for example. Give yourself the RL and fire a few rockets at the plat in it's starting position. Then trigger the secret, let the plat go down, fire a few more at it in it's final position. You'll see what I mean.

I knew there was a high probability Baker already had this, but I included it in the hope that other engines would pick it up too (e.g. QS doesn't have it) because it's such a basic feature and genuine improvement. 
Reminds me of something I should mention now, in the event you are interested in doing this:

A mechanism for rendering verts interpolated between 2 frames (factor of 0.0 to 1.0 between the frames). I can't recall the details of the conversation and insideqc is immune to Google searches. If I recall, you stated this is impossible by any means in Open GL 1.x, but quite possible in D3D.

/Mention because if you have thought about it already, I suspect you would later ... 

The extension exists but I've never seen any hardware, either for real or in the various registries/databases, that implemented it. I suspect because any hardware that would support it also supports vertex shaders, which can also do the job.

D3D since at least version 8 has also offered the capability to do fixed-pipeline vertex blending, and hardware/drivers do support it. I did write code that used it once but don't recall the details. It was easy enough though.

IIRC stock Fitz does a lot of multipassing on MDLs and even if you didn't go all the way to hardware blending it wouldn't hurt to blend once only in software & cache the results for subsequent passes. 
Actually on reviewing the GL extension it doesn't seem to provide "tweening" capabilities, being limited to blending matrices instead.

So this seems to be another of the ARB's "we don't need the telephone, we have plenty of messenger boys" moments of glory. Sigh. 
Isn't something necessary or anything, just wanted to raise the thought. There may be a lot to test anyway ;-)

Looking at the code there is a per vertex color component that comes from a table depending the lightpoint value (dynamic light color where player is standing). I don't know how that easily gets into a color array, haha. 
IIRC stock Fitz does a lot of multipassing on MDLs

I think the fitz0.85 MDL code actually gets away with one pass, if you have the extensions:

if (gl_texture_env_combine && gl_mtexable && gl_texture_env_add && fb) //case 1: everything in one pass

Looking at the code there is a per vertex color component that comes from a table depending the lightpoint value (dynamic light color where player is standing). I don't know how that easily gets into a color array, haha.

Yeah - what I concluded when planning QS's r_alias.c updates was that, if I was going to go to the trouble of lerping in a vertex shader, the color calculation had to go into the shader as well.
Otherwise, I figured having the CPU still calculating lighting on every vert per mdl per frame (and still uploading data to the GPU every frame) would mean low performance gains for a lot of programming effort.

So what I ended up doing is passing in "shadevector" to the vertex shader - that's the fake light direction calculated from e->angles[1] and quantized, as well as the color sampled from the lightmap, and the lerping fraction. Then the shader replicates the lighting calculations that the Fitz code does on the CPU (except using MH's reverse engineering of anorm_dots, instead of the table itself, for convenience). 
aye, lerping verts on the gpu is kinda pointless if you're not also calculating lighting based upon it too.

ideally, use drawelementsindirect and throw 512 ents at the gpu per draw call, with atlasing/texturearrays or whatever for textures and SSBOs for the vertex data. you should get some awesome framerates that way at least when compared to other engines trying to render 10+k knights at a time.
actually using it without breaking everything else is more of an issue. yay compat... 
Makes sense, in the past I've wondered how much that calculation matters for objects other than the view weapon or extremely close items. In fact, I've wondered for interpolation whether or not floating point (0.0 to 1.0) is overkill for interpolation. 
In fact, I've wondered for interpolation whether or not floating point (0.0 to 1.0) is overkill for interpolation.

Floating point is likely going to be faster than alternatives on modern CPUs. By which I mean anything in the past 10 or so years. 
Window Resizing 
That is very nice. 
Window Resizing 
As it turned out the wrapper supported it anyway (aside from changing a window style to allow for resizable borders in the reset code), it was just engine code changes that were needed.

The version of the wrapper used by Mark V also lacks one function (other versions of it had that function) that can reset the mode without having to recreate the window, but that can easily be provided if Baker wishes to retain D3D8 for any reason. 
Include brush models in lightpoint calcs so that if you stand on a plat, train, etc you pick up light from that bmodel rather than from the underlying world geometry. 
I've been fiddling around with some batch files that could use Mark V and its install command as an "easy button" for getting some popular Quake SP content installed. I've come across a bug/quirk in the command behavior:

Sometimes a zipfile does not have any top-level folder, and also does not have any pak or progs, but does have things other than maps (so it likely does need/want to be in its own mod folder). and are examples of this; they contain lots of content aside from the bsp files, but the installer just puts the bsp files into id1\maps and throws the rest of the zip content away.

There's a few different ways to fix that if you want to. FWIW my own preference would be for the install command just to always put installed content into its own mod folder (or have that option available). 
Also something interesting I just noticed with installing I see that there an "FMOD.DLL" file in the original zip that gets extracted as a file named "dll" into the warpspasm gamedir.

Haven't really investigated this yet, but this may be because most of the extracted files are in the "warp" subfolder of the zip, but FMOD.DLL is not. So when doing path-munging to get the base file name, Mark V may incorrectly skip over too many letters of the path. 
I wonder if there is a tutorial somewhere to add a better modelformat to FQ?
Im thinking to add a (simple) MD3 loader based on JoeQuake or even IQM..

Would it hard to add IQM to FitzQuake? 
I added IQM to the RMQ engine, which was based on a much older build of QuakeSpasm that was nearer to FQ.

The big constraint of IQM in the context of Baker's stated goal to not go beyond GL 1.2 is skeletal animation: it's just far too slow to run this on the CPU. Even as few as 3 to 5 moderately complex models in view will pull your framerate down to a significantly low percentage of what it was. Stock FitzQuake is already CPU-bound and the last thing it needs is even more loading.

MD3 should be easy enough I think (I've never coded it up myself so can't comment more) and MD2 should be very doable (it can even share data structures with MDL). 
@mh -

true lightpoint

I would be interested in using your implementation of getting the light from brush models as a cvar or a worldspawn key to activate it. There are existing maps that this change alters the lighting in an undesirable way so it was removed from Mark V, but also I never quite 100% trusted my 2012 implementation. But I can remember pulsar wanting such a feature and activating it via a worldspawn key (name? "true_lightpoint" "1"?) would be ok for sure for a map wanting it.

dx8 build after dx9

Yeah if you have an enhancement for dx8 ... I expect the dx8 build to existing in the project as unused separate build since it's just 1 file

I've been slowly trying to wrap up implementation of the other platforms I want to have builds available for one example.


Thanks for the heads up on how certain specific files that don't contain primary playable Quake content or that weren't planned for in the installer.

About batch files, this reminds me that I should make sure Mark V can play demos via file association ...

c:/quake/mark_v.exe +playdemo "c:/path_to_file/mydemo.dem"

... which in theory I wrote, but in practice I have never tested. And since untested things rarely work ... I would expect it to not work ;-)

Same for ...

mark_v.exe +capturedemo "c:/path_to_file/mydemo.dem"

... which allows bulk capture of demo to AVI. But I haven't tested it recently and as untested do not necessarily work right, it may or may not do so.

@steve - Mark V won't be doing IQM, etc. and isn't suitable for total conversions, etc. Why not use an engine like FTE which does fancy model formats and can even run in a web browser and is built to support total conversions? 
Why im currently using FitzQuake is because my current project is based on an abandoned psp project which uses a customized engine from crowbar and porting it to pc would be basicially just copy/paste/modify my own modifications (so it basicially becomes a stand alone game using fq).

Using FTE would be a nice alternative ofc, but i dont know anything about csqc.. 
@mh - True Lightpoint 
If you could, could you also have your alternate truelight point throw the (msurface_t *) it hit to a pointer and the distance?

Without looking, I think lightpoint has to return at a minimum the color rgb (which I think it puts in a global). It would be preferable for it to also return the distance, the model (model_t *) and the surface (m_surface_t *) to globals as well.

No obligation, of course. ;-)

/I figure since your knowledge of the .bsp is a few tiers of above mine, I'd mention this. My understand of the .bsp is not too bad at all, but is not on the level that I could write map compile tools in a timely manner or spec out a new .bsp format ;-) 
@gunter - I made a stab at making the blood fullbright dark red, but the existing particle texture is not suitable :( Not even reversing the colors, etc. The textures in question are rather hard-wired for "subtractive blending". So that imperfection is likely to live a while, unfortunately.

@steve - I hear you. And empathize. There are csqc tutorials at insideqc, I suspect you already know this. If even mh has trouble fully implementing iqm at a good framerate, any mere mortal (including myself) has a 0.0000000000 chance (plus my interest in iqm for Mark V is also 0.0000000000).

If I were in your position, I'd start learning csqc and switch to fte. 
If you could, could you also have your alternate truelight point throw the (msurface_t *) it hit to a pointer and the distance?

Without looking, I think lightpoint has to return at a minimum the color rgb (which I think it puts in a global). It would be preferable for it to also return the distance, the model (model_t *) and the surface (m_surface_t *) to globals as well.

They're all trivially easy & I took the opportunity to clean up the code a little too.

Interesting thing: this should also work for putting shadows on bmodels (because "lightspot", used for positioning shadows, also comes from R_LightPoint) but currently it doesn't. I'll need to debug that a little.

There's room for substantial optimization in all of this code. With r_shadows 1 R_LightPoint is actually run twice for each entity; cull tests and a few other things are also run twice. There's a whole block of work that should basically be done once only much earlier in the frame.

Again, this stuff is such that it's not going to grossly impact ID1 maps, but start ramping up the entity count and it will make it's presence known. 
the engine supporting csqc doesn't mean it MUST be used, you can still get quite far without it (eg: smc, tenebrae etc). 
@mh - Awesome 
Thanks, MH!

They're all trivially easy

Then here's a quick question. Would you be interested in making SV_RecursiveHullCheck return the (m_surface_t *).

I have a hilariously awesome and clever idea for traceline and SV_Physics.

But I need traceline to return the surface because if it does, the check is "free" (no extra cpu).

/If this is possible. Also obviously, no obligation, now or ever. Keeps engine coding more fun ;-) 
Would you be interested in making SV_RecursiveHullCheck return the (m_surface_t *)

Not quite the same; the server code doesn't have access to this data, it just uses clipnodes and planes in the hull, not even touching regular nodes. 
I suspected as much :( At least I can mark that off my "investigate if this is possible" list. 
More Words About "install" Stuff 
So the reason I was looking at the install command: I was thinking about building a "Quake singleplayer newbie quickstart" package around Mark V and the Simple Quake Launcher. It turns out there is still a LOT that has to be explained, but the menus and install feature of Mark V do help a little. A quickstart package would be a nice thing to have handy for sharing if for example Quake goes on sale in the Steam winter sale tomorrow.

I wanted to provide batch scripts that would help install a sampler of custom Quake content. I laid some ground rules to pick highly-rated and/or influential or classic stuff from Quaddicted, rather than just trying to pick my personal favorites, and ended up with almost 30 selections.

I thought the batch scripts would be pretty simple buuuuut it turns out not so. There are sometimes mod patches to install, sometimes other things to fix about the mod (like if it includes an autoexec.cfg file that overrides your own), etc. And then there's the Mark V install command issues. At this point I'm not sure if the effort was worth it :-) but it's done and it is what it is.

The Mark V issues so far are just in the two buckets that I mentioned in previous posts. Either 1) failing to install all the files (because no progs.dat or pak file in the zip), or 2) mangling some file names because of subfolders.

Of the content I tried to install, these were in the first bucket:
arcanum, apsp3, func_mapjam2, mapjam6
and these were in the second bucket:
nehahra, warpspasm

The second bucket is fixable from the batch files just by doing file commands. Although in one case a file with a short name actually gets completely nuked by the path issues, but that's OK because I didn't want it anyway (the fmod.dll in

The first bucket I can also fix in the batch files by extracting the stuff from the zipfile myself instead of letting Mark V do it, but to unzip files I'm using a feature of .Net 4.5 which is only installed by default on Windows 8 and 10. So that's not ideal.

Anyway that's a lot of typing about install issues. To help break up the wall of text I'm going to stop this post and then have two short posts with some questions. 
Thing 1 Of 2 
OK so FYI, here's the installer batch scripts as they currently stand. The "installers" folder should go into your Quake folder next to Mark V:

The .bat files are the ones to run. Ignore the .cmd files as those are just common code shared by the .bat files.

If anyone wants to try them out I'd be curious to hear about problems you encounter. I probably will share these around during the Steam sale, likely bundled with Mark V and the Simple Quake Launcher and a bunch of readme files. I'm sure only a few people will make use of them, but even so it would be cool to get a tiny bit of advance testing.

Even if you are on an earlier version of Windows and don't have .Net 4.5, the installs of the "problem child" mods like arcanum should fail gracefully with a nice message about how to manually fix them.

So if anyone gives these a try, please let me know if they work or if they don't. If it's an interesting issue you could post it here, or otherwise to avoid cluttering the thread you can email me. Use the email address that's in the page footer of 
Thing 2 Of 2 
Last thing for now, a question:

When trying to give people a foolproof way to run Quake content, the major gotcha I'm left with is how deal with a mod that needs a base game. Like how warpspasm needs Quoth. I can install Quoth for them but I can't make them specify Quoth as a base game when they launch Quake to play warpspasm.

I know that Quake Injector solves this, but getting people to correctly install and use a Java program has turned out to be a hurdle. It's kind of bad that the mods and engines themselves don't declare and enforce base-game requirements. Has there ever been any discussion of standardizing on a way to solve this? Some metadata that the engine would recognize and honor? 
Forgive me for being an idiot here, but the Quake Injector is open source right? Is there any particular reason why its method of handling unpacking and installation isn't used by MarkV?

Obviously it's not something you can convert (It's java, after all), but surely the logic that it runs can be reproduced. If that were the case I imagine the only compatibility issues would be ones shared by it as well, rather than all these new ones that seem to have cropped up here...

I'm sure there's a perfectly good reason why this wasn't done, but I don't know it and this question has been on my mind a lot recently. 
Mark V can unzip most zip files properly just by itself.

The Quake Injector, as it is currently written, cannot. A brief discussion with Spirit, he was like "Ah, why didn't I think of that?" when I told him the secret sauce.

So the short version goes like this ... let's say someone has a .zip file that isn't in the Quaddicted database. Like this stuff ...

The goal of the Mark V is to not be dependent on a database to give independent parties the potential of possibility of creating their own archives.

Also I view the Quake Injector as too permissive in the unzipping, I also think it does it slightly wrong -- a small gripe -- but engine developers worry about "the little things". 
The "installers" folder should go into your Quake folder next to Mark V

I hate to have to say it, but this is where "n00b-friendly" breaks. My experience was that getting stuff into the right folder(s) is the number 1 difficulty people have. 
Yeah, that's why I will probably bundle w/ Mark V and SQLauncher already in the correct folders if I share outside of this forum.

Although they will still have to understand folders to some extent in order to put pak files in the right place. Hmm maybe I should bundle in Baker's ez-installer for Mark V instead of just the Mark V exes, since I believe that will go fishing for pak files in Steam or GOG installs of Quake.

In the end though you're going to have to deal with files and folders at some point if playing Quake mods. There's eventually always going to be some sort of gotcha that an ez-installer can't solve. Might be possible to get past the initial hump though. 
My mistake, the Mark V ez-installer doesn't do that. I'm probably thinking of nQuake. 
having never looked into how the Quake Injector works, I didn't realize that it had specialized instructions to unpack troublesome archives. Darn.

Perhaps if it were possible to reference that database where possible? That way you could maintain compatibility and not rely on it for unpacking, but also benefit from the effort put into making it work. 
I'll do some thinking.

I like to do thing in slow motion, particularly during this time of the year. I thought of a reply, but I'm going to hold off related to theme of the movie "The Prestige" (the trick impresses everyone, revealing secret impresses no one).

I like the night and the cold and being there is an actual winter this year (awesome!), and this being the longest night of the year means that to be a decent person according to my standards must involve beverages of yuletide merriment. ;-)

/That being said, one of the folders of the source code doesn't seem to utilized much by Mark V. ;-) I wonder why it is there?!?!? 
Hmm maybe I should bundle in Baker's ez-installer for Mark V instead of just the Mark V exes

Copy the URL of the Mark V ez installer to the clipboard. Backspace out the extension (remove .exe) and then type .iss. Press Enter.

Now you have the Mark V ez installer source code to play with as you please so you can make somethign to your liking. 
I know you have an interest in user-friendliness.

You may find this 3.5 year old Mark V build intriguing R8 build from 2013.

In it, type "tool_menu 1". Pressing the Windows key activates the menu.

Mark V R8 2013 - Menu Prototype Screenshot 1
Mark V R8 2013 - Menu Prototype Screenshot 2

I'm not sure where this fits in to any conversation. 
I downloaded an old build of mark v which mentioned a ghost demo, do you have a version with this code? I may want to incorporate it into my speedrun/irc mod.

//#define SUPPORTS_GHOSTING_VIA_DEMOS // Baker: Older Mark V had this. Ditto. Race a ghost from a demo. 
The R8 build above (#716) has that feature and contains the source code. Although I liked the feature, there are situations that can arise that are impossible for "race your ghost" to handle. Was a cool concept. 
All I want is for the demo player position to be played, I don't want him to interact with anything in else the world.

I'll have a look. I want a better understanding of how demos work anyway.


I expect that you'll have some feedback and I'll have some work. 
Direct3D 9 SDK June 2010 is correct SDK? 
June 2010 should do, yes, although I wrote it to work with any version (so long as it includes D3Dcompiler.h) 
Incidentally, I did all of this work using Visual C++ 2008 Express, and I do recommend that you build the initial DirectFitz project before trying any integration to Mark V. 
DirectFitzQuake 9 
Finished compiling ... For anyone who wants to try the initial Direct X 9 build, here is a .exe

MH Direct X 9 - FitzQuake 0.85


@mh ...

5 minute mark comments

1) Wow! That's a nice framerate!
2) Adjusting the brightness moves the pixels on-screen by 1 pixel up and by pixel 1 left. Presumably gamma != 1.
3) vid_vsync sure works. I had to turn it off to check it out
4) I see you took a different and more organized approach, implementing several C++ instead of the single file approach. Not that this makes any difference at all.
5) Didn't see any .lib files in the project, nor #pragma comment(lib, mylib.lib) so I am guessing d3d9 has pragma comments in the headers somewhere.
6) Haha, it resizes!
7) Surprised no contrast cvar, you used to be very insistent that any decent engine must have contrast ;-) /I agree with that, obv.
8) Haven't checked the contrast/gamma ranges.

Initial comments. May be a few hours or possibly even tomorrow before I have more comments or a may change my mind and investigate it a lot more before then ....

Main reason: I was coding something which is 85% of a complex change and if I don't strike while the iron is hot, I may forget the subtle details.

But needless to say, I'm liking this Direct3D 9 wrapper quite much! 
Direct X 9 Water Warp Screenshot 
Some Responses, No Particular Order 
There should still be one #pragma comment (lib), for d3d9.lib, but since that only exports a single function I could very easily dynamically link instead. Everything else is dynamically linked at runtime, primarily to resolve problems caused by different versions of the d3dx9 and d3dcompiler DLLs.

I didn't implement a contrast cvar because I wanted to keep intrusive changes to the original engine code at a minimum. Of course I then went and made a lot of intrusive changes elsewhere! Anyway, the brightness/contrast setup does support contrast, but the engine just hard-codes it to 1; I took the calculations from Mark V's gamma tables (used for applying brightness/contrasdt to screenshots) so they'll be consistent with those.

I understand what's happening with the "adjust brightness/shift by 1" thing but I'm not sure I understand why. Need to look into that more.

Yes, I found the single-file approach quite difficult to work with when making wide ranging changes. I switched to C++ quite late and mostly on account of a comment you had on wglMakeCurrent in the old wrapper - so that part is your fault! After fixing that up, I found that I wanted a "context" struct to keep things better-organized than using a lot of standalone globals, then found that I was passing this struct as the first param to a lot of functions. That's the point at which one needs to consider switching to C++, for code-cleanliness and robustness if nothing else.

On the other hand I do see a huge appeal to the single-file approach. I love stuff like stb_image where you just drop in a single header and you've got everything - so easy! But at this stage I don't think I'm going to switch back.

I'm going to let you chew over things for a short while before I pick it up again; currently debating what the best way to deliver new versions of this is going to be. Obviously you'll need to change some of the public API stuff "from "gl*" to "d3dmhgl*" or whatever) and I seem to remember that you're comfortable using WinMerge so I think I can just bash ahead with the internal stuff and leave it up to you to work out the diffs? 
took the calculations from Mark V's gamma tables

Cool, now I don't have to look into that. I was messing with the contrast just 30 seconds ago to play with it.

Quakespasm uses Mark V's gamma/contrast system and Mark V's gamma/contrast system is backwards compatible to WinQuake.

I put a lot of thought and planning into Mark V's gamma/contrast system and I was, for instance, very pleased when ericw implemented it same in Quakespasm.

Also noticed some other things, like colored lights "option" for scrag/wizard attacks and such. And a possible dynamic light calculation correction in r_lightpoint not related to the concept of getting the light from inline models (*5 or *10 models, etc.) 
R_LightPoint was actually the last thing I worked on, earlier on today. I'm really pleased with how that turned out, but still annoyed about shadows.

I just really love adding those extra dynamic lights. I can understand that they might have been slow in 1996, but in 2016 they're so cool to have and add so much to the game.

Reminds me that I haven't corrected the stock Fitz support for > 32 dynamic lights; that's very badly broken. 
Reminds me that I haven't corrected the stock Fitz support for > 32 dynamic lights; that's very badly broken.

I have 128 dynamic light support that was based on a tutorial you wrote, but whether or not you'd like tutorialize within DirectFitz 9 for, say, Quakespasm or other engine without feature is obviously up to you ;-)

For reference the easiest map to see where the change matters is the Warpspasm secret map, but I suspect you had to have a test map in mind yourself, otherwise how would you know if it works? Hehe

still annoyed about shadows

This 2007 build of DarkPlaces has correct shadows ...

Just pointing this out. Obviously, the source is in that .zip since that is how LH has always done it.

Shadows, a pestilence that annoys engine developers ;-) 
What's annoying is because "lightspot" (or my equivalent of it) is calculated in R_LightPoint, and because that's what used for positioning the shadow, it should just automagically work - no extra code needed.

That tells me that the likelihood is I'm doing something else wrong, but right now damned if I can think of what. It'll come.

Thanks for the reminder that I had written a tutorial about the lights. No, I didn't have a map in mind, it was just obviously broken (trying to fit 64 light bits into a 32-bit int isn't going to happen). 
@mh - GlOrtho One Call Is Different 
If you ever get a chance, this block of code has me somewhat confused:

(Water warp area ...)
....// bottom-left-is-origin crap
....glOrtho (0, 1, 1, 0, -1, 1);
....glOrtho (0, 1, 0, 1, -1, 1);

I know Direct3D uses a different 3D matrix than the "mathematically correct, but somewhat inconvenient and annoying OpenGL 3D matrix especially when you want to do 2D".

But none of the other glOrtho calls are treated in that manner? Something I'm not seeing here, I'm sure ... 
The other glOrtho calls are set up in a way that they cancel out. This one isn't, because I'm using normalized device coords and identity matrices (those glOrtho calls are really the equivalent of identity with D3D being vertically flipped) so I need to correct for it.

Ummm - did that make sense? 
Mentioning something, even though it doesn't really matter.

With dx8 Mark V in windowed mode, if someone alt-tabs out of it, I do something sneaky and minimize the window -- to obfuscate the fact that the window must stay on top of all others.

May be an unchangeable characteristic of Direct3D.

I hadn't thought about this in quite some time. But since DirectFitz 9 doesn't employ a trick like that, for a moment I wasn't quite understanding why it was staying topmost when it lost focus.

/This behavior does not much matter, but I'm just pointing it out. 
Actually my suspicion was correct - that was nonsense. NDC goes -1..1 but I'm going 0..1 for starters. What's relevant here is glCopyTex(Sub)Image copying from bottom-left, but D3D StretchRect copying from top-left. 
Yes that makes sense. It's an optimization, not a behavioral difference ;-) 
Look for WS_TOPMOST in the window styles and kill it. 
Unless I am somehow doing something wrong searching the source code, WS_TOPMOST returns 0 results.

Although I know far less about Direct3D, I have always been under the impression that a non-topmost window in D3D is impossible.

/Also, this isn't something important. 
Sweet, new goodies to play with. And I can ruin it all by injecting something to give Quake all those features it was always missing, like hacky SSAO, awful Vignette effects and dumb colour grading.

Honestly though, even though I don't have anything technically useful to say, I feel like both Baker and mh need to be thanked and congratulated for making cool things for Quake like new engines and renderers. So thanks and congratulations for being cool! 
I Just Wonder 
if autosave feature is disabled by default in the latest build? 
Topmost Window 
I'm just not able to reproduce it:

I suspect something localized on your PC. 
@baker: any chance that you could post a tutorial to implement md3 support to fitzquake?
I saw you started one at insideqc, but never finished it. 
@pulsar - Auto Save 
I'll look into it. 
It could be my Direct 3D drivers. I notice that DirectQ does the same (minimizes it). So apparently the behavior of Direct3D 9 is subject to some sort of variance, since clearly yours is different (and more likely up-to-date). I may end trying to grab the Window style flags -- is it GetWindowsLong --- and see if I can detect the behavior. 
NVIDIA (pulsar / Johhny) 
I did end up trying Mark V on a GeForce high-end gaming laptop -- I think the driver version was (372.70). Did not experience flickering, but the driver wasn't (372.75) and didn't have time to do an update.

However, the display was high DPI and Mark V likely needs the DPI awareness attrbrite because even the experience in the WinQuake version was rather "unpleasant" on a high DPI display. 
@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