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

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

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

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

/Mac version is not current yet ...; Linux will happen sometime in 2017
First | Previous | Next | Last
Mark V - Release 1.35 - Windows / Linux (Stable!) 
Download at normal location:

The Mac build remains version 1.20.

New Features vs. Mark V 1.20

- Very fast "triple the fps" DirectX 9 build courtesy of MH
- WinQuake looking water warp in Open GL/DX9 (MH again)
- Volumetric shadows - r_shadows 3 (MH again)
- Sky speed up in Open GL/DX8/DX9 (Yeah, MH)

- Linux Open GL build (thanks to JimBob for testing, Spike for debug tips)
- Linux WinQuake build

- Resize on-the-fly windowed mode in all builds (except DX8). Yes, even Linux. Tried to make the Linux build fancy. May have succeeded.

- QMB enforcer lasers available video

- Improved NVidia cards experience (killpixel, Kinn, johnny law, pulsar)
- 2 Extra options in video menu for convenience.

- Automatically bypasses's ancient opengl32.dll (Syrion)
- Warpspasm correct startdemos by overriding Quoth 2.2 (path0gen)
- MH solved context creation issue in version 1.25 (dwere, breezep, ...)
- MH added extra control over r_waterwarp in 1.35. Type "find r_waterwarp" in console for details.

Next update hopefully some time in the spring! All feedback, comments, etc eventually get considered, a nice thing about the Func_Msgboard layout. 
Should have noted Gunter, railmccoy did a lot of testing of DX9. Maybe others. I've been updating page, installers, .zips, etc -- if missed someone who helped beta test it sure wasn't on purpose. 
Instant crash when attempting to launch any form of 1035. dx8,9 and good ole mark_v.

Apologies if I missed something in this bustling thread regarding this.

You two deserve many beers. 
More Beta Tester Credits 
Other reporting issues or feedback during latest development spree:

Fifth, Damage Inc, mugwump, nightfright, pritchard, adib (hope I didn't miss anyone, had to glance through hundreds of posts).

@damage - Sorry, if I couldn't implement true rotation. Ran out of time. Will have to hit that up next development period (likely the spring). You can always use the RMQ engine or presumably DarkPlaces or FTE for such experiments in the mean time. 
Can you add -developer to the command line and then post a quake\id1\qconsole.log? 
Sure Can! 
If Its Crashing 
then remember to delete your .cfg file. I've had this happen to me a few times with new builds and deleting the cfg has sorted it out. 
Thanks. Can I get a copy of your autoexec.cfg, okcam.cfg and config.cfg so I can examine them? 
I'd still like to know what settings would cause the engine to actually crash.

If there are settings that can cause the engine to crash, I would want to make the engine handle that without crashing. 
Here Ya Go 
Do you have to okcam.cfg? I'm looking through things. I can say I don't crash with the config.cfg and autoexec.cfg you provided, but the okcam.cfg wasn't in your download.

/Is looking through settings 
Does the following:

cl_bob "0.012"
cl_bobcycle "0.55"
cl_bobup "0.7"

Just a cosmetic tweak. 
I'm going to make a guess here ...

Does work ok? 
Same Issue 
I do not see an okcam.cfg anywhere!

But yes, 1032 still crashes for me. 
It's in my model pack. 
Ah, model is causing crash. Makes sense! Thanks for letting me know!

I couldn't find anything that made any sense, DX8 doesn't even have most of the new features, haha. 
Okay Cam! 
Well, just for testing I completely removed dwere's pak and I still receive the same crash.

Just to clarify it's simply: "Has stopped working" prompt.

This is testing on 1032. 
If I misinterpreted the above ...

Other than how you have an unusual resolution like 3440x 1440 ... which since you have max texture size of 16384 I don't think would be a problem ...

My only thoughts ---
1) NVidia driver issue?
2) Borked mp3 sound track
3) Does work with reset config and clean id1 folder.

I'm just not seeing anything that would cause DX9, DX8 and regular Mark V crash?

What is most recent that works for you? I'd try Mark 1.20

And if you aren't having some sort of content specific issue somehow ... maybe someone else will report same issue? 
Ok, is a "has stopped working".

What was previous version that worked?

All the builds:

If you can tell me the last one that works, I might have something to work with ... 
Let me know if 1.20 (Build 1020) works. 
Okay, so I believe the last version that worked was 1028...when performance was improved on dx9.

Clean Quake folder runs 1035.

Placed my mp3 tracks and it still runs fine.

Placed dwere's pak and runs fine.

However, I went to change texture mode to '3' and it crashes to desktop with "Has stopped working" 
It's Gl_texturemode 3 
That's the only thing in my autoexec. I apologize I sent you the wrong one as I have numerous quake directories for engines.

I can run on my "dirty" installation just fine when I removed that entry. 
Triple Post In The Name Of Testing 
If I try to change the texture mode to anything it crashes. 
I'll do a quick update without an hour. 
Mark V - Version 1.36 
Downloads at the usual place ...

-Mistake in gl_texturemode corrected (reported by Bloughburgh)

Which is one of the 2 new items in the video menu added in 1032. 
Time For Beer 
Thanks for the help getting this polished up!

All the downloads are up-to-date and no compatibility issues!

Thanks to Bloughsbough for finding that issue 5 minutes after Build 1035. ;-) Way better timing than something like that happening a week from now.

/Next updates in the spring! 
Texture Filtering 
Thanks a lot for the menu choice between filtered and non-filtered (pixellated) texture filtering modes. I had been asking for that for a long time. ^^

Two questions:
1) Is the option "GL_NEAREST" equivalent with the filtering mode gl_nearest_mipmap_linear?
2) I guess having this option in the menu now means that it's not necessary any more to put it into autoexec.cfg? 
It's ALIVE! 
Ya every thing works for me so far no issues! 
@mukor - Thanks! Yeah, "Time for beer" is quite literal and I'm doing the mfx right now ;-)

24 hours ago, I was left with the prospect of taking a timeout with flaw of unknown origin affecting dwere, and compatibility stuff ticks me off, compatability is #1 on the list for me and is a major reason why I engine code. Obv, I also do not like engine crashes (so couldn't rest until Bloughsburgh's problem was resolved).

Some timely insight by Johnny Law, a dev note by myself and then MH actually being able to experience the problem ... invaluable as an engine coder -- let me tell you.

@nightfright --- I added the "pixelization" option to the video menu because I honestly didn't know which one was the "right one" -- I like my FitzQuake gl_linear_mipmap_linear and if I want crunchy pixels I use therailmccoy (WinQuake version).

I found a thread where Spirit and MH discussed the issue ... Spirit said there is almost no difference between gl_nearest_mipmap_nearest and gl_nearest_mipmap_linear -- but mh (who knows both the GL renderer and WinQuake renderer better than anyone else) said gl_nearest_mipmap_nearest is the closest one.

1) gl_nearest isn't gl_nearest_mipmap_linear, it's different
2) gl_nearest_mipmap_nearest is better according to mh.

I don't think about this topic often, but the "too much detail math" is here ...

I fall into the gl_linear_mipmap_linear preference camp, so I don't think about this topic much but I understand the appeal to those that do.

Perhaps this will be followed up with a better explanation by those more familiar with the topic. Since I'm a gl_linear_mipmap_linear (trilinear) guy ... I'm not the best guy for this job ;-) 
@rook - Thanks!

R00k -- you know what sucks? When Bloughsburg had a crash issue, I ended up booting both my Windows 8 and Windows 10 machines -- because I thought the issue could involve Win 10.

I enjoyed playing Quake on Ubuntu more than either Windows 8 or Windows 10. On Windows 10 I hit some fucked up key that activated a narrator (fuck you Windows 10!).

Meanwhile, the Linux experience was dreamy --- and in no small part because I juiced the Linux build with all the Windows-ish goodness I possibly could.

/Also, for a while I wouldn't turn on my Windows 8 machine because I feared it might be a Windows 10 machine the next morning. Windows 8 sucks compared to 7, but Windows 10 sucks 5x more than Windows 8 because the next update it might undo all the customization and cleaning out garbage out of the menu you spent time doing. 
Texture Filtering II 
According to a definition on the Quaddicted site, it's like this:

Point sampled. Lowest quality, highest performance.

GL_NEAREST but with a bit more quality for far objects (software-like).

GL_NEAREST but with even more quality for far objects.

Personally, I also think mipmap_linear offers better quality than mipmap_nearest, and that's why it was the mode I had been using all the time. Are there any chances to add this mode as well (maybe as "Pixellated/Smooth")? 

X = how close-up textures are rendered.

Y = how different mip levels are blended together as objects move closer or farther away. 
Nearest_mipmap_nearest is closest to software Quake because software Quake used mipmaps. It's as simple as that.

If I'm in a crunchy pixel mood I use nearest_mipmap_linear which avoids banding between the mip levels. I can post screenshots later on that demonstrate this. It's one of those things that you might not notice, but once you do it drives you nuts.

Nearest on it's own disables mipmapping, which causes distant textures to shimmer and sparkle as you move around. Sometimes people mistake noise for detail, but this is basic sampling theory stuff. There's a weight of mathematical papers on it, including articles in the Mike Abrash Black Book, and I'm not going to get bogged down rehashing what others have said better elsewhere. You don't want to disable mipmaps, that's all.

The last thing is relating to mipmapped water, which Fitz and most derivatives don't have. As the water warps it can subtly shift between different miplevels. Again, drives you nuts once you notice it. Solution is to use ddx/ddy (GLSL dFdx/dFdy) on the unwarped texcoords then a tex2Dgrad lookup. You can't do that without shaders. Not sure if vkQuake or any other publicly released engine does it though. 

This was recorded in 1.00, so it's pretty out of date. I died, rapidly clicked and started the map again like this. That's all I have to say - I haven't tried reproducing it yet. 
Thanks Baker, I just happened to pop on at the right time I guess. Cool to see those options be included in the menu as well!

I found it strange that it crashed after trying to set a mode...then I went to the correct autoexec and saw it ONLY had the texturemode command hah. I really need to conform all of my directories with my master config.

Looking forward to trying when I get home! 
Yeah FWIW I use nearest_mipmap_linear too. And with some anisotropy set (so I really need to go re-read that discussion above about those interactions).

Obviously that's not the pure Winquake look but I likes it. :-) 
Same, nearest and mipmap linear. I like the distant smoothness with the crunchy pixels nearby. 
Good Stuff 
You two rock as I have said, more beer!

No problems running 1036 from a quick test around!

Love to be able to change the water is a bit intense at 3440x1440! 
May I Just Say... 
It's been a fucking pleasure working with Baker on this. 
@mh - Yeah, Was Fun ... 
Each of us working on different set of features at the same time in way that allowed asynchronous development which covered quite a bit mileage in short span of time.

A very enjoyable experience, indeed.

Looks like I should have picked gl_nearest_mipmap_linear instead of nearest/nearest for the option.

@bloughsburg - type "find warp" in the console. 
Pixellated Mode 
I doubt that gl_nearest is a mode many people will use. My suggestion would be to simply replace it with nearest_mipmap_linear and use that for "Pixellated" mode. 
Any luck on Intel graphics 3x performance? So far DX9 runs stable at 15-40 fps and is definitely better than QS. 
That's your fps on Arcane Dimensions right? 
Something I Commented In Ad 1.5 Thread 
Mark V has a bug with the rewind feature in demos. when you rewind, the clock go forward instead of backward.
when you pause (down arrow) and unpause, the time is resynced.

this is scr_clock 
@topher - thanks for reporting that. Must have wired up the wrong clock when absorbing some JoeQuake/ProQuake features back a couple of months ago.

/+1 to do in the spring update 
A workaround in the meantime, if you are interested. Add +pq_timer 0 to the command line or throw it in autoexec.cfg 
QuakePone, if you're interested I posted 2 builds in the QS thread here to check for a potential problem that affected some versions of Intel graphics.

Additionally, as MH mentions, try benchmarking "gl_flashblend 0" vs "gl_flashblend 1" (this may be faster; it stops the lava balls from casting dynamic lights and just draws a fake glow instead.) 
I tried this in my own engine, on a nvidia 960gtx, and it really didnt matter. yet as I like you are using gbra uploads, but then in the most classic settings, im getting 2200+fps with playdemo demo2 on Qrack vs 1600 in Mark V using really close effects; no motionblur, no r_novis, classic particles, etc. in DirectQ / RMQ i get 3000-5000fps.

maybe lightmap uploads matter? 
er 5000 in dq not rmq 
bottomline is a stable fps in given map we dont need >200fps in single player maps. 
An NV 960 is irrelevant unless you can get a test case that goes below about 500 fps.

Gimme the Intel benchmarks, that's the interesting stuff.

There's probably things I can do for lightmap updates but I'm not willing to gut the code unless I'm satisfied that there will be payback at the end of it.

I might also make one of my experimental GPU lightmaps engines available, because I'm interested in how that might perform. I'm cautious about not creating expectations in the community though.... 
Found In The Mirror In Arcane Dimensions 1.50 
Map = ad_magna

In console type: "setpos 2496 56 -292" And you'll be at the mirror.


/In Mark V, you can type "viewpos" to see your current x, y, z -- which also sets the default setpos. So if you type "viewpos" at a red armor, walk away and then type "setpos" you'll be back at the red armor. 
If it is lightmaps --- and that's an if --- slowing things down.

Type: r_dynamic 0

Then dynamic lighting is simply turned off. 
In Mark V, do the following after starting up Arcane Dimensions.

temp1 0 // Turn extra ad particles off
r_dynamic 0 // Turn off dynamic lights .. no lightmap updates will happen at all.
sv_cullentities 2 // Strict visibility tests on all entities
map start // Restart the Arcane Dimensions start map


See if your fps improves. 
These commands helped a lot in previously barely playable maps like ad_tfuma and ad_swampy. I might leave temp1 on 1024 and r_shadows on 1, still. 
Cool! Glad it helped out some.

In the Quakespasm thread, mh, ericw and myself and others are discussing performance related issues related to Arcane Dimensions. 
I'm starting to warm to the idea of doing some kind of release of one of my GPU lightmap experiments. ericw has expressed interest in how parts of it work and I'd be fascinated to learn how it performs on QuakePone's machine.

I've basically got 3 engines: Quake/OpenGL/assembly shaders, Quake/Direct3D 11 and Quake II/Direct3D 9. The Quake II engine is probably the most developed but it misses D3D 11 enhancements and draw call overhead does pile up. The Quake/GL engine is very barebones and I'm not sure where the code is. The Quake/D3D 11 is most likely to be let out. 
Huh. About the issue where models in front of the sky look "darkened" ... well, it makes the shaft look BETTER because then the contrast doesn't cause it to be as washed out!

(see my post on Old Page #1321 with screenshot illustrating that fullbright textures get ugly and washed out when contrast is applied)

Here's a screenshot showing this effect:

Shaft looks better with sky behind it! Maybe something like this could help all fullbright textures to make them not as ugly when contrast is applied....

Starting with -nostencil removes the sky effect, though it still lets you see r_shadows 3 through models (second screenshot above shows a distant grunt shadow visible through a dog's butt, heh).

I know you're aware of the stencil issue, mh, but I just had to display these interesting screenies ;) 
@gunter - Was Playing Co-op On Your Server 
On your server with JimBob and ORL.

Hadn't played Frostbite in some time, that map and the rest of the "2005 Wintery Map Pack" are always great experiences.

You might talk JimBob or even yourself into delete all maps and extra sounds in your Quake folder to watch the map/model/sound download in action.

JimBob wondered how I had the maps and the music, haha ;) Well, I didn't until I connected.

They downloaded automatically, of course.

Mark V has the best stay-connected http map/model/sound download this side of FTE. 
The auto-downloading is great. And I have noticed the .LOC files downloading before. I guess those are for frogbots?

I just wasn't sure if you actually got the music. I don't mean the intermission dance loop WAVs. Rather, I mean the soundtrack MP3s I selected to match the edited .ENT files (e.g., "'sounds' '65'"). I didn't know if Gunter had uploaded those.

Also, I'm not sure where it all comes from, since I think the FvF server is still Magic Proquake? I do vaguely seem to recall you talking (once upon a time) about having downloads come from a 3rd-party source like QuakeOne or w/e? 
Locs are for team deathmatch and such (dm3, etc.) like "At the red armor with 87 health"). You can turn off downloading locs. Type "find loc" in the console, you'll see a cvar that can be set to turn that off.

/mp3 don't download, mp3 tend to be large, aren't needed to play. It's a player preference anyway. 
Any Chance... 
of also moving r_shadows and r_waterquality variables into config.cfg?

I find it a bit complicated to set them externally through autoexec.cfg. And since texture filtering has already been moved... 
I've been really enjoying the winquake build, it runs very well. I ran into this little guy after I disabled mips. He's harmless but has worn out his welcome :) 
just found "showram".

Whenever I get stuck on something I just make a forum post or drop a message on irc so 30 seconds later I can figure it out myself :P never fails. ever. 
Don't know, but I'll think about it.

I worry about mods changing obscure things, causing niche settings to write to config.

1) quake.rc, autoexec.cfg
2) QuakeC

Case in point, Malice messes with untold numbers of weird cvars like viewidlescale that most users have never heard of.

Imagine if you exited and everything saved, all those peculiar settings would be part of your config and short of reseting/deleting your config, you wouldn't know how to reset them.

I'll think about it.

But my instincts tell me that no matter what, someone with very specific tastes is always going to find something that needs to be an autoexec.cfg 
Mods will only affect the config in the mod's directory tho. 
Mods should be properly set "gamedir" and yes everything saved, including .sav files .dem and .cfg to that folder.A footprint to a gamedir should mean anything I do here when i quit should save to gamedir. 
that's true except, when you switch gamedirs during a session, the cvars and aliases and keybinds are retained, and when you eventually quit that session they will be written to the last gamedir you switched to. 
What Metlslime Said 
Some people use game command (i.e. "game travail"). Some people like R00k probably use gamedir capability more for CTF.

And although no small number of people use the command line either from habit or because of the Quake Injector -- there are those that use "game travail" way.

And these different set of circumstances have to be factored in. 
when implementing the command in fitzquake, i considered writing the config to current gamedir, clearing all values to default and then loading the config in the new gamedir as a way to resolve this, but it could have negative results such as changing your video mode or mouse sensitivity, or other settings that the player doesn't expect to be per-mod.

The core problem is that some settings are global user settings and some are mod settings and there is no formal distinction between the two.

Most experienced players don't feel too much pain from this since they have autoexec.cfg files that force the correct settings (of course this breaks down when a mod includes an autoexec!) 
Spring Thoughts 
These are major things that, in addition to the topics noted above and earlier in the thread, are likely to be goals in the spring.

List of some different future possibilities

1. Coopable 3D "Quake Injector" built-in, concept Undergate screenshot About everything needed to finish the concept is in the engine already.

2. iPad/iPhone/Android versions with Minecraft-like controls (Minecraft is very playable on an iPad). I played the awesome Kurok mod for Quake FitzQuake version on a PlayStation Portable and am not likely to be satisfied until I can play Quake on at least an iPad and also like it.

I also did tons of engine modding of PSP Quake engines, so yeah I'm not pleased about not being able to Quake on devices.

3. Kurok capability screenshot. I have added almost every required capability into Mark V, but a small few remain.

4. Multiple-players, same computer. working prototype demonstration. This means studying Microsoft's XInput for game controllers, because the working code does not have the needed input support.

5. Spiked Quakespasm's super-compressed protocol. I like demo rewind and will have plan out right way to achieve it.

6. Playing .zip archives without ever decompressing them. i.e. Travail .zip never gets unzipped.

7. LAN Co-operative peer-to-peer multi-threaded download of required files (Like the client downloading "" from the server). Would make LAN co-op setup even easier and Mark V already has a ton of co-op capabilities. Mark V actually has a beta form of capability disabled in the engine for polishing.

(Note: Even a 70 MB download is nothing on a LAN. Over LAN that file could have downloaded hundreds of times while I typed this sentence.)

8. A re-written sound caching system to allow changing sndspeed between 11025, 22050, 44100 at any time.

9. Native Linux without SDL. Will add better support for video capture, hardware gamma.

(Might adopt Spirit/jdhack's Requiem Engine decision to use fmod for mp3 playback, but I still haven't explored all the mp3 options, including some of ericw's thoughts.)

10. Other things mentioned elsewhere in the thread, I'm sure. 
Yeah, exactly. I've invested some time and energy into ideas on how to sort out those issues. 
"when you switch gamedirs during a session, the cvars and aliases and keybinds are retained, and when you eventually quit that session they will be written to the last gamedir you switched to."

Uhh, I just tested, and Mark V does not actually do that. Well, I mean, it does carry over settings, but all config changes seem to save to the directory you started in, always, not the last dir you were in when you quit. But if that's the way you are starting the mod every time, I guess you would end up with all your config settings each time you play anyway....

Though I don't think that's the correct way to go about it.

I'm with Rook on this -- let each game dir house its own cfg stuff for that mod. And I still say it should automatically exec that config stuff upon changing to a new gamedir. This would allow the user to keep settings for each game truly separate. And if someone changes to a new dir, it won't carry over config stuff from a previous dir that perhaps shouldn't apply (assuming there's a setting for the mod that should supersede an old setting -- just retaining defaults is fine). And it wouldn't (shouldn't) save config stuff you change while playing that mod back to the base id1 folder (as it does now if you start in id1 and manually change to the new dir).

So yeah, each game dir should have its own configs, really, which override anything from outside that game dir. And when you quit, the config for your current game dir SHOULD save within that game dir.

I could illustrate a problem with the current approach:

Start Quake normally (plain id1). Let's say you have normally bound "shift" to cycle weapons. Then you want to play FvF or something with a grapple, so after you change "game fvf" and "bind shift +hook" then you quit the game, it saves that binding back in your id1 flder....
Now if you want to play normal Quake again, you have to rebind the shift key.

If it saved your (now altered) bindings in the fvf folder, you wouldn't have a problem. And if it would exec all the configs from the folder you changed to, it would all be set up automatically the next time you change to the gamedir....

Then that would make everything work consistently in the same manner no matter what method someone uses to select a gamedir:

"marv_v -game fvf"
would behave identically (loading configs) to typing in the console:
"game fvf"

Wouldn't that consistency be better? 
Gunter Keeps Revealing Secret Tweaks 
If someone uses the game console command (i.e. "game travail" or such), they start out in id1.

Then switch to travail.

Obviously, if you always start up in id1, you would want any changes to video resolution or setup to also apply to id1.

Since id1 is the config run on startup, yeah, that's where it should save too!

If someone uses -game whatever from the commandline or the Quake Injector, the config saves in game whatever just like you would expect. 
So While Revealing Secret Polishing Tweaks ... 
Mark V saves settings every time you exit the settings menu or the console.

So if you wonder why no matter what happens, everything is always saved the console history is always up-to-date.

That's why!

/I prefer to not mention these little niceties and polish-ups because I just consider it part of polish.

Like how Mark V forces a WASD default key setup and makes the mousewheel do previous weapon/next weapon by default. 
makes me want to rip out my autoexec cfg and do some gamedir testing... i think if i do a gamedir AD then my current gamedir should save config.cfg first switch dirs then load config.cfg from there, and vice versa. I hope this is the case already if not i'll have to change it. I have added a writealias command that dumps an alias.cfg for each gamedir but the user then has to make an autoexec.cfg to exec alias.cfg or maybe i should make it do that automatically...hmm 
Levels Menu? 
my levels menu doesn't work in the quakespasm folder. I have the quake HRP and the menu graphics change. What does this? In the DP folder works fine.

DX9 version is great, it kills on my R9 280.

Also what graphical things are supported? Just unpacked textures? Can it ever support things like dp pretty water? 
Any Chance Of Co-op Saves? 
Is it possible? 

"New Game"
"Levels" (Only appears if nothing above graphically replaced)

So if an exceptionally rare mod (X-Men, for instance) replaces a graphics there ...

Or if a user is using high definition graphics for those menu items ...

Rather than present the user a "Levels" graphic that clashes with the appearance of the menu, it simply disables itself ;-)

I'm just rather picky and I'd rather have menus that look nice than a menu with an item that clashes with the rest of the items on-screen. 
@fifth - Mark V Can Save/load Co-op Games 
Mark V can save multiplayer games, including co-op games which was the main target.

/If it isn't working, let me know. 
Also what graphical things are supported? Just unpacked textures? Can it ever support things like dp pretty water?

QMB particle option in menu, MH waterwarp (defaults on), MH volumetric shadows (r_shadows 3).

The Open GL version (not DX9) has a raw test implementation of bloom that needs more work in the future.

Eventually, it'll be run through the gauntlet, maybe possibly sometime in the spring, but not necessarily because isn't high priority item.

External textures use the same names as DarkPlaces. Mark V only supports .tga files. 
Can It Ever Support Things Like Dp Pretty Water? 
That would need a VERY significant overhaul of the entire renderer.

It might not be immediately obvious, but DP pretty water needs shaders. Then you're in a position where, in order to have other effects be consistent, you have to implement *everything* in shaders.

Another thing is: the reason why DP runs slower is because it does all these effects. If you start with another engine that runs faster, port DP's effects to it, then ... the other engine will also end up running slower. End result is that somebody's time has just been wasted in rewriting DarkPlaces.

I've always been of the opinion that it's a big world and there should be room for lots of engine options in it. Each engine has different goals. If you want to "pimp my Quake" then DarkPlaces is the engine for you, but other engines don't share that goal to the same extent. 
@johnny - DX9 Version 
DX9 version is great, it kills on my R9 280.

MH did an incredible job with the DX9.

One of the rare (and fun) examples of something going from simply non-existent to polished in just over 3 weeks.

The awesome beta-testers here who help out and provide fast, high quality feedback is unimaginably helpful to engine development.

Most incredible beta-testers ever! Engine development is hard, but smart detailed-oriented testing can take quite the edge off! 
Lol, I had no idea. I thought it was like standard quakes implementation. Plus the save option sits under the single player menu 
Stuff like DP dies on AD, down to 7fps. Other games, ie Q2, Q4 run much better at the same resolution with HD and extra effects cranked.

I've had the best luck with this engine and quakespasm spiked.

For instance ad_fuma... markv/dp = slowdown right at the start by the lift. markvDX9 = smooth.

>QMB particle option in menu, MH waterwarp (defaults on), MH volumetric shadows (r_shadows 3)

I found the particles and if waterwarp is on by default I just have to try the shadows. My transparent water in QSS has issues rendering, wrong things or distant things will show up.

>>Rather than present the user a "Levels" graphic that clashes with the appearance of the menu, it simply disables itself ;-)

I wish I could override this. Typing map is somewhat of a substitute. I do 1080P on a 42" screen so I really like the high res. See your point on shaders though; I remember playing quake and quake2 on voodoo2 back in the day and to see it keel over with a quad, 16gb of ram and a card faster than the original PC is shocking. 
Remove or rename gfx\sp_menu.tga (or gfx\sp_menu.lmp) and will probably load, if that is what is going on.

Possible (non-ideal) workaround. 
Hm, I would say the information and function is more important than the aesthetics.

It's no big deal if the "Levels" menu looks different; it's no less useful, and it's not like people are going to be staring at the menus for long periods of time. A menu isn't there for artistic value -- it's there for functionality, just as a way to get to the setting you want. 
Oh... AND it makes it even worse with your force-choosing what map to stick me on when I go to start a New Single-Player Game (oh how
I hate that feature).

I tested with FvF3 (a later version, not the version my server is based on) which contains custom menu graphics. If install the custom maps from FvF4 (which contains one called fvfstart.bsp) along with, say, the iikka, terra, and dopa maps, then your map-forcing feature (which I hate so, so much) decides to ALWAYS stick me on fvfstart rather than the default start.bsp when I use the default menu option to start a single-player game.

Furthermore, since there are custom menu graphics, the "Levels" menu is missing, so I cannot even use the menu to work around the feature (which I truly, truly hate) to start the standard start.bsp.

So, the "Levels" menu should always be there, even if it's ugly, but more importantly... (you can imagine me shouting this loudly to properly convey the hatred I have for this feature) THE DEFAULT MENU OPTION TO START A SINGLE-PLAYER GAME SHOULD *ALWAYS* START THE DEFAULT SINGLE-PLAYER GAME. heh.

I know, you probably spent time and effort coding this feature thinking it was a great idea, but it's just not. This is as bad as all the "toxic settings" you hate so much when some servers or mods force upon the user. This is just as bad as a mod containing an autoexec.cfg within a pak file that force-starts you on the same map every time despite what you, the user, want to do, because just like in the case of an autoexec in a pak file, it cannot be disabled in Mark V.

And no matter if I am wanting to run the dopa, terra, or iikka maps, I will get forced to start on the fvfstart map every time, because it is first alphabetically, so it's not like the feature is working well to begin with -- you can't read the mind of the user, and selecting a map alphabetically is no substitute. So just go back to the default function for the default menu, and if the user wants to do something non-default, the wonderful "Levels" menu lets him run whichever non-default mission he wants.

Well, assuming you don't hide the "Levels" menu because it doesn't match new menu graphics.... But as I said, I feel the functionality is far more important than the aesthetics. 
1) FVF running (-game fvf)
2) Single Player->New Game
3) fvfstart.bsp loads

99 of 100 people would call that perfect behavior ;-) 
IF U Have a starting map in your own gamedir then just call it start.bsp, like everyone since 1997 does it? ;) 
nvmd re-read gunter's post 
Pixel Lock Test 
Select and rotate pitch and yaw by selecting a single pixel on the screen and dragging it.


Initially was a bit frustrating, then the slightly rusty 3D math kicked back in. Have to imagine the frustum as a sphere.

Combining and project and modelview matrix, the center of any pixel on the screen has an exact "pitch" and "yaw".

There are shortcut cuts methods that wouldn't achieve pixel-level selection precision, but I wanted the real one. 
[ The above is what happens when you click submit instead of preview, typos galore :( ] 
heh. for me the key to that feature is the convenience of the list. renaming the graphics isn't the worst thing. I don't have as much passion about is as gunter. I'd just start from the command line if it was picking the wrong map regularly.

lots of stuff, ie the mapjams never even had a start map. not sure if "maps" works in any other engine but it would have saved me alt_tabbing at least. AD has mod folder selection from a menu but no maps.

the r_shadows 3 looks good, I would have never found it. 
>>AD has mod

should say DP 
Start Maps 
recommended behaviour would be for mods to create startmap_sp/startmap_dm aliases that specifies exactly what to do, and for engines to invoke that instead of doing 'map start'.
that way you're not getting randomness...

if only more engines+mods used that...
more seriously though, what kind of weirdo actually uses the menus? :o
(especially if the console's maplist dump supports clicking) 
Stuff like DP dies on AD, down to 7fps. Other games, ie Q2, Q4 run much better at the same resolution with HD and extra effects cranked.

I've had the best luck with this engine and quakespasm spiked.

For instance ad_fuma... markv/dp = slowdown right at the start by the lift. markvDX9 = smooth.

I can see why that might happen - polygon counts are absolutely insane in this part of the map.

There are a combination of things going on here.

Insane polygon counts.

MarkV GL makes no attempt at draw call batching. That's going to mean that bigger more complex scenes will bog down more and more.

MarkV D3D9 takes those GL calls and batches them, so it can handle those scenes better. It's still transferring a LOT of data to the GPU every frame though.

Quake 1 map formats are working against you. There's actually not a whole lot visible in that start scene, but Quake 1 lacks the vis format enhancements that even Quake 2 had, so it's pulling in a LOT of hidden surfaces.

DarkPlaces + huge data set + bad vis format + bling is not a good combination.

Quake 2 doesn't have the bad vis format, so it's data set is smaller, so you can bling it without as much slowdown. Likewise more modern formats.

Putting your data into vertex buffers so that it's already on the GPU rather than needing to be transferred every frame helps a LOT with bigger data sets too.

It's like the Quake equivalent of death by a thousand cuts. 
"1) FVF running (-game fvf)
2) Single Player->New Game
3) fvfstart.bsp loads

99 of 100 people would call that perfect behavior"

Maybe, but I complain louder than those other 99 hypothetical people combined! :D

And the problem is that this same thing would happen no matter what mod you were running in "step 1." You'd get fvfstart.bsp no matter what mod, because it's first alphabetically....

Actually, in the FvF4 full version package, the mod is programmed to always start the fvfstart.bsp map when a player goes to start a new single-player game. Probably somewhere in the QuakeC it does that.... This is more like what Spike suggested. If the mod actually specifies a map to run, that's fine -- you give control of such things to a mod when you run a mod.

Though the automatic start map picking does not seem to occur when you are just running id1 Quake.... Why is that?

That actually seems backward, in a way....

I mean, if you're running a mod, the mod itself will usually contain some way of starting whatever map it want to start, if it doesn't want the default start map.

But if you're running just plain Quake and you have a single-player map pack installed... then you DON'T try to select the start map via the engine ?

Well, I don't understand the reasoning behind that, but I dislike the feature in either case.

I do love the "Levels" menu though. 
My perspective most closely aligns with Spike's above about how mods should supply the information on the proper start map.

In a perfect world, that is the correct solution. 
Should always be the name of the start map imo

Anything else is asking for trouble. 
I can think of only one case where "start.bsp should always be the name of the start map" doesn't apply, and that's where a mod has only one map.

If a mod has only one map, and if a player selects "New Game", then IMO it's obvious what the player's intention is (hint: it's not to load ID1's start.bsp).

We're conditioned to think of "New Game" as being the equivalent of "map start" but if you step back and think: "is it really?" you might get a different perspective. 
" mods should supply the information on the proper start map. "

Agree. But if they don't do that, then the default start.bsp should be used instead of just guessing at it.

"Anything else is asking for trouble. "

Completely agree. I have been running into said trouble in actual practice -- though it's not that it can't be worked around but manually changing levels after I get dropped in the wrong map; it's that it is a major change from Quake's expected default behavior.

"If a mod has only one map, and if a player selects "New Game", then IMO it's obvious what the player's intention is (hint: it's not to load ID1's start.bsp). "

Actually, I don't agree with that, due to something I have done with FvF....

I have a modified DM6 map that contain an extra area which has nothing but a deadly lava pit with ledges above it, referred to as "The Purifier." When players vote to start a new Quest, I first transfer them to The Purifier area to kill them off before starting. The reason for this goes back to before I had the source code, and couldn't just strip everyone's weapons and frags from then without killing them... so the solution was just to kill them in a deadly trap before starting a new Quest game. At first, I had a separate small map for this, but later Orl modified DM6 to contain the Purifier in an extra area. This allows all players connected to the server to not be stuck in the console when The Purifier is called -- instead, if they don't have the modified map, they just feel like they are floating in space above DM6 while they die (the map on the server has the lava area, so the players can be in the DM6 map, inside that area, even if they can't see it). Of course, now I have the source code and could just strip the players' weapons and frags away before restarting Quest mode, but The Purifier became a traditional part of FvF, so it remains and is included with the FvF download files.

So, long story short (too late!), even though FvF has only one map included with it, it should never use that map by default when I go to start a new single-player game... because (before I had installed other maps in my FvF folder) I get put on DM6 when I try to start a new single-player game!

That is something that should never, never happen....

So yeah, default menu function for starting a new single-player game should start start.bsp EVERY time.

There are many different ways a mod can control that if it's not what is desired. 
Mark V's first priority is to play single player releases at Quaddicted and those released here. That first priority will never change.

FVF is not a traditional single player release like ARWOP, lunsp1, Travail, Marcher Fortress, Once Upon Atrocity, Grendel's Keep, Warpspasm, Soul of Evil, The Colony, GMSP1, Middle Evil, Rubicon 2, etc.

So yeah, maybe you have to add +map dopastart to the command line.

Oh the horror!

Mark V - #1 priority is Quaddicted/Func_Msgboard map releases. Feature is well suited to those.

But yeah, you can argue this until the cows come home and it will never change, because it is conflict with the stated goal of supporting single player releases conveniently. 
If I install ...

1) "game cda" - Castle of Dark Ages - Single Player new game should play the release.
2) "game lunsp1" - Single Player new game should play the release.
3) "game coagulatest" - Single Player new game should play the release.

I could name 200 more examples.

Now maybe someone like Gunter doesn't play single player releases off Quaddicted.

That's fine. But you have to remember that this engine is built to work in harmony with single player releases.

Arguing something in conflict with the #1 stated goal of the engine is just a waste of time. 
All that being said, what Spike said #1244 has been a low priority item to examine and possibly implement.

Not even close to the first time Spike has conversed about such a feature, it has come up at insideqc in the past on multiple occasions.

So possible future ability to specify what you think the start map should be for FVF via quake.rc or such doesn't seem like a stretch. 
No, I'm not familiar with all the single-player releases, but I have to ask, of those you mentioned, are they actual mods that should be installed to their own folder? Or are they just map packs?

Mods should have their own method of starting the correct map.

Map packs (like Terra and Iikka that I know of) are just installed to the maps folder, usually in id1.

In the former case, your map guessing isn't needed, and in the latter case it apparently doesn't function.

Let me check all the ones out you named, to be sure I thoroughly examine the issue.

CDS - pak file with progs included, so it's a mod, but it contains a readme with instructions: "3. Then load the map by typing 'map cda'."

lunsp1 - same, with instructions, "type 'map lunsp1'."

coagula - instructs user to use command line "-game coagula +map cogstart"

ARWOP - has instructions "Start a new game, and you will be taken to the start level of
'A Roman Wilderness of Pain'." So it's done the correct way, within the mod itself.

Travail - same, mod does it correctly/automatically.

Marcher Fortress - contains instructions to use command line "-game marcher +map marcher"

Once Upon Atrocity - starts the map in the included autoexec.cfg

Grendel's Keep - instructs to start map + mod by command line.

Warmspasm - looks like it does it automatically by the mod.

Soul of Evil - also done correctly by the mod.

The Colony - well, there is one "Colony" that is just a bsp with instructions to copy into id1\maps\ and run with "map" command, but there's also:

The Colony GMSP1 -- gives command line to start mod + map.

Middle Evil - instructs to use "map" command.

Rubicon2 -- apparently does it correctly in the mod.

So let me just tally this up.
Of the 14 potential things you mentioned (there were 2 Colonies):

5 of them do it the most correct way, within the mod itself, when you start a single-player game.

1 of them does it by an included autoexec.cfg, which is the second mostest correctest way to do it, I'd say.

1 of them is just a bsp which is placed in 1d1 with instructions to use "map" command (noted separately since the map-guessing feature doesn't work unless a mod is running).

3 of them have instructions to use "map" command.

4 of them provide a command line for the user to start the map + mod (oh, the horror of having to use the command line ;)

So, is the feature REALLY well-suited to these things?

In half the cases it either is completely unnecessary or won't work.

In the other 7 cases, if the user is following the instructions, it will never be used, (even though it would function correctly).

I'm sure there are many, many more map packs we could examine, and we could each look at the examples that either make it look good, or unnecessary, or bad.

But the feature is completely necessary in 0% of the cases, since all the map packs provide instructions for starting the map.

The feature is useless in 50% of the cases, because the mods either do it correctly already, or the feature doesn't work for maps in id1.

The feature is actually bad in some cases, such as ones I have mentioned....

So you've got a feature that's 0% necessary and only 50% useful, while sometimes actually being detrimental....

It's just not an overall good feature, even for the intended purpose of single-player maps.

Do I expect you to remove the feature? No -- I can tell you love it as your special child which you put time and effort and thought into creating ;) But I'm sorry, even though you love it, your special child is a tard XD

Even the people who aren't complaining as much as I am have said that start.bsp should always be the default (with mh's note that this may not necessarily be the case if there is only one map).

Me? I'm a Default Purist. I still am bothered that your pitch settings are off by .17 from default Quake :D

But this -- changing a cardinal menu function? That's so much worse to me....

But no, I don't expect you will remove it.

What I ask is please, please, PLEASE for the love of cake give me the option to disable it! A console variable, a menu setting, heck, a command-line option, ANYTHING so that I can have my Quake and eat it too! Er, I mean, so that I can have my Quake default functionality restored to it's proper functioning like it did back in 1996!

Let me just quote you the words of a wise man, please consider them carefully ;)

"Mod authors almost never intentionally did wrong things, they only sought to provide a good user experience for their mod.

Nonetheless, there are toxic quake.rc and autoexec.cfg files out there.

And playing single player release with the player in control of his settings is #1 for Mark V."

I know you didn't intentionally do the wrong thing, but this setting is toxic to me, and you have taken away my control to even disable it.... ;) 
I would definitely count all instances where the user is instructed to use the "map" command as instances where automatically launching the map is desirable/necessary. Mark V is designed for a plug-and-play experience - you aren't supposed to have to leave the game/engine to read readme files, just like you don't have to with the Quake Injector. 
Don't know. I'm not going to be doing more engine coding until (probably) the spring, except anything I decide to do as a leisure activity or experiment for my own satisfaction.

I won't be making any kind of decisions right now. Nor thinking about the "to do" list.

If I code something before then, it will be a leisure activity or solving a complex 3d math puzzle or something.

Wallclimbing mod

Found the old pubdm mod pretty much written by R00k. 
I'd personally discount those that give instructions. People don't read readmes. Never have, never will, you can keep your credit card details in a file called "readme", perfectly safe.

Discount a mod that provides an autoexec. That's the LEAST acceptable method to me (of those you list, there are worse). The mod author is making a statement here: Their preferred settings are more important than mine. That kind of thinking can fuck off. I'm the player, the autoexec belongs to me.

So I make that 9 that are player-hostile (1 actively so) vs 5 that do the right thing. Almost two-thirds.

Now, I'm not saying that Baker's approach is the best. One useful purpose it has served is starting a discussion around this problem, because despite what you claim, it IS a problem. People have trouble getting the Quake executable into the right folder, so you cannot claim that installing and using a mod is an intuitive trouble-free experience for everyone.

Personally I'd love to see something built into the Quake Injector. Maybe something built around Spike's suggestion, or something else, so long as it can be standardized and adopted. 
What do you mean "built into the Quake Injector"? I thought that already handled loading maps without a startmap. 
I'm not familiar with the Quake Injector -- I've heard it mentioned, but have never used it. But I was just thinking, "maybe a good solution would be a stand-alone Quake runner, much like QView, but for running mods + maps.... Maybe that 'Quake Injector' could be made to do something like that."

So yeah, you could have a program that looks like Qview, only it scans your Quake folder for mod folders and asks you which one you want to run, and maybe it scans that folder for map files, and if there is only one it runs that, or it could use a similar "guessing" algorithm to select the most likely start map, perhaps showing a list of those maps with the default one selected. Then you click run, and bingo-bango, it automatically runs your selected Quake exe with command like automatically tacked on (similar to how Qview does it to connect you to a server), with -game +map automagically set for you. (Though Qview just tacks on "-exec Qview.cfg" and puts its settings in that).

Heck, someone should make an updated Qview that can both handle running local mods and connecting to online servers, perhaps with a master server list setting included....

You have a point about people sometimes not reading the readme.... Though I'd think in general if they were downloading the zip files manually and unpacking them, they know what they are doing and would likely check the readme, or would just check the map folder and see what's there. Though the Quake Injector thing might bypass that? in which case, yeah, the user may not check the readme.

Though, in that case, there is the wonderful "Levels" menu in Mark V so they can run the included map (I really like menu, and feel it is the correct and best way to handle maps).

In regard to mods including autoexec.cfg, that actually seems like one of the best ways to handle it to me (even better than just having your map named start.bsp) for the very reason you mentioned, mh -- "the autoexec belongs to me."

Meaning I can edit the file easily to include or remove whatever settings I want. I don't mind the mod author putting his suggested settings in there, because, again, they are easy to change (assuming they don't commit the terrible sin of sticking the autoexec in a pak file, but that is rare).

It actually seems handy to me that the mod author would include an (easily editable) autoexec which will automatically start the intended map.

But yeah, I agree that it would be nice to have something for noobs built into Quake Injector for running mods/maps (if it doesn't already?), or just a new version of Qview with that functionality included, or just a new little stand-alone app (which would be pretty simple, really) that could run mods and/or maps with a few mouse clicks. 
Just a couple unrelated observations because I was starting up the Soul of Evil mod while testing the map running stuff. This mod uses its own start.bsp map.

I use an old version of Fitzquake (.85) for comparison, and I noticed two things:

1. Mark V is smart enough to not use the default start.lit file from my id1 folder.... Fitzquake does use that file, resulting in some... unusual colored lighting effects, heh. It doesn't look bad, it just look different, with strange colored lights splashing on the walls from no apparent source. But yeah, Mark V is probably correctly doing this.

2. Even upon first running the mod (by command line), so there would be no cfg files to read from in the mod folder, Mark V carries over some settings from id1. This can be good or not so good....

It doesn't seem to carry over the resolution settings -- that would actually be a good one to set....

It does carry over controls I have set up, which is good for basic movement controls, but not so good in that it keeps keys bound to aliases which are now no longer set (by the autoexec in id1).

It also grabs the settings I have made in the menu, including disabling the demo playing... and in this case that turns out to be bad, because the mod has a little "intro screen" demo that runs by default.

This is a tricky thing, because it's either "all or nothing" using the settings from id1 (or its hidden cfg file somewhere?) as the defaults in a case where you run a new mod... (weren't me and someone else complaining about that previously? heh).

On the one hand, it's handy to not have to set up your controls again, but on the other hand, generally you should be starting from scratch (with the actual Quake defaults) when you run a fresh mod (or delete your cfg file)....

Of course, knowledgeable users will have their basic keybindings in a separate cfg file which they can exec to set up all their default controls and preferred settings....

I think in this particular case, despite the user setting his id1 Quake to not run demos (because he's seen those 1000 times before), upon running a mod where the setting has not been previously made, the demos should default to play (it's actually an intentional part of this mod's experience).

Hm, yeah, this is tricky. There are good and not so good points about it... in which case I start to lean toward sticking to the default behavior (no cfg? default settings apply).

Perhaps there would be some middle ground where keyboard bindings were retained (not much problem with that), but default settings such as "play demos" are not taken from id1 when a new mod is ran. 
so the shadows(3) sometimes go through walls and floors. bug or a byproduct of the mentioned overdrawing by quake?

I could take SS if needed. For instance dead ogres on top of a bridge are casting shadows on the ceiling when you walk under. 
Bit of both.

It seems possible that this is related to the draw order, and I'm going to work out what the possible best compromise is.

Assuming it can be fixed it will be in one of Baker's spring updates. Until then you need to accept it as a choice between 2 imperfect shadow options.

I think this is the fifth time I've said this... :) 
sorry, i tried going through the whole thread and must have missed it.

Documentation is a little sparse, maybe I'd have a better idea of all these things if I checked the source. 
Lit Water 
I thought I would raise this subject here because it seems like Mark V is one of the few engines currently under active development that isn't DarkPlaces.

What do people think about supporting lighting on water surfaces? Personally, I think it's a very nice visual effect and I'd quite like to see it in more engines *wink wink nudge nudge*. As far as I know compilers like ericw's tyrutils suite fork can support it, but I've never played with an engine that actually renders it...

Sorry if this has been brought up before. 
The other thing I thought of asking about is if it's possible to disable the Gamma Protector Clock? It makes my screens flash when it fights with f.lux. 
Go to video options and switch hardware gamma off? 
I'm currently using Mark V 1.20 (not sure if that's the latest version), there's only 4 options under Video Options - Resolution selection, Fullscreen on/off, and apply and test buttons. The only thing I've seen relating to gamma is the slider, but that doesn't sound like what you mean. 
That menu item was added in the current version, 1.36. You'll probably prefer the DX9 build over the traditional Open GL version since it is much faster (nearly 3x faster in many situations), but both are available. 
Reminds Me Of 96 
Woah, what happened to my framerate? I tried the dx9 build and it was fine, but the GL build tanked. I was getting a perfect 72 on my map before, but now I get something in the range of 22-23 fps with the standard mark_v.exe.

At least dx9 works. 
Also, r_waterripple is really cool, it's a shame about the seams though. 
Lit Water 
Is another topic that pops up occasionally. I'd like to see support for it. May be tough due to the way water morphs and deforms though 
As far as I know light maps are blended after textures are drawn, so depending on where the textures are warped it wouldn't be too much of an issue? I'm not sure how the water warping is done though. 
lightmaps and textures use different UVs so in theory the lightmaps don't have to warp. 
Pritchard, gl_subdivide_size 32 should get rid of the ugly seams, if you're talking about what I think you are, related to r_waterripple.

Something to try which might improve frame rate (GL or otherwise):

r_mirroralpha 1

Using non-hardware gamma will also decrease FPS, unless the gamma and contrast sliders are all the way down (basically disabled).

r_shadows decreases my FPS, so if you happen to be using that setting, try disabling it. 
I was thinking....

So, Mark V keeps a (somewhat hidden?) backup config.cfg file to prevent bad things, such as other Quake engines blanking out a lot of settings and such.

This is both good and not so good....

The good part is obvious.

But it can be not so good for some situations, like if I WANT to blank out my settings in my FvF folder... (they just get re-loaded from somewhere), and like above where I noted that when you play a new mod for the first time, things like "disable demo playing" should certainly revert to its default value (play the demos).

So part of this behavior is taking away user control, and part of it is altering a default behavior that can sometimes be better to not alter.

Anyway, here's my suggestion:

Instead of using a hidden config.cfg file, just have Mark V create its OWN config file in the current game directory, perhaps named something like Mark_V_config.cfg

And Mark V will automatically load the standard config.cfg file, then after that load it's own Mark_V_Config.cfg file.

This is an improvement in my view, because:

- The Mark_V_config.cfg file is easily editable/deletable by the user.

- Mark_V_config.cfg settings will not be altered by another engine which messed with the config.cfg

- Loading that file after the config.cfg will mean Mark V's settings will override settings that other engines have made (or erased) in config.cfg

Mark V would still alter the standard config.cfg file (as is standard Quake behavior) so that any applicable changed settings will apply to other engines. Probably the special Mark_V_config.cfg file would be nothing but a duplicate of the standard config.cfg file... (which is probably functionally equivalent to your special backup config.cfg file, but it's stored in the same game directory now).

And if a new mod is ran which does not contain a config.cfg or Mark_V_config.cfg, then the default settings should be applied (such as playing demos).

If you wanna get fancy, then save all BASIC keybindings and aliases somewhere and let them carry over even if no config exists for a new mod.

Extra fancy would be some menu option for this -- "Save basic config settings," "load basic config settings," "always retain basic config settings," or something like that within the Customize Controls menu (though I know how much you hate extra menus).

Or perhaps some of this this might mean making another config file, much like R00k was suggesting in #1224 (which sounds like a great way to do it all around -- saving aliases and such automatically, and automatically switching to new configs when changing mod directories).

So Mark V could write it's Mark_V_config.cfg which is basically a backup of the config.cfg, and also a Mark_V_user.cfg which will always be written to id1 and read no matter what mod is ran, which will just contain basic key bindings and aliases which would be unlikely to change from mod to mod. Though the Mark_V_user.cfg from id1 should load first in case the user has set up special key bindings for a mod -- such settings would then be read from the gamedir config files and override the basic user controls.

Hm, then, of course, any key bindings made while playing a mod wouldn't carry back to the basic user settings stored in the Mark_V_user.cfg in id1, but that's actually correct behavior, in my view -- UNLESS the user uses that hypothetical menu option "Save basic config settings". Of course, if the user was just running id1, those settings would be saved automatically.

So... in summary, and in order of loading:

Mark_V_user.cfg (always in id1, contains key bindings and aliases, loaded every time even when running other gamedirs. Saved automatically if running id1, or by user selecting a "save config" option when he's running a mod)

config.cfg (standard function, for cross-engine compatibility when possible)

Mark_V_config.cfg (saved alongside the config.cfg in current game directory, backing up all Mark V settings and overriding settings that other engines made to config.cfg).

All files are easily user-accessible.

And like R00k suggested, configs should be automatically saved/loaded upon switching gamedirs. 
Lit Water 
It would be better to discuss lit water after a couple of single player releases have the feature.

Would be proof that mappers will use the feature, that the compile tools work reliably, that another engine has achieved a stable implementation.

When these maps exist in the wild and after the rank-file can play these maps and potentially report/discuss issues in engines that current support them, it isn't out of the "idea stage".

Where are these maps?

Until they exist, from my perspective they exist this is the same as talking about leprechauns or the Loch Ness Monster. 
Methinks the reason for the absence of such maps is exactly the fact that there's no proper engine support.

Right now - what, Darkplaces has it? FTE, maybe? I'm not even sure. People don't work with advanced engines here. And it's not exactly the kind of feature that you could squeeze in as an optional bonus for special engines. It affects the way the level looks a bit too much. 
I would like to include lit water in my map - as far as I know doing so is as simple as setting a flag on my compiler. But it is a chicken-egg situation; I don't have any way to know how my map actually looks with such an effect, since I know of absolutely 0 engines which support it.

I'm sure you can imagine that authors may have reservations about releasing a project with something that is "maybe it works and looks good here, but I have no idea since I'm practically blind".

It's totally fair to not want to be the first/only engine with support for something, even if that is a little disappointing. I'm just concerned that someone will have to take the plunge with support, and given features like mirrors, I had hoped that Mark V might finally do it. 
the latest version of gl mark v runs really slow on ad_magna, while it ran fine on previous version that i had (mid december). dx9 version of the latest build runs it fine. what fps killing features did i miss previous month? 
Just checked, the DP dev build render lit water:

Add "-splitturb" to the tyrutils-ericw qbsp command line to get it. 
@pulsar - I guess I'll be double-checking the Open GL build come spring time to see if I did something that inadvertently caused a performance drop in Open GL. 
Lit water is one of those things that seems like a great idea until you go poking at all the edge cases.

Yes, I implemented it, saw what it looked like, and got rid of it.

I'm willing to add it to my DirectFitz thingy but please be aware of the following.

An engine can 100% reliably detect if a map has lit water.

An engine cannot 100% reliably detect if a map has not.

That's because a surface not having a lightmap doesn't mean that the surface isn't lit in Quake. It means that it's in total darkness. This is the kind of "let's save maybe 200 bytes per map" thing that matters when you're trying to run on an 8mb MS DOS machine but that causes untold pain and suffering later.

So a map with no lightmaps on water can mean one of two things: either the map doesn't have lit water (draw it fullbright) or the map does have lit water but the water is in total darkness (draw it with black lightmaps).

Do you light lava? Slime?

Do you add a warp effect to lightmaps? The lightmaps are a combination of (1) still, and (2) darkening the original texture, so the warp effect on the original texture is lessened.

What about translucent water? Darkening the water will make it appear more translucent. Maybe we should decide that because light goes through translucent water it doesn't get lit.

Should a map with unlit water still have dynamic lights added to it's water surfaces? And if so, is it OK that this would make the light seem brighter than on surrounding solid surfaces?


These are probably questions that people can't answer until they see it and start exploring around it. Like I said, I'm willing to add it to my D3D9 FitzQuake port if anyone wants it that badly, but don't expect it to be a 100% robust implementation at present. 
Just For The Sake Of Completeness 
Mankrip said maps like e1m4 don't compile with lit water. This was months ago, maybe that changed.

Until someone steps forward proving any of this stuff works and is polished ... I'm not sold.

I would like to include lit water in my map - as far as I know doing so is as simple as setting a flag on my compiler.

Man up?

Maybe find the courage to actually use the compiler option?

Maybe find the courage to load the map in DarkPlaces or existing engine that supports it? 

This, of course, is not compiled by any light tool. 
Do you light lava? Slime?

Should be up to the mapper.

Do you add a warp effect to lightmaps?

I wouldn't, but it depends on how you perceive the warping. Does it only represent horizontal movement of the substance, or does it also imitate vertical waves to a certain degree? Distorting the lightmap can help with the latter, I suppose.

Maybe we should decide that because light goes through translucent water it doesn't get lit.

Then it will glow on its own. 
Only Suports X & Y Targa 
So some of the HD backs from here:

fail with Only type 2 and 10 targas are supported message. I get thrown back to windows until I find the files and delete/rename.

Of course I had to extract them from the pk3s but even re-extracting doesn't help. Example is +1wall58.tga from arcanum HD textures. 
I'll look at having tga files that aren't type 2 or type 10 just do console prints instead of errors in the future (next updates likely in the spring).

Erroring out to windows seems like overkill.

Thanks for point this out. 
I couldn't figure out how to get the Darkplaces Autobuild from ericw's link to display the lit water. And yes, the turbs were split.

Man Up?
It wasn't/isn't an issue of "manning up", at least not from my perspective. I'm fine with turning on a compiler flag. I just like to be able to see the results.
Imagine compiling lighting for a map in general and never ever looking at it. Doesn't that seem like a daft idea? Perhaps you got the values all wrong, everything is too dark or too bright. But because you never look and see what the results are, you'll never know and your map will suck.

untold pain and suffering
Would it be possible at all for a compiler to actually write that data? Obviously it would increase file sizes, but would it necessarily break compatibility with engines if that were the case?

The other way to handle that that I can think of right now would be to change the result based on whether there is ANY water with light data or not. If there is some, you could pretty safely assume that all water is supposed to be "lit", and so water surfaces without light data could be rendered black. If there is no light data for any water surface, then you could assume that it is not supposed to be lit. There may be a few edge cases there, but that would, I imagine, cover support for correct water rendering in 99% of maps, as well as allow for it in the rare pre-existing "lit water" map and all future ones.

Also, I'd be interested in finding out why some maps refuse to compile with lit water? I've never had any kind of lighting setup outright refuse to compile on me. 
@Pritchard try this map in DP:

Here is what it looks like for me: 
I just like to be able to see the results. I couldn't figure out how to get the Darkplaces Autobuild from ericw's link to display the lit water.

Understood. ;-) I'd want to be able to see the results too. 
@ericw - that map works; the water is bright, and then it gets darker... and it's glorious. *hint hint, nudge nudge @Baker*

Now the question is why can't I get it working for my map? But that's something for your compiler tools thread, I imagine. 
Would it be possible at all for a compiler to actually write that data? Obviously it would increase file sizes, but would it necessarily break compatibility with engines if that were the case?

What I'm actually talking about is the 20+ years of existing maps that have this behaviour. 
Yes, of course, but if you could look at a map and say "none of these water surfaces have any light data, I should not apply lighting effects to the water", that'd be fine, wouldn't it? 
More Questions 
Should water have fullbrights? The stock ID1 lava texture is actually mostly from the fullbright palette ranges, a possibility that ID themselves had considered but rejected lit water.

Should water block light? It's possible for a surface to receive light but not block it - that's what doors & plats do. But if water blocks light it means scenes like the lava pit in start.bsp would be almost full dark - most of the light entities are inside the lava. 
I wouldn't be able to give advice on fullbrights for water without having seen it, but I imagine the answer is no. It would probably look like very ugly specular highlighting.

I don't think water should block light - it's unrealistic and would make extra work for mappers that they probably wouldn't see a point to doing.

Perhaps lava should have fullbrights though - it might look good for that. I also think the issue with lava looking bad if it's lit can be counteracted with surface lights, although it is something that would trip up noobs... 
The stock ID1 lava texture is actually mostly from the fullbright palette ranges, a possibility that ID themselves had considered but rejected lit water.

I think the orange fullbright range is just the best color range for lava in the palette.

I wouldn't be able to give advice on fullbrights for water without having seen it, but I imagine the answer is no. It would probably look like very ugly specular highlighting.

It can be a problem with existing texture sets, since they were developed with an assumption that liquids are never lit (therefore there's a greater chance for bad fullbright distribution on liquid textures).

But what if someone actually wants fullbrights on liquids? 
<-- Beer Is The Only Liquid-themed Icon We Have 
I'm a big fan of the idea of lit water
That looks pretty good - although it's hard to tell from such a small blurry image, but I'm pretty sure it looks a ton better than regular water.

should light block water

The only way of blocking light that would look correct, is if it affects the attenuation of the light trace as it travels through the water volume. That's probably a bit of a faff? Or could be easy, I have no idea.

What about directional considerations?

In this shot, the water looks bad because light is coming up from below the surface, lighting the rocks, but the surface of the water doesn't receive it, so the water/rock transition looks bad:

To look better, the water surface would somehow need to be lit taking into account light coming from both above and below the water surface, I think?

Kinda like quake's window textures - if the light is coming from either side of the window, you'll expect to see light on the window surface. 
With tools like defullbright out there, it might not be such an issue with existing texture sets. Perhaps it would be best to render fullbrights for liquids. 
Water would definitely have to be lit differently to normal surfaces, like Kinn describes. Again, that's on the compiler, rather than the engine... 
was mentioned last time this topic came up, but the lightmap on water should probably get blurred a bit too - hard shadows would probably not look good. 
Extra Soft And Supple 
I thought everyone used -extra4 -soft ;) 
I'm not sure how much this is a consideration, but...

To look better, the water surface would somehow need to be lit taking into account light coming from both above and below the water surface, I think?

...this reminds me that Q1 BSP actually stores each water surface twice. Once for the underwater view, once for the above-water view, and so visibility (not so important if you have translucent water) and backface culling (always important) work correctly. 
I don't use -soft, I'm not keen on that look nowadays.

On water though of course it's a different story. 
Quotin Maself 
The only way of blocking light that would look correct, is if it affects the attenuation of the light trace as it travels through the water volume. That's probably a bit of a faff? Or could be easy, I have no idea.

Thinking about this it's probably not too bad. I'm not ericw, but I think when you do a raycast you can note the point when the ray hit a water surface and take that into account when lighting geometry under the water. I have raised this to "probably would want it" because consider an outdoor pool/lake - you have sunlight lighting all the geometry outside, but you want to dive into that pool and see the sunlight penetrates the water to light objects just below the surface, but as you go deeper, the sunlight fades to black... 
meanwhile all the fish at the surface are pitch black because they get their light from the floor trolololoool 
Nothin' wrong with black fish. Some of my best fish friends are black. 
GPU Lightmaps With Lightmapped Translucent Water 
If that makes it into a release somewhere, anywhere, I'll be a very happy chappy. 
That Looks Pretty Cool 
Spring update anyone? 
I think Baker's gonna need to make the judgement call on whether or not MarkV gets it, because it's pretty much all renderer front-end work. I'm 99% certain that the current back-end will support it without modification, but I'm willing to commit to any modifications that may be required should Baker decide to go for it. 
@mh (and 1 For Ericw, 1 For Mappers) 
Just various random thoughts

1. Mark V has optional stain maps (defaults on), like FTE, which uses the lightmaps.

2. I'm sure you already have this one taken into account, rotated and moved brushes.

3. Here's a more complex one --- fullbright colors in water texture + software renderer :( This isn't necessarily as annoying as it sounds and in-engine conversion of a water texture's pixels from fullbright blue to non-fullbright blue at map load is likely an option. I guess I'll need to look at the textures/palette, I hope there isn't a fullbright blue without a non-fullbright equivalent.

4. Do non-supporting engines load lit water maps ok? It is sounds like they do, which would be an advantage.

5. Would be very helpful if ericw could mark the .bsp as having transparent water somehow to avoid the "don't know" scenario you outlined. One thought is inserting a worldspawn key "litwater" "1" (is this the best way to mark the maps? I'm not saying it is. But if lit water maps can be loaded in standard engines, at least this method does not require a new map format. But there could be a better way and this is just one thought, but avoids MH's "don't know" scenario.). 
Did a quick palette conversion test of the traditional blue water to a non-fullbright palette. It's fine. Non-obstacle.

Lava will have to be fullbright because the software renderer doesn't have a choice except to use the Quake palette, and there are no non-fullbright versions of bright red. 
I don't really have an opinion on lit water.
I guess it looks ok in those screenshots.

What I really wanna see is reflective water!
But r_texprefix_mirror doesn't seem to do anything when set to a water texture.... 
Sorry For Hijacking Your Thread Baker 
About corner cases:

- Winquake.exe seems to be fine with the example lit water map I posted.. it doesn't have a problem with liquid faces missing TEX_SPECIAL.

- The qbsp options "-splitturb" (and "-splitspecial" which is older) unset TEX_SPECIAL on the affected faces.

The main problematic case I can see is a face with:

- texture = "*water"
- lightofs = -1
- styles = {255, 255, 255, 255}
- TEX_SPECIAL is unset in the texinfo

Do you render that fullbright or solid black in an engine with lit water? I think it needs to be rendered fullbright; faces with those settings will exist in the wild if anyone ever used the "-splitspecial" qbsp option. It would be worth checking how Darkplaces handles this corner case since it's the first released implementation afaik.

So to fix this case, the light tool just needs to avoid writing those "implicitly black" faces for lit liquids. IIRC, mankrip requested that a while ago but it looks like I didn't implement it yet in my light tool. I think if I do that, we don't need any other kind flag to mark the map as using lit water. (presumably the engine should support mixing lit water and non-lightmapped lava)

- Other rendering stuff: imo fullbrights should be rendered normally (for fitz engines, respecting the gl_fullbrights cvar), the lightmap should not warp (I'm imagining it as a shadow cast on floating leaves that are swirling around; the shadow shouldn't swirl).

- Light tool stuff: there is already some handling in my tool that mankrip contributed; lit water faces can receive light from either above or below, and they don't cast shadows. This part I'm not so concerned about, it's easy to tweak with features as they are needed. 
Here's a more complex one --- fullbright colors in water texture + software renderer

That didn't even occur to me, but yeah - a GL/D3D engine can just not draw a fullbright, but software doesn't even have the option.

Rather than remapping I think if it was me I'd probably do an extra colormap.

Do non-supporting engines load lit water maps ok? It is sounds like they do, which would be an advantage

Not a problem. Most of the work is actually changing various cases of "if (surf->flags & SURF_DRAWTURB)" to "if ((surf->flags & SURF_DRAWTURB) && !litwater)" at runtime, so load time is fine.

Would be very helpful if ericw could mark the .bsp as having transparent water somehow to avoid the "don't know" scenario you outlined.

I think the don't know case was me being nitpicky more than anything else. It is possible but the probabiility is so low that I don't think you'd ever actually see it.

What would be more worrying is bad tools setting surf->samples for a drawturb surface in a map that shouldn't have lightmapped water, because that's really the only way you have of checking, but I don't know if such bad tools even exist. Either way, providing an r_lightmappedwater cvar that the user can set to 0 can help with that. 
Water with garbage fullbright pixels is a texture pack problem, as it always was with garbage fullbright pixels. I don't think it should be solved engine-side. That would only complicate things. 
Random Extra Thoughts 
Although not an official texture, *tele teleporter textures should probably be fullbright (not lit). Both Mark V and Quakespasm treat *tele textures differently.

dwere: Water with garbage fullbright pixels is a texture pack problem ... I don't think it should be solved engine-side

Sounds logical. 
What About 
tell the mapper to put liquid brushes in a func_group and then set all the different liquid lighting options on the func_group. 
Personally, I've had enough of having to do that with _phong 1 on all my func_details... 
The idea isn't to annoy the mapper by making him manually set the rules up on each func_group - I assume there would be default liquid lighting settings that are used if nothing is specified, but...if you want custom light behaviour on a certain liquid body then you can func_group the liquid and set some options...

Beats having hardcoded arbitrary rules for teleport textures and whatnot imo. 
Or Even Better 
Do it like surface lights - have an entity whose sole purpose is to specify the light properties (aka override the defaults) of a particular texture, which then applies to all instances of that texture in the map. No need to use func_groups.

I only thought of this because with custom liquid textures used for random things like teleporters or energy fields, the texture names can be unpredictable (I think Knave has a *starfluid texture or something) 
I think the special entity could work, although I don't think it's ever been done before - with surface lights, it's a single key that specifies that the light it's on should be duplicated and spread across all instances of that texture. It's not specifically a custom entity that does anything different to a normal light.

This is quite offtopic, anyway... 
(Maybe) Simplified Navigation For Non-Traditional Platforms 
I'm slightly tempted to add an (optional) auto-jump feature where a player at an edge will automatically jump *only* if they can make the jump at the current speed *and* they are running.

If they can't make the jump and are running, the option would work like "edgefriction 999999" (if you don't know what it is, you might try it) and make it very difficult to fall off an edge.

And perhaps have the option have an "automatic jump up" if forward progress requires a upwards jump that can be made.

(Because pressing "jump" seems to be an annoying burden if you aren't using a mouse + keyboard). 
Not Sure I Understand 
But is it similar to quake 3's awesome stair clipping. I hate q1's momentum loss around short floor variances 
I can understand that this might seem attractive on accessibility grounds, but (and unless I'm seriously missing something) wouldn't it totally fuck with your game if you were playing with "always run" enabled? 
rebind the jump button to +run 
I don't fully get it, but it sounds like a terrible idea.

Why don't you just make it a full bot so the player doesn't have to press "attack" in addition to not having to press "jump?" Because "aiming" is an annoying burden if you aren't using mouse + keyboard... or, you know, if you just suck at Quake :p heh. I know you're probably thinking about Gamepad controls, but still, meh.

mh, the "always run" menu option already fucks with my game by borking up my sidestep speed... AND Mark V changes it to default ON (that's an old complaint of mine, heh. [oldpage #1154]). 
I know you're probably thinking about Gamepad controls, but still, meh.

I think he's talking about things like phones and tablets. Gamepad users don't have a problem with jumping. 
Touch screens is exactly what I thought it was too, where you might have left thumb to move, right thumb to look, tap to shoot, and ideally you'd like to be able to jump while moving and shoot while jumping but you're out of options for how to handle it. 
mh, the "always run" menu option already fucks with my game by borking up my sidestep speed... AND Mark V changes it to default ON (that's an old complaint of mine, heh. [oldpage #1154]).

I'm not sure about the details of how MarkV implements this.

I like the Quake 2 method which maintains a separate cl_run cvar and just multiplies the speeds by 2 if it's set. Seems less messy to me that Quake's faffing around with cl_forwardspeed. Any reasons why that hasn't been adopted (aside from "iiiiit's nottttt Quaaaaaakkkkkkkke", that is)? 
Triple Post 
@Gunter - found your discussion of "always run" in the other thread; repeating here for info:

This is not a good setting to default ON. It's weird. It doesn't actually do what you'd think (make it like you're holding down the +speed run button) -- it just messes with your normal "walking" forward and back speed, but not your sidestepping speed, exactly. So you end up being able to run forward fast, BUT when doing so you sidestep slowly... EVEN AFTER you press the run button or use +speed in the console. Always Run must be switched off to get proper sidestep speed when running, even when using the +speed option (unless you make other settings, I guess?). Please default it back to off. A better fix would be to change the "Always Run" menu option to actually lock +speed on instead of whatever weird thing it currently does.

This is basically what Quake II does.

It's "always run" option, via the cl_run cvar, is exactly the same behaviour as the +speed key. In addition it has the following nice behaviour.

If "always run" is off, pressing the +speed key will speed you up.

If "always run" is on, pressing the +speed key will slow you down.

Even nicer, it's basically (aside from cvar declarations and removing the old cl_forwardspeed behaviour) a one-liner:

I'm coming more and more strongly in favour of this being something that should be standardized across Quake engines. 
Thus far, I've only seen one control scheme for touchscreen that was "ok" (Minecraft) but have some thoughts for improvement.

The difficulty of "getting it right" somehow increases the appeal to me. 
Mark V merely defaults always run on. Like what happens in the original Quake if you toggle it.

Gunter is arguing it should do more than that because turning on "Always run" in original Quake didn't also increase backspeed or sidespeed.

Which I didn't do in Mark V because in my opinion it should use the FitzQuake definition of always run.

So Gunter is arguing against the original Quake behavior, saying Mark V's "always run" should do more (ProQuake's always run sets all 3, for instance).

+speed - I myself have never found a scenario where I would want to walk instead of run in Quake. Not in any of hundreds of single player maps. Not in any of countless of multiplayer games/maps. But I can describe scenarios where changing it to Quake 2 style is a behavior change in original Quake.

I might be a bit of bad person in that I find both of the above kind of topics on the "boring side" of the spectrum. 
OK, I suspected that didn't come across as clearly as intended.

Just to summarize:

Quake has two run behaviours, and they're both different.

"Always run On" via the menus just bumps the values of cl_forwardspeed and cl_backspeed.

+speed applies the value of cl_movespeedkey uniformly to all axes of movement.

Quake II's behaviour is identical to +speed in Quake 1. Let's not get the idea that anybody is advocating for porting "Quake II movement" to Quake 1, because that's not happening.

What Gunter is arguing, and I am supporting him in this, is that the Quake behaviours should be consistent.

This is a simple matter of player expectation and principle of least surprise. If you have a "+speed" key, you expect it to have the same behaviour as "Always run On". 
I prefer the mark_v and fitz implementation of always run. I find quakespasm is too quick to judge when you strafe 
@fifth - Agreed. And because Mark V is intended to preserve the feel of FitzQuake. Modern ProQuake does what Gunter advocates and it doesn't feel exactly the same to me. So I stuck with the FitzQuake way.

@mh - The behavior of +speed is described here ....

Devil's advocate: Why mess with a defined behavior? Couldn't someone who wanted +speed to slow them down instead set cl_movespeedkey 0.5 in their autoexec.cfg?

My thought is this is already available to a user if they decided to do so. So it is not necessary to break defined and known Quake functionality like what, say, Quakespasm does. 
QuakeSpasm, Fitz and MarkV are all the exact same so far as strafing is concerned. No difference whatsoever in the code. 
Devil's advocate: Why mess with a defined behavior? Couldn't someone who wanted +speed to slow them down instead set cl_movespeedkey 0.5 in their autoexec.cfg?


That's not what I'm saying. That's a side effect, not the main thing. The main thing is an "Always run" option that's the same as +speed.

You don't have to have +speed slow you down. Just change the "^" to "||" in the one line of code and it won't.

Again: the main issue is that "Always run" and "+speed" behave differently. I am saying that they should behave the same. That is all. 
And incidentally, the Quake wiki is wrong. That's not what +speed does; all you have to do is look at the code to see that.

What +speed does, in the original Quake code, is adjust all 3 axes of the final movement. It doesn't modify cl_forwardspeed or cl_backspeed. What's described in the wiki is what "Always run" in the menus does (with the exception of the cl_movespeedkey part).

You see - two different behaviours. One modifies all 3 axes: forward/back, up/down, left/right; the other only modifies forward/back. One modified after the full movement is calculated; the other modifies before. One applies the value of cl_movespeedkey; the other just doubles. 
if that's the case why does QS feel a bit twitchier on the strafing than Mark v?

I feel like I hit strafe in QS and I feel I have less control cause I shoot off so fast.

I'm not trying to be an ass about it, genuinely feels different to me. 
I think I'm seeing where you are coming from now. Quake has a number of inconsistencies in that department.

Like how +jump is slower in water than +moveup.

Quake is crazy like that :( 
I almost inserted the word "allegedly" when describing the +speed entry.

(As an engine coder, I don't trust a non-engine coder's description of what something does because they didn't use the code as reference. Although that page was made pre-source code release). 
Here is the "fucked up" thing.

Client movement is "normalized" (vector math).

So if you mess with the sidespeed max, it affects your diagonal movement speed.

This is (probably) why that behavior in Quakespasm doesn't feel like FitzQuake, because I think Quakespasm uses the same increases "all of them" that modern ProQuake does.

Which to me doesn't feel like FitzQuake, which in turn is why I didn't do that in Mark V. 
And when I say "normalized" --- I mean that increasing the sidespeed max has the consequence of decreasing the effective forward speed max when moving diagonally.

So even slight diagonal movement feels different than original Quake/FitzQuake/Mark V in an engine that increases all the speeds like Quakespasm or modern ProQuake. 
I have used QS more frequently recently and that's due to the music not working again in mark v and also the twitch integration in one of the QS forks.

Currently using Mark V off-cam and QS on cam. So there's that I guess.

I also have a "pure" quake folder with winquake and various folders with pretty much each engine.

But I do have to re-adjust my thinking when playing in QS due to the strafe differences. It's probably not noticeable to most people but it's fairly jarring to me for some reason 
QS changed some stuff in 2013, I think it now behaves like you suggest (+speed and "always run" both affect forwardmove/sidemove/upmove, +speed with "always run" slows you back down to walking speed):

(I don't understand why that "cmd->forwardmove /= cl_movespeedkey.value;" line was added though.)

Baker, I play with always run on and do use shift to walk sometimes (e.g. useful for navigating narrow ledges to get to secrets). But I can see where you're coming from regarding keeping winquake / Fitz behaviour identically.

I have a hard time noticing the difference between sidespeed 350 and 400. 
I do like the option to have +speed slow you to walking speed if "always run" is on -- it seems like I've encountered that behavior in one of the other engines, maybe Quakespasm or FTE. It's like, "why not?" because +speed effectively won't do anything if you are already running, so go ahead and have it toggle your speed.

FifthElephant, look on the old page ( ) at post #1154. That will explain why the strafing feels different in Quakespasm (or if you are using a +speed key instead of "always run"). I believe that's actually the correct behavior -- you SHOULD sidestep fast if you are running, so you can avoid rockets and stuff.

I really dislike my sidestep speed suffering when "always run" is on. I know Baker has resisted making an adjustment to this behavior (which I believe is a flaw or oversight in Quake's original coding -- and I would much prefer it to be consistent as mh suggests), but my plea in that case it to leave the menu option defaulted to OFF (as it was in original Quake). It ends up being more config settings for me to return to Quake default behavior:

cl_forwardspeed 200
cl_backspeed 200

And I actually have a key bound like this:

alias +slow -speed
alias -slow +speed
bind b +slow

because sometimes I do want to return to walking speed, like if I want to position myself carefully to take a screenshot, or to get just the right sniper position, or if I want to build up a massive fireball for the Mage in FvF (his Delayed Fireball attack travels at walking speed, so if you are moving forward and firing them, you get like 4 of 5 of them all piled on top of each other, heh, for a massive explosion when they hit something).

Touch-screen controls? Yikes. That would be tricky. If someone really wants to play Quake on their phone, I'd say, "get a bluetooth gamepad," heh. Like the Ipega 9055 that clamps around your device.... 
Yes, my bad, that was indeed changed.

It looks as though that line was added to prevent cl_movespeedkey from being applied twice, once from the menu code and once from the following block.

Quake II drops the side speed default to 200, then when always running it goes to 400.

I wonder how all of this behaves with values of cl_forwardspeed set in configs? 
I just checked and Quakespasm also modifies forwardspeed and backspeed. Now I'm even more confused. 
Hey, what about a sort of compromise where the "Always Run" menu option would have 3 possible values:

All Directions 
Regardless, anyone who doesn't like autorun behaving exactly like +speed can just set some cvars instead of using the menu item. Being picky about EXACTLY how something behaves is experienced users' lot, and experienced users shouldn't have any problems creating an autoexec.cfg.

A reminder:

cl_forwardspeed 400
cl_backspeed 400
cl_sidespeed 350
cl_upspeed 200

Those are the values for when autorun is toggled ON from the menu in the original game. If you want to be able to walk, set cl_movespeedkey to less than 1 and use +speed to slow down.

Though you might want to set cl_upspeed to around 400 if you don't want to swim like crap. 
Nice To Know Dwere 
@dwere For The Win; "Keep It Simple" Is Winning Strat 
Being picky about EXACTLY how something behaves is experienced users' lot, and experienced users shouldn't have any problems creating an autoexec.cfg

When I first started engine coding I discovered "expert user bias". I was building modern ProQuake, I added a field-of-view slider that went from 90 to 110. Spirit said "I use 130 and the slider doesn't go that far".

I wasn't for or against anyone's particular settings but it didn't take long to realize that accommodating all preferences while keeping things simple for the average user.

Expert users can already do what they want.

There are engines that try to appeal to all possible settings.

ezQuake has a ridiculous settings menu with several pages and each of them scroll. Likewise, DarkPlaces has menus galore.

I think this flies in the face of the KISS rule --- "Keep it simple, stupid!"

"Keep it simple, stupid!" -- is why conservative engines rule and why advanced engines are frustrating. 
I probably shouldn't harp on this, but this is what I believe ...

Bad engine design expresses itself in the form of menus. 
Well, the thing is: an average user would probably prefer autorun to behave in a modern, convenient way. The problem here isn't even the fact that there are subtle movement angle differences. There are more jarring symptoms of hackery.

Like, turning the autorun ON doesn't invert it. In other words, you can't slow down anymore. I can't recall any game made in the last 20 years that would behave like that.

Another thing is that the strafing speed is locked at 350, which means that you can't strafe slowly at all.

Bad engine design expresses itself in the form of menus.

This I agree with. Doom source ports are a great example of what happens when you pile up engine modifications and try to be flexible about them. Though the game was always at a disadvantage when it came to extending the gameplay functionality. 
There are also certain mod concerns with how the menu always worked.

Malice is probably the only example, but I consider it fairly important. Toggling "always run" forces certain speed settings upon the player, which is fine in Quake, but what if the mod wants different values?

Having a separate variable would allow mods like Malice to have a (somewhat) working autorun toggler that wouldn't break anything.

Just my two cents. Since I'm aware of the problem, it doesn't really affect me. 
But the behavior of Quake's always run is hardcoded in menu of the Quake engine. So whether or not Malice has different settings that option in the menu changes it just the same.

Mark V is meant to be an equivalent drop-in replacement for the original Quake, except that it has Quake's definition of mouse look and always run on (instead of requiring a user to go to the menu).

Mark V does not change any of the Quake cvars from their default -- aside from the always run defaulting on. 
But the behavior of Quake's always run is hardcoded in menu of the Quake engine. So whether or not Malice has different settings that option in the menu changes it just the same.

I know. That's the problem.

I hope that at least QS will implement the Q2-like functionality (I think there were some plans for it), because what's there right now clearly isn't that. 
I actually kind of like EZQuake's menus, I remember installing it and spending a good 30 - 40 minutes messing around with all the different options to see what changed. Should totally add a 15+ page menu with every possible cvar on it to Mark V. /s 
(ironically That Engine Was At One Point A Model Of Clean Design) 
I thought ezQuake was the possibly the greatest Quake engine ever the version before they did that with the infinite menus and the laggy mouse driven cursor.

When it was like a FuhQuake with extra features, it had a simple menu that let you do many general settings.

So at one point, ezQuake was quite a nice engine that was laid out so cleanly it was arguably the model of excellent engine design.

Then they decided to add "Cool features" or something and it got all dorkulated. 
I'm Surprised 
That Baker even added the extra menus that he did. I never expected much more than standard 
Re: Adding The Preferences Menu 
I hated every second of it. I felt like I had failed.

WinQuake gun position as an option forced me to do it.

I still try to think of ways to kill the preferences menu. 
Having additional menu items is fine, as long as the menu as a whole stays concise and organized. Not adding important things that regular users might need is about as bad as adding unnecessary junk.

For example, adding "previous weapon" to the controls menu is helpful. 
It's funny that you say that cause I agree, despite using that menu myself. Unreal had a little known secret menu hidden from the casual user. I think that is a good way of having a clean look but allows power users to tinker 
The benefit of menus is that they provide the user with visible options that they otherwise won't know about (because they are hidden in obscure console variables).

Experienced users are mostly aware of these options, but Mark V has so many more options (with not-so-great documentation) that even I am uncertain I know all the options I may want to fiddle with. The "find" option in the console is certainly very helpful, but you have to know what you want to search for before you can search for it.... With a menu, it's like, "oh, that's an option? Neat, let's see what it looks like..."

I don't think being "automatically anti-menu" is really the best approach. The problem may be that you've encountered some BAD menus, but that doesn't mean all additional menus are bad.

It would be nice to have the Basic menus for the basic user, then perhaps some deeper level of Advanced menus for people who really want to tweak their settings (sounds like that secret menu FE just mentioned).

I'm against "bad menus" myself.... I don't want things to get too cluttered up when I am trying to change some basic options. But I am not against having advanced menus with tons of settings in them, as long as they are clean and easy to understand and navigate. 
I think Quake is in a unique position because a lot of it's defaults are actually no longer sensible defaults.

That's at least partially on account of it's heritage - moving from a mostly-keyboard setup with no free looking, nobody actually had a clue how the game would have been played.

It's obvious that ID had expected joysticks to be the predominant control mechanism. Just look at all the joystick setup cvars, the existence of a dedicated readme for joysticks, sample .cfg files for different models, sponsorship deals, not to mention the ganky joystick code in the engine itself.

The existence of sensible defaults means that menu options are not really such a huge necessity. In Quake you need to either change the defaults or give the player an easily discoverable way of doing so themselves. 
"I do like the option to have +speed slow you to walking speed if "always run" is on -- it seems like I've encountered that behavior in one of the other engines, maybe Quakespasm or FTE. It's like, "why not?" because +speed effectively won't do anything if you are already running, so go ahead and have it toggle your speed."

I also have this behavior in Qrack, if your speed is > 300 then it will cut your speed in half, if its less then it will double it, both forward back, side as well. I'm used to pressing shift in modern games to "sprint" so it helps. 
@r00k - Gunter Quote 
Your quote of gunter -- that's actually probably the strongest argument I've seen.

Not the "other games" part -- I'm indifferent about that -- but the +speed "doesn't do anything if you already running".

I somehow missed seeing that in the thread until now. Probably because where lots of comments in a short period of time. 
The core issue is that all of the cl_*speed cvars relating to movement have defaults of 200, with the exception of cl_sidespeed which is 350.

Most people are used to "always run" just doubling forward and back speed, so it becomes forward 400, back 400, side 350 and up 200 (up is rarely used).

Doubling the speed on all axes, either via +speed or a Quake II-ish method, will increase cl_sidespeed further and cause it to dominate.

Quake II changes cl_sidespeed to 200 and removes cl_backspeed. I'm not sure when cl_sidespeed was changed but I do know that cl_backspeed was removed in the last month before Quake II went gold, so that was a change made after Quake II was it's own engine rather than just an experimental branch of Quake.

Quake II also changes cl_forwardspeed to not be saved to your config. I believe saving it was just a hack in Quake 1 so that the always run setting would be saved, but have no evidence either way.

All of this is discussion points. I know which behaviour I personally prefer but I'm not trying to convince anyone else. 
So, does capturevideo only work when watching a demo? Or can it record "live" gameplay? I set my codec and FPS but it complains about them not being set when i enter the command. If it only works on demos, adding that explanation to the error text would be useful. 
You can capture in real time, but capturevideo is intense and not necessarily a good fit for real-time capture --- it's going to be an fps/cpu hit and at higher resolutions the penalty gets stiff.

bind x "capturevideo toggle"

Make sure you have the other capturevideo settings the way you want:

capturevideo_codec xvid // I'd recommend this at least at first
capturevideo_fps 15 // You can always increase it.

Smaller resolutions like 640 x 480 are going to work better than larger ones because pixel count increases drastically.

You may also wish to consider something like Bandicam which works great with DirectX which Mark V DX9 obviously is. Someone earlier in the thread said how great Bandicam is. 
"Quake II changes cl_sidespeed to 200 and"

no wonder i always though sidespeed was weird in quake 1.
I played Quake1 freeware version all the way through, then later played Quake II extensively. Then came back to Quake 1.

//R00k: i didnt want +/-speed with 'always run on' to eventually STOP the player, but instead toggle the speed from walk to run, or run to walk.

if (cl_basespeedkey.value && cl_movespeedkey.value)
if ((cl_forwardspeed.value > 200) && (in_speed.state & 1))
if (!(in_klook.state & 1))
cmd->forwardmove += 200 * CL_KeyState (&in_forward);
cmd->forwardmove -= 200 * CL_KeyState (&in_back);
if (!(in_klook.state & 1))
cmd->forwardmove += cl_forwardspeed.value * CL_KeyState (&in_forward);
cmd->forwardmove -= cl_backspeed.value * CL_KeyState (&in_back);

if (in_speed.state & 1)
cmd->forwardmove *= cl_movespeedkey.value;
cmd->sidemove *= cl_movespeedkey.value;
cmd->upmove *= cl_movespeedkey.value;
if (!(in_klook.state & 1))
cmd->forwardmove += cl_forwardspeed.value * CL_KeyState (&in_forward);
cmd->forwardmove -= cl_backspeed.value * CL_KeyState (&in_back);

if (in_speed.state & 1)
cmd->forwardmove *= cl_movespeedkey.value;
cmd->sidemove *= cl_movespeedkey.value;
cmd->upmove *= cl_movespeedkey.value;

only issue i have with above code is when you set your speed cvars to something like 180 then you will go in the opposite direction with +speed :P 
no wonder i always though sidespeed was weird in quake 1.

Probably to make dodging easier for keyboard-only players. Once again, only somewhat relevant in 1996.

Useless trivia: Chasm made itself look like even more of a Quake clone by copying this behavior.

only issue i have with above code is when you set your speed cvars to something like 180 then you will go in the opposite direction with +speed :P

Uhhhh, I have them at 160... 
So is that "reloading the level dead" bug specific to Mark V? I've been getting it a lot lately. Don't remember ever seeing it with QS. 
Centerprint Positioning 
<p>if (scr_center_lines <= 4)
y = vid.height*0.35;
y = 48;</p>

This code always puzzled me. At modes larger than 320x200 the result is that centerprints more than 4 lines (including the e2 entrance message in start.bsp) will be rammed up near the top of the screen, whereas centerprints of 4 lines or less will be more accurately centered. This looks awful.

There was some kerfuffle over the whole thing in the old thread.

I believe I know the reason why.

It's for the slow finale printing at the end of an episode.

The give away is the positioning of the gfx/finale.lmp banner in Sbar_FinaleOverlay - it's at a y of 16, and when we add the banner height of 24 we get 40; 8 more pixels for a blank line between the banner and the centerprint and there's the 48.

Why did Carmack do it this way rather than checking for cl.intermission == 2? Probably the same reason he did a lot of other crazy-seeming things in the Quake code - a rush to get things done and get the game shipped. 
Some further evidence: Carmack's .plan for 17th June 1996 gives us the exact date that the centerprint change was made.

Interestingly he was also working on items relating to level transitions and boss/finale stuff on that day. "end of e4 text crash" was an item. So the evidence definitely correlates this change with work on finale messages. 
Well, like you said, he could have easily made it only apply to the "Congratulations" messages and not other Centerprints if he wanted, but he just notes in the changelog:

"changed center print position for very long text messages"

And I'm sure he would have noticed the E2 entrance message being affected by this, since it's right on the Start map, so it's no accident.

It just makes sense to me that any "very long" message would be moved up, out of the direct center of your view.

I actually didn't know that the Congratulations messages were considered Centerprints -- they use different functions in QuakeC, but I guess the engine funnels them through the same printing method. I tested it and, indeed, an end level message of only 4 lines will be centered lower on the screen. Weird.

If he were just trying to position those end-level messages only, counting the number of lines would be a very hacky way to do it. that sounds like something *I* would do! 
Picked up a couple of new Mark V users last night -- some old returning FvF players (I'm talking old players from the 90s).

They said Mark V works much better for them than GLquake (obv!), but they were still having some connection problems -- and I've seen another player who has this issue on the server too (I think it's Mr. Burns who has this issue, maybe):

When the level changes, they get stuck in the console and never reconnect to the server. We still see their names as connected players, but their frags are shown as "0." I believe we told Mr. Burns to try typing "ping" in the console when this happens, and that sometimes allows him to connect and get back in without having to totally reconnect and lose all his frags.

I don't have any control over the server (Polarite does that), but it appears to be running "Magic ProQuake Server Version 3.90" in linux.

I really can't provide much more information about this issue.... I assume it's one of those things where it gets stuck doing the "keepalive" messages in the console. I'll ask more specifically the next time someone encounters this -- it's only a few players, but it affects them consistently.

Also, one of the returning players asked about mirrors -- he wanted to be able to see his reflection (mentioning that it was a pretty big deal/cool feature back in the day), and I told him mirrors only worked when running plain ID1... but I realized that it really SHOULDN'T be this way, as it violates what I think should be a pretty important aspect of Quake engine design: you shouldn't take away user control and force your own preference on the end user (even with good intentions).

I mean, there are already various mirror variables that the user can set if he wants mirrors to be on or off (and actually, they should probably be off by default). If the user wants to turn them on, even in a mod or map where it might not work well, he should be able to do so.

Also, for those users that want to play with mirrors, how about an easy way to set a mirror texture. Specifically, something like (probably used in conjunction with tool_texturepointer, but not necessarily): if you input "set_mirror" in the console, it will assign the mirror effect to whatever texture you are pointing at (manually typing in those texture names for the mirror texture prefix is a chore and prone to typos, heh).

Of course, there's the issue of having to restart a map before it takes affect, but it would still be handy for people that want to play around with mirrors.

I suppose it would be handy to be able to feed the pointed-at texture into any of the tex prefix variables, actually.... Not sure how that could be implemented, other than copying the selected texture name into the console and allowing tab to autocomplete the various things you might want to apply it to.

Ah, yeah, it would work if you just had it stick "r_tex [copied texture name]" in the console and positioned the cursor right after r_tex, then tab will autocomplete all the various r_texprefix things with the selected texture already filled in. 
Mirror ??? 
I want to see a Quake ingame video of this effect 
If he were just trying to position those end-level messages only, counting the number of lines would be a very hacky way to do it. that sounds like something *I* would do!

This is actually exactly the way Carmack coded a lot of things in Quake.

How did he test to see if you were connected to a server and therefore the status bar should be drawn? By checking the number of console lines drawn. How did he test to see if a map was running? By checking if the console was fullscreen. Quake is full of crap like this. 
Holy shit. I would love to read a compilation of "quake code nightmares" like this. 
Lightmapped Water 
Well that was unexpected. :/

The "semi-official" 32-player deathmatch map death32c, still available on ID's FTP server ( has lightmapped water.

And the lightmaps are messed-up:

I guess this means that other maps with messed-up lightmaps on water surfaces may very well be out there in the wild, but in the absence of engine support for lightmapped water nobody was ever aware of them.

You could control this with a cvar but that's pushing responsibility back to the player, which I don't like.

Since lightmapped water is a new feature I suggest a worldspawn key indicating it's presence. That way engines that don't support it can ignore it. Engines that do support it can pick it up. Maps like death32c aren't subject to false positives. 
I wonder which compilers were writing that junk data? Worldspawn key has my +1. I've already forgotten all the discussion we had a while back, so I'm a clean slate on that (except for the point that it'd be really cool, that still stands). 
check the styles. if there's multiple 0s then its clearly uninitialised.
while its possible for a light util to write multiple of the same style, 4 of them is basically pointless as it would oversaturate everything. 
check the styles. if there's multiple 0s then its clearly uninitialised.

Bingo, buy the man a large beer.

I believe that these maps may have been lit with ID's then-unfinished qrad tool. 
DarkPlaces shows the same problem on death32c:

I would lean towards a worldspawn key now as well, since there are no released maps using lit water yet. 
"Quake Code Nightmares" 
From the video code:


These are all global variables that are used to store what is essentially the same information. I don't even think I have all of them here. But all that you really need to store is the window handle and you can derive everything else from it. Sure you can potentially optimize by caching some stuff, but this crap reads like any time something was added to the video code, a new set of globals was added just for it. Of course they all have to be kept in sync and consistent, so any work on the video code is a tangled mess from the outset. 
I'm trying to host a dedicated server with this and anyone outside my network can't connect..

I love how faithful this client feels to the original Quake and I know netquake is tricky and not as ideal as QW but honestly QW feels OFF to me..

Any ideas on why folks can't connect? Tried dedicated.. noipx.. My ports are open, no firewalls.. I hosted a QW server last night without a hitch. 
Mark V should launch a single port server just like Quakeworld. Only port 26000 needs to be open. (Feature is essentially courtesy of Spike).

It could be the clients other people are using.

By default, Mark V uses FitzQuake protocol 666 --- this means DarkPlaces and ProQuake cannot connect, for instance, since they don't support protocol 666. sv_protocol 15 is regular Quake.

What you should do is try to connect to yourself from another client through your public IP. Also you may wish to do sv_public 1. 
ericw: I lean towards worldspawn key

If that's the best way to do ... then whatever solves the problem ;-) And any engine should be able to read a worldspawn key pretty easy ;-) 
@JPL - Mirrors ... 
Mirrors ... here you go ...

If you want to play on that quickly assembled test map:

Pulsar threw a mirror into Arcane Dimensions ad_magna map, but it is very difficult to find it because the map is huge.

In Mark V, type "setpos 2496 56 -292" in the console with ad_magna loaded and teleport directly to the mirror ;-) 
Yeah, folks were using Mark V and could connect to my QW server just now.. haven't tried SV_public 1

The server does list my local IP rather than external, anything I need to do there? 
Also super weird... I can't connect to my own server anymore using localhost, 127, or my network address.. but I CAN join through the multiplayer public menu. No one else can see my server though. 
And when I type sv_public it says UDP WRITE, sendto, bad adresss ? 
Holy shit. I would love to read a compilation of "quake code nightmares" like this.

It's turtles all the way down. 
Add -noudp6 to the command line to disable ipv6.

See if that solves the problem, what operating system and version are you using? Like is this Windows XP or a certain version of Linux? 
I'm using Windows 10, it's definitely attaching to an ipv6 address so I bet that will do something. I'll try it later, thanks for the help! 
I've seen that ipv6 oddness before, but not on Windows -- ironically, the iPad example doesn't like ipv6 when connecting to a server.

The next time I load up Windows 10, I'll see how it reacts to ipv6. 
Something I noticed with Mark V - Release 1.00.

When I first get into the game, my frames are all over the place for like 5 seconds and then it goes to normal, anyone know why? I'm on an AMD 480, Freesync with windows 10.

Also an FOV adapt feature would be nice, Like the one in QuakeSpasm. 
Also an FOV adapt feature would be nice

Mark V uses a similar algorithm to fov adapt, although if I recall it is an mh variant (640/432?). Even the software renderer uses it.

It can't be turned off, but since it is aspect ratio correct, I can't think of why someone would want to turn it off.

If misunderstood what you meant, let me know. 
Cool I'm fine with that!

Also...being able to change mods/maps in game would be great...instead of just being able to change the levels.

Something QuakeSpasm doesn't have, you have to use Injector.

Injector works but seems it will never had a final version. 
Something QuakeSpasm doesn't have, you have to use Injector.

QS and MarkV both have this, the "game" command:

game xxx
exec quake.rc (optional.. loads the configs from the new mod.) 
In Mark V, you can type "install travail" or "install rapture" in the console and it will install Travail or rapture off Quaddicted.

You can type "install b" and press TAB and it will autocomplete one of the about 530 Quaddicted mods recognized.

I'm just lettting you know these things.

Like ericw pointed out, the "game" has existed for a very long time in FitzQuake and derived engines like Mark V and Quakespasm. 
there's a mirror in my explore jam 2 map as well. it's big and right on the mandatory route.

I do love this feature. 
I remember the mirror corridors section in Prey (the old one, who the hell decided to call the new game the same as the old one that did not have any siquel). I wish it could have been done in mark v, but it's impossible so far with one mirror at a time limit.

I still wish it will be possible one day. 
The calculation I used originates in a thread at and an online FOV calculator that used to be at - the latter can probably be picked up at nowadays.

I just lifted the calculations over to the Quake engine.

640x432 was chosen as a baseline aspect ratio which everything is calculated relative to. This is GLQuake's default 640x480 less 48 status bar lines. Arguments can be made for and against different baselines.

QuakeSpasm uses a different widescreen FOV calculation standard, and I'm not going to argue that either is more correct than the other. The great thing about standards is that there are so many of them. 
Still no one will comment on my bug :( should I try and make a demo of it or something? Do those even work when the issue occurs when restarting a level? 
#1376 ? 
I think it's safe enough to say that nobody else has even seen that bug.

You might give a little more info. Map? Custom progs? Etc? 
I first mentioned this happening in post #1182, here's the link I posted back then:

That's a RJ6 map, and I'm pretty sure that pack used original id1? Anyway, what happens is that if I die and click lmb to restart the map, I start the map "dead" like in the video. Except I can swing my invisible axe and make particles, also shown in the video. I'll see if I can make it happen again soon and try collecting more evidence. 
Here is me playing that map ...

Kinn was playing that map in WinQuake and he didn't say he had a problem with dying and spawning wrong.

There are tons of QuakeC bugs (i.e. the progs.dat).

A demo and a savegame would be something to go ;-) 
Yeah, I'll try playing some id1 maps tonight and see if I can get it to happen. I've had it happen both in that map and one other which I forget the name of. The other one was a mod though so it's not as useful. 
I've experienced this numerous times (can't confirm the axe thing, never tried) with vanilla quake. I was unsure if the behavior was intentional and too busy to check. 
The two new Mark V users played again tonight, and both experienced the disconnecting issue when loading a new level. One of them had fiddled with his firewall and thought he'd maybe fixed it, but nope. It only happened to them one time each. It's odd that both of them are having the issue, since they have different setups.

One is from Texas, one is from Canada. One is Win7, the other Win10.

The error they said they got was "level load failed"

One said he usually spams the console with "ping" to sometimes get back in... but I guess it didn't work this time.

I told them to try and come here and post any more details if they could figure out anything else.

Other than that, they really like Mark V, heh. 
You might need to adjust your server's connection timeout, and to be honest as a non-server operator I'm not 100% on how that's done.

Are they using external textures or lots of external fluff? (If they using the really high res versions of an external texture pack, the impact is going to be multiplied.)

During reconnect, if someone is using a lot external textures it increases the load time and can increase it beyond the connect timeout.

I've played a number of multiplayer games on your server. Never had any level change problems ever.

But I don't use external textures except if I am doing testing that needs it. 
I think I found out how to repeat the bug: it happens when you die after reloading a save. Or at least a quicksave, I haven't tested with regular saves but I'd assume it's the same. Can anyone else make this happen, or just me? 
I'm able to reproduce this problem. I'll see what's up when I have time. 
The "semi-official" 32-player deathmatch map death32c, still available on ID's FTP server ( has lightmapped water.
And the lightmaps are messed-up
other maps with messed-up lightmaps on water surfaces may very well be out there in the wild, but in the absence of engine support for lightmapped water nobody was ever aware of them.
Since lightmapped water is a new feature I suggest a worldspawn key indicating it's presence. That way engines that don't support it can ignore it. Engines that do support it can pick it up. Maps like death32c aren't subject to false positives.

DarkPlaces shows the same problem on death32c

Just because mh, lordhavoc and others don't know how to reliably detect lit water, it doesn't mean it's impossible. Retroquad never accepts false positives.

Cluttering the tools and engine code with a worldspawn key for this is pointless, and only serves to hide the fact that the engine's support for lit water is done poorly.

Also, let me rectify Baker's false statement @ #1285:
Mankrip said maps like e1m4 don't compile with lit water.
This is false. What I said is that a few ID1 GPL maps such as e1m4 has countless leaks. This means that their VIS data can't be compiled, which has nothing to do with the lighting. I've already compiled it with lit water and no VIS ages ago, but I wanted to be able to get the VIS data compiled too.

Until someone steps forward proving any of this stuff works and is polished ... I'm not sold.
The solution in Retroquad works flawlessly, is robust, clean and polished. But I try not to care about proving stuff for others. Nobody ever asked me about it, it would just make me seem bitter, and I'm sure I've already mentioned ages ago that the Retroquad implementation of lit water was finally perfect.

Also, <a href="">by the end of last September, EricW's implementation in the light tool was already perfect too. I've done extensive testing for him and showed it when the final problems got fixed. 
</a> Fail 
I always have net_connecttimeout set to 45 seconds, and I know the players with the connection trouble aren't using any external textures (I keep telling them they should try the external textures, heh).

It could very well be some issue with the server. It's just odd how it only affects certain players, and it affects them repeatedly, but nobody else. Extra odd how it affects BOTH these two new players....

Though the fact that it's known that typing "ping" in the console can sometimes get around it, would indicate that it's been a Quake issue for a long time....

I can't really provide enough information about it to really troubleshoot :/ 
I didn't know the GPL map sources for e1m4 had leaks. I thought when you mentioned the problem that it was a tool issue when using lit water.

Anyway, the conversation evolved a lot since then and yeah ... I'm sold now.

But my non-belief was largely due to the apparent non-existence of any known test maps.

When avirox, myself and gb were working on true rotation, we made a number of test maps with QuakeC sources, engine sources, .map files and map compile instructions. 
I guess if one of them could play using "developer 1" and also record a demo, then the next time they get the problem zip up the demo + qconsole.log, there would be some information to go on.

From your description about how typing "ping" helps, it sounds like a message got blocked by a firewall in a non-NAT fixed client.

If I had a qconsole.log where developer 1 was enabled where one of these players had the problem, I might be able to learn more.

I just now connected to your server, I don't experience this problem. And apparently you don't.

At the moment, there really isn't enough information to speculate. 
So how do you detect that those water faces weren't compiled with lit water? 
I obviously can't speak for Mankrip, but I adopted Spike's suggestion of checking the styles too, and confirmed that they were all 0. Lightdata offset for these surfaces was also 0, so whichever light tool was used clearly left the surface uninitialized rather than explicitly setting offset to -1.

My current tests looks like this:

1) Initialize loadmodel->litwater to false at the start of Mod_LoadFaces.

2) Check lightdata offset as standard; if it's -1 there's no lightmap so none of the rest applies.

3) As an additional check test all styles for 0 and lightdata offset for also 0; if this check passes then we have an uninitialized surface so also no lightmap.

4) Otherwise there is a lightmap; at this stage check if the surface has a water texture and if so loadmodel->litwater goes to true.

5) Finally when building the surface polys and lightmaps, I set surf->litwater to the value of m->litwater.

It's clear what happened here; the code that correctly initializes the face for no light ( must have been removed from whicever tool was used for lighting this map. 
ericw: Detecting maps compiled with lit liquids.

mh: whichever light tool was used clearly left the surface uninitialized rather than explicitly setting offset to -1

That's not a problem, because there's no need to initialize the surface cache parameters since they should be ignored on non-lit surfaces. See my code on the link above.

My current tests looks like this:

1) Initialize loadmodel->litwater to false at the start of Mod_LoadFaces.

That is bad. Non-lit surfaces are defined on a per-texture basis, and it's perfectly possible for a map to be compiled with both unlit slime and lit water, for example. The engine should not use a global setting for this.

4) Otherwise there is a lightmap; at this stage check if the surface has a water texture and if so loadmodel->litwater goes to true.

There's no need to tie the engine's lightmap usage to texture naming conventions.
One of the potential ideas I have is to implement support for non-subdivided unlit surfaces with regular textures: for example, surfaces using fully black textures (or textures with fullbright texels only) could be rendered much faster this way.

the code that correctly initializes the face for no light (...) must have been removed from whicever tool was used for lighting this map.

It was not removed, because what truly defines the lack of lighting on specific surfaces is not the face data. The map was correctly set to use no lighting. 
TEX_SPECIAL works cleanly. I guess the fact that it's unused in the engine made it easy to miss.

That's not a problem, because there's no need to initialize the surface cache parameters since they should be ignored on non-lit surfaces. See my code on the link above.

I'm actually talking about the face having been left unitialized by the light tool, not by the engine.

If you check the link I posted to LightFace ( you'll see that what it does is first set offset to -1 and all styles to 255, then does the TEX_SPECIAL check.

A face with TEX_SPECIAL should also have offset -1 and styles 255. death32c has faces with TEX_SPECIAL and offset 0, styles 0.

The only concern I have about using TEX_SPECIAL is that it's set by the bsp tool, not the lighting tool. This may be purely theoretical: are there any bsp tools that don't set TEX_SPECIAL? 
nice catch, those water faces in death32c have the TEX_SPECIAL flag set on their texinfo. So I agree there should be no need to have special handling for styles = (0 0 0 0) and lightofs = 0; seeing TEX_SPECIAL is enough to indicate that they are meant to be rendered fullbright. 
Lest my questioning be thought of as criticism, I'm actually really happy with the outcome of this. I was able to simplify a bunch of horrible code and the case where one liquid type is lit but another unlit just falls out naturally from it.

It's rare in Quake that the right solution turns out to be so simple, but this is one of those moments. 
@pritchard (@mh @mankrip @ericw) 
Pritchard, awesome beta testing work you did in identifying the situation causing the problem.

I've identified and solved the issue.

@mh @mankrip @ericw - pretty cool discussion sorting out the inner mysteries of lit water. It's nice to see lit water look like it getting closer to go "prime time" from the bsp editor to the compiler tools to the engine. 
I guess the only real outstanding questions I have are (firstly) relating to dynamic lights.

Specifically: should unlit water surfaces receive dynamic lights?

Now, I would LOVE to put dynamic lighting on all water surfaces, lit or not. But it's admittedly easy for me because I've decoupled dynamic lights from lightmaps - it's just commenting out one line of code. (This also made it easy for me to add dynamic lights to BSP brush models.)

The other one is interaction of lightmaps and translucent water.

I've pretty much decided that translucent objects of all kinds (water, glass, etc) don't get lit - they're translucent so light goes through them rather than reflects off them. So instead they're drawn fullbright but with translucency. 
I think this has been brought up before, and I stand by what I said back then. Lighting translucent surfaces is the way to go. I think it would look more accurate, considering that surfaces which are semi-opaque (i.e. 99% of water/brush alpha uses) will still catch/reflect some light in real life.

Also, having to choose between lit water and transparent water would suck. 
This may be purely theoretical: are there any bsp tools that don't set TEX_SPECIAL?

The only one I know of is the -splitspecial flag from TreeQBSP (which is in tyrutils, as well as Bengt's TreeQBSP). TxQBSP (as well as id qbsp) always set TEX_SPECIAL for texture names starting with * or sky in map.c:FindTexinfo.

I guess if someone happened to compile a map with TreeQBSP/tyrutils and used "-splitspecial", and then used whatever light tool was used for death32c.bsp, we could have false positives again, but it seems pretty unlikely. 
The SQLauncher is AWESOME.

I've been renaming all my map titles in the Quake folder to the actual name of the maps, and I can just use SQLauncher to play them. It takes a bit more time renaming everything, but it's much neater. And you will actually the map title.

Quake Injector is a bit buggy, I just prefer to download maps from Quaddicted one at a time so I know what I'm getting. 
The SQLauncher is AWESOME.

I've been renaming all my map titles in the Quake folder to the actual name of the maps, and I can just use SQLauncher to play them. It takes a bit more time renaming everything, but it's much neater. And you will actually the map title.

Quake Injector is a bit buggy, I just prefer to download maps from Quaddicted one at a time so I know what I'm getting. 
mh: should unlit water surfaces receive dynamic lights?

In the software renderer, that's impossible; surface caches needs surface subdivision.

ericw: I guess if someone happened to compile a map with TreeQBSP/tyrutils and used "-splitspecial", and then used whatever light tool was used for death32c.bsp, we could have false positives again

It wouldn't be a false positive. It would be a true positive, because the lack of the TEX_SPECIAL flag would make the light compiler treat liquid surfaces identically to regular surfaces. The only problem would be the lack of backlights, which can be solved by recompiling the lighting alone, without modifying the BSP data. 
Specifically: should unlit water surfaces receive dynamic lights?
I'd say it's up to each engine. I'd personally leave unlit water without dynamic lights.

I've pretty much decided that translucent objects of all kinds (water, glass, etc) don't get lit - they're translucent so light goes through them rather than reflects off them. So instead they're drawn fullbright but with translucency.
I'm with Pritchard, IMHO semi-transparent glass and lit water should still get lightmapped. Fitzquake 0.85 does lightmaps on func_'s with the alpha key < 1, though I'm not sure how many maps make use of lightmapping on glass, Fifth & I exploited it in ad_tfuma.bsp for example:

The logic, I guess, is that you can see shadows on dirty, scratched up windows.

It wouldn't be a false positive. It would be a true positive, because the lack of the TEX_SPECIAL flag would make the light compiler treat liquid surfaces identically to regular surfaces.
Ah right.. in that case, even the vanilla id light.exe would generate lightmaps for the water/sky. I guess a better question is, how many released maps (e.g. in quaddicted, or idgames) used TreeQBSP's -splitspecial option, and thus have lightmaps for their liquids? This would be a time when it's handy to have a mirror of quaddicted and run a script across all of the maps.

I'm guessing the answer is "0". 
Wow Yeah 
translucent water *has* to get lightmapped. In fact, the translucency is going to be essential to sell the lightmapping as convincing, otherwise water is going to look like pea soup. 
If you can see the surface, then it reflects light. A certain amount of light passes through it, but not all of it.

Besides, like I said earlier, translucent objects (or any objects, really) glowing in the dark doesn't make any sense in a lot of cases. 
Feasibility Of An In-fighting Slider 
Wondering if this is even possible from an engine perspective? One of my answers in sock's recent survey post:

5. Are you put off by certain monster (horde) setups?

No. I don't love excessive in-fighting though. It's frustrating and I wish modern source ports could have a "slider" for in-fighting. Perhaps: "never>rarely>normal"  
That would get very buggy very fast. Play a map like ad_tfuma, it opens with a bunch of infighting. If that was disabled it wouldn't be the same. 
Infighting doesn't come from the engine anyway, it comes from the QC. It would be totally inappropriate to put any kind of control over it into the engine. 
I was asking if it was feasible.

re: ad-tfuma Not sure if it would keep you from playing the map though? Also not really necessary in AD as mappers can add a key to suppress infighting. So it would really just be for vanilla Quake. As I asked: Wondering if this is even possible from an engine perspective?

mh - why would it be "inappropriate" to add this feature to an engine? 
The Infighting In Ad_tfuma 
is planned and set up using triggers.

I'm not sure why you would want to alter this behaviour as this is my vision for the map. 
the logic of the game is in QuakeC
the monsters are in QuakeC
the infighting rules are in QuakeC

the only thing that the engine can do is put the slider in the menu 
I mentioned above this would be for vanilla Quake not AD and it's just an inquiry. Not trying to destroy your art. ;)

@topher yeah I get that's how it works. It was more of an academic question. Wondering if you could modify QC behavior through the engine. Apparently not. 
my guess is that it's possible but it will be hacky, bug prone and harder than modifying and recompiling a new progs.dat 
Wondering if you could modify QC behavior through the engine. Apparently not.

Well the engine can change the QC, but that's not really the point. The logic that deals with infighting is all in the QC, so all you could really do in the engine is do something like a truly disgusting hack such as preventing self.enemy from changing on an entity if certain conditions are met. However, you could only reliably guarantee it working for id1 (the assumptions you make in the engine to make it work for id1 wouldn't necessarily be valid under any other mod), and any other mod being run under it could break in all sorts of subtle ways. 
mh - why would it be "inappropriate" to add this feature to an engine?

First read Kinn's answer just above - that covers the technical reasons why.

Then read Fifth's answer because it covers the gameplay/modder perspective.

I know you said that you were asking about vanilla Quake, not AD, but it's still relevant. Infighting is a designed behaviour of vanilla Quake - it's even mentioned in the Quake manual:
Q: Did I really see two monsters fighting each other?
A: Probably. Some monsters hate one another almost as much as they hate you. You can use this to your advantage (exercise left up to the reader).

Infighting is game logic and the correct place to modify game logic is in the QC code. The engine should not try to inject modifications to QC code. I'm actually shocked and appalled that this even has to be explained. If you want to modify the QC code, the correct thing to do is... modify the QC code. Make a mod with reduced infighting and play that instead. 
IMO This Should Be A Progs Thing 
If you really want such a feature then make your own progs or throw money/sexual favours at someone to do it. 
I'd do it if you threw money at me ;)

I actually previously modified this behavior in FvF. I think my monsters only have a 50% chance of getting mad at each other if they hit each other by accident. If they get hit intentionally by another monster, then they immediately retaliate (they just check to see if the owner of the attack is a monster, and they sometimes ignore the attack if it was not intentional -- if the owner of the attack has you set as its enemy, then it was intentional and you return the favor). This cuts down on the monster infighting, so they can focus more on killing the FvF players >:D But it's still fun to try and get the monsters to fight with each other instead of them all turning their attention on you!

Buy yeah, this is not something the engine should really be tinkering with.

Except MAYBE as a secret hidden setting which is defaulted off; like a new, harder difficulty mode or something. But I think there are plenty of other issues Mark V can be addressing before adding something like that.... 
AD Does Have Something Like This I Think 
I could be mistaken but I think the infighting behaviour is slightly different in AD and they don't instantly change target unless you do a certain amount of damage. 
could someone sent a config with basic graphics to to improve the fps (dx9_mark_v.exe)?

My notebook isn't very good, onboard video and etc.
what's the command for save a config? 
Config (dx9_mark_v.exe) 
My email:

How can i put the Time (with high size) on the center of the screen?

Tks everyone! 
We need more women in Func_. 
The only major default thing that might help FPS is to disable mirrors (which really should be disabled by default):

r_mirroralpha 1

To always show the clock, set:

scr_clock 1

(Baker, the help info for scr_clock is incorrect. It says 0 = deathmatch only, and -1 = never. That info is reversed).

I think the only thing you can do to make the clock bigger is to make your HUD bigger, like:

scr_scaleauto 0
scr_sbarscale 2 
Onboard video is actually capable of running fast without needing to compromise on quality. The problem isn't onboard video, the problem is how the engine is coded.

One of FitzQuake's claims is "if you can run glquake, you can probably run Fitzquake". Unfortunately that means that it tends to brute-force certain things on the CPU where a more elegant, faster approach often exists.

MarkV has inherited that tendency, so hence it suffers from the same problems.

No amount of "go faster" config options can fix that; it needs a complete rewrite.

It's a fallacy to think that the older API is faster with low-end hardware. Low-end hardware these days supports shaders and VBOs; really old low-end hardware still supports shaders and VBOs. Shaders and VBOs allow a faster renderer.

I recommend that you run QuakeSpasm and run it with all extensions enabled; odds are that it will run substantially faster than DX9 MarkV, even on Intel hardware. 
Config (dx9_mark_v.exe) 
Thank you Gunter!
With the command r_mirroralpha 1 improved something.

My notebook is a Lenovo E520 - I5.2410 CPU 8gb ram, 128gb ssd with Intel HD Graphics 3000.

Thank you mh too!

I downloaded the QuakeSpasm, but the QuakeSpasm FPS is similar than MarkV FPS (200..300). what do you mean "with all extensions enabled?". Could you send to me some config?

Thanks in advance! 
With an Intel HD 3000 that's going to be the best framerate you'll get. The only option you have is to lower your resolution.

"With all extensions enabled" means don't disable multitexture, don't disable combine, don't disable shaders, because hardware will run better with these enabled and QuakeSpasm is more sensibly coded than most.

If you're doing nothing to disable these then you don't need a config, just keep things the way they are.

I'm currently working on an engine that will probably run twice as fast, but it's not suitable for general use yet. 
Has anyone seen baker in the past week or so? :/

In other news, has this "transparent models" issue been seen before in any other engines, or is it unique to markv? Noticed it while playing today and I wasn't familiar with it at all beforehand. 
YouTube's video encoding is bad for analyzing such things, but it seems that there's a conflict with the skybox renderer, maybe related to the Z-buffer. 
@Infighting Questions 
Thanks everyone for your answers. It really was just a curiosity and I learned a lot in just these few answers. The reason I asked here is that Mark V seems to be the engine with the most "out of the box" and unique features. I will look into a progs version. Maybe something exists or can be gleaned from AD dev kit. 
Ya know, if you want to play Quake with the monsters being smarter, more dangerous, and not in-fighting as much, you should come play FvF ;)

We usually gather to play on Sunday nights....
Ok.... Another complaint about the secret cfg files overriding expected behavior:

I installed a clean copy of Quake and Mark V into a completely separate folder ("Quake1"). I ran it and got everything set up how I wanted it for THAT folder only.

Then when I went back to my original Quake folder ("Quake") and ran Mark V, the resolution settings I had made for the separate folder were loaded... (perhaps other settings too).

I do not like that, no I do not.

All cfg settings need to be kept separate for each folder, and for each mod.

This goes back to the stuff I was commenting about in #1276 with ideas for a better setup with these config files -- too much behind-the-scenes stuff not matching user expectation. It would be better if the Mark V config files were saved alongside the standard cfg files, and were user-accessible. 
Source Ports Should Write Their Own Config? 
I made mention awhile back about the overwriting of my configs and the "secret" area as well.

What if custom engine wrote their own "branded" config.cfg? EX: markv_config.cfg, fte_config.cfg, qs_config.cfg etc etc

That way no one engine writes over another's config file.

Also, there really is no need to complicate such a simple execution of saving a players configuration settings like this:


Especially given most are not even aware of it and simple browsing of folders doesn't even reveal it. 
All I want is a way to save video settings and only video settings. Having a mod load in 640*480 and move all the windows on my 3 displays one display across (apparently... Idk, it just gets weird) is beyond frustrating. I guess I should just force my res through launch args but still... 
Launching in 640x480 fullscreen should never happen these days either. 
Has anyone seen baker in the past week or so?

Real life. ;-)

You might have noticed "update sometime in the spring", "update sometime in the spring", "update sometime in the spring" ... haha.

Yeah, let's just say I have some action-packed awesome fun battles going on in real life, the kind of scale that makes my eyes light up for battle (heheheheheh).

And that's where my attention is going to largely be quite a bit for the foreseeable future.

But back on topic ...

Here's something to look forward to in the spring!!

Mark V - Mouse Driven Menu Video

Mark V - TouchPad Tap Fire/Drag Look

That plus whatever mh cooks up and whatever bite I have time to take out of Spike's Quakespasm Spiked apple. I still want to get 4 Player support going ... I hope that happens. I've got that itch. Question will be time.

I always read all the posts. I said spring because spring is vague is allows lots of room for interpretation, hehe ;-)

/But yeah, expect me to not consistently be around. But it doesn't mean I don't care. When time comes, I'll deep probe all the feedback. When the time comes ... 
Just Glad You're Still Alive 
I'll be thinking of your persistence in 3 weeks when I'll have 2 XBox controllers on a specific weekend and digging into XInput tutorials.

A year ago, I would not think I would be doing such a thing. ;-)

Sometimes I also question what reality I am living in where I can actually do these things on a whim. A few years ago, I was quite the novice and I still don't entirely understand how I acquired the level of expertise I now have nor what induced me to make a software renderer version nor how I did the majority of it in 3 weeks. It's like "Flowers for Algernon".

I blame hanging around mh and Spike.

5 foot away, there is a beer that needs drinking. I now must attend to this urgent matter ...

/End slight ramble. But incredible things are in the pipeline for the next Mark V. 
4 Player Splitscreen With Pads 
Is literally a dream scenario for me. I host regular game nights and buy a lot of MP games for it. Being able to make death arenas for my friends would be epic 
4 Player Splitscreen With Pads 
Is literally a dream scenario for me. I host regular game nights and buy a lot of MP games for it. Being able to make death arenas for my friends would be epic 
4 Player Splitscreen With Pads 
Is literally a dream scenario for me. I host regular game nights and buy a lot of MP games for it. Being able to make death arenas for my friends would be epic 
Sorry for the spam. Currently at work posting from my phone 
I'd Say That's Some 4-player Splitscreen Posting Right There 
Won't Launch On Mac 
I have the same trouble others mentioned with the app not launching on Mac. My Quake folder is in Applications, and has the id1 folder in there alongside Mark V Quake. When launched, I get a dialog that reads

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

Opening folder ..."

and then I get

"W_LoadWadFile: couldn't load gfx.wad

Game data files are required to run; usually this means you need Quake shareware or registered version.

Is Mark V in the proper folder?


Other Mac Quake files work (Fruits of Dojo, Tenebrae), so I'm confounded. 
Won't Launch On Mac (Sierra) SOLVED 
It looks like the problem is with the Sierra Quarantine Attribute

Followed the instructions here, and all's working now. 
Suggestion: something that saves your most recent previously-used resolution.

So like, if I was in 1024x600 Full-Screen and I used the menu to change to 800x600 Windowed, when I press ALT-TAB it should take me back to 1024x600 Full-Screen (it takes me to 800x600 Fullscreen).

I note that this already works in the other direction -- starting in a Windowed mode and changing to Full-Screen in the menu, then using Alt-Tab will toggle me correctly between those two modes.

I'd like an actual permanent saving of the previous mode used (when it's a change from full-screen and windowed -- like save it in a CFG file) so that this behavior will persist even upon starting a new game. Then I could easily toggle between the windowed and full-screen modes I want to use, automatically. 
Hopefully in the next release, there will be better rendering for transparency... 
Freshly Installed The Latest Mark_V 
on C:\Quake and the music is working on the game again. It doesn't like being on D:\Games\Quake for some reason.

Music is on mp3. I have an E:\ blu-ray drive and an F:\ backup external. 
MarkV Crashes On Model With High Vertex Count... 
...despite being well under the vertex limit.


I posted a thread addressing the issue over at Quakeone, R00k sent me this way to get a hold of you. Did all the troubleshooting I could initially think of. Thought you might find this interesting: 
When this model is converted to strips and fans it comes in at 4284 vertexes, which overflows an internal buffer that's particular to MarkV and was introduced by the shadow code I contributed.

@Baker: increase MAX_LERPED_VERTS to 8192 seems to be one way of handling this because it's consistent with the other counts in gl_mesh.c; at least it means that if a model crashes this it will also crash other engines. 
Thanks for the reply mh. I had a feeling the culprit was right in front of me while scanning through gl_mesh. I'm more on the QC side of coding though, so I wasn't entirely sure what all I was looking at. 
Is 320x240 Stretching In Hardware Mark V Possible? 
I just tried out Arcane Dimension for the first time, and I'm just blown away by it. I really want to play through each and every level of that mod, but there is something preventing me from enjoying it.

Up until now I've used the winquake version for playing quake, and while that is perfectly fine for the official quake content and my own maps it doesn't get along with high-caliber stuff like AD very well. On one hand there are graphical issues with transparency that are to be expected, but the performance also takes such a drastic hit from all the cool effects and increased polycount in every level that it's just not playable any more.

The funny thing is that the obvious solution of switching to hardware mark v actually makes things even worse. Because unless I want to stare at a blurry mess, I need to render in my laptops native resolution of 1336x768 instead of stretched 320x240, which more than nullifies the benefit of hardware rendering in terms of raw performance.

Why is stretching only supported in the software version? I know that most gl-based engines only support 640x480 as the lowest output resolution you can select in the menu, but it's clearly possible to render the actual game in resolutions much lower than that since you can adjust the screen size in the menu to achieve just that. I took a screenshot of the smallest screen size in hardware mark v at 1366x768, which results in the actual rendering resolution only being slightly larger than 320x240. If you would implement a feature that scales this window to fit the screen borders again, that would have the same effect as the stretching feature in software mark v, right? Is that how the feature works in that version?

I can't judge how much work implementing this would be, or if it's even possible at all. It seems like it should work to me, but there very well might be hard limitations preventing the feature from being in hardware mark v in the first place that I'm unaware of. I just want to let the devs know that this feature would be huge to me and everyone else who loves chunky pixels coupled with smooth performance.

I'm surprised so little people seem to play quake this way to the point where there is pretty much no support for it, software mark v being a rare exception. Most players seem to prefer resolutions that utilize every pixel of their screen, but I just can't enjoy quake that way. It has nothing to do with nostalgia in my case, I missed the pixel-period of gaming by quite a bit since quake is actually slightly older than me. It just feels so much more alive in low resolutions. It has to do with how everything is constantly changing shape as you get closer or farther away from it, for example how particles blend seamlessly with the chunky environment, choppy animations seem to flow naturally, flames look like hand-drawn sprites at some distances or how you sometimes can't even tell what monster is waiting for you at the end of a dark hallway. Viewing lava and water at an angle also look incredibly organic due to this, even though they're just a single texture tile repeated over and over. If you look at all these things on a high resolution with interpolated textures and lerped animations, that magic feeling completely fades out of existence. You suddenly see everything very clearly for what it actually is: simple brushes, blurry textures, and crude animations. It feels like looking behind the stage even though you're actually still looking at the stage. That is apparently just what happens when you force a game two decades old to conform to today's graphical standards. It should look objectively better due to the modern improvements, but it just doesn't, not to me at least. I don't want to bash on everyone how enjoys quake at normal resolutions though, even if I'm coming on pretty strong here. I'm really happy that quake has evolved into something that can be so many things and has an engine for pretty much everyone and their personal preferences, and I'm thankful that even less popular ones like mine are represented to some degree in the community and in mark v, even if just in the software version.

I'd happily do the work of porting the feature myself, but I lack any kind of knowledge that goes beyond the very basic level of fiddling with quakec and have no idea where to even start tackling things related to rendering, making this plea to devs my best shot at getting the quake engine of my dreams for now. I'm gonna keep learning more about quake development and programming in general though, it's just going really slowly since I'm far from being a John Carmack and feel like I'm up against something my puny brain can barely comprehend whenever I look through the source code.

Guess that concludes this wall of text, thank you for sticking with it me the end. :) 
This makes me want to try playing at that resolution. I hope you get your wish for increased support! 
Isn't It 
just a matter of turning on "pixels" mode? Forgot how to do it. 
setting these cvars:

r_lerpmodels 0
r_lerpmove 0
gl_texturemode gl_nearest

should make MarkV/Quakespasm closer to what you want, other than the resolution.

Yeah, this is a good request. So to summarize, the ability to render at a res like 320x240, and then scale (unfiltered) to a higher resolution (lcd native res). 
It Already Does This 
there is a gl version of Mark V winquake which has resolution scaling.

I didn't read the wall of text, maybe I'm missing something? 
I tried it and I got a headache :( 
I Can Relate 
I read the whole text and @killpixel, yes, boristhesp1der did try running Mark V in Winquake mode. But that didn't run fluidly in AD. He's looking for a Winquake alternative that runs AD fluidly while playing in a Winquake 320:240 resolution. This is essentially what you wanted to say @boris?
320:240 is my thing as well, at least when I play the original maps from ID. I use the Mark V Winquake for that because it supports folder-music instead of CD. As for modern maps I use Quakespasm with
gl_texturemode GL_NEAREST_MIPMAP_LINEAR because everybody knows that GL textureinterpolation looks rubbish with Quake's low-res look. 
The GL Version Of Winquake Didn't Run Fluidly? 
bummer. Well, he could try Darkplaces. HEAR ME OUT.

there's a retro shader for DP floating around. along with that try these:

r_viewscale .5 (or .25)
gl_texturemode gl_nearest force
r_lerpmodels 0
r_lerpsprites 0

should give him a fairly retro look until he find a more faithful alternative. 
The funny thing is that the obvious solution of switching to hardware mark v actually makes things even worse.

This is the way things are going to be so long as MarkV uses glBegin/glEnd code.

In an ideal world scenario: MarkV would move to vertex array and VBO code, the D3D version can be scrapped (because bad GL drivers are no longer an issue once you start coding sensibly to begin with) and better GL ES compatibility would come about as a bonus.

Resolution scaling won't help much with this. It will help with fillrate but with glBegin/glEnd code it would still be pushing the same amount of vertexes and draw calls irrespective of resolution, which is where the real bottleneck is.

Call to action: get on Baker's arse and get the glBegin/glEnd code killed. 
Since rendering is the current topic, what are the chances of getting proper transparency depth in Mark V?

It's thankfully not too obvious in my map yet but it is pretty annoying. 
@boris - I've been impressed by your ability to self-solve issues (main reason why I am posting since I'm mentally not here, yeah you really impress me). Open GL can't really scale pixels when rendering, although since I'm not AAA+++ in rendering someone may mention a frame buffer trick or shader trick with 6 asterisks next to it.

@pritchard - you didn't state the problem and I'm not level 25 at mind reading, only level 22 although I aspire to be level 25 some day. If it is depth sorting, the answer is yes! because that is on my list.

@mh - "glBegin/glEnd" It kills my soul somehow. I've actually not eliminated glBegin/glEnd for Open GL ES. I created an extra renderer Open GL ES "wrapper" that throws them in VBO. ;-) That being said, yeah I agree in principle. (Insert: I'm probably 6 weeks from doing an update even though technically I have one ready, is there is an update to remedy alpha entity for D3D? No need for an immediate reply, just planning ahead a bit).

@adib - "just a matter of turning on "pixels" mode? Forgot how to do it." --- It's in the video options menu.

@fifth - When Spike sees what I did, he'll fucking hate me. Spike's skill > Baker. Baker's creativity > Spike. I admire Spike. I plan to smoke him a bit. It's not all what your powers are, it is also what you can do with your powers.

@Spike - "oggs" --- In real life, no one has ever heard of an "ogg". It's a technically inferior poor man's mp3 used in a few Quake engines --- no where else in any game or any medium is an "ogg" a format a ordinary user has ever heard of. The mp3 patents have expired. Ogg have no future.

The Unreal Engine doesn't support ogg.
The iPhone can't play an ogg.
The Anroid phone doesn't do oggs.
There is no future for ogg.

The question isn't why DarkPlaces doesn't do mp3. No actually that is the question.

I like it when someone complains about the lack of ogg support in Mark V. When the next Mark V comes out, I expect mega-tons more complaining.

Complaining is awesome. Because complaining is the backbone of progress. 
that makes OTP and Shambler the most progressive people on this forum... ;)

Nah seriously, can't wait to see what stuff gets added this year. I agree about Ogg. I used to be a fan when the MP3 patent was restricting people but it's served it's purpose now. 
Keen Beer Moment 
Yeah, there will be "mega-tons" more complaining.

Because the next release Mark V will be the first true "5 platform" engine. The iPhone/iPad and Android.

And for anyone who has watched any of the videos, yeah Mark V just happen to run on a mobile platform --- it will run fucking awesome on a mobile platform -- in a way no one has ever done.

And it will be a stealth release.

A. Like the past versions of Mark V, I will make nominally a zero effort to promote it. I'm not looking to mainstream Mark V, this engine is meant for those few of us left that enjoy Quake for what it is.

B. iPhone App Store. Yeah, I'm not doing that. Someone with a Mac doing a self-compile and share amongst friends is how that is going to work -- in a best case scenario.

/Six to Eight Weeks Probably a Ground Break Release. Six to Eight Minutes -- my ETA for a beer run. Ill-advised post? Aren't they usually? Haha. Cheers! 
Pre-Beer Run: @ Fifth 
Shambler is a complainer who has put blood and sweat and intellectual sophistication and effort into his passion. I once got into an argument with Mugwump and he said "You are the opposite of Shambler" and I was like "Well, I hate to say this but I probably agree with him on nearly everything ... my only difference would be that I place a high value on diversity".

/I now resume my end-of-night beer run. 
I Often Share The Same Views 
but it's usually the way things are said rather than what is said that can be irk-some. :P

I think if you're doing mobile platforms it will be interesting to some but control is definitely going to be the biggest hurdle to overcome. 
I Was Going To Buy Myself A Gamesir G3 Bluetooth Gamepad 
So another reason to get it sooner. 
is there is an update to remedy alpha entity for D3D?

Remind me again of what the issue was? There's quite a bit of chatter about alpha stuff in this thread, with the most recent I recall being depth sorting issues, which aren't API-specific, so I'm unclear on this. 
Thanks For The Answers Guys, Really Appreciate It 
Kind of a bummer that scaling on hardware is out of the question though. I'm still gonna share the mockups I made though, so you can actually see what I had envisioned for yourself.

I just scaled screenshots from regular mark v down to different "integer fractions" (sounds weird but I don't know the proper term for that, I mean scaling in such a way that the resulting resolution contains no decimal numbers in both axes) of 1334x768 to make them look software-rendered. The result is actually pretty different from the real thing for a number of reasons, the most obvious being atmosphere. Coloured lighting and fog really make a world of difference, and this screenshot alone doesn't even do that statement justice.

In the unlikely case anyone is actually interested in this, I noticed a few interesting things making these mockups. Take the skulls for example, which change size in software mark v depending on your scaler. Candles change position and also get a different model on hardware/software. The skill pillars and everything at their distance looks noticeably worse at 3x in reality because software quake starts to blur out the textures at a certain distance from the player, which is unfortunately not quite far enough away for the transition to happen seamlessly. (Fixing that would be a fun project, eh?)

You'll notice that as the scaler increases, there start to be more versions of the same mockup with numbers attached to them. Those signify how the picture was scaled from the original, which can make a world of difference in the end result. 1 means scaled down in 1 step from 1344x768, 2 means first down to half at 672x384 and then to the end result, 3 means first half, then third, and then end result, etc. Most of the time one step looks the best, but sometimes multiple steps actually preserve some details that would otherwise be lost, like the metal edge on the lower step of the stairs. I also had this anomaly for the 6x scaler where no matter whether I scaled from 1x or 2x, the result was exactly the same down to every last pixel. That doesn't happen in any other scaling scenario. Thought it had something to with scaling from an even to another even scaler at first, but it didn't work for 4, 8, 12, or 24. I used GIMP to scale the whole image without interpolation, so If anyone can explain what happened there I'd be interested to hear.

On somewhat of a related note, and since problems with transparency are hot topic right now, I'd like to present you the following:

Is there a way to get software mark v beefed up to deal with this? I don't know if the crash is actually caused by those transparent textures, but that level (foggy bogbottom) runs (for a few seconds at least) far worse than all the others and is the only one filled with them, so it's probably not that far fetched. 
Hardware Scaler 
is a feature I wouldn't mind included if it was ever possible. I like the blocky aesthetic 
Take the skulls for example, which change size in software mark v depending on your scaler. Candles change position and also get a different model on hardware/software.

Heh, the candles don't change because hardware/software - they change because the candle entity is deliberately set up to spawn a random version each time (they come in many variations of tall/short/thick/thin)

The skulls changing size though is some funky shit - why is that happening? 
For what it's worth, hardware resolution scaling is possible. Never said that it wasn't.

You do need render-to-texture to do it with best performance, which means OpenGL 3.0 or GL_EXT_framebuffer_object.

A slower GL1.1 path involves a glCopyTexSubImage call.

The point that I need to be absolutely clear about is that MarkV's bottleneck is elsewhere, so hardware resolution scaling would give marginal improvements to it. With e.g. QuakeSpasm it would be worthwhile for cases that are fillrate-bound, but MarkV isn't fillrate-bound. MarkV is CPU-bound. 
Wait A Minute, What Do You Mean By Cpu-bound 
Is regular Mark V also rendered on cpu? I just assumed a gpu was a requirement for opengl. So Mark V essentially emulates gpu-features on a cpu? Is that correct? I don't know enough about this stuff...

That certainly would explain why performance is so bad. Apparently my poopy laptop isn't at fault after all, I just tried running those levels in quakespasm and they run at a stable 60. I hadn't even considered that to be a possibility, mostly because my laptop struggles to run just about anything that came out in the last 15 years. 
By CPU-Bound, mh means (I think) that the performance limiting factors in markv are operations that are always done on the CPU in all games.

I'm no graphics programmer, but as I understand it, the CPU has to explicitly ask the GPU to draw each frame. If it takes too long, it won't matter how fast your GPU is because it's just sitting idle a lot of the time.
Quakespasm sends it's draw calls in a different way to markv which means that the GPU can always be busy, or at least busy more often to the point where upgrading your GPU will make a difference.

I might be wrong about all this so take it with a grain of salt. 
Thanks Pritchard, that explanation seems a lot more likely than mine. The difference it makes on my system is batshit crazy though, that's why I thought it had to be cpu rendered. While mark v sometimes dips down to less than 10 frames in busy areas you won't even notice as much as a hiccup in quakespasm.

I guess I'll have to switch engines for now, I'm gonna miss you zoom button... :( 
Pritchard has the right of it.

When drawing objects, every single component of every single vertex has CPU overhead in MarkV that doesn't exist in QuakeSpasm.

For any given scene this overhead is based on the number of polygons and number of vertexes in the scene, so it's fixed irrespective of resolution.

Small scenes - like in ID1 maps - are barely affected, which is why it won't be noticeable if all you ever do is e.g play DM3.

As the polygon count goes up the overhead gets more and more. 
Baker what features and stuff do you think you might want to implement in Mark V's next release?

(Crazy and Stupid) Ideas:
Atleast try to support orl's Zeangala map or what ever its called.Who knows,someone might make an adin1 like bbin1
Create feature like in reQuiem
(Might need to check this one)
Music command like in QuakeSpasm
Some proper coding!

So far I know 4 coders doing engine stuff
Re: Post #1504 
Does anyone know why the skull models change size between the different resolutions? That's some crazy beans... 
Sort of, at least. In a proof-of-concept way.

The video makes it look pretty crappy and stuttery, but it actually runs and feels awesome. The only real downside to this method is that you have to be incredibly careful not to make any sudden mouse movements, that causes the borderless window to stop capturing the cursor for a fraction of a second and the magnifier will register that movement, jerking the viewframe in whatever direction you happened to be aiming.

Keyboard aiming it is then! I can handle that. Probably. 
That Looks Mighty Sexy 
You could always use a joypad? 
Feature Request 
So you mentioned that 4-player splitscreen is a thing you want to implement in the future? How about 4-player splitscreen that also allows people to join from the internet?

I have been playing a bit of the remastered Turok 2 from Nightdive and this has the same feature. It's a good way of getting people online and playing! 
You could always use Audacity or any sound tool to export to mp3. 
... is also good at that: I created some custom sounds and background loops a while ago with it.

It is not a freeware, but it has a lot of interesting features. 
Feature Suggestion For More-legible Text 
How about a Text Contrast adjustment that will only affect the text (maybe like the texture baked-on gamma/contrast).

The dull text can be hard to read in front of all the other dull colors in Quake.... I don't want to universally ramp up the contrast for everything, so it would be nice if I could just adjust the text contrast alone. 
Kustom Conchar, Hudnum, Conback 
I was running an ancient version of dp then fte before mkv. in those I was using a conchar file that had black outlines and cleaned up characters, the diamond grip numbers, and conback from qtest. I had obtained these from quite some time ago all for clarity and legibility sake. Is there any way to have mkv load external wad assets, or does it perfer certain fyle tipes such as pcx? 
Mark V only supports .tga, uses the DarkPlaces way of naming replacement textures.

For instance, throw this file in quake\id1\gfx folder (conchars.tga).

Random comments: Gunter should be using a custom charset ;-) He could adjust the contrast in an image editor and self-serve. 
If your custom gfx are in .lmp format:

DP/FTW will use a loose id1/gfx/conback.lmp (conchars, etc.) in preference to the one in id1/pak0.pak, but vanilla engines including MarkV require you to put them in a pak file (e.g. create a pak2.pak) in order to override the stock ones. 
Thank Yah 
Everything was in a portable network graphic format so I just used gimp to patch them over to targa. I also increased the color saturation levels of everything and added black borders to the hudnumbers as well. Another thing I noticed after this was if you disable the start demos it just dumps to console, is there any way that it could pop the main menu up as well? I also saw a sort of custom start demos command but I couldn't get it to operate. 
Akira, just put "menu_main" at the bottom of your autoexec.cfg file if you want it to pop up automatically upon game start.

Wow, that custom conchars.tga is definitely high-contrasty-more-legible in the game... buuuuut it doesn't look like Quake, heh.

I guess I can mess with the contrast and make my own custom conchars, but it would still be nice to have such a feature built in. 
this is the one i use, and Gunter will approve! 
edit: what you CANT see by that image is that the characters have a thin black outline around them.
Unless I selected the wrong file. Or just look in Qrack's pak0 for charset-3. 
Not bad... (had to convert to TGA for Mark V, but it works). That's more Quake-like than the one Baker linked, but I'm very picky in that regard, heh, and it's still not quite right.

I came up with this one by just ramping the hell out of the brightness/contrast so the text really stands out, but it's otherwise still the original Quake characters: 
Scr_clock Setting 
Just a heads up, Baker. Looks like the cvar scr_clock still allows the game time to be drawn when set to -1 if playing DM (it does disable in SP).

Wouldn't normally bother me but it overlays on top of the player colors (the mini-scoreboard when viewsize is set to 120). 
EDIT: sorry, I meant when viewsize is 100 or less, in regard to the above post 
Using The Dx9 Render 
I've come across a few bugs. The first one is in mutiplayer the ping command doesn't seem to work, I tried ping 100 and ping +100 but I don't see any changes on the scoreboard or latency. It seems to be in there though as it doesn't come up as an unknown command. The second is single player that when you die and instantly hit space to respawn your view remains sideways, I'm not sure if it has any relationship with quicksav or being splattered. The last one I've had happen a couple times first on some map from 1996 then in ad monsters spawned like brushes I was using quake injector. 
1) There is a loadgame + death bug reported by Pritchard. Will be fixed in the next release (already fixed in unreleased code). Results in the deadness issue you outlined above after loading a save game.

1) ping +x is not supported (ability to lag yourself). Feature exists in ProQuake/DarkPlaces/Qrack, but adds some complexity/ugliness to maintaining the network code. Possible it may get added at some point. 
is there any portal culling for VIS like in DP? 
Doesn't have such a feature, which AFAIK is intended for real time lighting.

Arcane Dimensions quake.rc has r_useportalculling 0 and Map Jam 8 users needed to turn off r_useportalculling to avoid issues with DarkPlaces.

Arcane Dimensions finds it necessary to turn off r_useportalculling in the quake.rc file for gameplay or visual compatibility reasons. 
yeah, "r_useportalculling 2" breaks map if you have some Warnings/clipped portals during VIS. It's very annoying, but 50% of fault lays on mappers side ;)

I was just curious if there are any VIS improvements in your engine, or do you plan any?

As we know VIS in Quake is very primitive and does it's job poorly, so you have to do tricks etc. to limit r_speeds. 
The idea the engine would do the same thing as vis (which can take untold hours to run in some circumstances), and do it better and do it instantly on map load doesn't make sense.

I'm just saying ... if the engine could do that, why wouldn't you take those calculation and throw them into the vis tool instead?

Yes Quake vis sucks terribly, especially at open maps. Kills frame rate, makes demos huge --- like the 10 GB "I played Arcane Dimensions!" demos, makes QuakeC slows, makes map uncoopable with enormous network traffic.

The correct solution is improvement of map compile tools.

/Maybe you should get together with other interested parties and raise a $2500 bounty and try to induce someone who writes tools either in Q1 or in Q3 or at id Software or for another game engine to get Quake vis right or vastly improved.

/One idea. I'm often wrong about these kinds of things. 
I agree Baker, the only problem with vis, IMHO, is the thing where certain uses of func_detail can cause vis to see through your map where it shouldn't. I'm not sure exactly where the problem lies (qbsp or vis) but I'm sure it's fixable.

Unless the problem I mentioned leads to exaggerated PVS in AD maps in a lot of places, vis is not really to blame for large demos in AD and the large unreliables, that's just the particle system based on entities and lack of use of static entities combined with protocol 666. 
Yeah, my main complaint are open spaces. I know how to optimize vis for indoor maps.

I did hedge maze and of course everything is rendered, because of open space above it... I'll have to add some obstacles to separate sectors better, or try some hint brushes, but I think hint won't help in this case.

Best option would be occlusion culling like modern engines do, but of course it's impossible with BSP.

Anyway thanks :)

Btw. how different is Q2's VIS? (except doors blocking it) and how much we can borrow without a need to upgrade BSP ? :D 
ericw, you've done awesome work with the tools so this isn't directed at you. It isn't your responsibility to fix vis. You are a volunteer. This isn't a reflection on people that do the great work on the tools.

But yeah ...

vis is certainly to blame. It is supposed to block faces and entities from being drawn. That includes things like AD particles.

/I don't like thinking about it because it is very disappointing. Nor do I seek to bring it up. Kreathor brought it up, haha. He's the bad guy.

Dead horse, I don't wish to beat it. I won't be bringing up, and I didn't raise the topic this time either. 
Nor do I seek to bring it up. Kreathor brought it up, haha. He's the bad guy.

Yeah but I haven't brought it to blame you guys, but to ask if there are some better solutions on the horizon and what can we do to improve this situation.
I saw that Mark V has some nice features, so I thought I'll ask if there are some features supporting VIS...

Speaking of raising a bounty I'm in, but...
Considering I'll give $100 I'll have to find other people willing to pay $$$ to get $2500 in total, which probably is impossible, so I think it's time to finally dive into code and see what we can do in that matter. 
Nah It's Cool 
Reporting problems is only a good thing in my book.

Wow, ad_mountain's vis looks really broken. Assuming the player was in-bounds and then you used lockpvs and noclipped outside?

The ARWOP screenshot doesn't look too bad to me.. assuming the player was at the start position when pvs was locked? Also I am 99% sure ARWOP predates func_detail being used commonly so it would be immune to the bug that can cause total breakage (vis seeing into entirely separate areas).

The last one of ionous/pulsar's map, I'm not sure there is much unneeded stuff, that's a big open arena type area.

Another point to remember at least with Quakespasm, it has the anti-flickering patch so if an entity exceeds MAX_ENT_LEAFS, the server will always send it. So testing in Quakespasm, large bmodels that exceed max_ent_leafs will always render, and it'll look like VIS messed up but it's just a server quirk. 
So testing in Quakespasm, large bmodels that exceed max_ent_leafs will always render

Yeah, I wasn't trying to draw attention to the bmodels.

Although those aren't Quakespasm screenshots Mark V uses the same mh/spikey solution. 
@kreathor. Mark V supports external vis which allows, for instance, true transparent on id1 maps without vispatch (files on the Mark V page).

Mark V supports sv_cullentities 2 -- which on poorly vised maps can cut-down on network traffic substantially and (sadly) increase rendering speed.

sv_cullentities from essentially borrowed from FTE (although I may use R00k algo?) and DarkPlaces has a similar feature.

It also has r_lockpvs and r_lockfrustum borrowed from DirectQ which mh said he borrowed from Quake 2. 
Cull Brushes 
I think I mentioned before that there should be some kind of brush that mappers could place that allows more freedom over culling.

Unreal Engine used to have "visibility culling" that you placed a brush to give hints for vising purposes. Maybe Quake has something similar (is this how hint brushes work??). 
I would assume that if they're supported at all, hint brushes work like described here:

I do wonder if using such brushes would improve maps... It's another layer of work on top of what is already required but with some bigger maps it could be worthwhile. 
Mark V supports external vis which allows, for instance, true transparent on id1 maps without vispatch
Thanks, I'll have to check this feature out

I do wonder if using such brushes would improve maps... It's another layer of work on top of what is already required but with some bigger maps it could be worthwhile.
If you do it correctly then yes. Problem is if you have big open spaces, then it won't help you much... although in my case I used it to cut portals behind big building standing in center of open space.

I like this "tutorial". Explains it properly: 
What did more modern engines such as Source do to improve their VIS? Half Life 2 has plenty of huge open spaces that run well. 
Half Life 2 (Source) is using PVS and occlusion culling for outdoors. 
So how is PVS (Potentially Visible Set) different from VIS? The Valve Dev wiki describes PVS as a collection of visleaves which might be visible from a given location. Isn't that just how VIS works? 
VIS is just a tool/process of creation of PVS, so to be 100% correct with nomenclature, we shouldn't use it to describe PVS ;)

Anyway we are OT a little, maybe we should move with this conversation to Mapping Help, before Baker gets mad :P 
Source Engine 
For the curious:

By the way, Source uses vvis.exe. 
Old Mirror Control Complaint 
I needed to look at a modified FvF player model in a mirror today, but could not do so because Baker took away the mirror control from the user....

"The Id1 Mirror Texture Only Works With Id1 -- It's Intended Behavior
if someone is playing Soul of Evil or Travail or something and some random texture is pointlessly a mirror because it is window02_1, that would be annoying as hell ... "

But r_mirroralpha is a user-controlled variable, and if a user wants it on, it should be on, no matter what mod they are running. It should also be defaulted to "off" ("1"), so if it IS on, then it's definitely intended to be on.

I had to load up FTE to look at myself in a mirror in FvF, and even that engine wouldn't let me activate it in Multiplayer mode, telling me it was a cheat. Boo! (I'm the server operator -- I am the one who should decide what is or isn't a cheat on my server, and I don't feel mirrors are a cheat). But at least I could use mirrors to look at the modified player.mdl in FTE Single Player mode.

I dislike when engines decide for me what settings I am allowed to use in what modes. 
I may end up coming up with a method to allow a gamedir mod to enable that as choice. 
Does Mark V supports scrolling textures? What's the name convention? 
Yeah, type "find scroll" in the console.

It's only in the GL build. 
sv_cheats 1; restart;
then you can do whatever you want.
and so can other users on your server, so have fun with that.
unfortunately nq doesn't do serverinfo, so that'll only work with an fte server.

use mirror_* for mirror textures in future. those should always be mirrors, and need not be considered cheats. window02_1 on the other hand is present on many maps, and in many of those it potentially exhibits serious graphical glitches that allow it to act as a wallhack or whatever. so yes, its generally considered a cheat unless the mapper explicitly intended it.

for similar future needs, you might want to consider using chase_active or equivalent (most engines support it to some extent), or maybe try fte's splitscreen.
its generally easier to look at it from other angles then. 
His server coops existing maps. He doesn't have any choice in what the texture names are so he doesn't have the option to change the texture names to mirror_ * 
I've tried to test it by entering "r_texprefix_scrollx wizmet", but it didn't work. I'm using the version 1.36. 
That feature was slated for removal, looks like is broke. I probably was working on mirrors and removed it, but forgot to nuke the cvar and friends.

It works in this ancient build binary + source.

The reason that feature is slated for removal is largely because:

1) I can't imagine a scenario where it could be turned into a standard.
2) This method has no ability to control the speed.
3) You can do animated textures in maps using the +[texture name] animated textures method in regular Quake and it works on everything, although it is jerky and has a 10 frame limit.
4) Low interest in porting scrolling to WinQuake, hehe.

There's also probably better ways to do it too.

Was a nice experimental feature back at the time, I just wanted to see what it would look like. 
Retroquad uses the [ and ] characters to prefix parameters for scrolling.

[ is negative
] is positive

The first of them in the texture name indicates horizontal scrolling. The second one indicates vertical scrolling, and it's optional.
The second one must be followed by a number indicating the speed. The first one only must be followed by a number if the second one is omitted.
If the speed value is omitted in the first one, both will use the same speed:
]1 horizontal scrolling, 1x speed
[1 horizontal scrolling, -1x speed
]0]1 vertical scrolling, 1x speed
[]1 diagonal scrolling, -1x horizontal & 1x vertical speed
]1[2 diagonal scrolling, 1x horizontal & -2x vertical speed

Retroquad's texture naming parser can also recognize parameter prefix characters anywhere in the texture name, allowing for multiple effects to be combined. The water in this video uses 20 textures named from *watersa]0]1+00 to *watersa]0]1+19 . The parser reads it as:
*water it's a water texture
sa the texture's individual name
]0 zero vertical scrolling
]1 horizontal scrolling at 1x speed
+00 to +19 animated frame index

The only thing I couldn't decide is whether the speed value should be in units per second or in loops per second. In the first case, big textures would need big numbers to fully scroll, and in the second case, small textures would need fractional numbers to scroll slowly. However, the first case also makes it easier to sync multiple scrolling textures with different dimensions.

The reason for all these is to make texture naming as economical as possible while still being flexible, since vanilla Quake only allows 15 characters per texture name. 
4) Low interest in porting scrolling to WinQuake, hehe.

Getting it to work properly in the software renderer takes a lot of work, so it's understandable.

A cheap way would be to scroll the texture per-texel in the surface cache. WinQuake uses a similar method to scroll the sky overlay, which is why its movement is so jerky. This would only look good on fast scrolling textures, but at least it would work. 
Your video certainly looks very nice. 
By the way, Retroquad animates sky & liquid texture frames at 15 fps, rather than the default 5 fps of regular animated textures. Alphamasked "fence" textures are animated at 20 fps. This was hardcoded just for that demo, but a standard for custom timing of texture frame animations would also be a good thing.

However, the 15 character limit for textures makes it a pain to add more customization. The name "*watersa]0]1+19" is 15 characters long already, and even if we remove the "sa" characters from it, there would be no room to define a 15 fps interval, which would require a special character plus two numeric characters (e.g. *water]0]1+19,15). 
By the way, sorry for hijacking the thread, but I'm just trying to encourage more coders to implement such features, and maybe define some standards for them. 
Engine issues and engine support of mapping enhancements are always on-topic. Not sure what you are apologize for.

Your results look nice and are smooth.

It seems wrong to put the timing in the text name, yet with Quake we do water, alpha masking, animated textures, etc. by the name .. so ...

The naming convention you are using seems quite sensible. 
In my config file, I use:

r_texprefix_scrollx z_exit

...just for the nifty effect (scrolling EXIT signs).

Though in some places where the mapper uses the texture somewhere else (like the start of terra4) it looks... odd. Like only the fullbright part is scrolling, and not the rest of the texture. Not that I'm complaining -- I like experimental features to play around with (as long as they default off!)

And yeah, I used chase_active, but I wanted to see myself from the front too. Mirrors were (well, they should have been...) the quickest way for me to do that, heh. I did not know about the various FTE features (splitscreen, eh?). 
Oh, something else....

I found that my player.mdl in \fvf\progs\wasn't even loading in Mark V, because there is a player.mdl in the fvf pak0.pak file.....

But the replacement player.mdl did load in FTE when running FvF.

I believe, no matter what the original default was in this case, that if a user has replacement content in a folder, unpacked, it should override anything in a pak file.

FTE seems to have made that choice, and it's a good choice.

I remember the complaints about "toxic settings" in an autoexec or other file inside a PAK file, and how that completely takes control away from the user (and placing those settings inside a pak is like the worst case scenario). Well, giving preference to any unpacked files, rather than what's in a pak file, would fix that issue too.

It seems obvious that if a user places some files into folders in their mod/id1 directory, they want to use THOSE files rather than anything that might be in a pak. And a pak is the hardest thing for a user to actually modify... so it's hard to work around. 
If You Don't Like Mushrooms, Don't Order The Pizza With Them ;-) 
Is your current mission to make FvF no longer work with traditional style engines?

If you want the best of both worlds, do what Arcane Dimensions does and simply not use pak files at all!

Then you won't even have the issue you are describing, haha ;-)

Do you see what I mean? You are mixing pak files and free standing files, but no one is making you use pak files at all! That's a choice.

The logical thing is to not use pak files if you don't like Quake's loading order.

Sock never has this problem because he doesn't use pak files.

All you have to do is make a FVF2 folder with everything unpacked, and you can play around as much as you like.

You could be living the high life in 5 minutes! 
It's not an FvF issue. It's a Quake issue.

The same problem exists if someone wants to use a replacement model in their id1 folder. The pak file overrides the unpacked replacement stuff, and that's not what should happen, because if a users puts a new model in his id1\progs folder, he WANTS to use THAT one. Why make it more difficult for him?

Would your suggested solution here also be to unpack all the id1 pak files, then remove the pak files, so only the unpacked files exist in id1, so a user can then use replacement content?

Or make them run a separate mod just for 1 replacement model?

What a hassle. FTE does it correctly, in my view, and allows the user-content to take precedence. Can you explain why is it better for pak files to take precedence? They are the most difficult for the user to modify. I can understand why they may have made it that way back in 96 -- maybe they didn't want the user to be able to easily mess with Quake.... But we are way beyond that now. People created programs to get to the goodies in those pak files. There's no reason to make it so difficult anymore for people to drop in replacement things.

When a mod has a lot of files, sticking then into a pak file is the most convenient and tidy way for a modder to package the mod. If a modder chooses not to do that, it may be for the very issue I'm describing here!

Of course a pak file does take control away from the user, though, which is mostly fine, because that's what mods do -- they change stuff. But then if a user WANTS to change something himself, it would be nice if he could easily do that -- like in this case, if he just wants to replace a certain model by dropping it in (a player created a new player.mdl just for FvF).

In summary:

giving precedence to unpacked files
pros = More convenient for the user to drop in replacement content. Protects against toxic settings in a pak file overriding user cfg files.
cons = None ?

giving precedence to pak files
pros = None ? Slightly helped id keep Quake from being altered back in 1996?
cons = prevents easy drop-in replacement content. You have to use a new pak file instead. If a mod contains toxic settings in a pak file, there is no way to prevent them from being initialized.

Am I missing something? 
If files in a folder override pak files, why have the pak files at all?

Quake for 20 years has had pak files have the precedence.

FVF is fully under your control. If you don't like the behavior of pak files, do them free standing files like Arcane Dimensions.

Arcane Dimensions, because it uses no pak files, doesn't have the issue.

If you don't like the behavior of pak files with your mod, then don't put the files in a pak.

1) Doesn't require anyone to do anything.
2) Compatible with every engine! 
...Quake for 20 years has had pak files have the precedence...

To me this reads as:
...Quake for 20 years has done things the wrong way...

It seems pretty obvious to me that whatever is included with the game (pak0.pak, pak1.pak) should be overridden by any new content.

It's 100% true that if you really want to solve this problem in your own mods which use their own folders, you should not use .pak files. There's no changing the way that some engines will behave at this point.
But why make using them so difficult in engines which are under active development? pak files keep things neat and make it harder for unwitting users to break your mod and so on, but the penalty a mod author incurs when using them is unnecessarily great. 
Where do you stop?

DarkPlaces loads every single .pak file found in a folder. And loads .pk3. And loads the pak files in alphabetical order. And supports a rainbow of file format from .tga to .jpeg to .png and probably others like .dss. And a rainbow of model formats.

Others want things simple.

Like the Quake way. 
Spike will say with pride that FTE loads external replacement textures from, I believe, 132 different possible folders -- supporting all the various replacement texture schemes. There are also different replacement model schemes.

A conservative engine wants 1 folder where something goes and one set of rules where that set of rules = QUAKE.

There isn't a right or wrong. Just an approach.

A conservative engines wants to stick with simple. 
It's Quake.

For every one person who wants something done one way, there's going to be five others who want it done five different ways.

The only thing you get by asking multiple people is multiple answers.

The closest thing to any kind of community consensus is "do it the way [Popular Engine X] does".

Gunter in particular has a very bad habit of "what I want for my mod is more important than anything else", then causing drama and outrage over it. I'm not certain that's useful feedback.

Quake already has an established way of allowing standalone content take precedent over pak files - put it in a gamedir of it's own. Multiple gamedir support is trivial to add to engines (and far more useful than arguing the toss back and forth over things like this).

A general-case solution that's more useful to everyone is always better than a special-case solution that just keeps one person happy. 
The PAK file precedence is part of Quake's copy protection. One of Quake's selling points was: if you want to play custom content, you must buy the game.

PAK0.PAK has its CRC value verified by the engine. If the proof-of-purchase file (from PAK1.PAK) isn't found in the path, Quake refuses to load anything but the unmodified PAK0.PAK file, which contains the shareware episode.

The PAK file precedence also served to prevent users from creating custom maps using the same names of the original maps and complaining that the original maps didn't work anymore... And to prevent users from going full "FreeQuake" and replacing the episodes 2-4 with custom maps.

id Software already had people selling shareware Doom CDs full of custom content, and they decided to prevent that from happening to Quake. 
Cracked Quake Torrent When? 
Is there any particular reason why this behavior should be continued today in engines, aside from respecting id's desire to, y'know, actually sell a game and make some money from their hard work? In the modern world of filesharing, it's such a lackluster form of copy protection that it may as well not be there at this point. 
DarkPlaces has its own set of special rules for content, which you have to learn. Many modders for DarkPlaces struggle to make Quake compatible mods because they have habits that don't work with Quake. 
(you Knew This Was Coming! :D) 
"Where do you stop?"

You stop at making unpacked files take precedence over pak files. That's it. Don't use a fallacious "slippery slope" argument like, "but if I make a reasonable change, then I'll also have to make every unreasonable change everyone else wants!" This has nothing to do with supporting all the formats Darkplaces or FTE uses. You still haven't explained the benefit of leaving it "the way Quake has done it for 20 years?" That's not a reason. How many other non-optimal Quake behaviors have you already changed?

"It's Quake. For every one person who wants something done one way, there's going to be five others who want it done five different ways."

Well, so far you've got more than one person wanting unpacked files to take precedence, and NO ONE wanting it the other way, other than people just saying, "that's the way it has always been" without providing any benefit for that approach.... How many other non-optimal Quake behaviors have you already changed?

Will anyone step forward and say they prefer pak files to take precedence, and give an actual functionality reason for that?

"Gunter in particular has a very bad habit of 'what I want for my mod is more important than anything else', then causing drama and outrage over it. I'm not certain that's useful feedback."

Oh, bite me, mh :P

I just said this isn't an FvF issue -- it's a Quake issue. This would be better for everyone. I have laid out my actual arguments for why, and you have not provided a single counter argument to support your position other than, "I don't like when people want different things and I don't like Gunter because he always out-argues me" ;)

"A general-case solution that's more useful to everyone is always better than a special-case solution that just keeps one person happy."

I completely agree with you, mh! But that supports my (and others') position in this case that the behavior should be changed, because it would indeed be a general solution that would be useful to everyone!

I am dramatically outraged that you would think otherwise!! :D

Can you explain who it's useful for to leave pak file preference in place? Modders who want to inflict unavoidable toxic settings on the user?

I'm aking the same question as Pritchard here, "what benefit is there to keeping this behavior?"

Nobody is answering except to say, "it's always been that way and I don't like the complicated things Darkplaces does."

We're not taking about Darkplaces. We're talking about this ONE behavior. That's where it stops (in regard to this issue). This isn't a change that's going to cause any compatibility problems either....

Please describe the benefits of pak file preference. mankrip did a pretty good job of describing the benefits id saw back in 1996.... Now what is the benefit in the modern day? Isn't the whole point of engine development to improve on the original things that might not have been optimal for the users? I mean, why didn't we keep id's original network code? ;) Would it still serve any useful purpose today, or would it just make things more difficult for the user?

In regard to why I, as a mod author, use a pak file to distribute the FvF client files? Because it's the most tidy, convenient way to distribute a mod, instead of using multiple files and folders. AND it also keeps the user from easily being able to nose around in the files to swipe them for their own use! Heh. So yeah, a pak file still serves as a slight (very slight, really) deterrent for pillaging my content, however, I don't mind if the user wants to use other replacement content on top of mine, and I see no reason to make that a difficult process for them.

Again, this isn't just for FvF -- it's for anyone who wants to use replacement content for Quake with or without mods.

If you're looking for some form of consensus, why not run a poll on Quakeone? Then maybe someone would give an actual functionality reason for preferring pak file precedence.... 
You are new to a discussion about this topic.

I've read or even participated in this same exact discussion 6-8 times, including a couple of times at Inside3D and a couple of times at QuakeOne.

I used DarkPlaces before I ever engine coded and experienced firsthand the pros and cons of the functionality. I also like DarkPlaces as a total conversion engine and both Mark V, and before it, ProQuake acquired several gems from DarkPlaces.

It is safe to say my opinion of that DarkPlaces feature is due to knowing a lot about it works.

Typically, the those arguing for the DarkPlaces way of doing things is inexperienced with using the the feature, and unable to describe the downsides because they don't have the experience to understand the other side of the coin.

And perhaps I'll try to explain again. But probably not today.

Seems like no one is reading or making an effort to understand what I am trying to communicate in my replies.

I may be typing this post just "for fun" as it seems the other ones went unread.

But I hope it does get read ... 
OK, I'll bite.

The upside of having loose files take priority is that the user can easily replace PAK file content.

The downside of having loose files take priority is that the user can easily replace PAK file content.

Think about that - and if you don't have a Zen moment when it becomes clear, you haven't thought about it enough, so think about it some more.

This isn't just about copy protection, it's also about protecting users from malicious (or just plain old badly designed) mods and from themselves.

Whether you like it or not, the way Quake has done it for 20 years is the EXPECTED behaviour. Mods are made and released on the assumption that this is the way it behaves, experienced players run Quake on the assumption that this is the way it behaves, experienced players help out struggling newbies on the assumption that this is the way it behaves.

If it's in a PAK file it takes priority. This isn't about advantages of one vs advantages of the other. PAK files taking priority may even be the inferior option but that doesn't actually matter (I have an opinion too but it's irrelevant). It's about what everybody expects to happen.

You may have a different expectation but don't be so arrogant as to presume that your expectation should overrule 20 years of everybody else's experience. 
The way Quake works, if you have a mod with a pak0.pak in the folder (let's say -game zer) you have 100% assurance the mod will behave properly.

With the DarkPlaces way, a user will say "I don't know what is wrong? I have pak0.pak in place, but some weird model is showing up!"

Later they will say ... "Oh, sorry. I was doing XYZ and forgot to delete it."

The DarkPlaces way takes away the security of knowing a pak file containing a mod is a complete and full assurance of proper installation and running. 
I should add.

I do understand your frustration to a certain extent. I am the person who fought, and lost, the stuffcmd wars a few years ago, and stuffcmd is actually potentially dangerous to your PC, never mind just being a squabble-fest over file loading order. 
just stop using paks. you complain that paks taking precedence makes it hard for users to replace files, but you forget that any paks make it hard for the user to know which files they need to replace (and the form of that data too).

that's not to say that I agree with Baker, frankly I see his argument as user-hostile that further discourages people from grouping their content thereby making it MORE likely that people will be stuck with content that they forgot to delete on account of not being able to separate it so easily.

quakeworld downloads often REQUIRE files outside of paks, or at least maps.
The singular exception is when you have md3s or q3bsps that depend upon shaders and external textures that the client won't know to auto-download. In these cases, pk3 is a superior format that offers compression and is easier for people to open. Essentially, such content should be treated basically like q3 content is treated. But until then, just don't use paks. 
PAK files also serves as a versioning system.

If your mod is fully contained in a PAK0.PAK file, you can make an update for it by storing the updated files in a PAK1.PAK file. And then, you can revert to the previous version by simply removing the PAK1.PAK file. I've actually done this in one of my mods, because it gives the advantage of knowing that the PAK0.PAK will likely always be the same, no matter the version of the mod.

Loose files doesn't use a cascaded versioning filesystem, so they require you to remove all previous versions of the files, which makes it impossible to rollback a bad update.

Anyway, a command-line parameter to control the precedence could be nice for development purposes. 
Why Is This Getting So Much Attention? 
Clearly it makes no sense to change this behaviour except to keel to the whim of a single individual. 
We are reading what you write, Baker, but you're just talking vaguely about Darkplaces. I don't use DP. I just happened upon the functionality in FTE, and I liked it -- actually, I didn't even realize it was different; I just knew that FTE did exactly what I wanted/expected it to do -- it used the player.mdl file that I dropped into a folder.

Now you're saying that pak files are good because they let the modder know 100% that the mod will work for the user, but you've previously been talking about how Arcane Dimensions installs everything unpacked, so it doesn't have the issue of pak files overriding user content.... It's like you're telling me I should do it two different ways! Why can't I have both the convenience of putting my mod files in a pak to ensure easy/correct installation, and also have the ease of letting more tinkery users drop in their own content if they want to?

Sure, they might mess things up, but this is the same issue as any other piece of software you give to a user. The user might mess things up. If they do, they can just delete and re-install the thing....

What I'm now hearing from you and mh is, "protecting the user from himself."

Like if the user installs some replacement content, then later derps out and forgets he installed some replacement content, and can't figure out why there is replacement content in his game....

Would not the same thing apply if he were using extra pak files?

Is Quake 1 really a game for derps? Is that the kind of user you are designing Mark V for?

Everyone derps out sometimes, but unpacked replacement content would still be easier for a derp to find/remove than stuff in a pak file, because it's all easily visible unpacked. In a pak it's hidden.... "What is this pak4 thing I have in my folder? I do not know. And why is my player model so weird?" vs. "What is in this progs folder? Oh, there's a player.mdl in it. Oh! That's why my player looks so weird!"

So, mh says for both pro and con, "it makes it easier for the user to change things."

I don't know why you're not having a zen moment about that yourself.... You strike me as the kind of person who would use linux because you'd hate Microsoft always "protecting you from yourself" and not allowing you to change things you want to change.... This reminds me of an old commercial:

So do you think it should be easier or harder for a Quake user to change things? Apparently "harder?" So you're a Windows guy, eh? :D

(I'm actually a Windows guy myself, but I'm a superhacker, so I make it do what I want ;)

Ya know, the whole reason that Quake is still alive after 20 years is because it was relatively easy for users to modify stuff.... Zen moment? Should it be easier or harder for users to modify stuff in Quake?

You also throw in that it's about protecting from malicious/badly designed mods... Uh, isn't that backward? Unpacked file preference would help protect from bad mods, because the user could easily see/change unpacked files or replace stuff in a pak file with their own stuff (a bad autoexec in a pak file, for example).

As far as "expected behavior," well, it's "expected behavior" (how it has "always" been) that you must put the Quake CD in the drive to play the soundtrack. But now we can drop mp3 files into a folder and play the soundtrack.... That "expected behavior" was changed to make it easier for the user. This is the same concept: let the user easily drop in files for Quake to use. Should we not allow that because some derp might drop in the wrong mp3 files and then wonder why Ace of Base is playing when they start Quake? :D

And I have to ask, "expected behavior" of whom, really? Certainly not any new players, or other people who have never messed with this stuff in detail. Heck, I don't regularly mess with it in detail, and I actually expected a player.mdl to be used just by dropping it in a folder! Then I was like, "Wait, why is this not working? Oh crap, the pak file overrides it."

So I ended up having to stick my single replacement model into a pak file.

What a hassle. I can't imagine that's good for anyone, no matter what they expect.

And being that many experienced users will be using other engines like Darkplaces and FTE, well, their "expected behavior" would not conform to the 20-year-old way either.

So maybe some old Quakers are "expecting" it, but I bet if you gave them the option, they would prefer it to work in a different, more convenient, way.

Actually, Baker, if you have links to the multiple discussions of this issue you've had in the past, I'd be glad to look them over to see what else I may be missing.

mh, I'd probably be against you on the stuffcmd issue, heh. It is a useful tool for modders -- aure, abuse is possible, but I use it to bind the FvF chat impulse so players lower their gun and blow smoke while chatting. But I think Mark V has some cfg protection for stuff like that. 
"just stop using paks."

Sounds so easy, but in practice that means I'd have to completely unpack my id1 pak1 and pak0 files. That's a mess of files! (I'm not just talking about my mod, but every mod with a pak, and also standard Quake.)

And just because I might want to use a replacement player.mdl ?

Heck, it's actually easier to complain a lot about it and hope Baker might consider changing it ;)

(But really, it's not just to make things easier for myself, but for other people as well). 
Low Brow Vs. High Brow @spike Mostly 
There are low-brow engines and high-brow engines.

Low Brow Engine - Your TV remote has 4 buttons (Mark V)

Favors an uncomplicated and reliably smooth and enjoyable experience and will sacrifice options, capabilities and preferences to get there.

Assumes the user knows nothing, has guard rails. Caters to the user that knows nothing -- protects them. Most features are obviously exposed, few features beyond core feature set.

When no one has any questions or problems, the Baker feels like "Mission Accomplished!" It's reliable and intuitive!

High Brow Engine- Your TV remote has 106 buttons (DarkPlaces/FTE)


Caters to advanced users. Plenty of settings. Plenty of capabilities. Support for cutting-edge techniques. Boundless depths, options, abilities.

Assumes the user knows everything and caters to the user that knows everything. Has layers and layers of features beyond the obvious ones.

When a user has something sophisticated they want to do and realize that FTE can do it, Spike feels like "Mission Accomplished!" It helped someone with sophisticated needs execute their idea!

(This is why Spike and I seem to argue a lot about some things, but agree about others.) 
"Clearly it makes no sense to change this behaviour except to keel to the whim of a single individual."

Uh, no.

I've laid out clear, concrete reasons why it "makes sense," which have nothing to do with my whims.

And I'm going to count at least 3 people here that might prefer it the way I am advocating for. Make that 5:

mankrip (for a command line parameter to allow the option)

And I will count:

(their creators obviously preferred this functionality)

You see me arguing for it, but I am arguing as "the user" and not just for myself. This would make it easier for every user.... It's just that every user doesn't read this forum. Do as I have suggested -- make a poll on Quakeone where there are more users, and see what everyone else actually thinks. 
Count me in with mankrip re: the command line switch to change the behavior. Why not give the user the option? I don't see the downside. 
I hadn't really considered the "versioning" aspect of pak files, but it certainly does make it easier when, on the rare occasion, I update the contents of the FvF client pak file, to know that all the user will have to do is replace their pak file with the new one and they will be correctly updated. If I were handing them the mod as unpacked files, that could be messy and tricky if I ever removed some of the files.... I'd have to give special instructions to delete certain files during the copying of the new files.

So that's another reason why I use a pak file for FvF -- easier/more foolproof updates for the user.

And I too would be happy with a variable to alter the file/pak precedence. That would still make it easier for people, because I could tell them, "you need to set this variable to let your replacement model work correctly." 
A command line option doesn't seem objectionable. I'll consider it without making a promise as to when.

So it is very likely to happen, unless it somehow interferes with something else. Which doesn't seem likely.

Having the option available would be nice, there are sometimes it is nice to change things on the fly easily.

I just don't like that as normal default behavior. 
Excellent. Thanks for considering it.

I'd also hope it will includes a console variable for easy setting, even knowing that would be something like, "this setting will not take effect until you restart Quake/the map/whatever is required."

I wouldn't dare suggest a menu setting, knowing how much you hate menus ;)

But then again, a menu setting would make it easy for the low-brow derps who Mark V is intended for!

*Throws an FvF ninja bomb and runs away* 
I Wouldn't Have Submitted 
I'm disappointed Baker. 

Nice denial of service you have going there.

You see Gunter - you need to think beyond what you immediately want. 
Yes, I already agreed that abuse was possible. I just said so.

But do you remove all the potential valid, good uses of the command because of hypothetical bad uses? (Has your example ever actually been used in a mod?)

Hey Baker, I think mh is asking you to prevent screenshot from being used in a stuffcmd!

Mark V already protects your cfg file getting messed up by stuffcmds.

I can't think of a legitimate reason to allow stuffcmd screenshots.... So that's something that could be prevented.

But removing the whole stuffcmd functionality would be throwing out the baby with the bath water. 
There's no simple way to implement a cvar for it, because config files are only loaded after the filesystem is initialized. It's impossible to make a cvar change the filesystem initialization behavior.

Now, if such a cvar would be used to change the filesystem behavior on the fly, that would open a can of worms, specially on engines that supports changing the game directory on the fly: Set a mod dir, change the precedence, and add another mod dir; the precedence of the previous paths gets screwed. 
And that's why you wouldn't make a good engine coder.

In the end, Baker is interested in improving his engine for the users, and not just winning an argument for the sake of winning an argument.

Actually, that's why I post here too -- not to "win arguments" but to improve Mark V for the users, of which I am one!

My ideas of what might be an improvement may not be the same as other people's ideas, so we argue about it, but it is not personal, not even with mh for me (he's done great things for Mark V), though sometimes I can't tell if he gets caught up in just wanting to win the arguments or not ;)

In the end it would be silly to stubbornly refuse something that several people are stating a preference for, if the only reason is "don't give in to Gunter." Baker is not that petty!

And I'm certainly glad other people do speak up to state their preferences here, so that mine is not the only voice. 
I Dunno Man 
It's not about whether I would make a good engine coder. I probably wouldn't but not for the reasons you gave.

It just appeared, from an observers POV, that you basically bullied and harassed Baker into adding a feature after he gave you plenty of well-reasoned answers as to why it wasn't a good fit for the engine.

I mean, I have asked him to include stuff from time to time but I am in awe of the relentlessness of your stubborn pleas.

Maybe I am just better at taking no for an answer. 
There were wins here.

Gunter did argue annoyingly hard.

Then again, he did eventually suggest a viable solution -- which no one has ever done before -- in the idea of making off by default but with ability to opt-in.

mh signaled he had complicated feelings on the subject and I've used DarkPlaces before for some deep modding where the functionality was helpful.

I've also seen DarkPlaces beg and scream for help because they messed up something so terribly bad and no ones wants to reply to them because usually it's a super-newb who barely can find their Quake folder so they get the "leper treatment" or insightful advice like "delete your Quake and reinstall".

So ... I think I'll have a beer and hope to laugh about this in the future. ;-)

/Gunter has found some very, very obscure bugs in the past. And spotted inconsistencies few would notice, allowing them to be resolved. 
You surrendered like a Frenchmen! D:< 
"Gunter did argue annoyingly hard."

I do everything annoyingly hard!

(That's what she said!) 
Fifth's joke was better. 
I shall prepare a PowerPoint Presentation to prove it was not.... 
Is 64-bit Linux support coming? That would be awesome. 
There is a Linux version available on the Mark V page for those interested in provided feedback and willing to experiment.

A few people have said it works very well. One person had some audio issues with their sound system. Tested on Ubuntu, told it works fairly nicely with Debian.

Your mileage may vary. 
No makefile for linux. :( 
I may have missed something in the avalanche of posts, but when Gunter started talking about having to unpack the id1 pak0.pak and pak1.pak files I started to wonder if there's a fact being overlooked...

The pak file precedence over loose files only applies within a game directory, right? I believe it is the case that a loose file in a game (mod) directory takes precedence over any file in id1, regardless of whether the id1 file is in a pak or not, correct? Is everyone on the same page about that? 
Post #874 has compile instructions. 
@ Johnny Law 
I believe you understand correctly how it works.

But say you want to only replace the player.mdl when paying standard Quake... with the one contained in this pack:

That becomes rather annoying to do, since it's not as simple as just dropping the replacement model into progs\id1\, because the pak file will override it.

So you end up having to create whole new "mod" folder just to use one replacement model, then you have to create a batch file to run quake -game whatever, or you have to type "game whatever" in the console if your quake engine supports it....

What happened with me is that a player took that model and applied the FvF skins to it, so I wanted to try it out. The problem is that FvF already contains a reskinned player.mdl in its pak file in my FvF mod folder.... So again it was not so easy to just drop in the player.mdl and try it out.

So Spike suggested "stop using pak files" and that's why I described having to unpack the id1 pak0 and pak1 files too, because even if I'm not playing FvF (or any other mod with a pak file) I'd still have the same problem if I were trying to just replace the player.mdl (or some other model) for standard Quake. 
OK I'm going to try this one more time.

The way Quake has always loaded content goes like this:

- Gamedir 1/PAK files/Loose Files
- Gamedir 2/PAK files/Loose Files
- Gamedir 3/PAK files/Loose Files
- Etc.

(And yes, even stock ID Quake can load more than one extra gamedir; try -rogue -hipnotic -game XXX").

Here is the Quaddicted Single-player maps archive:

This is a repository of content all authored under the implicit assumption that certain Quake engine behaviours are consistent.

I say "implicit" because I'm absolutely certain that none of these authors (or at best very few of them) ever sat down and actually thought about this. But nonetheless the assumption is there, so please don't try to play silly buggers about it.

Change the content loading order and do you know what is going to break in those maps? Because I sure as hell don't. So they'll have to be tested, somebody's going to have to go over them and check that there's nothing in them that breaks.

What you have is one case, and it's not even a gameplay case - it's a test case. And you're behaving as though you believe that one case should take priority over everything else. You're jumping up and down shouting "I WANT I WANT I WANT" like a child, and not showing any awareness whatsoever that there is a whole body of existing content and Thou Shalt Not Break Existing Content.

One test case in FvF does not get to take priority over the body of existing content.

Feature requests are always more likely to be listened to and taken seriously if the person making the request gives some indication that they've thought it through and that they understand the implications. I'm not seeing that from you. 
I don't think anyone has put much thought into that compatibility angle before.

Considering the volume of single player releases, it would require an enormous amount of effort to find the ones with conflict situations. 
This is the kind of thing I've been bitten by before.

Even what seems like quite simple changes, say something related to behaviour of the viewsize cvar, can explode spectacularly if a mod uses it in an unexpected manner.

I think the key phrase there is "in an unexpected manner". The definition of an unexpected manner is that you actually cannot predict in advance what the impact is going to be, so it's no good someone asking for a list of disadvantages to a proposal.

"When in doubt do what ID Quake did" is a good maxim for certain classes of changes. With the SP community having converged around FitzQuake and derivatives, "when in doubt do what FitzQuake does" is also a good maxim.

We're not just talking about engines either. I've seen enough content made with buggy tools that just happens to work because engine behaviours or quirks accept it. I've been in a "put the bugs back" situation more than once.

The onus is on the person asking for a change to demonstrate that the change is benign, or at least that's the way it should be. Changes to very fundamental behaviours of core subsystems should always be approached with extreme caution. 
Ok, I see it is IS personal for mh. I think he just dislikes me because I consistently out-argue him. Well, he's going to like me even less after this.

mh, you are just being a crybaby now, but let me address your actual "arguments."

"The way Quake has always loaded content"

Yes, that's been pointed out repeatedly. But as Pritchard said, that's like saying, "Quake for 20 years has done things the wrong way" Or, if not strictly "wrong," then certainly in-optimal.

"Change the content loading order and do you know what is going to break in those maps? Because I sure as hell don't."

I do know: Not a single damn thing. Nothing. Do you know what kind of contrived situation would have to exist for the loading order to break map packs? The mod would have to install both a pak file AND unpacked files with the same names, yet with the files in the pak being the only ones that are supposed to be used, because for some reason the unpacked files with the same name are not the same files....

Seriously, HOW ELSE could the file load order mess up a map pack? You probably can't even come up with a realistic situation where it would, without your user do really weird stuff (which could happen no matter the load order). Maybe if the map installs as a pak file in your id1 folder and you already, for some reason, have different maps with the exact same name unpacked in your id1/maps folder??

The fact that you don't see it wouldn't cause a problem except in an extremely contrived circumstances shows that YOU are the one who isn't thinking this through.

Your flimsy argument amounts to trying to whip up fear of a boogeyman which would never actually occur unless you intentionally tried to make it happen. "But something might break! You just don't know!! Think of the children!!!"

You're grasping at straws.

Seriously, are there any maps/mods on Quaddicted that say, "this will not work with Darkplaces or FTE for some reason"? No? I'm not surprised.

"What you have is one case, and it's not even a gameplay case ... One test case in FvF"

Uh, no. I said it could impact anyone playing any mod or standard Quake if they wanted to easily use replacement content. I've pointed that out repeatedly. Do you not comprehend?

"Not even a gameplay case?" What? This isn't some hypothetical thing I came up with out of nowhere -- I never would have brought up the issue if it had not IMPACTED MY ACTUAL GAMEPLAY. Do you not comprehend?

You characterize me as crying like a child, but it's you, mh, being the crybaby. You're just being ANGREH. You don't have actual good points to support your position -- just hypothetical boogeymen which it's clear you didn't even think through (or you would have realized how ridiculously improbable it would be to actually break any of the maps from Quaddicted).

"When in doubt do what ID Quake did"

See, that's rich, because in the past when I have argued for using Quake's Default Behavior instead of some change Baker has implemented (centerprint position, or start map guessing), you have thrown the same whiny bitchfit over it. So it seems it doesn't matter whether I'm advocating for Default or not -- you're just against whatever I suggest.

(Normally I like Default presentation to the user, but this is behind-the-scenes, to make replacements easier)

"Feature requests are always more likely to be listened to and taken seriously if the person making the request gives some indication that they've thought it through and that they understand the implications. I'm not seeing that from you."

I can only laugh at this :D

You're not seeing a LOT of things, mh.

So don't even worry about it. If some weird, obscure issue pops up because of this change, you can bet *I* will be the one to find it! I'm the one who has been finding the weird, obscure bugs that result from the changes Baker has made, because I have an extreme eye for detail and a meticulous mind for thinking on many different levels. So just because you "sure as hell" can't see what might beaffected, don't worry -- I can. ;)

Now, was any this necessary, mh? Nope. Baker already decided to leave the default behavior in place and add an option for the user to change tit. Yet you still felt the need to make a fuss and post at me with silly arguments and insults, because, apparently, you are a sore loser. And like FifthElephant, you just didn't want to see me get what I want.

Now, I normally do not post at people in such a demeaning manner as I have at you here, but this is certainly how I respond when someone insults me the way you decided to. So, if you don't like this, then refrain from making such petty characterizations of me in the future :p and then I will stick to addressing your actual arguments as I normally do.

Baker, don't let the "compatibility scare tactic" dissuade you from this -- you know if it produces any unexpected negative issues, I WILL find them! ;) 
mh is relating his experiences involving the development of DirectQ. He is not referring to you at all.

I watched some of the DirectQ users "carp" on mh with insisting DirectQ must do certain things.

Something unseen here is that very few engines end up surviving compatibility.

I could tell you things that crash qbism super8 hard. I could tell you things that don't work right in FitzQuake. I can tell you things that don't work in Quakespasm.

mh and I work well together because we view compatibility as #1.

/So please leave mh alone. I already said what I plan to do. 
Might add that I also know single players that have problems with Mark V's automatic impulse 12 support. If you are serious about compatibility, you know your own engine's weaknesses as well. 
Seriously, are there any maps/mods on Quaddicted that say, "this will not work with Darkplaces or FTE for some reason"? 
Remove: "single players"
Substitute: "a couple of (rare) single player mods"

/Premature submit strikes again! 
Now, was any this necessary, mh? Nope. [...] And like FifthElephant, you just didn't want to see me get what I want.

I wish someone wanted my naked body that hard. Now I'll feel jealous of Baker too. 
@Baker "He is not referring to you at all."

Ah, well, then I must have misunderstood when he used my name ;)

But it's no big deal for me, really. I approach internet arguments like a Quake Deathmatch: whether you win or lose, it's all for fun, and it's not worth getting legitimately upset over. :D

@mankrip Yeah, I guess I really should have specified I was talking specifically about compatibility with Darkpalaces due to the unpacked file preference is has. I have no idea about all the many other differences in Darkplaces, and what compatibility issues they may cause.

Actually (side story), I remember several years back I tried using Darkplaces for the FvF server, but I encountered compatibility issues.... I think I emailed LordHavoc about it, and it was something about either checkbottom or some other way to see if something was on the ground, and what I was doing in FvF wasn't working in DP. LH said that code never really worked right in standard Quake or something.... In any case, I went back to proquake server, and I don't know if the problem would have been fixed by now or not.

So yeah, I understand compatibility issues are indeed important, but "compatibility problems have been caused by other things" isn't a valid argument in this specific case. Do we never try to change/improve anything due to fear of incompatibility? No, but of course, we do tread carefully. 
"I wish someone wanted my naked body that hard."

Well, just make a quake player.mdl with a skin of your naked body, and it will be REALLY EASY for people to drop it into their game once Baker makes the setting available!

(And NOW I see the downside!! What have I done!??) 
Ok, now that this is all settled ...

It's June. It's great weather and sunny ... 
It may be sunny now, but not for long!

Anyone else going to catch that full eclipse in August?

It is passing DIRECTLY overhead for me -- I am right in the center of its path.

I guess all those sacrifices to Shub-Niggurath are having an effect! 
I'm in the southern hemisphere, and it's winter now; no snow, though. 
"But it's no big deal for me" - Gunter after 3 scroll pages of bitching.

Please don't include me in your diatribes either, I was poking fun at you light-heartedly. Baker clearly got this. 
Ok, got it. You are allowed to "poke fun" at me, but I'm not allowed to mention what you said. That's a reasonable expectation. 
Might be time to move this to the beef thread as Pritchard has suggested. 
It's not an "internet argument" though. You don't seem to understand that, but it's not. This isn't an argument where somebody wins and somebody else loses. 
Then I'm not sure what it's about for you, mh.

From your first post on the matter ( #1574 ) you decided to assault my intentions and motivations and mis-characterize me in a poor light.

Even on a side issue you felt the need to make it about ME rather than what I was saying ( #1595 ), but I continued to address the argument rather than the arguer.

Then after the issue was settled (Baker decided to leave the default as-is, but to add a setting to change it -- a win/win situation) you again decided to post and complain and VICIOUSLY assault my character and motivations.

THAT is the point it became an "internet argument."

Now, I want to clarify: only my last post was what I was referring to as "an internet argument" in regard to having fun winning or losing -- normally when I say "argument" I am using the formal sense of the word: arguments and counter-arguments and making points in a discussion. But an "internet argument" (I probably should have said "internet squabble" or something) is more like a flame war.

Yeah, at that point it's more about "winning," but if you look back up to my post #1598 you will see I said just what are you saying now -- the point of me posting here is not about winning or losing, it's about helping to improve Mark V (and this feature will be an improvement to Mark V). I even said in that post that it wasn't personal with you.

If you believe in your position, you make good, valid arguments for your position. You don't start questioning the character of the person who is not for your position.

Now, I am a Quake player, after all, so when you fire enough rockets at me, I will fire a BFG at you ;)

This was the FIRST time I have assaulted your character in all of these Mark V discussions, but it is certainly not the first time you have questioned mine and cast me in a negative light.

If you want to avoid this again in the future... just stop doing that. Let your (formal) arguments stand on their own without making it personal. If your arguments are sound, then they are sound and they should hold up on their own no matter who you are arguing against. So how about you stop casting aspersions on my character?

Anyway, it STILL isn't really personal for me, despite me firing a BFG at you.

So let's be friends! 
Theres A Reason Why The Quake Mod Scene Is Dead 
Hi, I'm using the Mark V 1.36 source port and when I enter the exit portal of Gloom Keep, the game often (about 5 out of 10 times) crashes back to desktop with the "Mark V has stopped working" notication. This happens both with the regular gl version as well as with Dx 9. Is this a known issue? 
I can't remember if I have it fixed in the unreleased version or not. I'm thinking it is fixed whenever the next update will be released (date unknown).

That was a fun mystery, engine coding-wise.

When you go through the exit teleporter on Gloom Keep, there is a world brush model that has never been seen before and isn't visible in that frame either, but due a mirror surface in the area, the model comes into visibility but hasn't been precached.

I have to assume that since I know so many details about the circumstance that I have rectified the situation in the in-progress version. 
Thanks for the answer. I deactivated the mirrors via the console command mentioned above and now it works fine. 
UI And HUD Aspect Correction 
Since this problem appears in a bunch of modern ports I will repeat my post of half-a-year ago

Quake is originally designed for 320x200 resolution to be run on 4x3 displays (just like Doom). This means, that whole screen should be stretched vertically. The original game nicely adjusts viewport so that actual gameplay window is always at true aspect no matter what resolution is set - 320x200 will look exactly like 320x240. But the UI is not. It is designed to be stetched, so it only looks right on 320x200 and 640x400 resolutions and is "squished" on every other.

So what's the problem? Mark V removed id's aspect corrcection and treat every resolution identically. Setting up 640x400 and 320x200 result in stretched in height gameplay window.

The ideal solution would be to add an option to make correct UI scaling. Here's some example shots of original winquake and Mark V scaled to 4x3 and upscaled 
Nice to mention this, it's one of the most overlooked things in custom engines.

But I'd like to add that Quake is actually inconsistent when it comes to video aspect, because the 3D renderer was coded for a 320x240 4:3 screen (square pixels), while the 2D renderer (and artwork) was made for a 320x200 4:3 screen (non-square pixels).

Doom's "3D" renderer was indeed coded for non-square 320x200 4:3 pixels, IIRC, because it didn't support other resolutions (before WinDoom). Quake was the first id engine with multiple resolution support, so it's quite poorly coded for it in some areas. 
I'd be cautious about how this change would look in a hardware accelerated engine. On the surface it seems easily achievable by just rescaling your ortho projection and 3D viewport by the appropriate amount, but there's gonna be a whole lot of edge cases with texture filtering that will need to be worked over. 
But I'd like to add that Quake is actually inconsistent when it comes to video aspect, because the 3D renderer was coded for a 320x240 4:3 screen (square pixels), while the 2D renderer (and artwork) was made for a 320x200 4:3 screen (non-square pixels).
the only thing is that it wasn't. original software renderer actually could do a valid 3D picture with virtually any resolution and pixel aspect, and if you choose 320x200 (640x400) you will get just right picture in every aspect (no pun intended) 
Milkey Wilkey 
The particle renderer, which is part of the 3D renderer, was explicitly coded for 320x240, with double height scaling for 320x480.

The underwater warp is also inconsistent across screen resolutions and was coded for a 320x240 video buffer, as explained in this standardized test. It also means that it's impossible to always get a fully aspect-correct image in ANY resolution in the original renderer, because while the HUD only displays properly in 320x200, the underwater warp's waves only displays properly at square-pixel screen aspects (320x240, 512x384, etc).

The original software renderer is not consistent even across multiple HUD sizes.

The software renderer also screws up skies and particles when the FOV changes.

But most people never pay enough attention to notice all the problems in the renderer. 
I... uh... um.. er.... :u

Ok, yeah, I'm bringing up the contentious topic that we just put to rest, but bear with me... you will NOT see the ending coming!

Ok... So, I was considering what mh was saying about "expectations" that people supposedly have about the loading order for content like models, in regard to the pak files vs unpacked files having preference (default from original Quake is pak).

Previously I pointed out why this isn't just for mods (mine or anyone else's) -- it's also for standard Quake if you want to use the player.mdl from this pack:

I looked at the readme file included with that, and it just says, "To use these new models place the 'progs' folder inside the 'Id1' folder in your Quake directory."

Ok, so it's apparently not the model creator's expectation that pak files should take precedence, so he must have been using one of the modern engines that changed the behavior.

So then I did a web search to see how other people might answer the question, "how to replace player.mdl in quake." The first link that pops up is a Quakeone forum post (naturally) where someone was asking just that: "Easiest way to replace player model?"

On page 1 of that topic, someone mentions creating a mod folder and dropping the file in the progs folder of the mod, and another person mentions something about looking in the pak file.

Then at the top of page 2 of that thread:

the guy is told, "Yes. You can just create a "progs" folder into id1, drop the model into and you're done."

Ok, so again, expectation seems to be that just dropping in the unpacked model should work, and the final post in the thread has the guy saying he did just that and it works... with DirectQ....

Yes, that's the kicker. The guy asking the question said he was using DirectQuake (he said that on page 1 as well).

DirectQuake is mh's own Quake engine, and IT HAS UNPACKED FILE PREFERENCE. :u

I decided I'd better test this for myself, so I found and downloaded DirectQ (for some reason it's not that easy to find), version 1.8.8 (because 1.9 crashed for me), and sure enough, it's just as simple as dropping the unpacked player.mdl into id1/progs/ and it works in DirectQ!

So... like... um.... Do I need to repeat that? mh has been BLASTING me for daring to ask for a feature THAT HE ALREADY PUT IN HIS OWN ENGINE :u

So yeah, Baker, please import this wonderful feature that mh was wise enough to implement in DirectQ :D

I have admitted that I've been wrong about things in the past. DirectQ was riddled with mistakes, I freely admit it, and that's one reason why it's no longer developed. You don't get to score points that way I'm afraid. 
...back To Sanity... 
I'm more inclined to believe that the 2D GUI gfx were actually designed with a 1:1 mapping of texels to pixels in mind, rather than any specific resolution. 320x200 is just an accident of history.

I did code up aspect adjustment just to see how it looks and as expected it's pretty crap when texture filtering kicks in.

It might be OK as an option but otherwise I'd leave the default alone. 
I'm more inclined to believe that the 2D GUI gfx were actually designed with a 1:1 mapping of texels to pixels in mind

Look at the pentagram icon. It should be a perfect circle, which only happens at 320x200. At 320x240, it becomes oval.

Also, the console background itself was obviously made with a non square pixel aspect in mind, and it has text pasted over it by the engine. With square pixel aspect, that text's aspect becomes different from the aspect of the rest of the engine's texts.

The help screens, which were made to cover the whole screen, are also 320x200.

And lastly, enlarging the 2D art vertically when using square pixels makes more sense than reducing the 2D art vertically when using non-square pixels. If the 2D art was reduced vertically, the help screens wouldn't cover a whole 4:3 screen. 
By the way, non-square 2D pixels should be optional, because several mods uses custom GUI artwork with square pixel aspect.

When rewriting the GUI renderer, I'm going to make it use an optional non-square scaling enabled by default. 
I think about the 2D rendering differences.

As there is no separation between the software renderer vs. the Open GL build -- it is FitzQuake calling the shots and saying what to draw and the location -- using a canvas system that WinQuake never had.

The source code in Mark V doesn't actually trace back to WinQuake, not even for the WinQuake build.

Which is way different than mankrip's engine or qbism super8 or engoo.

It is also why Mark V has immensely more versatile video capability than any other WinQuake. The video code is literally 100% FitzQuakian.

Shorter version: Eventually the aspect ratio thoughts will happen once the engine eventually settles down where there aren't "big leaps forward" looming. 
Eventually the aspect ratio thoughts will happen once the engine eventually settles down where there aren't "big leaps forward" looming.

Same thing here about colored lighting. It would be a pain to implement it now, only to rewrite everything when the new color transformation system gets implemented. 
Just to clarify what I mean: here's som screenshots with various combinations of aspect correction and texture filtering.

The "200 Height" shots are using the old 320x200 resolution but at a 4:3 aspect.

Pay particular attention to the menu slider bars. This is what I mean by a 1:1 mapping of texels to pixels. 
Oh, yeah. Now I know what you mean.

When you said "1:1 mapping of texels to pixels", you didn't limit the meaning to square pixels. A 4:3 320x200 screen will have non-square pixels, but the texels also have the same non-square aspect, so the screen will display the texels in a square ratio to the pixels.
A 4:3 320x240 screen multiplies the rows to compensate for the "non-square texel to square pixel" aspect when necessary.

Yes, such scaling generates notable artifacts at lower resolutions, which is another reason to make the 2D aspect correction optional. But at higher resolutions, the artifacts becomes unnoticeable. Also, some custom texture filters may help. 
You don't really get to do custom texture filters with hardware acceleration though. Well you can, but you have to write them yourself in fragment shaders so a lot of popular engines don't get to play. Otherwise texture sampling is fixed functionality.

Forgot to mention - one thing I really like about Quake's 2D graphics is the fact that they're so crisp and clear, and this is as a result of the precise pixel work that went into creating them. It's something that you might not notice at first, but any kind of texture filtering on them blurs out a lot of the fine detail. 
Texture Filtering 

Would be nice for some maybe to have a gl_hudfiltermode convar. 
Really Though 
If there was a Quake engine that supported temporal antialiasing (TAA), then texture filtering would be completely unnecessary. 
I've cropped your unscaled screenshot to 320x200, and did some tests using The GIMP:
320x200 source

320x240 mockup, nearest scaling

320x240 mockup, bilinear scaling

Bilinear scaling in The GIMP shows that it's possible to scale Quake's 2D GUI in a way that looks good. It may be complicated to get that same quality using hardware rendering, but it's definitely possible. 
Tool_inspector, Why Are You This Way? 
Mark V Question 
How can I keep Mark V from messing up my Quakespasm cfg? I switch back and forth between these engines and right now I exec a specific config for QS after using Mark V but it's still a bit messy. I gather that this is some kind of anti-cheat thing from some research here.

What am I missing? How can this be more seamless? 
two separate quake directories.
alternatively change all your config.cfg files to readonly so that nothing can overwrite them. 
Meh. Well, at least I have options. 
I gather that this is some kind of anti-cheat thing from some research here.
I don't think it's anti-cheat, what happens is when you exit an engine, it overwrites config.cfg with only the cvars / keybindings that engine is aware of.

So it's more of a limitation of the original quake config system, when extended to engines with diverging sets of cvars/keybindings.

I'm not too familiar with what has been tried to remedy this. 
Would be nice if the engines had their own sub config.cfg for the "new" non-vanilla id, non-standard cvars it has implemented.


...and so on. That way we could keep my vanilla config and each engine looks for that and then loads theirs. Even if there is overlap the engine in question would ignore the others. I assume it's not this simple and would require co-operation to make it a "standard." 
No, it actually is that simple. It's something like 4 lines of code. In Cmd_Exec_f detect config.cfg and write in the engine cfg, in Host_WriteConfiguration write out the engine cfg.

I have no idea why it's not done. I'd love to see it done. 
and write both a config.cfg and config-engine.cfg with the same contents, as encouragement for other engines to follow suit... well, that and so new engines pick up usable defaults too.

however it would also need to be gamedir aware for all those mods that came with a config.cfg provided, so they don't read settings from id1/config-engine.cfg in preference to those in mod/config.cfg.
if engines had done the same with config.cfg vs default.cfg, we wouldn't have mods doing the stupid thing of including config.cfg files!.. 
Is the most recent MkV release capable of running "The Forgotten Sepulcher" from Arcane Dimensions v1.6? 
The main engine-breaker in Sepulcher appears to be the leafs count; this is used for several hard-coded arrays in the engine and even the extended max in Fitz or earlier versions of QuakeSpasm is insufficient for Sepulcher, which needs 73755 leafs.

Personally I think that engines should be dynamically allocating these instead of using big static arrays, because otherwise it's an arms race: an engine will bump the max, a map will overflow it, an engine bumps it again and so on.

Anyway, the latest MarkV bumped MAX_MAP_LEAFS to 65535 for the Rubicon Rumble Pack, so it too is insufficient to run Sepulcher. 
Other Ad_sepulcher Limits 
1375 models
368 sounds
193 lightmaps (assuming 128x128)
2877 static ents
4743 efrags

For QS I made efrags dynamic, and was going to do the same with static ents (although 3k is about the upper limit with protocol 666 because of 64k signon) 
Sky Visible Through Water 
Very nice engine. Just one thing. When you set the water to be opaque like the original, the sky is partly visible through it in the hardware renderer. But not in the software renderer. This seems to be the only noticeable discrepancy between the two, apart from affine mapping not being possible in hardware either. How hard would it be to fix this? 
Here is me on E1M2 looking at the sky with opaque water using the hardware renderer. The sky isn't partly visible.

Hardware renderer, opaque water, looking at sky -- none seen

Maybe a screenshot of what you are referring to would help? 
I believe he's referring to the same issue some of us have reported before: shadows and the sky are visible through models (and water surfaces it seems) in the DX9 version. (see #1098 #1206 -- mh knows about it: #1109 ).

I jumped in the pool on e2m1 and saw the effect he's describing. 
Hello i have problem with Dissolution of Eternity HUD.
"The armour / ammo icons displayed do not match the actual armour or weapon you have equipped."
This person has the same problem,he is using a PSP port,im using a Mark V.Is the problem on my side or Mark V? How do i fix this? 
What command line are you using to launch it? 
Using -hipnotic the command line? Yes/No?

Probably your problem. Let me know.

@gunter - ok, r_shadows 3 option. Maybe a week later after his post I realized that was likely the issue he was experiencing. 
I meant -rogue, not -hipnotic.

No More Vsync In Mark V WinQuake? 
WinQuake runs with constant stutter but I couldn't find any way to turn on vsync. Can anyone help? 
I don't know of any WinQuake that ever vsync since that is a Open GL feature.

That being said, if you really want a WinQuake with vsync ... here is a slightly older beta with vid_vsync 0|1 capability:

It is the WinQuake-GL.exe in that .zip that has vid_vsync because it renders the buffer to an texture and then draws it on the screen through Open GL. 
Thanks Baker, I found that build last night and it's fantastic for playing Quake as authentically as possible.

Is there a reason why this .exe is no longer included or being worked on? It's really the best of both the GL and software modes, since it has no graphic glitches and z-fighting like the GL version, while retaining it's best features such as UI scaling and vsync.

It just makes no sense to me at all. 
The regular WinQuake can hit higher frames per second, doesn't matter much for small resolutions but if someone decides to max out in a very large resolution there is a gap.

It is actually maintained because the Linux and Mac versions of Mark V WinQuake are WinQuake-GL builds, I just don't put a Windows one in the Windows .zip because it would confuse most people. 
Are you planning to put WinQuake_GL.exe's in future builds? 
I could make it available somewhere on the page in the future when new releases happen. 
Also, there have been two longstanding bugs to do with monster spawns that have been around since the original WinQuake - one in e3m3 where the fiend spawns midway in the air in the circular lava room when the final bridge activates and another in e4m7 where the zombies spawn after killing all the underwater zombies in the first circular room. In both cases the monsters are stuck in the air after spawning when they should fall to the ground/water and start attacking. Could you look into fixing these issues? 
Are you sure that these are engine and not QC bugs? My recollection is that they happen in all engines, not just WinQuake. If QC bugs it would be inappropriate to modify this behaviour in the engine. 
There's definitely source ports out there that fix these issues, but I admit that most I've seen don't.

Why would it be inappropriate to modify this behaviour in the engine? They are gameplay bugs after all so shouldn't they be fixed? 
If the bug is due to bad QC code or mapping errors, then changing the behaviour of the engine to work around the bug does carry a risk: some mods may be using this behaviour of the engine intentionally to create a desirable effect. The fix for the bug in vanilla will break those mods in your engine. Which isn't to say that it's never the right choice to make those kinds of change, but you have to be thinking about the potential cost as well. 
QuakeC is game logic in a progs.dat, found in Quake pak0.pak. It exists outside the engine and is the game logic program. It can be compiled with a QuakeC compiler like fteqcc.

Some people (like preach) are really into QuakeC, he is the main author of Quoth and was involved in Arcane Dimensions.

Concise version: QuakeC behavior isn't related to the engine. 
Quake Info Pool - Currently not researched Quake bugs

"Right in the beginning on E4M7 some Zombies start spawning after you kill the ones in the water. If you stay under water as you kill them, the new ones will spawn above you, and fall down into the water. However, if you kill the ones already there under water, and get back up on the ground level, the Zombies will spawn in the ceiling, and just hang there."
Reported by Alexander "Prodigy" Møller
Demo is available for download (

QIP lives! 
I bet it's a bug in the map itself. Some trigger misfiring or something. 
Quake has a lot of silly mysteries/annoying things. It probably is a map design flaw.

Video examples:

Can't imagine how this one is possible.: 
The zombies' teleport entry points in e4m7 are just too close to the ceiling.

But if you have an online server with a sys_ticrate of 0.1 then they fall just fine, because the server doesn't check their position fast enough to know they are stuck before they fall far enough to not be stuck. sys_ticrate .05 or faster and they get hung up.

It can be fixed directly in the map or with QuakeC by altering the locations of the teleport points. 
Sounds like a mapper or advanced user could make an external .ent file if that is what is going on. 
Hey, *I* am an advanced user!!

Uh, is tool_inspector broken? it seems broken (in both GL and DX 8, 9). I had to go back to version 1.27 to make it work again. It did not work for me in 1.28

Ok, here is what the zombie problem is, I believe:

In triggers.qc, info_teleport_destination function raises ALL teleport destinations by 27 units upward. I think this is to get them off the ground a bit, to make sure monsters don't get stuck in the floor, hah. Well, the problem is that it causes the zombie teleport destinations in e4m7 to move too close to the ceiling. Though oddly, it's not completely consistent that the zombies get stuck. Sometimes they seem to fall just fine in single player, other times they may get stuck.... Maybe it has something to do with whether they are moving or seeking a target or something when they teleport in. Or it could even have to do with the FPS you are getting in Quake....

Yeah, that might make sense -- if you are getting really high FPS, then Quake checks sooner to see where the zombies are, and determines they are partially in the ceiling. If you are getting a lower FPS, then the physics check doesn't happen quite as fast, so the zombies fall down a bit and free themselves. That may explain why the original Quake people didn't catch the problem; they weren't getting a really high FPS back in the 90s!

But that's just a guess on my part, knowing that Quake physics are dependent on your frame rate.

In any case, lowering the teleport destinations should fix the problem.

So load e4m7, then type in console: copy ents

Go paste those ents into a text file: \id1\maps\e4m7.ent

Go to line 883, 889, 895 and change the "origin" Z values from 136 to 100, just to be safe. Save the file. Problem solved.


The problem is solved!
We solved the problem...
So ev'rything is awesome!
Problem solved! 
Yes, you are certainly an advanced user, haha.

You might consider uploading that file to somewhere for jayoo.

If you do, I'll mirror a permanent copy of the file.

ericw may interested in it as well.

/Yeah, Pritchard pointed out I messed up the inspector. 
As a quick double-check, playing it with a sufficiently low host_maxfps should be enough to confirm the theory 
That sounds like a very plausible cause Gunter (though I am far from an advanced user!).

I'd really appreciate it if you could run me through the steps to fix this and the other instance of the bug I mentioned.

Thanks for looking into this everyone! 
I'd really appreciate it if you could run me through the steps to fix this
He did just that in post #1686... 
I'll give you some pointers since you are passionate about this stuff.

That being said, after this initial information I'll leave it to others to give you tips or answer any follow up questions you have --- mostly because I'm largely "engine-only" and this is more QuakeC (gunter/preach) and mapping territory.

In that Mark V 1.25 or up to 1.27 in the Open GL version ONLY, there is tool inspector.

Activate it by typing tool_inspector 1. Type "impulse 9" and switching weapons with change information.

For the map you want to fix, like Gunter said, load the map and type "copy ents" in the console. Open a decent text editor like TextPad or NotePad++ and paste that text into the editor. Then save the file as c:\quake\id1\maps\e4m7.ent.

From the information for tool inspector (you may need to type like "edict 3" (where 3 is an entity edict number) in the console, you can find out enough information to locate the mapping entity information in the .ent file.

Doing anything with this information, it is very helpful if you are a mapper (what this site is all about) or QuakeC master (gunter is).

But what Gunter did was edit some spawn point coordinates.

A .ent file is an external entity file recognized by all modern engines (DarkPlaces, FTE, Quakespasm, Mark V, others), it overrides the maps information.

You might struggle with this at first if you aren't a mapper.

Happy hunting! 
Yep, setting host_maxfps 16 or slower does indeed make them fall down, even if they are currently stuck.

But even host_maxfps 20 is making them stick....

Ah... that's why they were falling last night on me -- I had tool_inspector enabled, and that was killing my FPS, haha.

And as I have pointed out, sys_ticrate of .1 makes them fall correctly on a server, and that's the equivalent of 10 "server frames" per second, isn't it?

But in the end, it's a bad interaction between QuakeC and the map itself.

The instructions I gave should be pretty simple to follow to fix it with an .ent file....
Though it would probably be better if someone really wanted to test to see EXACTLY how far the zombies need to be moved down to still fall correctly.

Don't look at me; I don't care that much. I run my server with .1 ticrate ;)

Guhhh... who am I kidding? Now that I said it, I can't not do it... heh.

Oh, well, it looks like they only need lowered by 3 units to work correctly (from 136 to 133).

Do I really need to upload the .ent file somewhere? I've already done all the hard work and told people exactly how to fix it! ;) 
I Didn't Know QS Supported .ent Files 
I thought only the spiked version did. Thanks for the info, Baker. 
I managed to fix the issues. Still need to trial and error the E3M3 fiend spawn position but the zombies in E4M7 were an easy fix. Thanks again! 
OK, after much messing around with an .ent file for E3M3, I'm unable to find the "info_teleport_destination" for the fiend who spawns stuck in midair. I've determined that the line 2164 corresponds to the fiend in question, but there are no matching teleport coordinates to the "target_name".

Maybe I'm missing something obvious so any help would be appreciated. 
Perhaps I should try reading instructions more carefully in future...

I used tool inspector to find the offending fiend's actual target_name and changed the teleport coordinates to fix the spawn.

e3m3 Line 1244 "origin" "-832 416 140" 
Mark_v And The Demo Fov 
heres the demo of two bots dueling each other on zed2 - the vondurs property

i'm using mark_v to record the demo, and my fov is something like 135/145

but when i try to replay the demo something's strange has happened to me, using mark_v 0/99

the latest ad_1/60 engine(quakespasm-admod) has been playing the demo ok 
The Demos 
you cannot change the fov value while watching the demos in mark_v 
Downloaded zed2.bsp map and played your fbots20.dem.

Changed fov several times ok, didn't experience any problems.

I believe you, but I can't reproduce what you are experiencing but maybe something will come to mind eventually. 
take a look at these screenies
yeah i can change the fov value, but the viewing perspective is a very weird in mark_v 
My initial guess works like this:

Mark V has angle smoothing, which is not obvious in single player. An online player can immediately tell.

It looks like Frogbots use some sort of QuakeC evil to move the camera around (jerky style) that isn't compatible with camera smoothing.

I didn't invent camera smoothing and in fact several engines have it, Quakespasm isn't one of the engines that have it.

It is possible you found a special case no one noticed before. 
Crash When Trying To Play Demo 
I get a consistent "Mark V has stopped working when trying to play a demo. Doesn't seem to matter what, but specifically now I am trying to play jam 9 demos.

Windows 10, 64-bit using latest MarkV release.

Happens in any version (DX9, 8, markv.exe)

Let me know what else I can provide! 
Scratch That 
Ugh annoying when the solution comes to you moments after finally giving in to ask for assistance.

I attempted to switch to jam 9 using the game command in markv. But running a shortcut with the -quoth -jam9 is what worked. 
Happens. Glad you figured it out. 
Hey Baker, 
there's this Admer guy at QuakeOne having trouble running Mark V. I told him I'd drop you a line, so for troubleshooting purposes you might wanna check posts #55-58 here.

Also, a few posts above those, Dutch states that he's experiencing a notable performance drop with the latest DX9 exe. 
I look at issues posted in this thread by the individual having the issue. There is a link to this thread on the Mark V page.

Keeps everything organized. 
Dutch probably made some setting that harms his FPS. Like r_shadows 3

He should try a clean install.
Same with the other guy who it won't run for -- completely new install in a new, clean Quake folder. 
Looks like an experimental map (an awesome looking one at that).

If that map gets released I'll see what is going on.

It could be one of a million things (vis, a texture, a skybox, external textures, a lit file, entity error, parsing issue, a texture name, a setting in Mark V even.). 
Hello, Baker. I'm the guy who can't run Mark V.

I tried what Gunter said, but the same problem still happens:

- I open the .exe
- RAM usage is at 9628KB
- After 15 seconds, the RAM usage jumps to around 46MB (I'm assuming it loads some game files)
- The .exe simply exits without a warning

In short, it won't run at all.
Sometimes, this happens: 
Yeah, it was a clean install, straight outta the box. New directory and everything. No old cfg files, lifted it all off my quake CDrom from '96. It's probably the r_shadows cvar. 
There should be a qconsole.log file in your Quake folder after you start Mark V.

Can you paste the text of that? 
That Microsoft crash report, could you post the text of that as well. Often the crash report text can indicate where something crashed.

What version of Windows are you using?

And I assume you are using current version of Mark V? 
Dutch, if you happen to be testing in the Start map, make sure to set r_mirroralpha 1 to disable mirrors. Mirrors are enabled by default (really shouldn't be). They are bad for my FPS.

I don't think any other FPS killing settings are defaulted on. r_oldwater 0 is another one that harms my FPS, but that isn't set by default. Assuming the secret hidden cfg file isn't retaining any non-default settings when you do c clean install....

You couldn't possibly be using a slower/older computer than I am (XP Netbook!).... I get between 40-75 FPS on the Start map, depending on what the lava balls are doing, as long as I don't have too many extra features enabled.

Hm, and if you happen to be running in a window, and you have some other program on screen that is drawing stuff, that could cause a problem too. I have a program called BitMeter, and it will destroy my FPS if I have it showing while running DX Mark V in a window.... 
I'll see about the crash report later today, because I'm currently using my phone. I remember it was referencing 3 files located in Appdata/Local/Temp.

My OS is Windows 7 (32-bit) and yes, I'm using the current version of Mark V, or at least that's what I think.
I've downloaded it here: 
Slight correction: Windows 7 SP1.

I copied the 3 files in another folder:


Should I send the .mdmp file? I'm a noob at debugging. 
I am on Windows 7, although not 32-bit.

The quake\id1\qconsole.log would be helpful. It is the log file Mark V writes out. 
Here are its contents:

Command line: [ ]
Log file: C:/Games/Quake/id1/qconsole.log
Sat Sep 09 18:17:08 2017
Mark V Windows (Build: 1036)
Exe: mark_v.exe (1327 kb)
Exe: 22:32:27 Jan 19 2017
Caches: C:/Users/kliker/AppData/Roaming/Mark V/caches
UDP4 Initialized: INADDR_ANY,
IPv6 Initialized: [fe80:0:0:0:a59f:53f6:4528:9fe7%41]
Exe: 22:32:00 Jan 19 2017
256.0 megabyte heap
1) Do the WinQuake or Direct3D versions run?
2) Is there an opengl32.dll in your Quake folder?

I know Quakespasm runs on your machine, so it shouldn't be an Open GL issue although Mark V uses some Open GL capabilities that Quakespasm doesn't.

If there is an opengl32.dll in your Quake folder, you should delete that. But since DarkPlaces seems to run for you, I can't see how you could have a (toxic) opengl32.dll in your Quake folder. 
Baker, compile a debug build for him, keep hold of the exact pdb file that msvc generates when compiling said debug build.
Send him the debug exe, get him to send you the resulting .mdmp file.
Open the mdmp in msvc.
Then you can see the stack etc, and inspect many of the variables that might be relevant etc.

That or rip the stack trace code out of FTE's win32 port. That would allow him to simply paste you a whole list of function names which is usually enough to figure out where it crashed (although not always what actually went wrong).
This of course requires no pdb files, so hurrah for that, but it won't show line numbers etc.
Still, if you expect your code is going to crash then its quite handy... 
Ywah, the strangeness/uniqueness of Admer's problem is has been making me think about improved crash data.

Can't do anything tonight, but I'll ask you questions tomorrow or Monday about what you are referring to in FTE. 
1) Yes, but they crash the same way.
However, the WinQuake and DirectX versions don't give any crash reports. That only happens with the original Mark V .exe. :P

2) I'm sure there is, I'll still check to make sure.

Mentioning OpenGL reminded me of something:

My GPU only supports up to OpenGL 2.0. This gave me lots of compatibility issues with programs that require OpenGL 2.1. 
1) No, they crash almost the same way.
(I misread what you wrote up there, sorry) 
If WinQuake or Direct3D are crashing, your OpenGL drivers aren't involved in this. Neither use Open GL. WinQuake doesn't use anything at all ;-)

So it is something else.

I never actually suspected a drivers problem, mostly wanted to rule it out. It but seems unlikely.

I have couple of suspects.

I imagine in the next 72 hours or less, I'll make a special build with some of Spike's inventiveness, and then exactly what is going will be clear.

Thanks for the feedback ;-) 
Well, I was wrong. There was no such file as opengl32.dll in my Quake folder. :P 
WinQuake LIVES 
Been looking for an update of WinQuake and so happy to see you giving it some love, Baker! The original software renderer is still very charming. I love that washed out shading, you can't replicate it in Quakespasm.

Tried loading Arcane Dimensions with this and was surprised to find out that it mostly works. The engine even auto converts the full color skyboxes to 8 bit! However some textures with alpha channel are broken, the fog in ad_necrokeep looks especially bad, and ad_swampy crashes when you get to the main area. Anyway, what I'm getting to is, any chance your version of WinQuake could be fully compatible with Arcane Dimensions? AD is probably the best benchmark for the modern map packs, so it'd be a good milestone to achieve, I think. 
I am sure Baker will eventually provide builds for *all* MkV builds that fully work with latest AD additions. Maybe even Ter Shibboleth. These days, mappers are doing everything to push Quake map specifications beyond any previously known limits. I hope that eventually we'll have a solution which won't require updating ports over and over again to make maps work. 
Fog in custom Quake maps is usually too subtle, to disguise the fact that it's not volumetric.

Custom Quake maps can "fake" volumetric fog by making some areas small enough for the fog to not show up, and making other areas large enough for the fog to cover them. Combining this with strong shadows in the small areas and very subtle shadows in the large areas makes the global fog seem to have different densities in each area.

The thing is, subtle color translations are very difficult to pull off in 8-bit color palettes. Large areas of the screen ends up being rounded to similar color values, resulting in huge color banding if not dithered, or heavy graining if dithered. This gets even worse when the raw color of the fog doesn't exist in the Quake palette.

Making fog look good in 8-bit color renderers requires design restrictions that the mappers won't adhere to. Just like transparencies usually looks awful in 8-bit color, fog and colored lighting will usually look awful too.

A fun thing is that the same principles applies to regular lighting. Vanilla Quake maps features mostly strong shadows, because subtle shading has lots of banding in the software renderer. But newer Quake maps usually disregards this limitation, because they're usually only designed for hardware renderers. Most of the awfully looking maps from the 90's usually failed to understand this limitation too. 
Another reason for the subtle fog in custom Quake maps is to disguise the fact it's not spherical. Thick flat fog looks bad when turning the camera. 
Transparency In WinQuake 
I've done some more testing in Mark V WinQuake and turns out the water/teleporter transparency (r_wateralpha) actually works, via dithering. I suppose the same effect could be applied to the fake fog layer in ad_necrokeep. It just seems like the engine has no support for alpha channel in textures, e.g. various trees and vines in AD and Jam 8 are broken, with solid white where they should be transparent. 
Put these guys in the maps folder and you'll have transparent water on the stock id1 maps

External .vis files for original Quake maps

They should work in DarkPlaces as well.

The original Quake maps don't treat water as transparent.

Alpha masked/alpha transparency doesn't work in the WinQuake version for brush models at this time (tried it maybe 4 different times, something I'm not understanding about the WinQuake depth buffer or draw process prevents me from getting the job done in this case.).

It actually works for .mdl models, but few maps use that although it might be visible in Arcane Dimensions in some cases. 
Alpha masked/alpha transparency doesn't work in the WinQuake version for brush models at this time (tried it maybe 4 different times, something I'm not understanding about the WinQuake depth buffer or draw process prevents me from getting the job done in this case.).

The BSP renderer sorts depth by edge at the spans level, rather than at the pixel level. To avoid this, I've tried partially reinitializing the BSP renderer upon rendering each alphamasked BSP surface, but this resulted in massive slowdowns. Now I only reinitialize it once for each BSP entity containing alphamasked surfaces. Qbism did something similar in Super8, IIRC.

Quake's spans-related code needs a lot of work. It's non-intuitive and has bugs such as this.

I don't fully understand it yet either, but I'm sure the reinitialization overhead can be eliminated almost completely. I should only manage to do so after fully rewriting it, though. 
Thanks for the link. Looks like a good read.

I had determined that some sort of reset was required, but either I did it in the wrong place or performed it incorrectly. Or the third possibility of something I am not considering and wasn't on my radar.

Some day in the future I'll make another attempt. Last time I almost got "serious" (I was piece by piece reimplementing qbism super8 in WinQuake until I isolated what I didn't understand), but then something more shiny to me pulled me away (probably something Spike did in Spiked Quakespasm like single port server).

Network code to me > everything else ;-) 
One more thing, does WinQuake Mark V support any kind of HUD scaling? Integers like 2x, 3x etc would look quite good even in software rendering I'd wager. The usual scr_*scale commands don't seem to work. 
In the video menu, stretch is as close as it comes, emulating 320x240 or 640x480 as best it can depending on your current display mode.

It isn't exactly the same thing as scaling the HUD, and for most people it is probably "good enough" -- although as a purist I don't feel it is good enough.

But since it would be quite time consuming and effort to implementing true scaling (aka FitzQuake) in the software rendering with the appropriate alpha masking support, such a thought sits somewhere closer towards to the back of list rather than the front.

Keep in mind a trule scaling solution needs to handle all 2D graphics like the menu, scoreboard, etc. otherwise it would be quite silly. 
Hmm, seems like the original renderer is pretty limited.

For the record, I've tried Qbism, and it does have HUD scaling and alpha channel support for textures, but I get heavy FPS drops in Arcane Dimensions, when there are any alpha channel textures in my line of sight.

Could we do this another way around and emulate the original paletted 8 bit look in OpenGL? In particular the lighting color map. 
Crash To Desktop 
....on trigger_changelevel - is this a known issue or could it be my map?

It's happened multiple times and on demo playback as well. 
I know exactly how do it. It isn't a question of that at all. The question is, of the things I can do, would I find that interesting enough to want to do before the 25 things that do interest me. If you understand.

Ask Spike or mh or ericw or metlslime or qbism or mankrip, part of an engine coding for a leisure activity is wanting to do the task.

@dumptruck_ds .. don't know. If it progresses to become a released map, I'll make a mental note of it after it is confirmed it doesn't crash any other engine. 
paletted look with gl = fte with r_softwarebanding 1 (or just use the softwarey preset). 
re: the map. tested on Quakespasm-admod last night and it was fine. I will do some further tests with other clients this evening and report back but for now at least that engine behaves as intended.

My trigger change level is made up of some weird shapes as you can sort of see in the screenshot. Not sure if that could be a cause or not. 
it seems the tool_inspector is broken on your latest release v36

also i've got a new video card gtx1070, and noticed a very weird video gliches with the fog enabled

there's no such gliches if i'm using quakespasm engine tho 
There Ain't No Gliches Either If I'm Using Dx_9 Engine 
Yeah, Pritchard reported the tool inspector issue a while back and then a couple of others later on.

I saw the glitching in your video. Could you give me "viewpos" coordinates and map name (or as an alternative the demo which gets me the same information).

I'm guessing since it only happens in certain frame, it occurs when a lavaball pops into view.

Quakespasm and Mark V and Mark V D3D all draw very differently, so the different behavior isn't unsurprising.

I'll make a note to try to recreate the next time I have my hands on a NVidia card machine. Since NVidia updates the drivers all the time, it is a possibility that this is a driver issue that will go away in a future driver update, but I'm not going to make that assumption.

Thanks for the high detail issue report. 
Yeah, After I'm Getting The New Card 
i've updated nvidia driver to the latest version

this glitch is only happens when the fog is enabled, disabling the fog removes the problem
would you mind if i'll send the map
to your mail? 
Spy, you know I think you are awesome.

I am email free! And I love it!

If it needs to be done privately, I guess you could send a private message at 
i cannot reach you at

btw, fitz08, has the very same issue 
I deleted some private messages over there, you can try again (but really since they upgraded the forum there, I don't know if that was problem or not) or upload to Quaketastic.

My gut instinct is that I think this is a driver issue that will magically disappear at some point once nvidia does an driver update or 2 on your machine.

They probably introduced some sort of stencil bug they introduced since ...

1) It doesn't happen in Quakespasm which doesn't use stencil by default.

2) It doesn't happen in the Direct3D version.

3) Didn't happen on your previous machine, no one else has reported a glitch like that. 
Hello, it's me again. :)
I've tried out a few older versions of Mark V, and the problem is still the same.

Now I'm starting to think that it's definitely up to my hardware. Certainly my GPU, because the drivers are so poor. Yes, the latest ones are from years ago.

In the near future, I might install modded drivers to see if it helps. Intel GMA 965 is a special snowflake among the 9xx series, haha. 
You might try the sdl_mark_v_gl.exe in this beta ...

Will it work? Who knows!

Had several beta testers with really, really bad/old computers, some which can't run Open GL but the Direct3D works and getting terrific fps.

Worth a shot anyway. 
Yes, the Intel 965 is pretty damn special - it was Intel's first hardware T&L part, the drivers are absolute cack and the hardware itself is actually slower than the prior (software T&L) generation.

As far as I'm concerned: weirdness, crashing, general bad stuff - that's expected behaviour under OpenGL with this part. 
I've tried out the SDL .exe, and just as I thought...

There's no hope. My GPU is the lottery in terms of incompatibility. :P
I'm not giving up yet, though.

I'll just wait until I build my new PC by the end of this year. Modern hardware will definitely handle it better. :) 
1036 Is Giving Me Problems 
Wonder if anyone else is having issues running it. I'm testing a map so haven't had time to really document things but it seems to stutter quite a bit after running for a few minutes. Can't even finish a play-thru.

Before I dive into reporting wondering if anyone else is experiencing the same behavior?

SO far it's just the main mark_v.exe

dx8, dx9 and winquake are behaving. 
Found A Really Weird Bug 
The following bug happens in all current versions of Mark V:
- Quick save and quick load at least once.
- Die and press space to restart the level.
- You respawn with death camera (slanted view).

Also, all versions of Mark V are stuttering for about 3-5 seconds every time I launch the game, sometimes also with cracking sound, usually when loading the first map. It's like it's caching something really bad. My machine is pretty modern, so it shouldn't be related to specs. The game is very smooth after it's done that initial bout of stuttering.

Also please consider adding support for OGG tracks. it's more common than MP3 nowadays and seems to be standard for Quake. Also PNG instead of TGA as well, most HUD/GFX graphics seem to be using PNG.

P.S. And maybe don't try to re-route when an opengl32.dll is put inside the Quake folder. I'm just trying to use a wrapper for some extra graphical effects. This one in particular. It works great with Quakespasm. 
The death cam respawn was reported (by me :D) a while back.

I don't think that ogg is more common than mp3 now... in fact i'd say it's even less common than it used to be, now that the mp3 patents are starting to expire.

I think the reason to avoid loading opengl32.dll is this
Well, I've got about a dozen Quake soundtracks (id1, hipnotic, rogue, shrak, malice, impel, xmen, n64 etc), all of them in 256 kbps VBR OGG, de-emphasized where necessary. I'm pretty happy with this collection as it stands and don't feel like repeating the process for MP3. I've read about Baker's reasoning on how MP3 is faster to access, but I'd still like an option for OGG support. And who knows, we might all switch to FLAC at some point.

Yeah, I get the reasoning behind avoiding opengl32.dll, in the old vanilla installations of Quake (and other games from that era) it's a 3dfx wrapper, which causes problems on modern systems. But I feel like the current solution of removing the option of using any wrapper at all is a bit too heavy handed. 
In theory MarkV already has .ogg support provided you have a DirectShow-compatible codec installed. As a rule of thumb, if you can play it in Windows Media Player, you can play it in MarkV. I know that for a fact because I'm the original author of that code.

In practice MarkV is hard-coded to only search for files with a .mp3 extension. Supporting .ogg as well should be just a matter of adding support for the other extension, but I didn't originate that part of the code (or at least I don't recall doing so) so I can't say what kind of work would be involved in this change. 
Ogg Vorbis Is History, Use Opus Like QS 
Ah, ogg files.

Supported on Windows, the Mac, the iPhone. Widely used in the commercial games industry and in the music industry. Supported by the Unreal engine and the Source engine.

Oh wait. That's mp3. None of the above support ogg.

My Android phone can play ogg. If you open an ogg file in Google Music, it will convert it to mp3 and then play it ;-) That's Google's idea of ogg support.

Ogg fits in nicely in the category containing 8-Track, BetaMax, Laserdisc, Zip drives, the Zune, PlaysForSure, HD DVD, Windows Mobile, Windows Phone.

Short version: Oggs? Fuck, no! Plus you don't even know why you are using ogg, Quakespasm supports mp3 -- so what was it that made you think "ogg" to begin with? Answer: You don't know, because no one using ogg ever knows why they are using ogg, especially because in the real world, no one is ever doing oggs because nothing supports them.

/Against my better judgment, I click submit! 
In practice MarkV is hard-coded to only search for files with a .mp3 extension. Supporting .ogg as well should be just a matter of adding support for the other extension

Thank a lot for this tip, turns out Mark V DOES play OGG if you just open the .exe in a hex editor and search and replace all instances of .mp3 ASCII text with .ogg. Really makes you wonder, why not just add literally 3 extra characters to the source code to enable OGG support? It really seems like Baker's got some personal agenda against it, since literally every other modern Quake engine supports OGG, because why not. Oh well, I suppose there's no need to discuss this further. 
The Smell Of Napalm On The Forum 
There's something wonderful about reading Baker raging against ogg, and then immediately afterwards reading about how despite Baker's strong desire to prevent it by explicitly coding it out, someone has hacked it to work with a find+replace.

It makes you wonder what ogg did to Baker - murdered/kidnapped family I guess - in the past to make him think "I have this perfectly good DirectShow support in my engine. I should ruin it and only use it for mp3 format music to ensure that my users have to work harder than with other engines!" 
Doesn't Sound Complicated At All? 
Implement a generic audio library and comment out ogg from the list of supported formats. 
why not just add literally 3 extra characters to the source code to enable OGG support

I obviously can't speak for Baker but this wouldn't be just 3 extra characters. It's only 3 characters if you directly replace the existing .mp3 support with .ogg support, but of course you then lose .mp3 support.

Adding multiple file format support would involve enumerating files of multiple extensions, sorting them into lists, making decisions such as which format has priority over others (not so clear-cut - how do you decide between a high bitrate inferior format vs a low bitrate superior format?), and how to handle the inevitable crazy-assed situation where someone has multiple formats in the same folder (some of which may even be multiple versions of the same file in different formats).

I absolutely do think that people should make the effort to do all this, of course. But it would need some guidance as to what the end-user expected behaviour is. Multiple end users pulling an engine in different directions is something I can personally vouch for as never ending well, and it would be nice to see players striking up a discussion among themselves about how they'd like to see these kind of decisions work out. 
Funny thing is, OGG is actually already listed in Mark V's file extension look up table:

But there must be some code that explicitly ignores or forbids it. Seriously though, just why. It's a relatively popular file format for video game audio.

To enable OGG support find the above bit in a hex editor and replace mp3 with ogg. Simply renaming your OGG tracks to MP3 should work as well, I guess. 
I'm confused... Isn't engine inter-compatibility something to strive for? Considering that all other engines support the format AND the fact that most soundtracks available online are in .ogg, it strikes me as odd that Baker would want to force the user to convert the files in order to use them with his engine. Plug'n'play, man, plug'n'play... 
Probably doesn't want bloat. 

Ok Baker, I NEED ogg support!

I tried the hacks mentioned above (either renaming my ogg to mp3, or hex-editing mark_v), then, after installing the ogg directshow filter ( ), Mark_V does play ogg.... and it loads in a FRACTION OF THE TIME as an mp3 file of the same file size!

Do you remember a while back, me going through a LOT of testing because I have an issue where loading an mp3 file causes Mark V to freeze up while the file loads? (mentioned in #651 above)

After some encoding gymnastics I managed to get that loading time (during which everything freezes up) down to only like 4.2 seconds for track04.mp3.... Well, I converted it to an ogg of the same bit rate and file size, and it loads in only 1.23 seconds!

So... yeah. That would be the reason to allow ogg files to be found by Mark V (since it is already capable of playing them).

You really don't have to do all the complicated stuff mh mentioned. Just state, "Mark V supports the following formats, in the following order of preference: mp3, ogg."

And let the users sort their own files and formats and bitrates. 
Indeed, there's no need to compare bitrates or anything, just let it read formats A|B|C in the priority of A, B, C. And the game folder should take priority over id1, e.g. say you have OGGs in id1 but e.g. Travail comes with an MP3 soundtrack, disregard the OGGs in id1 then, unless there's not enough tracks in the game folder, in which case read the missing ones from id1. I think that's how Quakespasm handles it anyway, correct me if I'm wrong. 
is there a way to set the fog value via an cfg file or fog depends on qc? 
@ Spy 
Just use an external_entity file(yourmapname.ent) Put the fog command in there. 
I Don't Quite Sure What You Talking About 
why would i put the fog command in the external ent file? and where exactly should i put it?

i'm using the fog value via the worldspawn. AD mod supports this and shows fog correctly, but it seems kinn's old mod (bastion/marcher) doesn't support fog from the worldspawn, as there's no fog after loading map.

i'm just wondering :) 
The worldspawn "fog" key is handled by the engine, it should work in id1 with MarkV (and most engines). Maybe bastion/marcher is resetting it via QC. 
@ Spy 
My answer was for the simple question of setting fog values via an external(.cfg) file, now I see your problem! 
i have a map with a worldspawn settings something like
fog_density x
fog_colour x y z

and after loading this map in AD the fog appears correctly, then i put the very same map in the id1/maps folder and run it from the vanilla game
there's no fog at all
until i manually set the fog numbers in the console, what gives? 
those are AD-specific fog keys.
Try: "fog" "density r g b" 
Have You Just Tried... 
"fog" "Density R G B"

All on one line for stock id? 
Try: "fog" "density r g b"

i put this line fog 0.015 0.35 0 0
into an *cfg file without the quotes, but no avail. 
Sorry, put it in worldspawn, not a cfg file :) i.e. the worldpawn key is "fog" and the value is "0.015 0.35 0 0" 
yay, it's working this way. silly me. Thank you Eric and damage_inc 
Hey, I require help
Whenever I try to launch any of those 2 executables using:
./mark_v_linux or ./mark_v_winquake_linux
I get following error:
bash: ./mark_v_winquake_linux: Permission denied
Double-clicking doesn't work either

On manjaro, hope anyone can help 
chmod +x mark_v_winquake_linux
Has done the trick for me, it works now! 
Marcher / Bastion Imps Sprite Issue 
I was playing back some demos of Spy's work-in-progress map in 1.36 and the final frames of the imp fireball (the impact only) show up as non-transparent. If this is not a known issue, or repeatable I can try a screencap to make this a bit more clear. Works fine in other engines. Notably Quakespasm-admod 
Kinn Sprites 
I've ran into this.

Which sprites are you using?

Kinn original: uses black for transparency requires enfine with support for .png override textures (e.g. Darkplaces) and additive mode.
AD: Not sure.
Keep: I converted all mine to use pink transparency for full support on all engines. 
It's actually an older map of Spy's that he's working on getting ready to release pretty soon. Not sure what assets he was using.

@Spy are you using the same assets from the original Bastion/Marcher maps? 
@dumptruck_ds Kinn Sprites 
Mark_V enables external textures by default, so set external_extures to 0 and reload the map

or just delete all of *.tga files from the sprites folder, they are absolete now 
Mark V's adaptive FOV calculation method seems to be quite different from QuakeSpasm and original FitzQuake. I need to increase FOV by about 6 to get the same field of view as in QS (using a 16:9 display). Of note, QS just does vert- when you set scr_sbaralpha 1, while Mark V does hor+. Not sure which method is preferable, however, it's possible that Baker based his adaptive FOV calculation on specific scr_sbaralpha and viewsize values. In particular, setting scr_sbaralpha 1 and viewsize 100 gives about the same FOV as in QS with full screen view point (that is scr_sbaralpha 0). But nowadays most people are probably playing with the transparent HUD, so this just results in smaller FOV. 
Good News! 
I have finally come across a solution to my problem. It turns out that I actually didn't have pak1 and pak0.pak. I thought I did, but I didn't check my ID1 folder. Long story short, I found something which contained both pak files and copied them over.

I love it. It runs like a charm:

I'm so sorry for wasting your time over such a dumb mistake of mine. 
>uses markv
>looks like glquake 
Missing PAK files was the problem?

How does that happen? If I remove my PAK files and try to run Mark V, I immediately get a popup error message saying it can't find the pak files.....

Maybe corrupt pak files? 
My laptop is 10 years old, I'd rather not...
Also, it's my first time using this sourceport, so I haven't tweaked all of the settings yet. Though, I'd love that to change. :)

Funny thing is, there were no .pak files at all in my ID1 folder.
The .pak files' contents were actually extracted to my ID1 folder, but the .paks themselves weren't there. Interesting. 
Interesting! You may have found "an issue."

I tested with unpacked pak files, and Mark V does indeed just crash without any meaningful error message.

These alternate engines I tested work just fine with unpacked pak files:

fitzquake 0.85

Unpacked pak files should be an acceptable setup... so... Mark V should be able to handle that.

Anyway, if you're interested in tweaking Mark V with all kinds of setting which make it look better (in my view), I have a page with downloads and settings to alter:

Then come play FvF :D
Any interest in bumping Mark V's limits to make it Sepulcher-capable? cf. comments 1661/1662 above.

Also, can anyone say "sepulcher-capable" five times fast? 
@Johnny - Some day ... whenever I do the next version of Mark V, which doesn't feel soon. 
So It's Dead Huh? 
And just when I finished compiling a nice list of bug reports and suggestions. Disappointing. 
Gotta love the internet.

So Baker writes "not yet but I will" and you interpret that as meaning "it's dead", eh? 
What's this I hear about Quake finally being dead? Oh well, it was fun while it lasted. I guess we can all move on to Unreal Tournament now. 
You Mean UT2k18 Aka..... 
....Quake Chumpions lololzor 
@iriyap, @adamer 
I think you've posted some well thought-out comments, including some refreshingly detail oriented ones. This thread is intended as permanent record of feedback so none of the information is lost.

NightFright could tell you stories, there is an obsolete older Mark V thread here with 2500 posts and his observations about obscure mods + crashes, a few which have led to improvements in Mark V and also Quakespasm -- over time ... it was not quick at all! Ironically, maybe 2 which ericw pointed out solutions, ericw didn't actually do them in Quakespasm until way, way, way later.

In free projects the author is always vastly outnumbered and with limited time and a real life.

@adamer - I'm glad you determined what was up with that (your pakless setup). Sure, in theory it "should" work (except it doesn't in Mark V) and it sounds like it works with other engines, but in practice an actual Quake install whether from Steam or the CD or shareware has pak files -- so yeah ... I'm glad that mystery is solvd.

@QMaster - re:Marcher --- I like the attention to detail/testing/thought it sounds like you are doing with your Uber mod. 
Unfinished Business 
I hope that one day I can do another test run as intense as the one I did before that big Mark V update back then. ^^ IIRC there is still at least one issue kinda pending with the final map of Malice when fov changes after reloading the game. It must have to do something with the boss attack and how the port handles the short-term fov changes. It was supposed to be fixed, but a few months ago I managed to get the problem again/still. Need to see what became of it. 
is the mod adjusting the fov or is it standard quake
oh reread the post i guess its an evil thing malice does
mods shouldnt ever change the users fov. could bean easy fix 
In case you decide to pick up your work at some point in the future, here's my final bucket list for the current version of Mark V. Some bugs, some missing features, and a few things that I think would be beneficial to implement.

- BUG: death camera doesn't reset if you quickload at least once, die and press space to restart the level from scratch.
- BUG: game stutters for a few seconds at launch (or every vid_restart), sometimes leaving the audio permanently cracking.
- BUG: parallax skies are noticeably darker than vanilla GLQuake.
- BUG: vid_multisample does nothing.
- BUG: r_bloom makes textures look grainy, maybe the bloom pass is set to nearest neighbor?
- BUG: adaptive FOV is smaller than it should be, I need to set my FOV to about 96 to get the same FOV as 90 in QuakeSpasm and DarkPlaces (using a 16:9 display). Basically FOV 90 should adapt to FOV 106 in 16:9, not 100.
- BUG: TGA alpha mask isn't properly supported, e.g. font replacements have white outlines.
- No protocol 999 support, crashes when loading Orl's maps like Ter Shibboleth or oms3_2.
- Remove the whole "opengl32.dll found" shenanigans, in this day and age it is most likely a graphics wrapper like ReShade, not the 3dfx driver from the original GLQuake package from 20 years ago. Don't make people hex edit your .exe to get some post-processing effects going on.
- Unlock the OGG support for external music, Mark V already supports it internally, why comment it out on purpose?
- Add optional HUD filtering, nearest neighbor looks bad at non-integer scaling values.
- Add PNG support in addition to TGA.
- Add the "N64 style" minimalistic status bar layout as seen in DirectQ/qbism/RetroQuad/etc. Crazy convenient.
- Add (integer) HUD scaling for the software renderer.Some info on this:
- Add alpha/fence texture support for the software renderer.
- Switch the software renderer from 8-bit to 16-bit to have enough colors for colored lights and proper transparent water. This is what RetroQuad is doing. Or Half-Life for that matter. 
Baker, do you have some public repo for this project, or just this zipped sources? 
4 player coop with quake spasms controller support is my only wish list item 
- Switch the software renderer from 8-bit to 16-bit to have enough colors for colored lights and proper transparent water. This is what RetroQuad is doing.

It isn't. Retroquad renders everything in 8-bit color, using 8-bit tables to access a single 8-bit indexed color palette. The tables are generated from 24-bit color data upon booting up the engine.

Retroquad doesn't use 16-bit color anywhere, and it doesn't do any direct-color transformations in realtime. 
Baker, do you have some public repo for this project, or just this zipped sources?

The source code is in .rar format. ;-) 
FQ And QS? 
Silly noob question time:

Can Fitz Quake happily coexist in the same folder so as to share the same Id1 folder and the like? 
Mark V and Quakespasm. 
Of Course 
I have been putting Mark V, Quakespasm, FTE, Darkplaces etc in the same Quake installation for years and see no problem other than the save game incompatibility between Darkplaces and others, which is in itself easy enough to fix manually. 
Cool Beans. 
That's good news. Thanks for the reply. 
Broken Links On Home Page 
Hey. Just thought I'd let you know that there are a couple of broken download links on the Quakeone/markv page.

The Undergate download is broken and so is the Frogbot mapset.

I presume it's something to do with the 'updates' that went on there a while back... :) 
Also: Why Doesn't This Autoexec Not Work? 
joystick 1
joyadvanced 1
joyadvaxisx 3
joyadvaxisy 1
joyadvaxisz 0
joyadvaxisr 2
joyadvaxisu 4
joyadvaxisv 0
joyforwardthreshold 0.15
joysidethreshold 0.15
joypitchthreshold 0.15
joyyawthreshold 0.15
joyforwardsensitivity -1
joysidesensitivity 1
joypitchsensitivity 1
joyyawsensitivity -1.5
joywwhack1 0
joywwhack2 0

bind "AUX5" "+jump" // jump on L1
bind "AUX6" "+attack" // fire on R1
bind "AUX30" "impulse 10" // cycle on dpad-R
bind "AUX32" "impulse 12" // reverse cycle on dpad-L 
Can you define "not work"? 
I create an autoexec.cfg file with the above text in it (a standard vanilla Quake cfg for controller support).

Mark V doesn't recognise it properly. The console says the engine loaded the autoexec file but the controller doesn't work at all in-game. No response on any button press or joystick movement.

It used to work in older builds of Mark V and Fitzquake. Just not Mark V 1.00. 
Check your syntax. Unless I am on crack many cvars need the quotes. 
I don't not know why it doesn't not work. I mean, the autoexec itself works -- it's just that I seem to recall that joystick support was simply disabled at some point in Mark V.... So yeah; it used to not don't work and now it won't don't not work.

Baker will have to make it so it doesn't won't don't not work when he gets back to working on Mark V again. It's as simple as that.

There is a workaround though -- you need to use a program that turns your joystick into a keyboard emulator. Something like JoyToKey or Xpadder. You might need to look for older versions of those programs, if the newer versions are no longer free. AutoHotkey can probably do that too, but is a bit more fiddly.

Good luck getting your joystick to stop won't don't not working. 
Linux Build And Music 
Is it possible to play background music with the current Linux build? Can't get it to work. 
it only supports cd audio on windows, and directsound is of course windows-only and artificially limited to just mp3. 
Yeah, the joystick code in Mark V is not quite correct.

If you dig deep in the OLD Mark V thread (Google up FitzQuake Mark V), a user with a joystick kindly posted instructions on how to make it work well.

I don't have a joystick, so I messed something up when I was trying to be "cool" or something.

/Mark V supports mp3 music on Windows and the Mac (and in my private experimental build, on the iPhone as well), but not Linux mostly because I didn't have time to get that up and running when I was making the Linux version. 
Someone should donate a cheap dual-analog usb gamepad to Baker so he can test this stuff.... You can get them for like $5-$10 on ebay.

Or if you wanna get more fancy, get a Logitech F310 gamepad ($10-$15), which has a switch on the back that lets it change between using XInput/DirectInput, for thorough testing.

Currently Mark V reports that it detects when a joystick is connected, but can't seem to detect any input from the gamepad, using either input method. 
Where Can I Get The Most Recent Version 
of winquake_gl? the latest packages don't contain it. Is there an archive somewhere? 
My Bad 
just found the archive


Within the next week, I expect to release a new version.

1) Optional Mouse driven menu video. The video doesn't do it justice how convenient it is.

When you have mouse driven menu, you use the menu about 8 or 9 times faster and it becomes far more convenient. You just click away.

The menu looks like the Quake menu is 100% the same keyboard menu, it just is mouse capable also.

2) Fix tool inspector glitch, the save game glitch Pritchard pointed out.

Time has not been one of those things in much supply lately. 
I'm very excited to try this new version out. Looks very cool and I LOVE that Levels menu. +1 GG and all that. 
what's the lowdown on glwinquake? is the most recent winquake gl and not labeled as such? was it discontinued? 
Controller Support? 
Just wondering if controller support will be re-implemented in the upcoming release. :) 
Another Thing 
I think sv_aim belongs in the preferences 
It's a subtle distinction, but sv_aim is a server-side cvar whereas the options menu is client-side.

What that means is that a nonlocal server could override if it was set from the options menu.

What it also means is that a client may not actually have permission to change it.

So on that basis I disagree; it shouldn't be in the options menu. 
I love the new lightning-bolt effect in Mark V, but i also love the classic particles in the other weapons.

Is there a console command that changes only the lightning-bolt effect? :/ 
OGG support please! (For reasons I mentioned above in #1767.)

And this would apparently be a really simple fix, since Mark V already plays OGG format -- it just doesn't bother to look for OGG files ? 
Does MarkV play ad_sepulcher?

How about adding lit support for the Winquake port? 
Mark V - Build 1050 - Ultimate Mouse Driven Menu Edition 
Direct X 9 - Mark V 1050 - Windows | Source

* Fully mouse-driven menu yet it is the classic menu.
* Tool_inspector works again. (Pritchard)
* Load game + death bug fixed. (Pritchard)
* Numerous other small enhancements/tweaks.

Special thanks to Pritchard in particular for bug reports and so it took this long for some of them. And probably Gunter when he isn't annoying or ticking off MH. Thanks to all other providing feedback, bug reports, suggestions, criticisms. And perpetual thanks of course to MH, Spike, ericw and metlslime.

I had hoped to get this out a day or 2 ago, but I wanted to get the mouse-driven menu tuned to exacting specifications.

Also mouse-driven was very, very, very hard to do. The Quake menu code is some of the ugliest in existence.

@killpixel, c0burn - I expended all my energy getting this across the finish line. It was harder to wrap up than I expected. @ Tribal - yes, and maybe Gunter will make himself useful and tell you how (type "find qmb" in the console and it tells you different cvars to turn stuff off) -- because I'm a bit sapped.

(mh note: scr_sbaralpha doesn't work with DX9 -- tried some tweaks/hacks but still failed -- and is the sole deficiency to what otherwise should be a rock-solid release. If some time in the future you had some time to check it out at a time of your convenience, that would be cool. No rush ;-) And thanks for your contributions!). 
btw, thanks!

@1830 unnamed guy - "I think sv_aim belongs in the preferences"

Well, it is in preferences!! Haha. 
Thank you!

You're awesome =D 
"And probably Gunter when he isn't annoying or ticking off MH."

I don't think that ever doesn't happen.

It looks like the previous issue has been fixed where you could see "the sky" through entities. It doesn't seem to happen any more. (#1665)

You can still see shadows though entities but only if you have set r_shadows 3 (I know those are experimental shadows though).

I have a transparent fake player guy inserted by the ent file, and he is only transparent if I set gl_fullbrights 0. If I set it to 1, he's solid. I'm sure I've mentioned this before. Ah yeah, looks like it has to do with fullbright textures (#1082, #977). That probably wouldn't be the same issue with the scr_sbaralpha.

gl_overbright_models 1 can also allow weapon models to be properly transparent when you have the ring, but not the transparent entity guy. 
@ Tribal

Yeah, as Baker said, you can use "FIND QMB" to see all the QMB effects. If you really wanted only the lighting effect, you'd have to have "QMB_ACTIVE 1" and "QMB_LIGHTINING 1" but have all the others manually set to 0!

I would suggest doing "FIND QMB" then type "COPY" to copy all those variables to the clipboard, then paste them into a text file and edit the file to remove unnecessary text and change the values of everything to 0 except the things you want. Save it as a cfg file then you can just exec it. 
Gunter +1. He might know the engine better than myself, haha. 
Let's man up. Besides I am feeling the code rage ...

March 9th. New feature.

I shock your world. SUBMIT! 
Marking The Calendar 

Thank you!

It works like a charm =D

Tho only thing weird is when I set the command "qmb_blood" to 0 it doesn't change the blood to particles, it mixes red particles with blood sprites o_O 
Hey, you're right. "QMB_BLOOD 0" doesn't deactivate the QMB blood.

You found a bug for Baker to fix!

You're an honorary Junior Grade Gunter now!

Find about 500 more bugs and you can almost reach my level ;D 
scr_sbaralpha doesn't work with DX9 -- tried some tweaks/hacks but still failed

Had a quick look over the code; you don't seem to be setting glTexEnv (GL_MODULATE) when drawing alpha pics in the status bar (compare with the setup for Draw_ConsoleBackground). In theory that shouldn't work in GL either, so I guess you just got lucky that drivers accept it, but you really should fix it for both. 
Yeah, Confirmed 
That fixes it.

Interestingly, it's also a bug inherited from the original FitzQuake code, so it's been around for a while. 
Hello and thanks for the this great engine!
I was making some tests running custom code for a mod and using "eprint" to debug some entities. However, this is making Mark V run unplayable with very low fps. I think it might be a bug, because other engines doesn't have that problem.
Also, loving the mouse features.

Congrats On The Release Baker 
Mouse Driven Menu 
feels really good, thanks! 
Finally fired this up today. It's great. The mouse menus are very nicely engineered. The engine is snappier too I think. GG 
@mh - oops! Thanks! I'll see if I can fix. I'm glad you are always in "rendering godmode" because I shift and fade focus. Haha!

@ericw - Thanks, obv! If you weren't around, I think I might feel alone because mh and Spike seem to know everything and it feels like only you and I have to scale up and grow, haha!

@dumptruck - Yeah, time and energy expended to make it perfect. Meticulous.

@hipnotic rogue re: joystick - I care about joystick. Right now, I'm not zoned into that but have "THE QUAD" running in some other departments and I need to kill the monsters my QUAD can nuke quickly as I don't have unlimited time.

@fifth - Thanks! I haven't forgotten about about joystick/four player. I need to level up to that point, killing some zombies immediately in my sight that I can kill. I want to see if I can reward Spirit emotionally. Spirit has made big sacrifices to build something awesome/nigh impossible and in my heart I want his ideals to come true. Plus when I see people stressing Spirit out every once in a while or accusing him of not doing enough, I just don't think that should be the reward for building something.

@epiolon - '"eprint" to debug some entities' Ah, I'm not Mr. QuakeC so I figure that is QuakeC printing of some sort .. perhaps a more QuakeC dev can translate to what causes your issue. 
I think we need to blame Gunter that you found a QMB cvar bug. I am really disappointed that Gunter let that slip by his bug testing.

I expected more from him, haha! 
Eprint Behaviour 
Standard Con_Printf will do a full screen update.

This is really useful if you're printing some text and you want to see it on the console right now.

It's painful if you're doing lots of small Con_Printfs to print, say, an entity, because each entity printed could trigger tens of screen updates.

If you have console logging to file always on it's also going to be constantly hitting the disk - again, tens of disk writes per entity.

Changing ED_PrintEdict to use Con_SafePrintf can help with the first. For the second you really need to do what the doctor said when you told him it hurts everytime you do this. 
I look into that, I get your drift. It isn't priority #1 on my list, but yeah message received. 
Addendum: Despite 12 beers to end a wonderfully chaotic weekend, sounds like an easy fix.

March 9th surprise is going to be a total blast! 
Con_Printf's screen refresh kinda sucks.
1) its slow!
2) ANY prints inside the drawing code results in recursion, and then more recursion, and then eventually CRASH! catching out many newbies.
3) if your drivers are tripplebuffering then its going to show the wrong print last, which makes it really misleading.
4) a number of frameworks don't allow you to swap buffers yourself making it a complete waste of time.

If you trust the engine then its redundant anyway - win32 engine devs are probably better off using OutputDebugString, while unix users will have working stdout. Its really only dos that 'needs' prints to be displayed onscreen NOW.
imho just redraw the screen only when developer is set (and when not recursing), then users can won't be sitting around waiting for the loading screen.

The one exception is with the connect command, but imho that should be made to be non-blocking anyway.

in the mean time, disable vsync. 
I will avoid using the function for now.
But seems like there's no vsync option on Mark V (and i usually disabled it because of input lag) 
if you do "find vsync" don't you find vid_vsync?

Maybe it should be a menu option!!

*hears Baker frothing at the mouth* 
Hey, I gotta leave a few bugs unreported so everyone else can experience the thrill of ... reporting bugs!

Hm, it looks like I did mention in #653 about blood and fullbright, which you looked into but couldn't exactly fix. mh mentioned there's a 1 and 2 setting for QMB blood. I had suggested adding some standard particles into the QMB effect to allow some fullbright to still happen.

Tribal mentioned: "when I set the command qmb_blood to 0 it doesn't change the blood to particles, it mixes red particles with blood sprites"

I am not at my Quake computer at the moment -- I'm wondering if maybe you did mix in some regular particles for the 0 setting, instead of disabling the QMB effect.... If not, you should have a setting that does do that! I guess qmb_blood 3, if both 1 and 2 are already used. What is the difference in them? 
MarkV seems to have console debug logging enabled by default, so it does hit the disk for every Con_Printf, meaning that debug printing of entities will be incredibly slow. 
Glad to hear you're still working on the split-screen.

No idea if borrowing the controller code from QS is possible but I'd say it works best there by default.
I'd say that having multi-controller support/setup would be best placed in the multiplayer setup menu.
Would be awesome if going into the multiplayer setup menu also dropped straight into split-screen and each player could adjust their own character colour, name and bindings.

I suspect it'd be a huge undertaking in code but would be super awesome for couch gaming, something that would probably go down really well for those who launch through steam etc. 
So Where's This 9th March Surprise ;) 
RIP Baker. 
That's The Surprise 
He vanished. Not exactly what we all thought or needed, but definitely a surprise! :P 
I Predict STILL Hungover. 
It seems that QMB_BLOOD 0 causes all kinds of particles (not just blood) to be a mix of QMB + Standard particles -- my blue water splashes and grey chat smoke, for example (I use lots of particles in FvF).

Also, OGG support, please! 
Update! Part 1 ... 
No I didn't vanish. Despite my stupid drunk posts, which when I get the time I intend to apologize to snug for ... I had some "coder frustration overload" + way too much beer.

Which is a nice reminder of why to patient, humble and kind. Coding is like a deathmatch against unmovable objects. You lose. A lot. Sometimes hard.

It is not fun to lose, nor lose hard. And I did not take it well that particular day. 
Update Part 2 
I missed the target date of March 9th.

I expected rolling over the coding problems and instead got socked with several deep and severe issues. The issues kept building and building.

Eventually, I toughened up and geared up for a brutal fight. One which I won 3 hours ago.

24 hours: Version 1.70. Part 1 of 2.

Both Part 1 and Part 2 are going to change things quite a bit.

And I'm not going to ruin the surprise, but a couple of developers likely suspect what's up. 
Add: Many people may think Quake is dead.

It isn't. Quake isn't dead. It is asleep.

In the next 24 hours, we will not be waking up Quake.

But it will be great eye opener of precise the manner of which it can be done! 
He goes from "drunken poster" to "vague mystical guru posts."

Either way he's working on Mark V, so it's good. 
I Think... 
I also need to get drunk. Otherwise I am not able to understand these mysterious announcements... xD 
In the next 24 hours, we will not be waking up Quake.

Quake will be waking us up. Showing us that what we thought was reality, was in fact a dream all along.

Looking Forward To It 
Really enjoying 1050. Although I am getting a water warp message in developer 1 even when there are no liquids in the map. 
Mysterious...I'm Intrigued 
Will It Run 
... all maps of the latest "Arcane Dimensions", that's what we are all wondering about! :P

But seriously, right now I wouldn't know how you could significantly improve Mark V beyond its already impressive feature list. Baker implemented pretty much anything I asked him. Sure, OGG music support would be nice, but Baker's teaser indicates it's gonna be a lot bigger than that. 
I Dunno, Ogg Would Be Huge 
OGG support, please!

Hey, how does everyone else pronounce this engine's name?

I was on Discord talking with a guy who is doing some Quake streaming on Twitch ( and he was saying "Mark 5" but I always say "Mark Vee" ... :? 
Mark Five 
V Is The Roman Numeral For 5 
I was born in MCMLXVIII 
Yeah, V is the Roman Numeral for 5, but with Mortal Kombat X, for example, X means 10, but the official pronunciation is "Ex" (says Eb Boon:
X is 10 because V is 5 and X is an upside-down V with another V above it. 5+5=10. 
This is a case of video game marketing and communities ignoring an ancient numbering system from one of the most powerful empires in history.

Who wins this one?

Mark V Build 1080 + Touch Screen Support (iPad/iPhone) 
Download: Windows | Direct X | Linux | WinQuake (Plus a WinQuake GL for KillPixel and a couple of others)

Source code: here iPad/iPhone source code is in there.

* Full multi-touch iPad/iPhone source code for an experience rivaling Minecraft for the iPad in user-interface.

** Drag look just like Minecraft
** Adjust sliders in the Quake menu by touch
** Optional support for bluetooth keyboards like the $7 ones at Walmart that support iPhone and Android.
** Tap fire. Double tap on the Ogre to fire at him if you like.
** 5 taps to host a "New Game" (cooperative).
** At the moment, it is the WinQuake build, can't muster up the stamina for the Open GL at the moment.
** Thanks to Mark V LAN discovery borrowed from Spike's fine work, "Join Game" for a LAN game is a breeze, just like Minecraft.
** Any map that works in Mark V, works on the iPad. But the iPad gets lower frame rates than a desktop, so standard Quake maps are plenty fast but it is likely that a 400 monster map with open spaces would run unacceptably slow.

* Mouse-driven menu on Linux and in WinQuake

* Touch Screen mode that I hope works on, say, Fifth's Surface Pro. All builds have a touch screen option in video options. Unfortunately, I do not have Surface Pro so there is not multitouch support, I would not be able to test it.

* Direct3D sbar alpha works thanks to MH's tip.

I may or may not take a quick stab at an Android port. If I were to do such a thing, it would likely be basically done in a 48 hour period. My main concern is that I think for Android I was use SDL2 and if I recall, SDL2 had a sound lag issue for me on Android -- and if it sound lag, I would be irritated.

This is Part 1. Part 2 comes in a few days, has nothing to do with mobile devices.

@Tribal - I took a quick look at the qmb_blood option, isn't quite the quick fix I had hoped. Thanks for the bug report. 
The LAN discovery feature is good news! As for iPad support I am... bemused but entertained? :-) I am inclined to steal my wife's iPad mini to check it out, altho looks like I'll need to figure out how to build it? 
I've Got A Surface Pro 2...can Test Later 
But I can't think of a use for multi-touch unless the Win10 build also has the touch controls for movement. 
Impressive. Congrats.

And I was concerned with your health... Coding and drinking doesn't go well for me, so I never drink. 
"Unless the Win10 build also has the touch controls for movement."

It does!

Video Options -> Touch Screen

Without multitouch, you can only touch one thing at a time, which sucks compared to the iPad version where you can press 3 things on the screen at the same time.

@johhny - To build for an Apple device, you have to have a Mac. My source code is friendly, you literally click "Build". But the sticking point is having a Mac. Plus, iOS has some new red tapes that iOS 9,8,7 didn't and the project probably doesn't meet those red tapes so you might have small chores like making a 98x82 icon and a 196x163 icon and 10 other pesky nuisances like that.

That being said, playing on the iPad version is un-fucking believable. When I got the multitouch interface working right and then loaded it up, I was not prepared for the level of awesome. 
Thanks! Nah, my health is 2x awesome.

I encountered Level 92 frustration developing this version, it was so frustrating at one point.

I had to get real tough and prepare for a dog fight in the mud. Obviously, I rose to the occasion. Besides, can't have mh or Spike thinking I'm not hardnosed like they are, haha! 
multitouch is surprisingly useful for touchscreens even if not explicitly needed by the app's UI, just for example having it not ignore a second tap because your finger from the first tap hasn't fully lifted off the screen yet, or, not completely ignoring everything you do because your hand holding the edge of the tablet is slightly touching the screen edge. 
Techical Note @ Qmaster 
On an iPad, you can touch 16 things at the same time.

If mh reads this, he may recall I implemented his "single point of checking mouse state per frame" mouse input paradigm long, long ago in Mark V. This version of Mark V extends that philosophy to the touch controls activation/deactivation and it was at first a major nightmare, but then it collapsed in simplicity and beauty after a dozen revisions. 
I have the multitouch tracking everything.

The user interface only acknowledges one press per button where the whole screen is a separate button.

To access the menu, you press a transparent triangle hint in the top left corner.

A funny thing, I was thinking of you off and on while writing this. To the best of my knowledge, you and Sleepwalker are the only other 2 that I know for sure is familiar with the ins and outs of the Apple interfaces and while well conceived, they required quite a bit of learning to use properly. 
But There Will Be 
... a new OpenGL build, right? That's the one I am religiously using! 
Is there something that the DirectX 9 doesn't do or some specific reason it doesn't meet your needs?

The DirectX 9 version is, in my view, absolutely superior in every way.

It is:
1) Does everything that the Open GL does (99.9% on that).
2) Vastly higher frame rates that blow away any other Quake engine except DirectQ and only eeks out a small win against FTE Open GL (FTE Direct3D likely beats Mark V Direct 3D because FTE has better rendering code). MH's extreme craftsmanship of the Direct3D 9 wrapper allows Mark V Direct 3D super-speed despite the fact I should rewrite the underlying rendering to probably get another 75% to 100% speed gain.
3) Bad Open GL drivers? NVidia doing a wacky update -- Direct 3D is immune! Can't happen. So stability + reliability +++. I get a bit tired of NVIDIA doing some update and it breaks something in Open GL, but the Direct X cannot be updated by NVIDIA (this is my understanding at least, and I think I am right).

Those are my thoughts. 
What does your Linux version use? I'm clueless on this stuff but hope to have a Linux machine up sometime soon. Also any clue as to why I am getting a waterwarp size is 1024 message in developer 1? No liquids? 
Hmm. Lots of duplicate symbol errors when linking the iOS build, conflicts between input_surface.o and various other .o files.

My first guess was that it might have to do with eval_flags/eval_frags being declared as int rather than extern int in progs.h, but changing that didn't help anything that I could see.

Will give it another whack later. 
Waterwarp Size Is 1024 
I think that message comes from code I wrote. I'll review it hopefully tomorrow and see what the cause might be. 
I use Ubuntu but the Linux binaries works on a fair number of other Linux distributions, or so different Linux users have said.

@ johhny - if I recall, there are 288 source files but if sometimes seeming randomly -- like maybe if it targeted the simulator or a generic device? -- XCode would try to compile 568 files. I plugged in an iPad and targeted that and it works fine. I am using XCode 8.2, I think the current version is 9.2 and since it seems like every XCode upgrade introduces some quirks/inconveniences to tackle, I put off upgrading a bit. Short version: Couldn't quite say, 
OK. I'm targetting simulator at the moment. Will wait until later when I can plug in the iPad. 
@johnny ... be sure create a folder called id1 in Documents on the iPad and throw pak0.pak (and pak1.pak) in there.

I can't remember the method to put files on an iPad offhand.

Note to self: Use Mark V http download offer to download pak0.pak or something on startup if it doesn't exist in the next revision. 
Direct X V1.80 Build 
I have taken a quick look at the Direct X build and it seems to look and behave just like the OpenGL one, so I stand corrected with my prejudices. I cannot say much about speed differences, but it feels smooth alright.

Still missing my favorite gl_nearest_mipmap_linear option, but besides that, it's all fine.

Is this build capable of running all the new maps of Arcane Dimensions now, btw? 
I need to add Sepulcher support. It is on the "todo" list.

My first priority is getting new unreleased capabilities off my hard drive and into reality.

Then I'll be adding things like Sepulcher support, etc. 
Go to Video Options -> Pixelization.

I'm 99.9% what you want is in the DirectX 9 build.

Let me know. 
waterwarp size is 1024

This is just a notification that should only happen at startup and when/if the video mode changes. If it's happening more often (every frame) it's a bug. It's nothing to do with water surfaces but is rather used for the underwater warp effect.

It happens even if the current map has no water because the next one (or the previous one) might.

The alternative is to destroy and recreate the texture each map, which could lead to extreme video RAM fragmentation, or to create it on-demand which (in addition to fragementation) could cause runtime hitches and stalls. So I decided instead to burn a little extra memory in exchange for performance.


This should be fully supported; I've reviewed both my original wrapper code and the MarkV implementation and can confirm that. 
I actually checked explicitly for that. The only options for the pixelated look are gl_nearest and gl_nearest_mipmap_nearest. Just like in the previous (OpenGL) builds.

Smooth mipmaps transition ftw! ^^ 
It should be settable from the console though. If something's missing from a menu option it's nothing to do with the API used. 
Egads. I version 1.36, I had gl_nearest_mipmap_nearest. Then I knew it needed to be the "other one".

So I switched it to gl_nearest_mipmap_linear. Then I forgot I did it.

Then I worked the todo list and switched it to the "other one" again and since it was gl_nearest_mipmap_linear in the source, I changed it to gl_nearest_mipmap_nearest. 
Then basically you switched it twice so it was effectively as if you had never changed it?

Well, now please just change it ONCE again and I can die happily. ;) 
I'm trying to cause this developer 1 + r_waterwarp message, but not having any luck. 
Line 812 of gl_texmgr.c is where it happens. 
Mark V - Buiid 1081 
Direct X | WinQuake - Windows rebuilds
(killpixel's winquake gl in there too)

Got rid of dumptruck's warp message printing in developer 1 and another message that was spamming some, gl_nearest_mipmap_linear replaces gl_nearest_mipmap_nearest and fixed noticed the menu being drawn during QuakeC or demo playback or disconnect go to console. 
That was a really fast fix. Thanks a lot, Baker! Another proof that Mark V should be anyone's favorite vanilla-style port since it's handled so well! :) 
thanks for the update! 
Thx Boo 
Crash Report 
Mk V DirectX 1081 crashes to desktop without error message (just the usual Windows notification that the program "stopped working") when trying to use the remade ogre model by Chillo:

Download (1.0 MB):

Tested in E1L2, crashed right away. The model is quite big, but I dunno if that's what's causing the crash. 
What engines is it known to work in? It looks like DarkPlaces and DirectQ.

Mark V supports 3984 verts, the maximum possible in WinQuake according to a note by aguirRe.

If it works in Quakespasm, for instance, let me know. 
It also works in my original FitzQuake implementation that I built the D3D wrapper on. 
Quakespasm Test 
Model loads without issues in latest Quakespasm 0.93 x64 build. According to QuarK, it has 1290 triangles. 
Number of triangles in a .MDL file can be very differrent to number of triangles in an engine. Most engines will unpack them to strips and fans for drawing whih can change the counts quite dramatically.

Basically, it's completely unsafe to limit the verts in a GL engine to the same limit as is used in software.

@Baker: running a debug build should tell you exactly where this crashes. 
Another Model Issue 
Another of Chillo's models, the Shalrath, gives an error message when trying to load the model:

"Skin taller than 480"

Package with model (shalrath.mdl): 
Ignore my last report. Just took a look at the Shalrath skin file, it's obviously a placeholder. It's just still about that ogre model, then. 
Another Crash 
E4M6 crashes with the Authentic model improvements pack. This used to work with previous (OpenGL) builds of Mark V.

Download model pack:

I could not identify which of the models is causing the problem. 
Map Crashes (summary) 
There are more maps that crash. I checked all maps of the original campaign and the model improvement pack does not work in these levels:

E4M6 (as reported above) 
These maps likewise work fine in my original codebase.

It's obviously a model that's common to them all overflowing an internal buffer that's differently-sized in MarkV. 
Found It 
I found the model that causes the problem. If you remove the Fiend model from the improvement pack (demon.mdl), the maps stop crashing.

This leaves two models to be investigated, demon.mdl from the existing improvement pack and ogre.mdl from Chillo's release. 
The only thing I can find as a possibility is mipmap generation for non-power-of-two textures.

In my original code I let D3D take over mipmap generation, whereas MarkV retains it's own mipmap generation.

These models have unusual texture sizes: odd numbers, not multiples of 4, etc. So when you go down a miplevel you need to be aware of whether you are going down exactly to half size, or if rounding down is involved, and depending on how the engine handles memory allocations for this, it may trigger a crash. 
Well, curiously the models won't work with Mark V 1.36, either. I just tried. However, they should since I remember playing through the entire game at least with the demon model since it is already in the improvements pack. 
If It Helps... 
I just tested various DX9 builds from previous Mark V releases. The last one that works with BOTH models without crashing is 1.27 rev. B:

Starting at 1.28, the crashes start:

Hopefully that narrows it down for Baker to find what's causing this. 
Time To Dust Off The Surface... 
That is a high quality investigation, thanks for the detail that should make tracking this down easier.

I guess I'll do an OpenGL in the next one *only* for the purpose of trying to nail down what is going on with this.

I *do* want to know what the differences are and unwind this small mystery, but also I want to get some more new stuff out. I want to get new concepts off my hard drive and into reality.

Speaking of which. I expect a new version with something quite new in 24 hours. Maybe 36 to 48 hours because I had to kind of fork the codebase and need to "unfork" it to get the source code tidy.

This isn't the "big one". The "big one" is still a few days out. 
@fifth - Really? 
I thought you used your Surface Pro all the time. 
Map Hard Crashes 1.81 
I am testing maps for dm4 Jam on Mark V 1.81 One of the maps uses a trigger_once to trigger a map hack using an info_null using W_FireLightning

The engine freezes and I have to Ctrl+Alt+Del to kill it. Here's the map and source. It's the large trigger once immediately after the info player start.

Map plays on most recent versions of DarkPlaces, FTE and Quakespasm 
In Order To Avoid Misunderstandings 
These crashes with high-poly models occur in both DX and OpenGL builds starting at 1.28, doesn't matter which one you use.

This also explains why I remember the new Fiend model working - last time I launched Mark V was well before summer 2017. 
I rarely use it tbh, I may use it more since I get extra long lunches now and could map in them.
It has some issues with keeping charge and the keyboard isn’t great so this is why, plus I have a decent PC anyway 
I remember finding out that the skin loading code for either SPR sprites or MDL models in vanilla WinQuake has a bad pointer arithmetic. I really don't remember exactly where it is though, but its badly offset by a very small value, something like 4 bytes. I remember being surprised that it didn't cause any crashes. 
Dear Spike, gamers, programmers and Quake fans. Could any of you lend any knowledge about multiplayer capabilities for FitzQuake Mark V? Does one need to setup static ip, forward ports and establish DMZ for good old coop with a friend over the internet (local server)?
I found Mark V enging is very good and i love it. But Quake without coop is not complete. 
Port Forwarding?? 
As far as I know you simply have one player start the game as a host and the other type in the IP address of the host in the join menu, same as usual. 192.168.whatever.whatever.

On Windows you can do Winkey, type run, hit enter, type ipconfig, hit enter then look for ipv4 address. 
You're assuming a LAN game tho. Cadaver747 sounds like probably he's talking about co-oping over the internet?

Baker would of course be the best guy to ask about Mark V's port usage. I'm pretty sure I recall that he's included some of the fixes done in a few modern NetQuake engines so that it only requires its single listen port (26000?) to be forwarded. 
for engines using a single server port, just reconfigure your router to forward that sepecific port (26000 for nq servers, 27500 for qw servers) to your machine, then eg google for 'ip' and give that to your friend to connect to (don't depend upon windows - it'll show you addresses that are only valid on your lan, which is not what you want).

for other engines, you'll need to set up dmz stuff crippling your router's nat+firewall stuff, as get your friend to do the same.

all quakeworld servers+fte+dp+qss+markv use a single port for connections. the rest all suck big hairy donkey balls (including quakespasm) at least for internet coop.
this is not the only reason that most people favour quakeworld for online play, prediction is another significant factor...

sidenote: with the exception of non-fte quakeworld, the above engines all also support ipv6. assuming your isp isn't dragging their heals and generally being lame then ipv6 makes things cleaner by removing the need for NATs. You'll still be firewalled by any good router though.

lazy people: if your router follows certain ICE-friendly rules (eg most home routers but few business ones), you may find that just setting sv_public 1 on your server is enough (the heartbeats should automatically open your firewall/nat).
the other person can then use their client's menus to find your server according to its hostname cvar - if they can spot it. This should be true of FTE+DP+QSS, but I don't think markv supports any real master server protocol so good luck with that.
probably the server listed by the master will appear to use a different ip+port, that's just the nature of NATs, but means they can't use a direct connect command.
But again, this depends on the server's router, so it might not work. Setting up explicit port forwarding on your router should fix it for any other routers.

do not use 192.168.x.x over the internet. it will not work. 169.254.x.x won't leave your lan. 10.x.x.x is another unroutable one, 127.x.x.x is also not going to work, 172.16.x.x/12 isn't going to go far either , and 100.64.x.x/10 means you're fucked and need to get a new ISP (carrier-grade NAT - this would only be between you and your isp, so you're likely to be screwed without otherwise noticing it) - ipv6 is your only real choice when it comes to CGNAT, or just get the other person to host. 
Mark V Multiplayer Works! 
Thank you Spike! I tested Mark V 1.36 and 1.60 (beta) for coop with my friend over the internet today. It works like a charm, just a simple port forwarding from my external ip to internal (for port 26000) and that's it!
You wouldn't believe what i tried to do to play Quakespasm online. Mark V rules!

Too bad not all maps from Arcane Dimensions currently supported by it. But i'm sure that'll be fixed in time. 
Cadaver747, you and your friend could also try connecting to FvF, which is almost always in co-op mode. Then you don't have to mess with running your own server (though it sounds like Mark V made that easy for you anyway). Other people might connect to FvF and join you as well. It's... different than standard Quake, with lots of cool options and enhancements.

Arcane Dimensions (only 1 Map To Go) 
Correction, only 1 map doesn't work, it's ad_sepulcher (The Forgotten Sepulcher).
Host_Error: ModLoadLeafs: 74168 leafs exceeds limit of 65535 
Thank you Gunter, but unfortunately your server is not meant to connect from my country (Russia), ping is almost 150. The idea of implementing RPG elements in Quake is quite interesting though. 
ad_sepulcher needs a bit more than just the standard "big map" support.

It's also the case that there are a handful of big static arrays scattered about the engine for which, by the time you move to supporting ad_sepulcher sized maps, you really need to move to dynamic allocation.

Finally, ad_sepulcher is going to run like shit in the GL version of MarkV because it still uses glBegin/glEnd code. It will run fine, but still far more poorly than it should, in the D3D9 version because it's transferring a lot of vertexes that don't even change to the GPU each frame. The particle system may however kill it with draw call counts; IIRC there's some very sub-optimal state change stuff hanging over from the original GLQuake still in the sprite code, and that's going to prevent the D3D wrapper from being able to batch things up. 
Man, I would have killed for a 150 ping 15 years ago when I was still using dialup and playing lots of Quake, and still kicking butt in deathmatch :D

But these days people think a 150 ping is unplayable, even in coop! ;) 
ad_sepulcher doesn't run reliably in QS either. It crashed from time to time while I played, which forced me to quicksave often.

Making an engine that runs it reliably seems to be one of the ultimate challenges in Quake engine coding. 
That's interesting; I would have thought that QS was the target engine when the map was being built, and would have received the most testing through all iterations of the build. 
I Thought QSS Was 
Well, my laptop has an Intel HD Graphics 3000 GPU and 6 GB of RAM, running Windows 7 64-bit. And the crashes happens after exploring the map for a while. First the engine starts stuttering and the hard drive starts making noise like crazy, and then the engine crashes. 
...the hard drive starts making noise like crazy...

Sounds like something else wrong with your machine that's only manifesting when it's under a particular load. There's absolutely no way that any Q1 map should be thrashing the HD under normal play - everything is in memory. 
OGG/MP3 Using Fmod 
Baker I'm 99% done adding ogg/mp3 to Qrack using fmod.
It's *way* simplier than you might think. Only thing i have to do is add a cvar to init/uninit the fmod instead of using a command-line parm.
I can shoot you a copy of my fmod.c file. There are other entry points where it plays cd tracks but they all points to functions contained in that one fmod.c file.

It's so simple i was kicking myself for not adding it sooner; not until i read here people yelling "OGG SUPPORT!" did i even pursue it. Know you use fmod, i thought i'd pass it along. 
I'm not sure if there is anything special about ad_sepulcher that makes it difficult to run - it has careful visblocking and with the fixes to func_detail in qbsp I made, the PVS is good quality. I'd expect it to have similar fps to other large maps in AD (and it does in my experience).

(The exception is if the engine supports the fancy particle extensions, i.e. QSS. Particle effects for all torches in the map render every frame without regards to the pvs. Also, various particle effects cause tracelines to run. This applies to all of AD, though it probably has the biggest hit on sepulcher due to probably having the most torches.)

Sorry to hear it crashed for you mankrip. The only thing I know that could cause disk thrashing is Quakespasm uses the original Cache_* code, which, if the cache is too small, will cause it to read MDL's off disk every frame. This is something I want to fix and I know of mh's tutorial on insideqc about it. Do you remember if you used an explicit size with the -cache command-line argument? 
There's absolutely no way that any Q1 map should be thrashing the HD under normal play - everything is in memory.

Windows automatically stores RAM contents in the swap file, you know. And it also happened without anything else running, right after I had to reboot because the whole OS got unresponsive.

I might run it again later and take a look at the RAM/CPU/etc usage in the task manager. 
Do you remember if you used an explicit size with the -cache command-line argument?

IIRC I've only used the parameters recommended in the readme file. I may look into it after going back home. 
There's absolutely no way that any Q1 map should be thrashing the HD under normal play - everything is in memory.

If the quake cache is too small, quake will keep unloading models to make room for new models. A bigger heapsize solves this I think. (in engines with standard quake caching/memory logic.) 
Yeah, the caching system is really the only thing, other than some kind of hardware failure, that could cause this.

It's worth observing that if one is using a replacement/"improved" MDL pack, they're going to consume more cache space and therefore have a higher likelihood of triggering this kind of behaviour. 
This seems to have gotten lost in the noise.

From the description it seems that MarkV doesn't have the robust SV_TouchLinks fix. Some discussion: 
Just had a look at the MarkV SV_TouchLinks fix. It's, umm... unusual...

My recollection is that QSS has a sensible fix that's absolutely trivial to lift over to any engine, so that should be the way to go. 
An interesting observation about MDL caching.

It's possible for 2 or more MDL files to only differ in terms of the skins they use; otherwise they have identical geometry (vertices, frames, triangles, stverts).

You'd think this would be a theoretical possibility at best, but it actually happens in ID1: progs/spike.mdl and progs/s_spike.mdl are identical aside from skins.

Load up ad_sepulcher and there are about 30 MDLs where this happens.

So to save memory with MDL caching, and also potentially save memory with VBOs if you use them, this is something you could check for, without being too disruptive to the rest of your code. 
I don't know if the SV_TouchLinks thing is similar to the old engine-crashing teleporters without proper destinations bug, but a QuakeC fix is mentioned here: 
I don't think that is related to SV_TouchLinks.

Here is Quakespasm's SV_TouchLinks fix which I adapted from Spike's in QSS: 
Screen Res For Mods 
Is there a particular reason why Mark V (1081) wouldn't copy over screen resolution settings from id1 folder when running mods from custom dirs? 
Because You Forgot To Copy And Paste Your .cfg From Id1 
That's Weird Then 
I am used to Mark V taking all settings from config.cfg located in the id1 folder... 
Here's my QuakeSpasm parameters for AD. They're from the readme:
-game ad_v1_50final -heapsize 256000 -zone 4096

The ad_sepulcher readme says to use these:
-game ad +map ad_chapters

I'm not sure if something else could be causing system overload. Maybe the Intel HD Graphics 3000 drivers emulating stuff in software? 
I've implemented a SV_TouchLinks "fix" in my code, and it broke the end-of-level teleporter in the map Citadel of Doom. That map is good for testing. 
Spike's more robust SV_TouchLinks fix works fine in that map.

The Intel HD 3000 should not be emulating anything in software; it's right at the start of the "Intel graphics are no longer crap" era and IIRC will even run Doom 3. 
Isn't "heapsize XXXXXX" Deprectaed In Current Engines? 
I thought this was no longer needed... 
mh: Yeah, I've played Doom 3, Quake 4 and the 2013 Shadow Warrior in it. 
Aw hell!

So many posts to read.

I had super-Android obsessive tunnel-vision "I will beat this platform into the ground and make it do my bidding" madness.

I figured there were be 5 new posts here, instead there are maybe 35-45 haha!

I will read them. But a bit too much too digest right now -- I see something about a TouchLinks thing, I have some sort of TouchLinks fix in Mark V from some other respected source but apparently not good enough for the issue in question. 
Do QuakeDroid bugs belong here or in the QuakeDroid thread. Enjoying QuakeDroid a lot btw. 
@qmaster - Yeah, QuakeDroid Thread 
Yeah, QuakeDroid is a different kind of animal.

So all QuakeDroid talk should be in the QuakeDroid thread.

I'm glad you are enjoying QuakeDroid. 
@Spike - thanks for helping Cadaver with his multiplayer.

@cadaver - Glad you got it working. Mark V uses Spike's single port server so just port 26000. 
Touchlinks - I can't recall where/how I got the touchlinks fix. And if I recall, when I was acquiring Spike's QSS single port server/IPv6/server browser capabilities, his was slightly different. Mark V has "co-op players can walk through each other on respawn and the ability to save multiplayer games AND reload them with the wrong number of players.

So if the code their looks usual, lots of action going on. 
@nightfright - here in a couple of days, I'll see if I dig into the Chillo model pack thing.

@nightfright2 - I am used to Mark V taking all settings from config.cfg located in the id1 folder...

Mark V loads AND saves the settings to the Quake startup gamedir. If you start up Mark V in id1, it will use id1. If you start up in "-game rapture" it will use rapture.

So it sounds like you played, say, rapture and then changed the video mode, which causes the video mode to write to, say, rapture --- then you started id1, the video mode from id1 was the old one.

@mankrip - Ok, you are talking about a Quakespasm issue. I assume. 
Wondering if you could add support for light entities in the entity inspector mode? Just curious. Not a huge priority. 
Sure, I can put that on the medium-term wish list. I think (?).

I haven't thought about lights in a long time.

I'm not immediately sure if they stick around or just ones that can be toggled/flicker like the E1M1 nail gun up the lift that is dark until you trigger it.

Do you have something that prompted this thought that perhaps you were trying to do while mapping? 
Working On My Tutorials 
I was recording a basic lighting tutorial and wanted to show viewers what the diff light values and whatever other info was displayed. However no lights for me at all. I was using 1.50 and I do need to upgrade my video capture directory to the latest version.

Honestly, I'd hate for you to add it just for me but I think the functionality is very cool overall and was curious about why lights weren't included. I didn;t try to examine switchable lights. Will try that. 
You've done a great job with those video tutorials, I've read that they have help a lot of people.

My focus with the tool_inspector was mostly QuakeC/entities as an assist to mappers to be able to

1) To get the entity # for an entity!
2) examine why something does/doesn't work in their own map
3) check out the mechanics of a different map

So lights never even occurred to me.

So lights never crossed my mind. 
Not really a request. I'd rather you work on Gunter's wishlist. ;) 
I'm not immediately sure if they stick around or just ones that can be toggled/flicker like the E1M1 nail gun up the lift that is dark until you trigger it.

Yep this is right, light ents are removed from the world on map load unless they have targetnames, or a sound/model attached to them (e.g. light_fluoro/globe etc). Simple enough QC alteration to disable this (misc.qc #45) but not sure how advisable that is. 
Makes perfect sense. No not worth the effort IMO. 
Choppy Refresh Rate 
Maybe it's just me, but Mark V D3D9 starts to visually stutter on the default host_maxfps "72" when I'm moving and "mouselooking" at the same time. I normally play on 144, which is double the default, despite it causing physics bugs, so that's why I didn't notice it right away. Is there a special CVAR I could tweak or something I need to configure in the NVIDIA Control Panel? Or is it a bug? Doesnt't happen with Quakespasm btw, but that uses OpenGL.

CPU: i7-4790k
RAM: 16GB DDR3 800MHz Dual Channel (1600 MHz)
Main-/Motherboard: GigaByte B85M-HD3 R4

Thx in advance :) 
Sorry for the double post, but I don't know how to edit my posts. Do I need to register? Please forgive my ignorance.

Anyway, in Scourge of Armagon, the SG & SSG leave one bullet hole decal every shot, these are rendered through walls in Mark V. 
@DabbingSquidward - Windows 10 Stutter DX9 
Wild guesses:

Only mentioning it because Windows 10 is known to install miscellaneous apps/features without user consent.

I wouldn't normally post wild guesses.

1- Search "Xbox" in windows taskbar's search bar (Bottom left of your screen where Cortana is)
2- Click on the Xbox application icon to open it
3- Find the settings icon (a small gear) on the taskbar to the left side of the Xbox application's window and click on it to open the settings menu
4- Find the Tab labeled " Game DVR" and select it
5- Slide the switch to off to turn off the Game DVR feature.

Other miscellaneous:

"List of things to try
Turn off game dvr
Turn off Windows game mode
Windows advertising stuff.
Turn off in windows update allow downloads from other pcs "
@DabbingSquidward - Decals 
I loaded up Hipnotic and in the first level shot both sides of a thinner wall and didn't see a decal on each side.

c:\quake\mark_v.exe -game hipnotic -hipnotic +start

I believe you, but can't replicate it. Do you have a save game you could provide? Like look at the decal and type "save decal". After saving a game it would be in the hipnotic folder, in Mark V you can just type "folder" it will take you there and be called "decal.sav". 
Forgot to mention it, I'm on Windows 7 Home Premium x64.

This is probably common knowledge, but where do I upload saves and screenshots? Sorry for the inconvenience, please bear with me. 
I haven't used a free upload service in a while, if I recall this one is okish:

I'm on Windows 7, but I don't have a 144 Hz monitor nor a GTX970 
@Baker fantastic job, but would it be possible in the next release to rise The step left / right icons at the same level of the fwd icon. In my opinion this would lead to an increased playability. What do you think? 
-->sorry Wrong Topic, The Post Was Meant For QuakeDroid 
Go to Screenshots and Beta post and at the top you will find login information for Quaketastic which is an ftp site you can use to upload forum related files. It has a web interface and you can scroll to the bottom of the page to login and upload. Welcome to func. 
@Baker @dumptruck_ds 
Sorry for taking so long, but I just uploaded a screenshot, a save and a video, all titled decal to Quaketastic.

@Baker I only have a 60Hz monitor but still play with 144 FPS, because I belong to the (supposedly small) demographic of people who think that having more frames per second than your refresh rate looks smoother. I also disable V-Sync in all my games and limit my FPS (via NVIDIA Inspector, Bandicam or ingame) instead to get around the input lag and still fix possible physics, etc. issues.

@dumptruck_ds Thanks for the introduction, I love watching your Trenchbroom tutorials on YouTube and as you can see, I'm fairly new around here. I usually hang around the ZDoom Forums and lurk (have no account yet) on Doomworld :) 
(@mh) Dabblingsquidward - Direct3D9 Specific Issue 
mh - Dabblingsquidward found that the decals in the Direct3D9 renderer through walls and this doesn't happen in Direct3D8 renderer 1036 build or the Open GL.

I'm think of trying to get out a comprehensive update of Mark V within the next 10 days after I can review NightFright's deal, get full Sepulcher in there.

If you have the the time and the opportunity to take a look at that in the next 10 days that would be awesome, but if not that's fine too. (video)

@(@mh) Dabblingsquidward

mouse - I really need to change Mark V to use RawInput, it may resolve the mouse issue you experience. Main problem is only so much time. 
I'm not going to be able to look at anything for the next approx 5 days (touring central Europe and drinking lots of nice beer can have that effect) but I am very interested in investigating any kind of state-related glitch such as this, so I'll be jumping on it first chance. 
touring central Europe and drinking lots of nice beer can have that effect

Enjoy yourself and have one for me! 
Go To Frankonia! 
We have one of the highest densitys of brewerys in Germany! 
@NightFright - Cannot Reproduce Your Issue 
I have used several versions of the "Authentic Model Pack".

I can't get any version of Mark V from 1036 forward whether Direct3D/OpenGL/WinQuake to crash.

I load map E1M2 using pakz.pak after renaming it to pak2.pak.

My success rate has been 100% with no issues in any version.

I'd sure like to fix the issue you are experiencing --- but without being able to replicate it, I don't have any method of taking any kind of action :( 
Reminds me that I never looked at the decals issue... 
I have analyzed my file structure and found something that is probably the ultimate cause for the issue.

I am using an autoexec.cfg in my id1 dir with the following entries:

r_shadows "3"
r_waterquality "32"

What causes the problem is apparently the r_shadows entry. If I comment it out or even only change it to "2", the crashes will stop.

Please create a file as described above and test the issue again. I am sure you will experience my problem this way. 
It's R_shadows 3 For Sure 
The r_waterquality 32 has nothing to do with it.

The crash appears to be related to:

// 3984 is WinQuake asm maximum verts possible

#define MAX_LERPED_INDEXES_12000 12000

If I increase the 12000 to 24000, it doesn't crash.

I am guessing that 12000 should instead be 3984 * 6 (23904), only because FitzQuake normally supported 2000 verts and 12000 must have been 2000 * 6.

This is my speculation, how mh's r_shadows 3 works is something I understand in a broad sense, but not in a detailed sense.

/End speculation, but the above seems to be fix the issue. 
I should have tried to run everything in a "clean" environment without any config files or other mods right away, my sincere apologies for that. :/

At least it seems certain now that it's not the new models alone that cause the crash, but using them in combination with this shadow option.

I guess it's still something that should be addressed since r_shadow 3 works just fine under normal circumstances. 
I suspected that it was going to be something like this, but when I did a scoot through a debug build about a month or so back I didn't see any evidence of the index list overflowing.

Strictly speaking the maximum number of indexes should be max triangles * 3, not derived from max verts, because any individual vert may be potentially reused an arbitrary number of times.

Even more strictly speaking GLQuake's MDL meshing function which converts a highly compacted triangle soup to strips and fans will mean that the generated mesh will potentially bear little relationship to the original in terms of counts. What I'm saying is that using the software Quake maximums as a limit on anything that comes out of the meshing function is asking for trouble. 
Anyway, in Scourge of Armagon, the SG & SSG leave one bullet hole decal every shot, these are rendered through walls in Mark V.

This is a problem with how polygon offset is implemented in GL and D3D9. (Don't believe 20+ year-old articles claiming that D3D doesn't have polygon offset; it does, it's just called something different.)

In D3D8 polygon offset is completely different, and probably doesn't actually work at all (at least in the context of MarkV), so hence that the problem doesn't seem to happen.

In D3D9 what GL calls "polygon offset" is called "slope-scale depth bias" and if you compare the GL spec with the D3D9 documentation you'll see that they're controlled by the same formulae. GL has the addition of an implementation-defined constant value which for D3D9 I assumed to be 0 (IIRC, I had good grounds for that assumption). Gotta love implementation-defined GL behaviour; what's the point of a standard if individual implementations can just do what they want anyway?

Another possibility is that I may be missing some state. In order to enable proper draw call batching in D3D9 I implemented lazy state changes where state doesn't actually change until a draw call is made; state change requests are tracked and only if a state change was actually required is a draw call batch finished, flushed, and a new one begun. It's possible, for example, that there may be interactions between polygon offset and depth testing that I hadn't considered.

That's something to work with. I'll update further as I find out more. 
Maybe I'll have to something to go with it soon. 
A workaround might be to disable polygon offset for sprites in the D3D9 build. Only temporary, of course, and it would cause z-fighting, but that seems less objectionable. 
I don't notice any z-fighting disabling polygon offset just for D3D9 -- perhaps because the decals are small, but the decal can slightly protrude off an edge.

Thought I might be able to be clever and switch it to glDepthFunc (GL_EQUAL) but didn't cause the "clip to surface" draw behavior.

But those decals are tiny.

/Causes me to wonder if hipnotic is the only mod that uses them. Almost certainly can't be the case, but I don't believe I have ever run across another mainstream mod that used them. 
A rather heavy update is coming in the next 2-3 days. I've stalled a bit on doing an update because I want the update to have what I want rather than do it in pieces.

(I've also had trouble merging code together with QuakeDroid ... some of merging it hasn't been entirely pleasant.)

Amongst other things, I have controller support which is causing me to debate whether or not do 2 player/4 player split-screen now.

(Except that would push things back maybe a week and I really want to do an update this week ...) 
I Vote Update Sooner... 
THEN prioritize your split screen addition. I suggest this for selfish reasons. I've basically switched to using Mark V as my go-to engine over the past few weeks. I'd like to do a video on Mark V as part of my tutorial series and would love to do that over the upcoming weekend. (if the release is ready and stable ofc)

My 2 cents. I'll be doing a QuakeDroid video as well when that is updated. 
Split screen is a significant enough feature. If you're going to do it, if you're going to do it right, then it's worth a release in it's own right and IMO you shouldn't hold up what might otherwise be a significant essential release for the sake of it. 
Good to hear about a new release coming in for a landing!

Controller support is pretty cool. I'm in a phase of playing some couch/TV Quake, and Quakespasm is great for that but it's a little tedious to not have a level-select menu there.

Of course the complete set of "controller support" features would include a menu-y way to also choose the mod and any necessary game switches like hipnotic/rogue/quoth/nehahra... just putting that out there. :-) I know there are reasons that this has not been done by most engines, especially as a top-level menu item. 
Just fyi, my short list of things I consider must have in the release is fixing the unpacking bugs that you pointed out in a couple of .zip files that were packed differently than traditional .zip file releases. 
Ah interesting, yeah please let me know if you make changes in that regard (or just point me at the relevant sourcecode). I want to make sure my little batch file installer continues to work.

If you want to see the current list of things that it works around, you can have a look in

There's three kinds of situations where I do something to change/fix files after doing the Mark V install:

1) The special case of making sure that quoth2pt2full gets put in a folder just named "quoth".

2) If the install puts things under id1, I move them into their own mod folder instead. Various reasons for that, but this is not necessarily a problem with the installer (unless there was a start.bsp, like with QUMP for example).

3) If the install fails to extract all the necessary stuff, or extracts some things with a truncated filename because of assumptions about folder structure.

Cases of #2 with a start.bsp: mapjam6, qump, rmx-pack

Cases of #3: arcanum, apsp3, dm4jam, func_mapjam1, func_mapjam2, mapjam6, nehahra, warpspasm 
Very helpful.

I think what I'm going to do is get an update out with what I have done now (I have 2 qmaster items I need to wrap up) and then next do a release with robust installer that handles edge cases and then go from there.

@mh - Yeah, I think I'll just get out what I've got rolling and due to the scope of 2 player/4 player split screen, do it separately. 
if the release is ready and stable ofc

The next release is going to need tire kicking before I'm satisfied that it is "stable".

But the next release should be incredibly robust and might even solve real old mysteries like killpixel's issues with WinQuake version lag (I hope).

I'll be doing a QuakeDroid video as well when that is updated.

Ironically, there is no way to do a QuakeDroid video myself. My phone ... which I love ... is an Android version that can't support video without rooting (which I'm not willing to do).

So a video of QuakeDroid would be nice because I simply cannot do it myself. :(

I went WAAAAAYYY out of my way, to make QuakeDroid as potent and usable as possible ... especially the console (<-- !!!) and the menu.

In past mobile Quake engines including other Android Quake engines, the console is microscopic, the menu non-interactive, poor ability to tune settings, etc. etc. 
controller note - a few days ago, I had the DirectQ source code open was about to more or less take the DirectQ controller support and put it in Mark V.

Then I had a funny thought, could the original Quake joystick code work if sufficiently enhanced. The answer was surprising.

I took the original joystick code and bashed it into a form almost indistinguishable to the very nice ericw/Quakespasm controller code, except it uses the original Windows API functions for axis/button reading. 
Splitscreen Question 
When the fov cvar is changed, which player will it affect?

Quake has several client-side cvars that were never designed to automatically handle multiple clients. chase_active, cl_forwardspeed, crosshair, r_drawviewmodel, and so on. And they're usually not binded to any keys, so there's no way to track from which client their value came. Also, some mods uses different default values for them, so if you create multiple copies of those cvars with different names for each player, those mods will be broken. 
You'll be able to look through the source code when it is released. 
MultiPlayer Saves/Loads Coming To The Menu 
Thanks to qmaster for the push to do this. I hadn't considered that idea before he brought it up.

In a non-supporting engine like Quakespasm, trying to load a Mark V multiplayer save will gracefully fail rather than crash the engine.

The awesome thing about Mark V multiplayer save games.

If there were 4 players in the save in let's say it a co-operative game, you can load it with only 2 players if you want.

Or load it with 1 player, haha!

Spike can't even do that :D 
/Jokes aside, the reason that Mark V can load a multiplayer saved game with less players than actually the save game is because I force it to always reserve 16 entity slots, this makes it so the player count not being the same isn't a deal breaker to QuakeC. 
huh? so you reserve a fixed number of player slots exactly like QW does, but still limited to less players?
The down side of that is that it makes servers with up to 255 players wasteful if you're running singleplayer or whatever.
So FTE defaults to 32 slots. If a saved game had a different number (like 255) then it just dynamically resizes the svs.clients array, but most of the time it just uses 32.
Frankly, loading a saved game with a different maxplayers limit is trivial.
The real challenge is making sure the players got the right slot, if eg they connected in a different order (or if someone has since disconnected, leaving a gap in the saved game, etc).

But yeah, I'm unsure what 'I' can't do here. Are you alluding to an FTE bug?
Or is the joke the idea that FTE might not be able to do something?.. I'm confused. 
Haha, maybe the joke is on me because I am now rememebering that conversation. Sounds like you told me the solution and then I implemented it -- and proceeded to forget how I got the idea in the first place.

On the plus side, I went out of my way to make sure the multiplayer save games aren't toxic to other engines.

/Yeah, I considered the issue of future higher max player limits (32, 64, 255, etc.) but realistically my main preoccupation is with co-operative play and I cannot imagine cooping a map with more than 6 players and even then players would have to fight each other off just to get kills. 
Might add, that the multiplayer save games store a bucket of cvars that are traditionally used by servers to use to add an extra level of game state preservation above and beyond the norm.

Quite a weakness in the original Quake save game format is the lack of better preservation of game state, which is more likely to be relevant in a multiplayer game. 
hey, maybe in future we'll see maps with 255 coop starts, and 255 deathmatch starts too.
but probably not.

I agree with the cvars, but you do need to balance between useful cvars and fucking over all the server's settings... obscure stuff like samelevel might sound good to save, but loading a multiplayer game then trying to start a singleplayer game could then screw stuff up, in a way that the user might not be aware of nor know how to fix. One solution is to latch the cvars to their saved values, and unlatch on map changes, but latching cvars gets really messy. 
I agree with that and agree with your firewalled system of settings. Someday I will catch up (although I have some disagreements on small issues).

That being said, you are modding an engine egregiously doing WORSE. Quakespasm runs quake.rc on every gamedir change, accumulating all kinds of random crapola ... including nasty stuff that wasn't intentional.

It is also piss poor for anything except a completely crippled luddite single player engine, especially in the long term.

Do I want to nuke all keys and reset them to default when connecting to a co-op server running a mod? Most people want to retain their keys, sensitivity, gamma, contrast, etc. and the old message about running quake.rc was superior to than implementing some very ... well ... half-assed.

Plus supporting gamedirs like quake/i_like_my_mods_in_weird_places_I_guess_I_dont_play_hipnotic_or_rogue_ever_apparently/travail

Considering Quakespasm Spiked is NOT crippled (great stuff you've put into it), what would you have the engine do if some goofus with a gamedir like that hosts a game with downloads enabled?

/Anyway, end of random thoughts on the multiplayer design topic. 
Clarity: the above is not a criticism of ericw, who I think is awesome. And his game controller code is organized so well I give it 6 stars out of 5, and made non-SDL controller code mirror that refinement!

Spike, mh and myself have long discussed vulnerabilities of things like quake.rc, oddball user preferences and I have personally watched the destruction of at least 3 engines before my very eyes.

I have strong feelings about detrimental features that take away choice or control from users or thrust chaos on them.

When users request things, they often don't understand the implications/side-effects or even how it blocks the future.

I'm not saying the user is always wrong or anything like that, but careful consideration has to be given to future implications of a change.

In the above post I outline how nice things in Quakespasm Spiked are impeded by some changes in Quakespasm basic. 
FTE reexecs configs only if it notices one of the files that it would normally exec is now in a different path.
It also saves its config to try to match the default.cfg (or config.cfg or so).
So if you switch to TF, then you get your mod-specific settings, and if you then switch to one of those map packs (that is only a gamedir because it has a new start map) then you get your id1 settings.
Note that when FTE execs default.cfg then it resets all cvars to their engine-set values before execing the rest of the config, which is meant to block undesired accumulation.
(unfortunately, custom cvars don't have engine defaults, so these don't get reset and can accumulate, especially if they were setaed. I assume that it would be okay to wipe them.)

Of course, this isn't an ideal world, so there's lots of mods that include pointless autoexec.cfg/config.cfg/quake.rc files that do more harm than good, etc. These anti-social mods will end up getting isolated.

Unfortunately other engines don't subscribe to the same ideal either, so they write config.cfg files all over the place and strip all sorts of settings, etc, even if you're not doing gamedir switching. The only way to handle these sensibly is to ignore the damn things completely, using a completely different file instead. Which of course breaks other things.
This is likely why you believe FTE's behaviour to be worse.
My solution: use FTE exclusively. :D

I'm not sure what you mean regarding downloads.
The client should have code to block downloading models named stuff like 'config.cfg', which prevents various forms of evil.
FTE will just automatically switch to whatever gamedir the server says, reloading configs only if it actually makes sense. FTE also attempts to download packages rather than files, and these have explicit gamedirs attached to them (but gah, remodelling packages!), unfortunately there's still a LOT of legacy servers that have no support for packages at all (nor the versioning that they can provide).
Regarding QSS, I never actually got around to getting it to automatically switch gamedirs (no mod-isolation code meant that I bottled out of trying), so yes downloads may currently end up being written into the wrong gamedir. :(
It does at least warn if the gamedir is wrong, but yeah, noone pays attention to warnings. 
These anti-social mods will end up getting isolated.

That line of thinking requires too many things that are false to be true.

The day of the curious user sailed long ago, today Quake is a commodity.

That doesn't mean there aren't curious users ... there are!

And if you think for a second, I've managed to do a Pokemon and "catch them all" with Mark V while punting the Steam noobsters off through trickery.

It's the Baker "cream of the crop" thiefdom steal.

And quite deliberate. So I get the brilliant ones and talent ones, while SteamNewbster123-where-is-my-Quake-folder is learning with some other engine.

The "haha funny" is that tomorrow never resembles the past. But tomorrow is easy to predict.

Tomorrow is coop.

When tomorrow comes, there won't be room for engines that suck balls at coop.

I've been saying this for years.

Sometimes I got mocked for saying that in the more distant past (I'd snicker a little and say nothing, in Steve Jobs style because I knew why -- "why" is a useful thing ... if everyone knew "why" the world would be boring and I'd never get to make fun of people for being wrong --I'm made out of a human so yeah, everyone has their faults, I'm a prankster by nature) -- but today everyone sees cooperative play knocking hard on that door.

Users often describe "tomorrow" as "today" thinking tomorrow resembles today. But that kind of "me too" thinking is why no one uses Windows phone, why Steam Machines isn't a thing, why BlackBerry was once king and is now dead.

Tomorrow isn't today. It is like "today", but more aggressive form of today.

What does tomorrow want?

/Question of the day. Someone mocked me for saying I was going to make a Quaddicted install (*cough* Spike!) then proceeded to make his own Quaddicted install in FTE. So yeah, like it or not, I suck because I understand what tomorrow is going to bring with some level of consistency but it isn't magic or even me -- it's just connecting obvious dots in an obivilious world. Not my fault!

A great question is why does this matter for a volunteer engine coding for a 22 year old game? But this rhetorical question is just me being a smart-ass again in a lot of ways -- in my head the answer is that if you can't win the small ones, how could you win the larger scale real-life ones? Which is why I find engine coding entertaining, everyone tries their best to do things right because it is somehow reflective of result generation on a larger scale.

Plus it is fun with those you've known the minds of for years!

/End stupid commentary. My next post is probably an engine release which has been compiled for 4 hours, but I have 4 beers left and we can't have that can we? 
3 Beers Remaining - The Assured Death Of OGG + Why 
We live in an increasingly mobile world. Mobile phones today have 53% of gaming revenue.

Quake's future will be partially on mobile phones. (Duh? Surprise????) Ok, no really).

Software decoders on phones eat 60-70% cpu. We all know CPU is battery.

That's ok. There are hardware decoders that take precious little cpu.

Clue: Hardware decoders ... 100% mpeg everywhere that means MP3.

Ogg? Uh. That's like 0%.

And if you can't hardware decode a music format on mobile, it has no future.

Now if Quake is to have a future (it does) and if part of the future of Quake is mobile (it is), where does ogg fit into that future?

Well ... under the stupid person's plan you could have ogg on the desktop (oh wait! Quakespasm supports mp3) and mp3 on mobile.




You could have MP3 everywhere.

Gee --- I wonder how this ends?

Ok --- no I don't. I've known how this ends quite a long time.

It ends with MP3 everywhere. It always did.

/Understanding tomorrow means you can extrapolate what to do today 
Ogg made sense when MP3 was still patented and an unencumbered format was required/desired. Where the Free Software world often falls down is in not realising that it's not 1998 anymore; the assumption is that rules and situations that applied in 1998 would continue in perpetuity, but the MP3 patents were always going to expire and Ogg's reason to exist would be reduced.

A technically inferior solution that has high market penetration or better ease of use will always win. The moral of the story is that end users don't give a flying one for technical superiority. They just want something that works and gets out of their way while doing so. 
Baker, you sound like you may be on a few beers too many, but I'm still going to reply with my own rant at your ranting, because you're touching on some of the issues I've had with Mark V:

What does QuakeDroid have to do with Mark V supporting OGG? If QuakeDrioid doesn't support OGG, then it doesn't support OGG (I will probably never bother copying the Quake soundtrack to my android anyway). I play Mark V on my WinXP netbook, not on my android device, and Mark V already can play OGG files (assuming the correct decoder is present on the computer) -- Mark V just doesn't bother to look for OGG files. So I have to rename OGGs to MP3, or hex edit and hack Mark V to look for OGG instead of MP3.

And as I mentioned in #1767, OGG files fix an unsolvable issue my Netbook has with running MP3 files in Mark V -- that being a long delay (sometimes ridiculously long) in loading the file in Quake. We did a massive amount of troubleshooting of my issue in the old topic, where I tried so many different things like installing various decoders, but NOTHING worked... until I tried using OGG files and the problem magically went away.

I've been holding out hoping you would do the utterly simple step of simply ALLOWING Mark V to see the OGGs that it is already capable of playing.... The other option I have thought of is either: offering a pack of OGGs files renamed as MP3 for download for people who want to use the soundtrack in Mark V, or hex editing Mark V and offering my hacked version for download on my site for other users like me who would prefer an OGG soundtrack (without confusing renamed MP3-OGG files).

This is not the future -- this is the now, and people are playing an ancient game using old computers, and those people are asking for OGG support.

You're simply wrong about this one Baker. Stop being so stubborn and LISTEN to the people who are actually using your engine. I think we know what we want... rather than what you're telling us we SHOULD want.

I also agree with Spike that switching gamedir should absolutely exec the configs in that gamedir. Otherwise you are not running the mod correctly. "game fvf" is supposed to replace the need for a command line switch "-game fvf" yet it does not, because it does not exec config files that are set up for that mod.

Yeah, we've been over this before ( #55 #68 #87 #89 ), and you always go with "but what if there are bad settings in those config files?" Then that's how the mod should run, because that is the expected default behavior of Quake when running a mod!

Basically I still need to use a command line "-game fvf" since "game fvf" does not work like "running a mod" is supposed to, and would require at least one extra step. 
Hey, Johnny Law. It looks like you are a real power user with running custom maps.

I'd like to get your opinion on a feature in Mark V (since we're revisiting some of these old issues): If you are running from a gamedir or mod with custom maps, and you use the menu to start a New Single Player game, Mark V guesses at what map to run instead of putting you in the default start.bsp (standard Quake behavior -- though actual mods can alter this to start you wherever they want).

Is this a feature that you actually make use of, or do you run custom maps a different way?

I really like the "Levels" menu that lets me specify any specific custom map I do want to run. (Though I remember there was an issue with the Levels menu being disabled when custom menu graphics are present, though me and someone else suggested it shouldn't be.. up around #1227 ).

But I greatly dislike the "guessing" behavior, and it has given me problems by guessing wrong from what I actually want, and I can't even disable this feature. It takes away user control, doesn't apply or function in some situations, and causes unwanted behavior other times (also discussed in-depth around the same location upthread).

I have to point out that it seems to me to go against Baker's credo, which he just stated:

"I have strong feelings about detrimental features that take away choice or control from users or thrust chaos on them." 
Honestly I'd forgotten that Mark V does that... hmm.

For almost any episode-ish thing that has a start or hub map, they use start.bsp for that purpose. On the other hand if it's just an unconnected collection of maps then I always just select the map I want explicitly through the levels menu or a launcher or whatever.

It's true that there are some older id1/vanilla maps that have a startmap+othermap combo for selecting skill, and since they expect you to place it in id1 they call their startmap something other than start.bsp. Like Adamantine Cruelty having an acstart.bsp map. If you put that in its own mod folder then it could be useful to have Start New Game infer that it is a start map, but since I'd forgotten about that behavior I always just explicitly pick the map in those cases too.

Sorry, no real opinions. I'm not sure in what situations the "guessing" behavior would be worse than not-guessing, since the worst case either way is that you end up launching the wrong map. 
I suppose one way in which it could be worse is if it guesses wrong but you don't realize for a while that you are in the wrong map. (Because you haven't played those maps before.)

Out of curiosity, do you remember an example of it guessing wrong? 
I believe that the guessing feature doesn't activate when everything is running from id1 (so it becomes useless when maps are installed in id1, as I assume a lot of custom maps packs are).

Issues I have run into include (more detailed info was upthread):

( #1251 )
Having a modified DM6 map included in my mod, and since that is the only map, Mark V assumes it should be run when I go to start a single player game. This is completely wrong....

Or, if I want to install extra maps in my mod folder (FvF can be used with custom maps, as can some other mods), then one of them will get guessed and selected when I want to start a new single player game, and it will always be the same map, either going alphabetically or looking for cues in the map name (like with your "acSTART.bsp" -- that would be selected). But that's almost never going to be what I want when I have many maps installed and I go through the menu to start a default single player game.

Baker's intent is to make it easy to launch single-player map/mod releases by using the menu; see #1253 (and you could read 2 posts later where I examined the map packs that had been mentioned to see how useful it would be in practice -- maybe 50% useful).

But I think the Levels menu is already the ideal solution for that. And it could still show the maps near the top of the list that it guesses are most likely the intended starting maps....

So to me it just seems that a feature which sometimes works, sometimes doesn't, and sometimes causes problem -- that's a feature that should not be activated by default with no way to disable it.

And it sounds like people may not even be using it anyway.... I'd assume that most people, like me (and you, it seems), would just assume that default of starting a new single player game in the menu will behave as Quake always did, and start the default game, and if we want to start a custom map we'll use that wonderful Levels menu. 
LOL at the whole "mobile gaming is the future and I'm the next Steve Jobs" nonsense. Sober up, Baker. 
Well, we can allow him a few rambling rants when he's on a few beers, as long as he becomes reasonable and rational at some point afterwards ;) 
This Is Madness 
As long as Baker doesn't turn Mark V into a mobile exclusive port, he may rant as much as he wants. 
Mark V - Version 1.98 (Stable?) 
Larger update than the norm for Mark V. 46 modifications plus some major revisions.

Download: Windows - Direct X | WinQuake (Direct X is fast!!)

Alternate Builds:
1. WinQuake GL (killpixel)
2. SDL "zero dlls" build with mp3 sound track + all controllers support

In this version:

1) Xbox Controller Support. PS4 + Steam Controller will happen later. (based on ericw help in the implementation in Quakespasm)
2) Perfect "install" unpacking for non-traditional zips (johnnylaw)
3) r_shadows 3 issue with higher vert models fixed (NightFright)
4) Big Sepulcher Support (pulsar, killpixel, qmaster reminders/nudges)
5) Multiplayer save game menu integration (qmaster)
6) Possible fix for input lag (killpixel, dabblingsquidward). Verification needed.
7) Alternate "joy_" prefixed game controller names (conversation amongst Spike, gunter, ericw)
8) DirectX 9 hipnotic decal workaround per mh (dabblingsquidward)
9) Dynamic scaling for scr_showfps 1 and friends (gunter)

10) And 36 other small or moderate enhancements including things like 64-bit killer buttons fix via ericw, small Linux enhancements and implementing tweaks from comments from many different users.

Next Version: Split-screen support!! (video

Now ... here's the catch ... will it be 2 weeks or next winter?

I'm a winter coder and we had a frigid April in Ohio/USA. I tend to vanish for months in warm weather. And I'm a bit burnt out.

But if there is enough user feedback, I also kind of feel like doing this sooner rather than later. I need a bit of convincing there are actually people who are actually going to use the split-screen with 2 people or more playing on the same screen sitting on the same couch. 
@iriyap - It's supposed to be funny as self-deprecating comedy through going the opposite direction. / Anyways the start of Cinco de Mayo is serious business. No time for beer rants! Peace out! 

Can you shed a bit more light on the functional difference between mark_v.exe and the SDL build? 
Also a heads-up... I tried "install mapjam6" as a test just now, and it went a little haywire. It put bsp files and lits directly into id1, and also discarded various other things from the .zip.

"install qump" went a bit better, but it still put the maps into id1\maps (rather than qump\maps) even though a start.bsp is among them.

Haven't tested other installs yet. 
Mark_V.exe has mh DirectX 9 uber-speed.

The SDL build serves 3 purposes:

1) Any game controller support instead of just Microsoft Xbox compatible. I don't have a PS4 controller to available to do the kind of coding/test for pure native Windows API at the moment. (I made phone calls and it was Xbox, Xbox, Xbox, Xbox. "Ok what about your friends? Xbox? Really?" What kind of luck is that? Especially since PS4 selling extremely well ...)

(Short version: Mark_V.exe all the way)

2) To see if gunter's foobared Windows XP machine can play mp3s with that because I use an entirely different direct Windows API method. I still hope he spills coffee on it, but it has been great for testing -- especially the extreme compatibility mh has offered with the Direct X 9 version (mh is simply incredible).

3) Poke Quakespasm a bit to go "no dlls". The same way Spike sometimes pokes at me about X, Y or Z (or how sometimes I poke at Spike a bit) or the same way mh occasionally pokes at me about X, Y, Z. Friendly developer "Aw come on dude!" peer pressure and all that.

Let me know how it goes with the install capabilities. I felt like I couldn't do a release without getting it right so I rewrote half of it to be very precise. 
@johnny - After Typing That Reply I See ... 
Well .. I'll test those examples tomorrow and do a version 1.98b.

I took a diverse pool of zips with many different configurations, but apparently a different have a diverse enough set in the pool.

Perfect is the goal. So ... perfect it shall be. And perfect is what I demand it must be be ...

Hah, perfect isn't required. :-) I will just be doing a test run through the examples I listed earlier. 
Actually, when the next build is up, I'll go through all of the 50+ installs that the SP starter pack currently supports. Not sure it will happen this weekend because of family stuff, but as soon as possible. 
Alright ... qump (what an incredible start map!) and mapjam6 now unpack ok.

1.98 updated

Only that binary has been updated while I kick tires on a couple things that don't affect the windows operating system. 
Hm, the mouse speed seems dramatically lower in the new build. I've always used a "sensitivity 10" setting, but now I need to set it to 20 to have the same feel (and the slider only goes to 11).

The SDL version seems... weird.... Text and other colors are off, and the sound it tinny. But it has the same freeze-up delay of around 5 seconds when I enable the music, as it loads track04.mp3 (and this was after encoding it in various ways to get that delay down from the original 14 seconds). but if I use an ogg renamed as an MP3, the delay is less than 1 second....

I don't remember all the testing we did in the past (it's all on the oldpage), but I think FTE and Quakespasm had no delay at all for loading MP3s for me....

Question: would the split-screen players be able to connect to an online server? 
1) Mouse now uses DirectInput so sensitivity is a bit different.

According to the research I've done, Windows updates in recent years introduced some behaviors that could cause "frame lagging" with the "ancient way" that Quake did mouse input (which involved recentering the mouse cursor every frame), hence the change to DirectInput which I believe will eliminate the frame lag some users say they experience when using, for instance, a high refresh rate.

Aside from having to tweak the sensitivity.

2) The SDL build uses 44100 as a forced sound frequency because of some sort of SDL2 oddness. Hence the much more crispier sound. I prefer the way that Quake traditional sounds myself but Mark V has a sndspeed cvar that can be set to 11025, 22050 or 44100 and is read on launch. (Has no affect in that SDL2 build, 44100 must be forced).

3) Too bad the mp3 has a delay on your old Win XP computer even for the build that uses a completely different Windows mechanism. I had hoped that on your machine that it would resolve the issue. I tried. I know reformatting that Win XP isn't an option.

4) Split-screen connecting to an online server ...

Well ... I wasn't planning on that.

If I did have it do that, would you be able to test it?

But here is a big question: I am planning to target exclusively the Direct X 9 for that feature. I have to really abuse Windows API to do split screen and SDL2 serves as middleware and isn't going to let me use the abusive Windows API evil that I do for split-screen. 
Ah yes, I remember back in the day I would use the -dinput switch, and that would have a similar effect of requiring me to ramp up my sensitivity. I think this does make my trackpad movement look very slightly smoother too. But you might consider allowing the Sensitivity slider to go up to 22 or so, since this will likely have a similar effect on other people.

Yeah, the XP MP3 issue is weird. On my other (even older) XP laptop, I recall I did't have the issue. But I also remember seeing a post on Quakeone where Dutch said Mark V has "a difficult time playing external MP3" on his WinXP computer.... I don't think he ever gave additional details about that, but I'd very likely assume it was the same issue.

Oh, I would certainly give it a test if split-screen could connect to an online server. Hm. But there are all kinds of issues around that, like if someone wanted to chat on the keyboard, which player's guy would speak? I'm guessing there would only be one "master" player which was attached to the keyboard, and others would be limited to a certain gamepad? 
Adjust slider range to reflect? Excellent idea, gunter! 
Gunter, Re:Split Screen 
I'm guessing there would only be one "master" player which was attached to the keyboard.

That is correct. Only one player can keyboard.

I once considered that I think Spike said RawInput can provide access to 2 keyboards. And perhaps someday I'll consider that route. But I don't feel like coding for such a situation right now.

Multiple keyboard support is probably very low priority. 
Add: Iriyap List + Parubaru 
Revisiting found the comprehensive list that iriyap wrote up that had some ideas/suggestions for improvement (self note it is post #1805 -- I keep losing track of it)

In particular, I have my eye on the few seconds of lag issue on video restart that affects some machines.

I know how this was introduced. I was actually trying to stop a sound jutter, and while fixing it on some machines indirectly caused this to happen on others. 
Install testing is looking pretty good -- I got about halfway through, might be able to finish it off tomorrow or Monday.

A minor feature request for your consideration: an optional argument to the install command to indicate "please put this in its own mod directory" (regardless of whether it could work in id1). Like, if I'm installing terra and I want to make sure it ends up in its own "terra" folder. 
Small interesting thing when installing func_mapjam5: there's a zerstörer.wad inside the zipfile, but it gets extracted as zerstörer.wad (let's see if that ends up showing correctly in the post here).

That's just in the "source" directory though so it doesn't matter functionally. Something to keep an eye out for though I guess. 
I can add an argument to allow you to do that. Maybe even one to force a folder (like a Quoth set). 
Cool. FYI the install tests all look good now. :thumbsupemoji: 
@Baker Arrow Key Bug 
I've experienced this both in Quakedroid and now in 1098. I don't think it's my hardware in this case. Here's an unlisted tube showing the issue. 
Meant To Add 
That a reboot fixed this issue but it's still bizarre. 
I'll certainly look into it.

And if you have anything that I have missed, please let me know.

I've had such a large list of touch-up or in some cases rewrites (like what johnny + I are discussing) that keeping a handle on every single thing has been tough. 
I think you need to unplug your PS4 controller.

PS4 doesn't using the same analog axis mapping as Xbox, it successfully detects your controller and then thinks you are holding a stick up.

/Educated guess.

I do plan to extend Mark V controller support beyond the currently supporting Xbox mappings, Mark V uses native Windows API so I have code this myself (which isn't a problem) but I haven't code such yet (and haven't obtained a PS4 controller yet). 
Shadows "3" 
I can confirm it's working again in the latest build with improved models. Thanks a lot, Baker! ^^ 
haha That's (almost) exactly what it was. I had forgotten I plugged in a PS3 controller to charge via PC the night before. When I read your post I looked down near my PC and there it was still plugged in. Fixed. Thanks! 
@NightFright - ;-)

@dumptruck_ds - Until I get my hands on a non-Xbox controller like a PS4 one, I'm going to force non-Xbox controllers to be ignored (if I can, and I believe I can). In theory, I could code the axis/button remapping without having a controller, but I know from practice that "on the blind" coding usually is a quagmire.

Eventually, I'll get my hands on a PS4 controller ... but I'd like to ask you this.

Is getting a PS4 controller to work with Windows as easy as plugging a USB cord in (it is that simple with the Xbox One Controller S, as an example). 
@iriyap - Your List 
I looked through your list.

First 2 items resolved. #1 already fixed. #2 - sound stutter on vid_restart that occurs on some machines (I've witnessed it first hand on a couple) should be fixed.

I looked at the sky in GLQuake vs. Mark V vs. Quakespasm with gamma 1 and contrast 1 which shouldn't be setting neutral.

The sky does indeed not look quite the same as GLQuake! But ironically appears to look about the same as WinQuake.

So now, I'm not quite sure what to think. WinQuake is kind of the baseline that GLQuake was supposed to look like. Still, maybe an option will happen.

Other things: tga fonts + alpha masking for replacement fonts. Older replacement fonts supported FuhQuake/JoeQuake which has less flexible rules. The newer ones tend to be oriented towards DarkPlaces which has different rules regarding the alpha masking (more proper rules, I would say).

The main issue that has caused me to do nothing is that the replacement fonts for DarkPlaces don't tend to be a 1:1 drop-in replacement but rather really need larger resolutions or they look terrible in resolutions like 640x480.

I had once drafted up a solution been eyeing a solution which is to determine the minimum scaling when loading the replacement font. But the fact I didn't do it bothers me --- I may have run into an issue like HUD replacements and font replacements might require the same base scale under certain circumstances.

WinQuake: A 16-bit renderer would be a massive undertaking. Mankrip lives and breathes the software renderer. My level of interest in the software renderer is very close approproximation to the original WinQuake feature set + modern maps. I would eventually like to get alpha masked textures working (I've made several runs at it). As for HUD scaling, FitzQuake has a ton of canvases and scales all over the place. Mark V's software renderer isn't actually based on WinQuake, especially not the placement and canvasing. A dedicated WinQuake-only engine like Engoo or super8 need not worry about canvasing consistency with a Direct3D/OpenGL version, but one of the main features of Mark V being able to switch between the WinQuake/hardware versions on a whim and get nearly the same experience. Re-writing all that canvasing would take far too much time, especially when the less capable but fairly accurate approximation "stretch mode" is available in video options.

Also looked at bloom. Then realized that at the moment I cannot bloom to work in the Direct3D build but I believe it is fault of something on my end (as opposed to the wrapper). I'll probably look at in the future.

Likewise, multisample isn't supported in the Direct3D version at all and to some extent I'm not 100% that multisample is relevant these days because simply using a higher resolution with a larger scaling factor typically gets approxiamately basically the same results. Multisample with modern very high resolution monitors on 3D renderering is going to be mighty tough to notice, but on older hardware like 640x480 crt modes yeah you can easily tell.

The Direct3D 9 wrapper's level of performance (rendering speed) and stability (AFAIK not even a botched NVIDIA update can mess with it, so it may be totally immune to those kinds of problems). 
Direct 3D supports multisampling but the details are interesting.

The OpenGL philosophy is "the programmer can go nuts and the driver will do it's best to sort out something that works".

The Direct 3D philosophy is "the programmer absolutely positively cannot go nuts, and that sorting out something that works business is on your shoulders, matey".

In a native D3D application this is actually easy. You just enumerate the supported formats and follow the rules.

In an emulation layer that has to translate from the GL spec (and oh lordie if it's pre-3.0 stuff) to the D3D rules the path of least resistance is to just not advertise the extension.

Sure it can be done. But time, patience and sanity are finite resources round my way. 
I have yet to actually game with a PS4 controller on a PC. Or a PS3 for that matter. When I plugged in the PS3 controller via USB drivers were installed but I don't think they were with the PS4. I do know Steam supports PS4 and you can use them with Sony's streaming setup. I have zero experience with Bluetooth on my PC so that may be the ticket. No idea and doubtful.

So using those controllers is NOT plug and play. That makes sense to me as Xbox controllers are native for the most part in Windows and Sony interfacing with PCs has been historically clunky - usually their software is pretty wonky there. 
The following will be available for the installer. Needs run through your series of tests, I'm rather confident it will pass them all.

1. Forced to specific gamedir:

install elek_neh_episode4 nehahra // a Nehahra expansion
install thehand quoth // A Quoth map
install qt_pre02 travail // A Travail expansion


2. Special "self" keyword

install bnt self // Maps only release forced to its own gamedir quake/bnt

@dumptruck - Thanks for info, trying to plan out how long I need the controller and what could go wrong. 
Is there a functional difference between "install bnt self" and "install bnt bnt"?

Like, would the latter fail because the "bnt" directory doesn't currently exist, or stuff like that? I don't have a particular desired behavior here, just making sure I understand any specialness about "self". 
There isn't no functional difference, "self" is just automatic naming "" ---> "bnt".

The 2nd question: if it is a maps only install, using the override will overwrite files.

If it has more than maps (i.e. pak or progs), it should refuse to double install. 
Going to have to kick the can on the "ignore non-Xbox controller" until the next version, I want to test it on multiple machines first and don't fell comfortable putting in a beta without doing that. (i.e. I worry if the code works wrong, it will ignore a real Xbox controller). 
Re #2608 
Got it, thanks.

Sounds good, this will make me delete a lot of code out those batch files. Which is a plus. :-) 
Mark V - Version 1.99 (Stable?) 
Download: Windows - Direct X | WinQuake (Direct X = fast!)

1) Xbox One Controller support tweaked
2) Should eliminate sound stutter on some machines (iriyap, parubaru)
3) In-engine installer tweaks (johhnylaw)
4) Linux versions refinements (todo: make available)
5) Other touch-ups based on input

This is in addition to Big Sepulcher support (@pulsar, @qmaster) and the NightFright r_shadows 3 w/higher verts replacements models fix and Direct X decal workaround (DabblingSquidward) plus other items outlined in post #2037.

Alternate Builds:
1. WinQuake GL (killpixel)
2. SDL "zero dlls" build with mp3 sound track + all controllers support

Looks like all bugs and standard usability feedback issues have been addressed, clearing the queue.

Needs verification of resolution of issues.

Thanks to all the feedback to get this very polished! Always consider feedback even if it is not possible to immediately act on it (@iriyap). 
Spot checks on the install stuff look good. I'll see if I can run through them all tonight. 
A non-install-related thing:

If I launch Mark V using the -game option, my base video settings from id1 don't get carried over.

(Other settings do seem to get carried over properly from id1.) 
If there is a config.cfg in the gamedir (say quake/travail), it will supercede what is in id1.

And with -game is how it should work.

For instance, I run quake/travail and then set a video mode and exit and then restart travail ... it saved the config.cfg to quake/travail and that is the one it should read the settings from.

I have thoughts on how to enhance that to accomodate what I think you are describing (and do it in a traditional way, not doing something crazy).

/If I am understanding you right ... 
There's no config.cfg in the gamedir. It's a fresh mod install. I launch Mark V using the -game parameter, and I don't get my normal video settings... it's back into 640x480 windowed and I have to set all the video stuff again.

Other things like mouse invert and key bindings are handled OK though. Whatever I have set in id1 for such things is carried over, as usual/correctly. 
Maybe it was that way with the 2017 stable release too? Feel free to ignore me if I've lost it. 
Nope, you found something. What it doesn't do is fall back to id1 when there is no config on the early read if a gamedir is specified.

It just tries to early read from Travail, and if it finds no file it just stops.

This only affects things thing vid_width and vid_fullscreen that are read early, hardly anything is.

Nice catch! 
Hm. #203 #215

(heh, sorry, just had to point that out because my mental file pings me when I hear an issue that I may have heard before....) 
I'm a bit confused about the three different download links. Which build should I use? I play Quake (and map) on an old Windows Vista Laptop and stayed away from Mark V because it performed sub 60 FPS even in id1 maps, so I just stayed with QS for now. 
The Direct3D. 
Sorry for my ignorance but does this build (1.99) address the non-XBox controller conflict? I have 2 controllers attached to my Win 10 machine. The first is a Hori controller set to PS4 and the second is an Xbone controller. I still have the spinning on the spot issue. I have to unplug the dinput controller before I can use the xinput...

Sorry if this issue is still to be addressed and I'm just repeating what you already know. :) 
@hiptnotic Rogue 
I'll do an update later today with the missing gamedir config issue and also put in something that should ignore your Hori controller but let you use the Xbox controller. 
Cool Beans. 
That'd be great. Thank you. :) 
@Hipnotic Rogue 
Yeah, I'll need your feedback and from dumptruck_ds since I don't have a non-Xbox controller available. ;-) 
PS4 Controllers 
I don't have a PS4 controller, but the guides I've seen online about using them on a PC all talk about using a driver called ds4windows, which presents the controller to games as an Xinput device (emulating an Xbox controller). With that driver installed, I'd expect it should work with no extra configuration through MarkV's Xinput support.

My understanding of DirectInput is, it should probably be disabled by default unless you have a match from a mappings database like because the axis mappings are going to be random otherwise, so you'll have spinning on the spot problems etc. Winquake had it disabled by default for the same reason. 
I can loan you a PS4 controller to test. I have two and we rarely play split screen. Since we're in the US. Shipping would be no big deal if using ground. LMK.

Ericw I'd offer but IIRC customs is a drag on your end right - or has that changed? 
Thanks for the thought, yeah, shipping + customs would probably be cost prohibitive; I was thinking of getting one since they seem like a nice controller. 
I could send you a 3rd party controller if you like. It's a GameSir. Switches between dinput, xinput and iOS. Wireless with a dongle... Lemme know. I'm in sunny Scotland. :) 
Which model do you own? I personally have the G3s, as it's really good for the price imo. 
Yeah, that's the one. I use it on my PS3 which I only have around for Xevious Resurrection!

For the money, it really is pretty good. Nice and sturdy. :) 
@dumptruck_ds - I should be able to get my hands on one.

@ericw - Yeah, more or less at some point I'm going to do pretty much what SDL2 does ... if not downright take that chunk of the code eventually. Ironically that controllerdb is more or less in the SDL2 source code. 
Mark V - Version 1.99 - Revision 2 (Stable?) 
Download: Windows - Direct X | WinQuake

1) Eliminating a config reading issue (johnnylaw)
2) Must add -joystick to command line to enable Xbox controller support

The adding -joystick to avoid false axis interaction with non-Xbox controllers. Some time in the future, I'll extend the implementation of controller support to an SDL2 level where it detects and remaps a quantity of known controllers.

Alternate extra builds which are provided for experimentation purposes or have been specifically requested: Extra builds 
Video config stuff looks good. Will do install tests later. 
Mark V Page Updated To Latest Version 
Updated the downloads/installer on:

Empty queue of existing issues, I think this build classifies as "rock solid".

(Always more features to do ...) 
Install tests are clean. 
Congratulations! I've just been playing Quoth on a laptop at 4k. A bit choppy here and there but it's an Intel HD 5500 so I don't think it's 1099. Glad you updated the website. I was going to nudge you a bit on that!

Now I can do that video! 
How is the default contrast value of 2 looking for people? It seemed ok running in a Windows VM on my Macbook, but on my desktop I had to crank it down to a value of 1. 
My mistake, it was also 1 in the VM too. Not sure how that happened since 2 is the default; maybe the previous build had a different default? 
The contrast default wasn't supposed to be changed. I may have been comparing different values between the hardware and software renderers.

I'll reupload. 
AD 1.71 Compatibility 
So is this build now fully capable of running latest version of Arcane Dimensions or some limits still need to be raised? 
I was able to play Sepulcher on the first build of 1099. I have not attempted Ter Sheboleth yet. That would be the real ball buster, even compared to Sepulcher. 
@NightFright/dumptruck_ds ... Loads Sepulcher and every dm4jam map.


Didn't feel like posting a technical post ... but ...


Eventually I will implement a big coordinates protocol (for maps like Ter Shobelth) like FTE-999, which takes the weaknesses of protocol 999 and fixes them.

I wouldn't be able to implement the very flawed and incomplete protocol 999, which cannot do co-operative play at all, because it would gross me out too much and I'd feel like vomiting.

Co-operative play is important. Any "big coordinates" protocol must be one that do co-operative play. And 999 sure cannot, but FTE999 sure can.

A large maps protocol like FTE-999 is on the to-do list. A 2019 item. But I also want prediction, framerate independence and something else I want which is boring and technical.

/End snooze fest technical post 
Rephrase About 999 
If you do a co-operative game, do you want to ...

1) Be killed by invisible monsters?
2) Be killed by vore balls you can't see?

That is what broken protocol 999 will offer you in co-operative play.

It also has "scale", which doesn't work on 2/3 of entity types (.bsp, sprites) and also doesn't work right on the other 1/3 of entities (.mdl) and would result in Ogre feet in the floor and bad collision.

So it is just loaded to brim with the brokesters upon more brokesters.

Wanting large-coordinates is a valid thing!

And those needs will be met in the future, but more in a FTE-999 manner that doesn't offer invisible monsters and being killed by vore-balls you cannot see. 
I'll go through and retest everything I've reported in the past....

First thing I checked: Looks like unpacked pak files now work.

Hey, Proquake 4.93 seems to have nicely-populated server browser (finds 36 servers).... Mark V only shows like 5 servers. How about reading Proquake's protocol to help populate your server list? 
Chiming In 
lenovo e480 win10-64
intel uhd 620 latest drivers
dxdiag seems good, still no dx seems to be present, all versions of dx-mark5 prompt an error, even older ones from 2016.

Good news is the last gcc version does run fine, nno errors seen while playing +5hrs.

Older versions/Win7 does work all of time by now.
Tested 1.99 on various hardware btw, all fine.

Congrats Baker! 
all versions of dx-mark5 prompt an error

You know, I really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, HATE it when people do this.

At least you could say what the error message was.

Those things don't exist for bamboozlement or amusement, you know. They exist to provide useful information on how the error might be fixed. Saying what the error message was can enable people to say things like "ah, you got that error message, that's caused by situations A, B, C, and to fix it all you need to do is X, Y, Z" 
Thx, that download helped, works now. 
I won't really be testing the SDL version... (it likes to freeze up or crash on me), but I will point out that it appears to be printing bronze text where it should be printing white text (like for player names and the FPS digits). 
I don't want to be the bearer of bad news... but the "QMB_BLOOD 0" bug is still there :P

if you set "QMB_ACTIVE 1" and then "QMB_BLOOD 0" to deactivate the QMB blood, it doesn't work, the command only mix qmb_blood with red particles :/ 
I'm using a clean install and testing lots of old things. I find that a lot of my suggestions have indeed been implemented. Excellent.

Here are some initial issues:

- Using Shader Gamma (the default), switching to any full screen mode that is not at my netbook's native resolution of 1024x600 causes Hardware Gamma to be used. It still says Shader Gamma in the settings, but it's definitely Hardware Gamma - everything gets darker and my desktop gamma is altered. Switching back and forth to full screen 1024x600 from a windowed mode does not cause the issue, and Shader Gamma stays in effect.

- I'm seeing something new: CDAudio: drive ready test - get status failed

Oh, I guess that's because the "External Music" is ON by default.
Ah, the error message does not appear if I disable external music, or if I actually have the music tracks in place... AS OGGs RENAMED TO MP3!!! because you won't allow OGG to be detected by Mark V.... PLEEEEEEEASE do this! I and others prefer to use OGG, and for me it addresses the issue with MP3 freezing up my game for unreasonable amounts of time as the MP3 song loads.... I'm sorry an OGG file killed your dog and burned down your house when you were a kid, but it's time to let it go, man!

- The mouse sensitivity slider now goes to 21, though that's right at the value I feel is good, around 20, so that doesn't leave much range for increasing it any more. The slider should probably go higher to account for users who might like it a bit more sensitive. I'd suggest at least 30 or so.

- Hm, pressing CTRL when the console is down (for ctrl+v) causes me to fire my gun.... Should that happen? I mean, I know it should fire my gun, but not when the console is down. ALT also has this behavior (I tried binding ALT to +jump to test it). Be sure you're in a multiplayer game when you test this, as the console fully pauses a Single Player game.

- Old issue that really needs addressed: the Multiplayer Setup menu, when you are changing your name, the name should not be committed until you are fully done changing it. It's like, for every letter you delete or add, it's doing a complete "name" command (which, among other problems it gives me, spams the console with name change messages).

- Speaking of old issues, r_noshadow_list contains bolt1.mdl which does not exists in Quake.... It's just... not... right!

- Known rendering issues: water surface is drawn on top of shadows, teleporter surfaces are drawn on top of water when viewed through transparent water (see #142 #147). And r_shadows 3 are visible through entities. Fullbright textures can't be transparent, and are made ugly by Contrast adjustment. (I know: all known issues -- I'm just noting that they still exist).

- chase_mode - I know it's an experimental feature, but it should really behave like other console variables. It's confusing because just inputting "chase_mode" causes it to cycle to the next mode instead of reporting the current mode. "inc chase_mode" should be the correct way to do that (though it wouldn't wrap back to 0 after... whatever the max value is).

(I've got a much larger list of preferences/defaults/suggestions I'm working on) 
"MWHEELDOWN" In Customize Controls 
I was running 1099 and found out in the "customize controls" menu, that "mwheeldown" binding doesn't display in the menu.

I have "mouse wheel down" bound for "next weapon" and it does allow me to bind it just fine, but the menu still displays it as ???, as if nothing wasn't bound (or if I have an additional alternate binding, it only displays it. Both bindings still work).

Anyone else have this problem? 
Well, thanks gunter/mfx/tribal/esrael/jl for the polishing tweaks I need to do! Much appreciated!

I guess going into hibernation mode will have to wait a bit!

But also why I did the (Stable?), thanks for the quality testing guys!!

@Tribal: yeah, I lost the stamina to do it. I hear you and it is important. Can't promise I'll do it immediately, I'm tapped out a bit. But I do appreciate your testing. 
"r_noshadow_list contains bolt1.mdl doesn't exist in Quake"

maybe it exists in hipnotic, rogue, zerstorer or something like that. metlslime put in FitzQuake 0.85 for a reason, but I don't claim to know what single player it is intended for.

hardware gamma

I don't know. It's your computer. I assure you if says "shader gamma", it's using shader gamma.

I'm still rooting for you to spill coffee on your computer, haha. I suggest creating an incident at Starbucks!

ProQuake server list

Dunno. I'll think about it for a Christmas-time release. I want to tune up anything small and take a break. I'm running on empty.

Hm, pressing CTRL when the console is down (for ctrl+v) causes me to fire my gun.. (must be connected to a multiplayer game)

Wow, that's interesting. It sure does! I was going to post "cannot reproduce" and then re-read about connecting to a multiplayer game so I connected to shmack and tried, and yes. 
That's a hell of an awesome catch!

I'd like to think I spot stuff like that.

Baker fail +1.

Now ... what I did was this ... I added ericw controller support. But I didn't want all kinds of joystick buttons showing for people without a joystick, so I made the display dependent on whether or not a joystick was connected.

But I was "too clever by half" ... and a tad not careful enough ... 
Mark V - Version 1.99 - Revision 3 (I Blame Esrael!)

Download: Windows - DirectX | WinQuake

1) mwheeldown wasn't showing due to a <= vs < typo (esrael)
2) Link to DirectX 9 drivers on homepage (mfx)

Experimental/requested extra builds: Alternate Builds

Question of the day:

Is DirectX Mark V faster than VxQuake (Vulkan)?

I have reason to suspect DirectX Mark V is faster than VxQuake.

(start.bsp beginning has a mirror there that Mark V uses so that is not a good test spot). 
Triple Speed Screenshot 
Screenshot: DirectX Mark V sometimes 3x speed of FitzQuake 0.85

And from what I have seen, VxQuake using Vulkan is only about 15% faster than its source base.

But the mh DirectX wrapper is offering a frames per second jump that is vastly greater than 15%. 
There's no point benchmarking an engine in small tight corners with very few polygons visible. This is the same syndrome as "50,000 fps in dm3 - woooo!!!!" - it's a meaningless statistic.

Benchmark it under heavy load, then do a comparison. You'll likely find that D3D9 MarkV is substantially slower than either QS or VkQuake (but substantially faster than Fitz) because it still hand-feeds all vertices to the GPU every frame, whereas QS or Vk store them in on-GPU buffers. But that all depends on where the bottleneck in your system actually is.

For the record, I make absolutely no claim whatsoever that my cobbled-together wrapper is faster than properly written native code, and I would always recommend properly written native code over a wrapper. 
Addition To The Above 
It's OK for Engine A to run at 200 fps in dm3 whereas Engine B might run at 5000 fps.

What matters is how they run in a map like sepulcher. If the same Engine A runs at 150 fps in sepulcher whereas the same Engine B runs at 30 fps, then Engine A is clearly the better performer. 
Waiiiit, Fitzquake had a noshadow list? Hmm, must have been inaccessible to the user, and only existed in the engine code? Ok, in that case, if you grabbed your list from Fitzquake, then it was Fitzquake that had an error in its list. Way back on the old page, I first reported that bolt.mdl was missing from the list, then I clarified that "bolt1.mdl needs to be renamed to bolt.mdl" See, that was just a typo in the original list: it did not contain the actual bolt.mdl but it did contain the non-existent bolt1.mdl (simply, the "1" should never have been there). So that's the reason Fitzquake had it there: a typo, not some intentional inclusion. Of course, even if it was an intentional inclusion to account for some specific mod, I would be against that too (it's not the engine's job to account for every custom model that a mod might use -- the correct option would be for the mod to include an altered noshadow list).... But it sure looks like it was just a typo. You did add the bolt.mdl that I pointed out was missing, but you didn't remove (or more correctly, rename) the bolt1.mdl which was there in its place, so now both bolt.mdl and bolt1.mdl are there... which is just building upon the original mistake instead of fully correcting it.

It looks like Quakespasm copied your early noshadow list (as stated here: ) and never fixed the error (they don't have their own Gunter to point these things out to them!), as you can see in its code (i.e., bolt1.mdl instead of bolt.mdl):

Hardware Gamma: Ok, then it is still using Shader Gama when it says Shader Gamma. The problem is that switching to any non 1024x600 fullscreen resolution resets my desktop hardware gamma setting just as if I were using the Hardware Gamma setting in Quake. i.e., normally my desktop gamma setting is adjusted up a bit, and that applies to Quake as well, so I don't have to adjust Gamma in Quake up by a lot. Using Shader Gamma in Quake in a window or fullscreen at 1024x600 doesn't alter my desktop gamma at all. Using the the Hardware Gamma setting in Quake, either in a window or in fullscreen, resets my desktop gamma, meaning I have to ramp up the gamma in Quake to make it brighter, then I have to reset my desktop gamma when I quit Quake.... The same gamma reset happens when using Shader Gamma, but only for full-screen resolutions other than 1024x600 (native).

And just a note: you don't have to connect to an online server to test the CTRL/ALT buttons in console; just do New Multiplayer Game locally.

Hey, would it at all be possible to allow mouse selection of text in the console for CTRL+C (copy text)?

Oh, and there's little chance of me spilling coffee on my netbook... I don't drink coffee ;)
Who would want to deal with a caffeinated Gunter?? 
And on the Second Day, Gunter posted his long list of feedback over here: 
FitzQuake's no-shadow list was indeed hard-coded into the engine.

Compare it with the tempent parsing code and it seems evident that progs/bolt1.mdl was a typo/bug; the tempent code (correctly) has progs/bolt.mdl but does not have progs/bolt1.mdl; meantime the no-shadow list doesn't have progs/bolt.mdl; I don't think we need to debate this one. 
Fork Of MarkV 
first of all I'd like to say a big thank you for this excellent source port. I love playing the WinQuake version.

A few months ago I made the following changes to the old 1036:
* Fixed a bug in single player where a saved game wasn't properly reloaded after death (you fixed this too in 1050)
* Changed all the defaults to make WinQuake look and feel exactly like the original
* Hid all the customization menus but without removing the variables, so if a mod needs them, it will work
* Limited the maximum resolution to 1280x1024

Ever since I made this, I've been following your changes and keeping my little fork updated, but I haven't uploaded it anywhere yet.
Since Mark V isn't on github or a similar site, I didn't want to just upload it and make it look like I'm the author so I wanted to ask if you're planning on uploading Mark V on github or a similar site, so I can fork the project and give you the credit that you deserve. 
Heyyy, I like the idea of having a fork that "Changed all the defaults to make [Quake] look and feel exactly like the original"... to a certain extent; I mean, I see no need to remove menus that allow for easy customization, and if a user wants a higher resolution, there's no need to prevent them from selecting it.

I have no problem with making all kinds of changes (I enjoy tweaking and playing with settings... which is why I break so many things in bugtesting!), but the default Quake look and feel should always be the starting point (which was the vast content of the post I just made on my forum -- all the actual reasons why I would like many settings to be reverted to the Quake Default, as they produce unwanted behaviors for me).

In any case, no disrespect to Baker, who is the true mastermind behind Mark V, but I (and others) would absolutely prefer use a fork which addressed all the issue I have with altering Quake defaults. AND maybe dosse91 would remove the intentional blocking of OGG support! :D

Don't worry, I'd still bugtest here ;)

Though I might run into issues with dosse91's fork trying to make everything like WinQuake whereas I prefer hardware-rendered Quake.... 
MAKE YOUR OWN github repo call it sporkV or something then not its a test fork of markV with a link to Baker's website. or make your github private and only show it off to baker? or no just compare notes. 
Ah, I don't care about credit -- I don't even have "Baker" on the Mark V page nor in a text file with the executables (or on most other things like the QuakeDroid page) because I don't care.

Everyone's work is a fork of Carmack's anyway, isn't it? /end joke

My only interest is conveniently being able to play any Quake mod in the context that was meant in a resolution independent and preferences independent way and be able to use as close to anywhere as possible (all major desktop platforms, all major mobile platforms) -- with the start demos working nice and properly which no other engine has ever taken the effort to do it because it is tedious and unrewarding (stuff like bizarre behavior of the start demos if the menu is opened when the start demo switches, etc. etc. It's like 25 things. Hence almost all engines hide the start demos because the problems are so hard to address.)

Settings is no win. Some people think Quake is GLQuake or ProQuake (like gunter) and some people think Quake is WinQuake/DOS and others prefer say the FitzQuake feel or (insert another engine).

There is no winning with settings, only trying to make the major ones available -- even with things like mouselook, always run, animation smoothing, stair smoothing.

I tried to make it easy to compile so someone wanting to compile themselves would be able to do that. 
<--- That Pitfall Guy Is Me Successfully Escaping ... 
Warm weather now. I'll check the thread sporadically in read-only mode, unless someone finds an Earth-shattering mistake or such.

Main difference from last year, is I think I get to vanish with no annoying bugs like last year tool_inspector being broke.

I Think I Heard A Whoosh 
And There He Goes 
See you again for v2.0, mate! You deserve a break after this update marathon, I guess. We can all play AD in the meantime. With Mark V, ofc. :P 
Well, dosse91, Baker's outta here for now, so it looks like you need to make your fork available for download and create your own thread here on Func so we bugtesters can take a crack at (breaking) your version and provide feedback :D 
Two points on Baker's last thoughts as he ran out the door:

"My only interest is conveniently being able to play any Quake mod ... and be able to use as close to anywhere as possible."

Would it not be so much more convenient and compatible to allow OGG support then, for people who have OGG Quake soundtracks (it seems to be a common format for Quake users), and for people who have computers that don't handle MP3 well though Mark V for some reason (like me!)....? Just saying! OGG support would serve both the stated goals there: more convenient, and more compatible.

"Settings is no win. Some people think Quake is ..."

Indeed, which is a good argument for leaving all settings at the Default. Then you are sure to please at least one (rather large) group of people: people who expect Quake to act/look/feel the way it always has (whether that's Win or HW version).... Other people who want to change that can do so, to their own tastes. But having the engine set SOME settings to different defaults (some old, some new, some Fitzquake) has no chance of getting it just right for anyone... except people who don't care.

... hey... how do you people make your quoted text appear grey?? Is it a secret function for registered users?? bbcode obviously doesn't work here.... 
Huh, ya know, come to think of it, there are already those options at the bottom of the Preferences page:

Set to Mark V
Set to Fitzquake

Why is there no "Set to Quake Default??" That should revert everything I complain about to the standard Quake Default settings ;)

And that should be the Default settings, heh, and then people could easily apply your Mark V recommended settings if they wanted. 
Quoting from #1763 for your benefit.

I obviously can't speak for Baker but this wouldn't be just 3 extra characters. It's only 3 characters if you directly replace the existing .mp3 support with .ogg support, but of course you then lose .mp3 support.

Adding multiple file format support would involve enumerating files of multiple extensions, sorting them into lists, making decisions such as which format has priority over others (not so clear-cut - how do you decide between a high bitrate inferior format vs a low bitrate superior format?), and how to handle the inevitable crazy-assed situation where someone has multiple formats in the same folder (some of which may even be multiple versions of the same file in different formats).

Adding this support is not as easy and clean as you think it is.

Replacing the existing MP3 support with a different format - easy and clean.

Adding support for two or more co-existing formats - messy, troublesome, hard decisions to be made.

You say "just saying". Well you've said it; over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and Sweet Baby Jesus Make It Stop.

You want people to listen to you? Return the favour and do some listening back yourself; I don't think that's too much to ask for. 
Been Super Busy 
I haven't been keeping up with Quake recently, good to see so much work still going into MarkV. Can't wait to play some split screen when it happens ;) 
Linux Binary PLEASE 
Any chance for a Linux version of the 1.99 release? And actually have working external music support? Quakespasm Linux has working music I don't see why the Linux binary of MarkV can't have it.

Also what the hell does "Cache_RLU: NULL link" or whatever even mean? I've never had that happen in Quakespasm. 
Now, mh, YOU KNOW that the paragraph you quoted from yourself in the past is utter nonsense (why are you trying to make it sound overly-complicated by talking about sorting lists and comparing bitrates and acting as though it's a crazy impossible situation if there are multiple formats in the same folder?).

Do you know how I know that you know it's nonsense? Because I just fired up DirectQ, YOUR QUAKE ENGINE, and guess what? It can play both MP3 and OGG files, and if I have BOTH an MP3 and an OGG file of track04 in the same folder, it simply plays the MP3 instead of getting confused by this "crazy-assed situation" and causing the earth to explode. FTE, on the other hand, supports both formats and gives preference to the OGG in the same situation.

So, YOU'VE done this. It was simple, because apparently you did it without even knowing you did it. It just works automatically, easily, and effortlessly for the user. But now you act like it's some impossible insurmountable obstacle to programming....

Are you retarded or something?

See, I don't listen to tards, because they say retarded things that just aren't true.

Just saying! ;) 
Now the continuing report of the weird centerview behavior....

Me and another player on the FvF server experience it working and not working at the same times. I checked the clock and it seemed to be right about 15:30 when it stopped working. On the next map (it starts working again after map change), I watched again to see if it would repeat, and it seemed to stop working again right about 15:30. Then it started working again around 18:00, stopped again sometimes after 20, then stopped again after 21... and stayed that way. At each point I told the other guy and he agreed that it would start/stop working during the same periods it did for me.

I was using Quakedroid with keyboard only, and he's in Linux Mark V using mouse + keyboard.

I tried playing around some more to see if those times would aproduce the bug in single player or local multiplayer, and by restarting a map on the online server and messing with the host_framerate, but I can't really get it to repeat.....

But it's rather odd that centerview (not force_centerview) should be affected by anything the server is doing... at certain times... for multiple connected players... isn't it? We were just standing around in the game not doing anything weird. Pretty sure I don't do anything in FvF that should alter a player's view like that. And as I reported before, after tapping the centerview key, the view will center itself after like 10-30 seconds when the issue occurs.

Weird one. *shrug* 
@gunter ... get me a demo and the time within the demo the problem crops up. Use cl_autodemo 1 or have your friend use cl_autodemo 1.

There are dozens of items used in the Quake view drift calculations, some come from the server or the mod (QuakeC).

It could be so many different things like the server/QuakeC specifying "wishangles" or movetype fly/noclip or an onground flag that without live catching it, there is not a reasonable chance of isolating what is occurring.

Since a demo is the capture of all communication from a server, the information within a demo should be enough for examination to see what variable is the source of what you have experienced.

Other: I'll build the Linux in the next 24-72 hours. The "link active" thing should go away. Although I spent some time examining ffmpeg, too many irons were in the fire and I never got around to adding soundtrack support for Linux nor QuakeDroid because there was too much going on. So that'll happen next time (maybe Christmas).

@fifth - Yeah, split screen is going to happen! Haha! Almost happened this time. Next time is a lock. 
It's ironic that this may happen when I am playing the least amount of Quake for about 10 years. 
Asking Baker for help since he has experience with both the software renderer and with things like his tool_texturepointer. 
Did I say adding ogg support was impossible? Don't seem to recall saying that. Yes, I've written it myself in the past, did I deny that? You'd think the fact that I've written it would put me in a position where I could be assumed to know what I'm talking about, but apparently not.

Yes, I know what code that supports multiple formats looks like. I know the kind of things it needs to do. I've written such code, so please don't assume that I'm BSing when I say that the MP3 code in MarkV is nothing like it. This isn't a simple modification, this is an extensive gut-and-rewrite.

Asking for the same thing over and over again when it's already been both patiently and impatiently explained that you're asking for a lot more than you realise is wearing pretty damn thin. 
I don't quite understand what's the big fuss about having to use MP3 versions of the Quake soundtrack. They are not that hard to obtain. "Other ports support OGG" is not a valid reason to insist on this IMHO.

Sure, it's maybe nice if you can use the soundtrack files in different ports if they are in OGG format, but honestly I am only using Mark V by now. As far as I am concerned, I got used to using MP3 files. 
@gunter - Your Rare Heisenbug Demo 
I reviewed your demo and peeked at some internals. Things affecting lookspring ...

1) internal game clocks (seems fine)
2) onground is non-issue
3) Although the problem went away on level change, it could be just a coincidence.
4) The server wasn't stuffcmding anything that interfered.

Can you link me up a copy of your config.cfg and autoexec.cfg so that I can review some other potential things since cvar settings combinations could be involved or divide strangely with floating point. 
I almost replied your post @ inside3d yesterday about your engine and polygon points.

But I suspect you might not like my opinion of an answer, but here goes ...

Mark V has *ALL* of mh's matrix calculation and manipulation functions. This stuff primarily is not needed for WinQuake since it doesn't use OpenGL, yet even Mark V WinQuake uses these.

I you looked at Mark V texture pointer code, you can see it drawing the polygon and doing that calculations you are seeking would be straightforward.

What stopped me from posting is that since you do the software renderer, you likely don't use OpenGL matrix transformations -- and I felt my answer would be unhelpful (*).

You'd also probably have to add some GLQuake extra fields to some structs to make life easier. So I figured you would hate my answer and didn't post it.

(* because it took me a couple of years of get good at 3D matrix math and if you aren't using it regularly, I doubt you wanted the "hey start learning it and in 6 months .." kind of answer.)

There is Carmack matrix manipulation stuff in WinQuake, but where it differs from the look and feel of OpenGL matrix manipulation it looks Greek to me, mostly because if I didn't need to understand it for a feature, why investigate. I think one of the few times I used Carmack's matrix stuff was for "fov doesn't affect gun" option.

More Concise version: If I were in your shoes, I would add all the glpoly_t to the WinQuake renderer and modify the surface structure and use those to access coordinates. Then use mh matrix functions against those points and things like Mark V project/unproject (which is basically similar to gluProject) But I don't think you'll like that idea.

Plus my thoughts are shaped by my lesser knowledge of the internal workings of the software renderer than yourself, so I don't even know if "what I would do" is optimal. 
(* because it took me a couple of years of get good at 3D matrix math and if you aren't using it regularly, I doubt you wanted the "hey start learning it and in 6 months .." kind of answer.)

Yes, that's more or less the point. I don't want to get deep into this kind of 3D math before finishing the stuff I'm working on right now. Plus, what puzzles me the most is not the math, but the fact that it seems that the on-screen vertex data is unreliable.

I you looked at Mark V texture pointer code, you can see it drawing the polygon and doing that calculations you are seeking would be straightforward.

For now I'm going to do it the brute force way and extract the coordinates from the chained spans data, iterating through the whole chain to get the max and min x & y values. I suspect there'll be a lot to rewrite in the engine to get this kind of data in a straightforward way. But I'll take a look at what you suggested, thanks.

By the way, Makaqu has support for .scale on SPR sprites, so you can copy it from there. IIRC it's pretty simple. It also has .scalev, which can be used to scale each axis individually. The only model format I didn't try figuring out how to scale is BSP. 
extract the coordinates from the chained spans data

The glpoly_t has those and generates them on map load.

BuildSurfaceDisplayList <--- in Mark V and I think the same name in FitzQuake 0.85, which might be the same code as GLQuake (never looked, but seems very likely).

Also see: DrawGLPoly where it shows code drawing iterating through a polygon.

Generates all that glpoly_t stuff. Just on map load.

For any glpoly_t named "p" ... the verts are p->verts[0] (X), verts[1] (Y), verts[2] (Z)

Anyway, the reason I recommend this is that the code for getting the verts is already written in GLQuake.

(Then create a projection matrix and a model view matrix based on current player origin/angles and fov and combined with the viewport width/height you can get convert between real world points and screen points including z near depth 0 and z far depth 1 as much as you like <--- part of answer you will hate obviously, but the nice part is that it works.). 
Here's a thought for you ... QuakeDroid has tap-fire and the very first QuakeDroid was (WinQuake) before a switched GL to be the main QuakeDroid.

1) Load up Mark V WinQuake.
2) Type vid_touchscreen 1 in the console.
3) Double click on a torch and watch what happens. It is QuakeDroid "tap fire".

Now double click on a wall.

Now think about the fact that in order for that to work, the "tap fire" has to know the targeting distance to get the angle of fire correct!

("Tap fire" has about all the calculations you want, and it does them in WinQuake! No GLQuake at all. It shows you how to do most of the things you need.) 
@Baker Help/support For My 100b Jam Map. 
Hey, I've got a map incoming for the 100bjam. It is currently using many new mdls, some with alpha textures recently supported with the newest Quakespasm release. Notable, these trees here as seen in Quakespam 0.93, Quakespasm currently displays all my models correctly:

When in MarkV dx9 the transparency doesnot work on 1 skin, also the model itself appears to be transparent with the background bleeding through

In Mark V the skin is fixed but bleeding from behind the model is visible, as well as a transparent layer that seems to cover the entire model:

Also, geometry is bleeding through all my models in Mark V even when they don't have transparent skins:

Currently only QS will run this map correctly. Anything that can be done Baker? 
@redfield (mh) 
OMG! It's beautiful! I knew you were a talented guy but I've never seen anything like that in Quake. I'm not sure I would have ever thought it possible.

1. Do you have r_shadows off?

If r_shadows is off ...

There is an Open GL Mark V 1.99 in the following zip (It's the SDL GL .exe)

I would recommend you check and see if looks ok in OpenGL.

Let me know ... 
Disable fog. 
Running on the newest openGL MarkV fixed all the issues with the models and the display perfectly now.

But there's a new problem. My map uses a func_illusionary for the bottom skybox face, with a minlight func_group beneath it. This is in order to properly light the models. Other methods failed because there is a problem with the current version of ericWs tools. This sky works fine in QS, but the bottom is not showing in this MarkV release now. 
I guess I didn't notice that the bottom skyface wasn't showing on older MarkV version as well. I mean I could try casting sky on a func_wall (although this makes sky 'shootable') instead as this also worked in QS, but will either of these methods methods display properly in MarkV? 
So there is a func_illusionary skybrush at the bottom of the map?

Do you have a sample .bsp that illustrates the issue? Need something to look at. 
Sample map with func_illusionary as bottom sky face, beneath that func group with minlight, beneath that a regular brush. 3 layer Sandwich. Run this in Quakespam and MarkV and you will see MarkV has no support for func_illusionary sky.

Source is included 
Cool! Sky brush entities are rare (so rare I can't name with a map that uses one, and I have lists of maps with uncommon features) I probably forgot to implement it for lack of a test subject. 
Yeah, otherwise it seems to run fine in the newest version which is good news. I guess this means v1.999 is on the way?:) 
Trouble With Rubicon Rumble Pack 
Rubicon Rumble Pack, version 1.03. In map telefragged, when you approach the area with the 4 labs (the one with the platforms going up and down in a pool of slime), Mark V closes to desktop with no error.

This is on Windows 10 1803 x64, with all versions of Mark V. 
For the area you are talking about, could you type viewpos and give me the numbers.

It looks like this:

Camera: (544 288 50) 0 90 0
Viewpos: (544 288 28) 0 90 0

Rubicon Rumble is a really big map. 
Sky entities addition done. Just need to build.

(I would like to look the issue that gvakarian says occurs with Rubicon Rumble before doing another build, I've looked around some of the maps but I don't know/can't find the area he is referring to ... the maps are gigantic). 
Great stuff Baker. I'm hoping that players who are MarkV users will be able to enjoy my map. Not sure how your gonna find that Rubicon glitch, needle in a haystack. Goodluck 
The approach to the 4 labs is in telefragged.bsp at "1134 -319 -8" facing angle "0 0 0". the labs are through the doors at the end of the hall. 
@ericw, @redfield 
Haha! Thank you!

If someone says they have an issue and I can't investigate it, it is annoying as hell!


@redfield - Any chance to get something to test the outstanding issue of screenshot you first posted that had black where transparency would be in the DirectX Mark V. I've done some fence model texture skin tests in DirectX Mark V and it renders just fine.

I'm glad to see alpha masked models get some live use in actual Quake. 
Heisenbug Identified 
It's a tricky one. Baker mentioning floating point divisions put me on the right track of what to look for.

Ok, in FvF, the Cleric and Monk can create health and armor. In Quest (coop) mode, they get XP (frags) for giving that health and armor to their teammates.

A regular health box given to a teammate earns you 0.25 frags... so after you've given 4 health boxes you've earned 1 frag/point/XP.

Quake doesn't have a problem with this for math and display purposes, as it only shows the rounded number in scoreboards and such, and when the map changes, the fraction is dropped completely from the frags value.

BUT! This seems to be the cause of the bug. When ANY player's frag value contains a fractional value, it prevents EVERYONE on the server from using centerview! Well, I mean, it usually works on a delay of like 20 seconds.... But what's up with that? Why should someone else with a fractional frag value prevent everyone's centerview from working correctly? Why would frags even be involved in centerview?

Upon tossing that 4th health box to a wounded teammate (so my frag value no longer contains a decimal value), my view will then auto-center right away (having previously pressed the centerview key).

Reproduced in Mark V, QuakeDroid, ProQuake, and Qrack... so... if you fix this bug, you'll be breaking new ground ;) 
@gunter - Great! 
Awesome gunter! Glad to see you solved the mystery.

I turned over every rock and was striking out. 

For me the big deal is that Mark V has a really hard time loading MP3 files on my WinXP netbook. I've heard another person say something similar.

When loading a decent-quality MP3 track inside Mark V, the entire game literally freezes up for over 20 seconds while a glitched menu sound (if I just activated external music in the menu) replays over and over until it unfreezes, and then the music starts playing.... I manged to find some re-encoding settings that reduced the quality of the MP3 a lot and got that freeze delay down to 5 seconds....

However, when I use OGG files (by renaming things or hacking Mark V with a hex editor to replace "MP3" with "OGG") then the song loads almost instantly, with only a 1 second delay or less.

So yeah, it's a real issue for me, and not just some weird irrational preference for certain formats! ;) 
Add: I'm not sure, but since you can reliably identified and recreated the circumstances in multiple engines, it gives me something to think about. 
Gunter, I just want to point out that it is impossible to play ogg on Android or an iPhone (without unacceptably chewing up metric shit tons of CPU -- hence the frames per second would be absolute trash --- because it is an obscure format and hence does not have hardware decoding in the processor) while because mp3 uses hardly any cpu at all because it has hardware decoding built into every phone/PC/device on the planet.

Plus the Mac version of Mark V plays mp3 via Apple API via hardware decoding using nearly 0% cpu. ogg being an obscure format that no companies ever use, there is no Apple API for that.

I care that your Quake works right, but you already found a solution that works for your computer issue with mp3 by cheating around with something that happens to work on Windows.

So your personal issue is solved.

My issue is I want things to work the same on all 5 platforms that Mark V supports.

Why the hell would I want to support an obscure music format that can never work on the 2 mobile platforms that I like with Mark V.

Why would I also want to recode the Mac version to support a shittier music format that uses more CPU? Oh -- and since I couldn't use Apple API I would have to rewrite the music code.

And the Quake .mp3 sound tracks are available everywhere, like on the Steam page. Case in point, this guy is links to it. Also Travail's soundtrack is mp3.

Also why the hell support more than 1 music format?

Shall we figure out new graphics formats like .bmp or hey let's do .gif!

The only engine that can't play mp3 is DarkPlaces, and to be blunt --- DarkPlaces is an extremely shitty engine for playing Quake because it made itself so damn incompatible with a lot of Quake mods.

I'm just communicating my point of view.

I don't care if people discuss it or what not, discussion is always a great thing -- environments where you don't find discussion or arguing are sterile and mindless. You might consider listening to my point of view, though --- I have one too! Haha 
mh, yeah, I was being overly-dramatic because you were doing the same. But you've remained clam and respectful in your recent post, so I will do the same (funny how that works).

Sure, I would normally take your word for it, in areas of engine programming, but not when you are making statements that are clearly exaggerated and misleading.

Of course, in your original post on the matter ( #1757 ) you pointed out that Mark V already supports OGG through DirectShow, which you knew because you were the original author of that code, but Mark V is hard-coded to only look for MP3, and supporting OGG should just be a matter of adding support for other extensions, but, you said, "I can't say what kind of work would be involved in this change."

After that tip, irlyap and I found we could hack Mark V to allow OGG files, and PRITCHARD made the amusing comment: "It makes you wonder what ogg did to Baker - murdered/kidnapped family I guess - in the past to make him think 'I have this perfectly good DirectShow support in my engine. I should ruin it and only use it for mp3 format music to ensure that my users have to work harder than with other engines!' "

irlyap made the comment that it would be like "adding 3 characters" which is when you pointed out it would not be THAT simple, which I'm sure is true, but the paragraph of reasons you gave (which you recently re-quoted) is the problem.

I'll just take one part of it as the crux (though I believe the entire quote is trying to make it sound more complicated than it actually is):

"making decisions such as which format has priority over others (not so clear-cut - how do you decide between a high bitrate inferior format vs a low bitrate superior format?)"

So, since you have coded multiple-file-format support before in DirectQ, did you actually DO that comparing of bitrates?

I already know the answer: No, of course you didn't. Comparing bitrates of various file formats would be a completely ridiculous thing to do. There are several Quake engines that support multiple formats, and I bet not a single one of them would dream of doing something like that. The only decision you have to make as to what takes priority is, "do I want MP3 or OGG to have priority?" and the answer to that is already quite obvious for Baker! Heck, I'm thinking that decision would happen automatically if the coder didn't want to specify a specific order -- the engine would just play the first format it came across according to it's internal list of formats to look for....

In #1764 irlyap pointed out that OGG was already " listed in Mark V's file extension look up table" and he guessed that there must be some code that explicitly ignores of forbids it. Then just a couple posts after that, both he and I pointed out that you don't need to do any of that overly-complicated stuff -- just add support for OGG with preference for MP3, and that's it. Sure, that's likely more than adding 3 characters, but I know it's nowhere near as complicated as the quote you brought back up, after we had previously "patiently explained" that none of that was necessary....

Now, maybe your original intent wasn't to make it sound overly-complicated and you were just considering options.... You did also say in that same old post, "I absolutely do think that people should make the effort to do all this, of course. But it would need some guidance as to what the end-user expected behaviour is. ... it would be nice to see players striking up a discussion among themselves about how they'd like to see these kind of decisions work out."

The expected behavior is just as I said (and maybe irlyap explained a bit more thoroughly in #1768 though he spoke of 3 example formats when all you need are 2). Allow support for MP3 and OGG in that order of preference. Or, stated more simply: just allow the engine to look for OGG files if it doesn't find MP3 files! How hard could that be?

Baker's objection to OGG has never been that it would be difficult -- he just wants Mark V to be The Engine of the Future, and OGG doesn't exist in his Perfect Future! (or something like that!).

Now, before there are any slippery-slope arguments like "Where do you stop? If you add one format, you have to add hundreds more..." -- Nope, all anyone is seriously asking for is a second format, OGG. So you have a mere two formats, and that's all you need. Nobody uses any other formats for Quake music (not that I've heard of -- someone said something about Opus and QS? Is that really a thing? What the hell's an Opus?? Isn't that the penguin from a comic strip??). 
I explained my point of view. I want the engine to work the same on all 5 platforms.

Tomorrow, you might get a new computer and you will no longer care about any of this. 
Ok, I'll address your points.

I accept that Android won't play OGG. No problems with that. But I don't see that as a good reason to say, "Since mobile platforms don't support OGG then I also want to prevent the desktop versions from using OGG when they otherwise could."

You say you want things to work the same on all 5 platforms, but that's never going to be quite true. For example, my WinXP netbook does not have a touch screen, and my Android device doesn't have a mouse.... Yet there are touchscreen and mouse things coded into the engine.... So what happens if I enable touchscreen or mouse on a device which doesn't support touchscreen or mouse? Nothing. Nothing happens. And that's fine. That's how it should be.

So if you allow Mark V to simply look for OGG files if it doesn't find MP3 files (simplest way of stating it), what would happen on an Android device, even if I had OGG files installed? Nothing? Would just nothing happen because Android won't play OGG files? So it would be no different whatsoever from now? That's what should happen: Nothing.

So there would be no harm done if a WinXP computer, which can easily play OGG through DirectShow, were allowed to do so, but a Mac or Android would simply do Nothing because it can't play OGG. For the user's benefit it would just be as simple as stating, "Mark V supports MP3 as the primary format, with OGG as an alternate format if you have a Windows computer with DirectShow which is capable of playing OGG" (and face it, Windows users are likely the majority, so it's not a trivial number of users we're talking about).

"Why support two formats?" For convenience of the users. I'm not the only person who has asked for OGG support in the past -- I only started asking when I found OGG magically fixed my freezing problem with MP3s (and I suspect Dutch had the same problem). Yeah, I can hack a workaround, but then I have to offer my hacks to other users who may prefer OGG for various reasons, and I find that "solution" to be ... ugly.

Nobody is asking for more graphic formats, and nobody is asking for a multitude of music formats. But yeah, apparently OGG was a fairly common format for the Quake soundtrack... otherwise there wouldn't have been multiple people asking for it.

And what would be the harm if just *Nothing* happened on platforms that don't support OGG? While at the same time allowing OGG to be used on supported platforms by simply allowing Mark V to check for an OGG file IF it doesn't find an MP3?

The benefit is that it helps users who either have MP3 problems in Mark V (like me), or users who already have the soundtrack in OGG format installed....

Pros: Benefits/is more convenient for some users.
Cons: None?

Is that accurate?

I mean, this isn't a case where you have to specifically tell android to NOT play OGG because it will be slow and crappy, is it?
Isn't it the case where Android (or Mac, or whatever) will simply do Nothing if an OGG is present? Because that's exactly what Mark V does now when an OGG is present! 
"Tomorrow, you might get a new computer and you will no longer care about any of this."

You keeeeep wishing that, don't you? XD

(And I still don't know how to make quoted text appear grey.... How do people do that?) 
And then I found THE FAQ thread.... Which told me the codes, which are very similar to BBCode but not exactly the same.... 
Baker, download this model and drop it into a map using Quoth custom_mapobject or AD misc_model and set the skins to 0 and 1.

I tested with an isolated clean install of Quake and MarkV Dx9 and your newest build. Only the new build displays these models correctly.

Thing was a bitch to make, so its nice that newest builds of all the engines (DP untested as yet) can display it properly. 
@redfield - Masked Models Will Be Ok In DX9 
I think everything is going to work ok for DX9 with the masked models.

screenshot: red tree masked model now renders leafy style in DX9

I'm not actually modify the DX9 rendering, but in this case was able to determine what the DX9 hated and do it a bit differently to get it pretty close to what it should look like. 
Just curious, what was different between the two mdl's that caused one to work and the other not? 
This is great Baker, thnx.

Yeah would be interesting to know. Its the same model only skin difference. 
The Red Tree Skin 
The red skin has fullbright pixels in it.

If you do "imagedump" and look at the fullbright skin generated ...

You can see dark red that would technically show up in pitch black with no lightning.

(Really the texture probably shouldn't -- like it might have glow in the dark pixels to the extent that dark red is , but it happens in map textures all the time too, haha.).

So it was using a combination of OpenGL capabilities at the same time that doesn't normally happen in Quake with alias models (.mdl), so the Direct3D wrapper wasn't prepared for that situation or at least never tested in that situation.

/Short version: Was a DirectX wrapper thing 
I gotta fix this POS tree asap. I'm gonna kill this fu*king thing! 
I had the palette set to no brights, goddmanit! 
This should be a meme or something 
I'm drafting court papers against mtPaint right now. No brights was loaded in the palette. FRAUD. 
Everyone Take A Deep Breath... 
Ok, the tree has been DEALT with. The evil brights are gone and the tree now displays in Dx9 Mark V as intended:

Directx9 Alice Quake Map

There is also a womans shoe model in an bubble with alpha applied and it seems to display as well. There is still a visible transparent layer across the models that does appear in the 1.99 release however.

Thank you @Baker and everyone.
I'm going to celebrate now with the mixing of chocolate and milk... 
^Does NOT appear in 1.99 I should say^ 
Just say "there is small rendering glitch in Mark V DX9 in one area and I'm told that it will be looked into and fixed in the engine if it can be".

If I can fix it, it'll get addressed. I wouldn't stop the show because of that. 
Mark V - Version 1.99 - Revision 4 (Final)

Download: Windows - DirectX | WinQuake
Download: Linux GL | Linux WinQuake


* Sky entity support (redfield)
* Alpha masked models w/fullbrights fixed in DX9 (redfield)
* Ctrl/Shift bind firing/console if on server (gunter)
* Linux "Cache LRU link_active" fix (Dr. Dumb*uck)

Also available are a couple of alternative/requested builds: extra builds 
Just related a note, (as I've reported before) my func_illusionary guy with his fullbright pixels still isn't transparent unless I set gl_fullbrights 0. The same goes for weapon models except the axe when I have a ring (unless custom weapon textures are used, which contain no fullbright pixels). 
Now, a fun story!

Oh my gosh.... I just went on a very frustrating adventure to try and make one point... and ended up with several points to make.

So to do this, I decided to try out Mark V's "install" command for map pack from Quaddicted. I've never messed with this feature before.

I tried "install qump" then I went to Single Player, New Game (because Mark V's "map guessing" feature is supposed to make that work)... but... it didn't start Qump.

So I looked at how it was installed, and I see that everything was put directly into the id1 folder....

So I checked the Qump readme, which explained that everything should be installed to a Qump folder.... But I scanned down and saw that the first map was titled "Beginning" (by PRITCHARD!), so I tried "changelevel beginning" -- map not found.

So I looked in the id1/maps folder and saw all the maps were actually named qump_[something], but there was no qump_beginning.... but I saw a "start.bsp" which had been installed.... Ok, that must be it, BUT because of unpacked files not taking preference, doing "changelevel start" will not go to that map!

Ok, so let's start over. I do "uninstall qump" ... NOPE! Mark V tells me the qump folder does not exist.... But.. you just INSTALLED it that way! argh!!!

Ok, I MANUALLY delete all the files that Mark V installed, using the list it told me in console. Handy.

And I notice that it overwrote my id1 start.lit file with qump's start.lit file.... *grumble* So I'll have to replace that with the correct lit file later.

Now, I remember people saying something about specifying a gamedir to install things to with the "install" command, but the HELP info for "install" doesn't tell me how to do that....

Soo.... I just guessed it would be something like "install qump qump".... buuuut that doesn't work, and produces an error message that I find unhelpful:

Need the game to install or the entire URL with
the http:// in it
Example: install travail or install [http://URL]

The version of libcurl used does not support
https:// at this time

So I give up on that and come to the conclusion that I dislike the install feature and will just install everything manually from now on!

I noticed when removing files that the file has been downloaded to a id1\_library folder, so I just unzip that and it already contains the Qump folder, making it very simple to install correctly.

Next I switch to the qump game dir and start a New Single Player game, and I'm in the qump start map (because it's correctly named start.bsp, making map guessing completely unnecessary).

So am I happy now? Nope! I finally got to the (only) issue which I started out wanting to illustrate: Mark V does not play the background music for this single-player release from Quaddicted because it's in OGG format!! XD

So I started up DirectQ (mh's engine!) since I knew it supports both MP3 and OGG (with preference for MP3) and did "game qump," and to my surprise it automatically tried to exec an autoexec.cfg file in the qump gamedir!! Which is now the third issue I have previously argued for in Mark V, which mh has strongly argued against, which I have later found to already be incorporated into his own quake engine!

So let me just go through this checklist:

[continued in next post, because I write more than 5000 characters!] 

So let me just go through this checklist:

Mark V:

1. Failed at correctly installing with the "install" command (and overwrote one of my lit files), and I couldn't find in-game help info to tell me how to do it correctly. So I had to install manually by just extracting the zip file, as usual.

2. The "map guessing" feature failed to help whatsoever, because in the first situation the start.bsp was installed to the id1 folder, and Mark V gives preference to the pak files (yeah, that's the Quake default, but it shouldn't be, because if someone has copied new files, like this new start.bsp, that should obviously take priority -- I guess that's issue 2.5). Then, once I installed qump correctly, the "map guessing" feature was pointless because the map pack correctly has its own start.bsp... and even if it didnt, I could have used the Levels menu to select a map.

3. Mark V does not play the background track because it's in OGG format, even though (on my system) Mark V can easily play OGG -- it's just hard-coded to only see MP3 files.

4. If I had set up my own cfg files in the Qump directory with any special configurations I want for Qump, Mark V would not run those for me when I switch to the Qump game folder....

Compare this to DirectQ, which is old and no longer being developed:

1. No difference in the first step -- I have to install the qump folder mahually. But since I know I have to do this, I wouldn't have to go through that annoying experience I had trying to use Mark V's install command!

2.5 Even if I had installed incorrectly into the id1 folder, DirectQ would have handled it correctly because it gives preference to unpacked files!

3. DirectQ automatically plays the background music because it hasn't been hard-coded to ignore OGG files.

4. DirectQ automatically runs the autoexec.cfg file in the qump folder when I switch to that gamedir (just the autoexec, not quake.rc), so any settings I want to use for qump will be automatically applied, as they should be.

Now, I'm not actually considering switching to DirectQ, but damn, it did EVERYTHING better in this example!! And each of these issues are things I have strongly argued for in Mark V. And ironically, every one of these things are things that mh has argued with me about, taking the opposite position! Well, not specifically on the "map guessing" feature -- I don't think he's said anything about that, but DirectQ also has a map selecting menu like Mark V does (which is the most correct option for starting custom maps).

mh may suggest that he made mistakes by including those features in DirectQ (he's done that before: #1640 ), but I'm serious here: mh, don't sell yourself short -- these features I've just encountered were great additions to DirectQ, because they "just work" and make things easier for the user without getting in the way or causing problems.

Now, back to the only point I was trying to make when I began this ordeal: some single-player map packs at Quadiccted contain the soundtracks in OGG format (as that was a pretty commonly-used soundtrack format for Quake engines), and Mark V, even though it could easily play them (though not on every platform, I understand), will not do so because you basically won't allow it to look for OGG files.... So... Mark V is (intentionally, in this case) not compatible with maps packs like the following, which contain OGG soundtracks, ranging from 1, 4, up to 11 songs:

These are just the ones I found when specifically looking.... Are there more? I would expect so.

You've said compatibility with single-player releases from Quaddicted if one of the main goals of Mark V, so why deny compatibility to the platforms (like Windows) which are easily capable of playing OGG if you would simply allow it to do so?

And oh yeah, all those other issues which I have argued for in the past, which just happened to come up when I was testing this example:

- No "map guessing" -- it causes me problems in addition to not working or not being needed.

- Unpacked file preference -- if a user installs unpacked files, those are obviously what he wants to use rather than the defaults stored in a pak.

- Exec autoexec.cfg when changing game dir -- if a user has an autoexec in a game dir, he obviously wants it to auto... exec it for that game.

Well, that was fun! XD 
Are you sure you are using the most recent version of Mark V? 
There's no way current Mark V would install/unpack qump to anything except its own folder.

Johnny Law and I used qump as one of the test subjects for getting the install unpack perfected. 
Ah, you're right about that; I have a separate test folder and didn't copy the today's newest Mark V there before testing. I was using 1.98.

I'm testing again with 1.99 annnd... it installed correctly to a qump folder.

Johnny, since you are familliar with a lot of the map packs, do you know of any others besides the 4 I mentioned that come with OGG soundtracks? 
Quick comment -- I wanted to look at qump's skyboxes on the original start map. Of course, qump includes its own start.bsp, meaning it overrides the usual start.bsp (as it should).

Then I went to the Levels menu and scrolled down past Qump's "Start - Between Worlds" map, all the way to the bottom section for "Original Quake Levels," hoping Mark V would know to use the start.bsp located in the pack file if I selected it from the "Original Levels" list... but... it doesn't, and qump's start.bsp still runs.

How about forcing it to use the original levels from the pak file if they are specifically selected from that section of the Levels menu? Is that possible? 
Thinks: I wonder if this same topic "over and over and over and over spam" reaches the point where moderator assistance becomes necessary? I sure hope not. 
I wonder if moderators will start taking action on all the passive-aggressive posts on this site? I sure hope not, even though a lot of people around here are [edited by moderator] 
Good catch.

What you want is possible as long as the unpacked maps are in a different gamedir (qump/maps) while the original Quake packs remains in id1.

Start the pack with -game qump, and type map ../../id1/maps/start in the console.

When running mods, it would be wise for the maps menu to add this relative path to the original maps' names. 
[edited By Moderator] No Offence 
i don't get that fancy shit, like automatically extraction to that given folder, the peeps are too lazy nowadays

just download the hotdamned archive, and extract it according the readme file 
About the "OGG drains too much battery" issue, that can be perfectly worked around by making the engine transcode the OGG files to MP3 and saving the resulting MP3 files to the storage flash/disk drive during engine bootup. This way, when the game wants to play music the MP3 files will be there.

Optionally, the OGG files could be automatically deleted after the MP3 files are saved, to conserve storage space. I'd leave such an option turned off by default, though. 
It's true. Few people will use the install command.

It's a stepping stone to full blown built-in "Quake Injector".

At this point is only needs a nice user interface inside the engine.

I want it to be very sophisticated like the Quake Injector, but I also want it to look nice and Quakey in the engine.

Maybe next "development season" I'll talk with Johnny Law and get his thoughts.

I would also kind like of like to enhance the frogbot support to offer some way of setting up the frogbots nice and easy in the engine. (Maybe "development season".)

/Next time things 
<--- There He Goes! 
Ended up doing a final revision for redfield especially because the map uses alpha masked models (I like alpha masked models and want them to be used in Quake).

I'll be back sometime before Christmas and do split screen for sure and I'll probably check the thread every few weeks in read-only mode.

/Back around Christmas, I imagine. 
I would also kind like of like to enhance the frogbot support to offer some way of setting up the frogbots nice and easy in the engine. (Maybe "development season".)

Wow, sounds nice! 
There He Goes 
Or so he said last time. We'll see.... 
@mankrip, nice, that would be a really clever way to "support" OGGs on systems such as Android that can't play OGG natively. Though I'm not sure how much of a delay might occur the first time the transcoding occurred. And it wouldn't help in my situation, as I would be right back where I started, with MP3. But still, that would be a clever workaround to allow maximum compatibility for soundtracks on all platforms. 
I've got a pretty thick skin so I can handle being called a "dumbf*ck." But I have never run Quake on Linux and have not tested Mark V on anything but Win7.

As far as the install command. I plan on covering that in the upcoming Mark V video. I love that feature and anything that will make it easier for people to play my maps is welcome. It's not laziness IMO. There are too many alternatives for people's attention. 
Mistaken identity. There's actually an FvF player called Dr.DUMBFUCK who I told to come here and report his Linux issue, heh. #2137

But I guess you could be Dr. Dumptruck! 
it wouldn't help in my situation, as I would be right back where I started, with MP3.

Then I don't see what's the problem. I don't pay attention to most posts. 
Shortest version: on my WinXP netbook, loading an MP3 causes Mark V to completely freeze up for up to 20 seconds, but an OGG file of the same track loads in 1 second or less. 
Then the MP3 playback needs fixing. 
I've been following the thread and didn't notice that name. LOL 
Mark V And Xinput 
Baker, here's a note for your next session. :-)

Sometimes I play Quake through Steam in-home streaming. My controller in that case is a Steam controller that presents as an Xinput joystick + buttons. This works with Quakespasm, but not with the latest Mark V (even with the -joystick option specified).

The console says:

joystick not found — invalid joystick capabilities (6)

Reading back through some previous posts I can’t quite tell if I should have expected this to work or not. So, FYI. 
Cool Stuff 
Thanks for putting out that new release Baker. You are da boss. My map should be out with the release of the upcoming mapjam. 
Yeah, I still have issues too. I still have to physically unplug my other controller (whether set to dinput or xinput) just to get Mark V to recognise my XBone controller. I, too, was unclear if these issues were addressed or deferred... I'm not the brightest bulb on the Christmas tree so it's nice to see I'm not the only one a little confused here. :) 
[edited By Moderator] Not Sure If This A Bug, But 
Let's say i'm running a background streaming video in my browser

i run MV, and in that case, the fps are locking at 60

i terminate the streaming video, the fps are upping to their max

i'm still cannot figure this shite 
Why Is Everyone Saying Android Doesn't Natively Support Vorbis? 
I'm fairly certain that Android has supported Vorbis since 2008, so why is everyone saying that Android doesn't support it natively? What's the big issue with Vorbis support anyways?

I also find it strange that people say that Vorbis is not used in the game industry at all and that it's 'obscure,' yet I can name 5 games off the top of my head that use Vorbis? 
I don't recall the claim being that Android doesn't supports oggs. The point is that hardware decoding of mp3 is ubiquitous, oggs must be software-decoded and that make a very appreciable difference to both performance and battery life. "Everything is software" is cutesy in the desktop space but it cuts no ice in mobile. 
Use Ctrl + F and search for OGG and you'll eventually find claims that Android doesn't support Vorbis.

And what exactly does Mark V have to do with mobile though? I still see no reason to purposely disable Vorbis support for the desktop if Mark V is used on mobile devices, especially when some people have issues with Mark V loading MP3s. 
About that: I still would like get an answer on mp3 playback in the Quakedroid channel. Just look at my most recent post over there. 
When I was mentioning that Android wouldn't play OGG, I was only mistakenly repeating what Baker seemed to say in #2169 where he used the word "impossible." But then I found that Android CAN natively play OGG, and I posted about it over in the QuakeDroid thread.
I read something online saying that ringtones in MP3 format do not loop in Android, but ringtones in OGG format do loop (if a certain flag is set in the file), so I assume that's why Google uses OGG format ringtones for apps like Hangouts (and other built-in alarms and ringtones you will find in Android).

brassbite, I don't think music support has been added to QuakeDroid yet. Like you, I could not get an MP3 to play in the game. 
Well Thats A Bummer 
Why are we even discussing adding ogg support when the fucking game can't even play any music at this point? 
QuakeDroid played the OST just fine for me... 
So... i'm trying to compile the last version of markV
(this one )

and i'm getting the following error:
fatal error C1083: Cannot open include file: 'windows.h': No such file or directory

what am i doing wrong? :/ 
QuakeDroid played the OST just fine for me...


Well, then I don't know what the deal is. I (and brassbite) can't seem to get the MP3s to play in QuakeDroid. We need word from Baker about this.

(And I think we're getting some cross-posting confusion between QuakeDroid and Mark V.) 
JFC Baker Has Repeatedly Said Ogg Wont Be Supported 
Stop banging on about it for gods sake. 
Gunter's mp3 problem will be solved in the Christmas update (this isn't new, I eventually gave up trying to communicate this to gunter).

Spike maybe a year ago told me about something neat he uses in FTE that will work even on Gunter's old WinXP computer just fine.

I'll add a cvar mp3_decode_fte and have it be a third click option in "cd/mp3 music on|off".

Gunter will end up being very happy and pleased.

@brassbite - I answered your question in the QuakeDroid thread (so anyone else looking for the answer can find it more easily).

@dumptruck - You wouldn't let me get the Trinity or the other 2 artifacts. And made me wait 10 seconds for the hammer. ;-)

@johnny - Yeah, just XBox controllers support. Microsoft controllers are actually backwards compatible to Windows 98 (!!) If you are super intent on using a Steam controller, find the release post and use the "alternate" SDL2 build! Your Steam controller *should* work with that. DirectX Mark V is not SDL2, so doesn't have the rich and deep controller support that they put into SDL2 (unless I steal it and graft it in, which eventually I will probably do in the future ... SDL2 is a very nice and freedom granting license .. a good reason to support SDL2)

@hipnotic - Yeah, it uses the first controller it finds. But in the Christmas version I'll add a way to set it to use "controller #2".

@tribal - I compile with Visual Studio C++ Express 2008 get it plus Service Pack 1. With that version, you open Mark V .vcproj and click "Build" --> BANG! It compiles.

So Tribal, I hope you can get it to compile. With the same Visual Studio, should be easy enough. There is no such thing as "current Visual Studio" because now they don't really do "versions" so I imagine they break things every 6 months or so because Microsoft is really good at that now.

/Resuming sustained months long inactivity ... 
@dumptruck - You wouldn't let me get the Trinity or the other 2 artifacts. And made me wait 10 seconds for the hammer. ;-)

I'm guessing you were probably messing around in the menus before starting the map. The sound files seemed to get out of sync with the triggers when I did that. Disconnect, set your settings and then reload. I tested the map in Mark V extensively and prefer it to QS. :) Should be a solid experience. 
I Wood've Bear With Baker 
a lotsa bears


20/30 buttles 
Hot Durmit 
Thank you for the links, but i couldn't install VS C++ 2008 :P

I download other versions of the same program and none of them install... i searched on google and it seems there's something worng with my framework NET 3.5 or something like that... i'll try to fix it on the weekend :/

Thanks again =D

And i agree with dumptrunk, i prefer MarkV to Quakespasm... i like the HUD that doesn't cover the weapon, the sound and music are better, the colors have more saturation, it seems to me that the explosions have more particles, i don't know, but the classic explosions looks more powerfull in MarkV) and the special effects like the shambler's lightning, tarbaby's explosion and the fact that you let me decide which special effect i want turn on or off is awesome =D

Thank you one more time XD 
Hi, it' me again =D

I think i found a bug :P

The tarbaby/spawn explosions doesn't change when you set to 0 or 1... it's the old/same explosion :(

i miss that pretty purple circular explosion from QMB 
Is WAV Playback Supported For Music? 
Just wondering. 
Wav Is Supported In Quakespasm 
...but can't confirm if it works in Mark V here at work. I wouldn't be surprised because uncompressed formats are generally easier to support and it's not OGG. (LOL) 
Spike has stated that .wav soundtracks is a bad idea.

Take an 4MB mp3 file and convert it to wav and watch it become 75 MB to 95 MB to 120 MB (it's kind of shocking -- you should try it and see for yourself.)

Spike said that the load times, the storage space, disk access time, memory usage make .wav "taxing" and undesirable for music play.

Anyway, that's what Spike said once upon a time when such a topic came up. 
That last post re: OGG was not a dig. I was LOLing at someone else. 
Gunter is very helpful and often able to make interesting observations that most people wouldn't notice. He plays co-operative all the time, knows QuakeC in a way comparable to Preach. Gunter isn't a bad guy, just passionate.

I think everyone occasionally gets passionate about something. Sleepwalker once had a guy named Dequer in the TrenchBroom thread who was "very passionate" about certain topics.

I think it is cool there are people still passionate about Quake.

Fun fact: Gunter once wrote a QuakeC rollercoaster ride. I kid you not! 
Just like this thread!!!!

That's a amazing. I do think Gunter's passion for Mark V has made it better. There's no one who is as vocal or who tests it more than he! GG Gunter. 
WAV memory usage is smaller than most compressed formats if it's streamed from the drive instead of being fully loaded. But the other negative aspects still apply. 
Gunter made a whole playground entirely in QuakeC where you collected "Quaders" to use the games and rides, which included said rollercoaster, a trampoline, and something else. The arcade games were tetris and pac man all done using Quake's special characters font. Along with little things you can interact with like sticking your hand down an ogres pants for a quader. All this was used as a hub for connecting to other popular servers at the time.

Sorry I know it isn't related to the topic, but it had to be mentioned. 
Also A Zombie Wall Climb 
Yes, The Hub mod. I remember long ago Baker had mentioned an idea about a Quake server that would act as a hub for connecting to other servers and maps, so I went nuts with QuakeC to see what I could come up with. Ok, well, all my QuakeC is kind of nuts. I probably don't actually know QuakeC as well as a lot of other coders, but I can hack code like a crazy mofo.

Using lots of stuffcmds I had all the various exits around the Start map linking to all the various active servers at the time. Just touching an exit would test the server and give you a report about what map and players were connected there, and if you sat in the exit for 5 seconds you would connect to the other server.

Of course I made the whole map like an amusement park (making new floors and walls just using QuakeC to copy entities), with lots of things to do....

Here was n old thread on Quakeone:

It runs as its own server, so I can't really get it up and running since I don't host servers. And it's more of a curiosity now anyway, since there are so few active servers these days, so it kind of lost it's initial purpose.

Though I have considered hacking the hub stuff into FvF Start map... but that would require me to be a lot less lazy than I am.

Oh, and I have to note the arcade games in The Hub were taken (and modified) from code made by FrikkaC and MauveBib.

And yeah, I'm passionate about stuff when I'm right about stuff ;)

And yeah, I will be very happy and pleased if MP3 starts working well for my WinXP netbook, but it would still be right to support OGG, for maximum compatibility and ease of use (remember, some single player map packs contain OGG soundtracks...). 
Mark V is going to have a built-in Quake Injector with full blown graphical user interface + search, taking the existing "install" command and taking it to the logical final step.

The same way QuakeDroid downloads shareware or how the "install" command downloads from Quaddicted, Mark V can easily download an mp3 for the very few Quake mods (three? four?) with some non-mp3 sound track.

Besides, Nehahra has the soundtrack in the crazy .xm format which I plan to convert to mp3 to eliminate the crazy fmod.dll dependency in Nehahra.

I've had a blueprint in mind for ages.

These small things are easily handled and not even interesting conversation to me.

I also plan ahead: Mark V had Android/iPhone code in the source for 2 years before QuakeDroid or releasing compilable source for the iPhone version which predated QuakeDroid by a month, for instance.

Likewise, today's Mark V source code has jpeg support so the built-in Quake Injector will be able to download map screenshots from Quaddicted and use them immediately on-screen.

/Boring details 
Nehahra DLL 
I always hated the fmod.dll dependency of Nehahra. Getting rid of that is another step in perfecting the support of this mod. Not sure if a conversion from XM to MP3 resulted in a loss of quality, though. 
There are a number of items in the pipeline, often undiscussed.

Like changing the Effects menu item from [Classic | JoeQuake] to [Classic | JoeQuake | NPRQuake]. The current source code is reorganized to make this straightforward to implement (last year's source code was not).

Also: Making mh's work on "r_shadows 3" really kick some major ass by having the option to have shadows acknowledge brush model collision as a surface (i.e. e1m1 slime bridge) would be great. The framework for the feature is already written. 
WAV memory usage is smaller than most compressed formats if it's streamed from the drive instead of being fully loaded.
In a world where 8gb is standard that's not really a big deal.

Besides, disk access is still slower than memory access anyway, so streaming from a HD in order to save memory, in a case where saving memory would not even be a requirement, seems to be the wrong side of a tradeoff. 
disk is slower but you can cache ahead as much as you need. The most intense disk i/o is at map load time so streaming during gameplay would reduce that.

(note: I am not advocating giant wav files to replace mp3s) 
XM Conversion 
Btw I am curious if Baker manages to make a flawless XM to MP3 conversion of the Nehahra music once it's necessary. I tried today and some of the tracks have crackling noise after conversion, even after normalization. 
How does this one sound to you? My initial attempt to convert had crackly sounds for this track.

I then meditated on it a little and the result was this ... which seems to be perfect.

Nehahra - neh5.mp3

Let me know. 
Mark V HD High Resolution Pack - June 16 2018 
Screenshots: Screenshot 1 | Screenshot 2 | Screenshot 3

Download: HD Pack - 128 MB and extract to c:/quake/hd

* High resolution textures (via
* Modified JoeQuake menu to match Mark V.
* Conback and character set (via
* .lits and transparent water .vis for Quake maps.

You may wish to set the following for best results ...

viewsize 110 // Hud to more Quakeworld appearance
scr_scaleauto 2 // "Auto Large"
qmb_active 1 // QMB effects instead of classic

Read more ...  
I'm not a fan of the look but I will check these out for educational purposes and I am a fan of Mark V. 
That type of look is popular in Quakeworld, DarkPlaces replacement textures users (Google up "Quake Epsilon" or "Quake HD" ... you might be surprised). and those who may have in the past really liked JoeQuake or Qrack (*).

There are also users who like high resolution textures because that have a large monitor and Quake textures don't look magnified on a large display because they lack the detail.

(Qrack: R00k doesn't seem like he is updating Qrack much these days. Qrack was popular for especially among those who liked playing original Threewave CTF online, and the last couple of years NetQuake multiplayer has declined quite a bit.)

I may in the future add some more options to support more fully the appearance of an ezQuake-looking HUD. 
its slowly evolving with some tweaks and feature
just not as many players any more so ive
ive been focusing on singleplayer functionality
but not dead but nothing to write home about
Trouble Since Windows 10 April Update 
My Windows 10 did the large April update, and since then Mark V has been super slow to start up, taking several seconds, whereas Quakespasm, for example, still loads almost instantly. Also, I'm not sure if it's related to the problem, but I tried playing dm4jam_ww, and without exception the game freezes when the Shambler's supposed to spawn at the beginning.

Has anyone else done the April update and had the above problems with Mark V afterwards?

For your information, if the engine freezes for you and you're unable to get the task manager window or the mouse pointer visible, I was able to do it with the following steps:

1. Press the WIN + TAB keys
2. Navigate to Mark V with the arrow keys
3. Press SHIFT + F10
4. Move the game to another desktop
5. Your primary desktop should become visible and controllable, where you can open up the task manager and shutdown Mark V. 
What I've observed is that the latest Mark V and latest Quakespasm both take a few seconds to start up now -- longer than I remember from before -- and that Mark V Winquake is still fast. 
I don't have issues starting up the engine but I get pretty poor performance. I've had slowdowns in id maps. Meanwhile my FPS doesn't dip like this in other source ports. Mark V WinQuake is all right but my PC has a hard time getting good performance out of regular Mark V. 
More Windows 10 updates weirding things up ...

Anyone else using Windows 10 have issues with the engine?

/Looks like an investigation is in order, but little surprised this didn't arise as an issue back in, say, April or May. 
Chiming in. Audio issues but I don't have access to that particular machine ATM. I thought it was my crappy hardware but then trying 1099 on an older Win7 laptop confirms there's likely an issue with Win10.

I will have access to another Win10 machine in a couple of days. Will report back ASAP. 
Not Sure Where To Ask This 
Is there a way to autoconcatenate demos? I never can do demos because I spam quicksave/quickload so often.

Am I admitting I play horribly...not really, but I love to save, do something stupidly crazy, probably die or fall to my doom, then quick load. I like to take huge risks, blast into a room, run around and get 50 baddies to follow me, trail vore balls through the lot, etc.

Is there a way to restart recording on the same demo file on quickload? 
Demo To Avi/mpeg 
Is there an engine with support to record demos direct to video format? 
Mark V has a way to record a demo to avi. Search for capturedemo above.

Also cl_autodemo for automatic demo recording. But I have not played with it. cl_autodemo 1 for host_maxfps 72 and cl_autodemo 2 for framerates above that.

I know there were some very good demo tools designed for protocol 15 that have wonderful features. I need to go and research them tho. I killed those brain cells with beer long ago! They are all old and may still work. Keygrip was the craziest one. Had an editing UI and everything. I tried getting it to work last year without any luck.

There was one great tool that made a highlight reel from deathmatches. It would eliminate everything but the kills and you could adjust the time before and after.

I am SURE there was one that joined demos. Just have to find it. But probably no way would it work with newer protocols. :(

I have the same issue. I Quicksave a lot and when I am reviewing someone's work I have to go back and reload and start a new demo. 
also if you just want a video and don't need an actual demo file, you could use outside software like Fraps or the Windows "Game Bar" 
There is a command line tool called convdemo for protocol 15 at that can concatenate demos (which may not be a lot of help since everyone uses protocol 666), but you could type "sv_protocol 15" in the console before playing and many maps probably still play with that on.

Mark V you can type "capturedemo demo1" in the console, the Mark V page has a codec that works fast and easy listed.

You can also do a .bat that looks like this and Mark V will exit after the capturedemo is completed.

c:/quake/mark_v.exe +capturedemo demo1
c:/quake/mark_v.exe +capturedemo demo2
c:/quake/mark_v.exe +capturedemo demo3

Mark V doesn't have a demo concat built into it.

Like dumptruck said, the "find" command finds about anything. 
Along the lines of what metlslime said, there are video tools that concat videos.

Probably easier to do that ... 
Oh Ok 
Drat...screen capture sucks though. Slows everything down. 
Quite a number of quake engines support video encoding one way or another. If you're intent on avoiding demos then my advice to you would be to avoid xvid. ffdshow should have an h264 encoder accessed via the x264 fourcc setting, but as that's patented I have no idea what americans should use instead for streamed video.

If you're okay with a demo, then try fte's capturedemo command. Its an offline offscreen demo capture process, so it'll run as fast as your hardware allows (iirc, dp also has some sort of offline capture, but it doesn't support 666 so w/e).

Which reminds me that I really ought to update fte's ffmpeg plugin in order to make use of nvenc etc properly, which should greatly reduce the overheads - if you've got an nvidia gpu (which should also be a way around patent issues). 
The supplied XVID codec on the Mark V has a few advantages that I have not been able to find in another free download:

1. It is rather fast. (WebM is way slower)
2. It doesn't come with adware.
3. It doesn't come with some other junkware.
4. It is easy to install.
5. It is known to work with the Windows video capture library that AVI capture Quake engines use.
6. Doesn't need a registered copy to encode.
7. It is known to work with the engine.
8. H.264 codecs seem to get overwritten by video apps installing their own special H.264 codec.
9. Doesn't do watermarks for unregistered versions.

For instance, I've found H.264 library and I did get it to work nice, but I had to do a lot of cmd.exe commands and might have had to run it as administrator --- too much to explain.

So I have a downloadable codec that is click, click, click to install.

/Anyway, the H.264 ones I found always seemed to have undesirable characteristics or junkware or put watermarks on the videos. And if it did work, the next video app might overwrite it with its own H.264 codec. Or so I recall. I myself would prefer a hassle-free H.264 codec without spyware or unwanted junk. 
Well Mostly 
I would just want to make normal demos under protocol 666 or 999 without changing my playstyle. :/ 
add "+cl_autodemo 1" to the command line or type it in the console before the map. It should do a demo every time you re-load from a save.

Then use something like Virtual Dub Mod (free) or some other video app to concatenate the videos together.

Another option is something like Bandicam and record the screen while you play. 
That's cool! Because I often refrain of recording demos because of Saving/Loading. 
Mouse Troubles 
Lately I've been having an issue with mouse clicks occasionally not registering. I doubt that it's a problem with my mouse because I've tested extensively in a few other source ports and I never had issues there. 
OBS Local Recording? 
It's worked pretty flawless from my experience? And I even have an old PC(circa 2010 AMD.

You have plenty of options etc, why is this not mentioned? 
I Have Obs, Quality Is Horrid 
Thanks baker, I'll give it a whirl. 
I play some Quake 3-4 times a week. Never experience mouse issues. And haven't seen any issues like posted in the thread.

I'll keep an open mind, though. 
It could be a Windows 10 thing. One of the updates within the past several months broke mouse look in the SDL 1 version of Quakespasm. I've used Mark V quite a bit but I only started noticing this mouse problem within the past week or so. Or maybe my mouse is failing but coincidentally only when using Mark V. 
I have a machine that I think now has all the updates for Windows 10.

Probably next week I'm going to see if I can experience any Windows 10 issues and see if I can locate a list of behavior changes for the "Spring Update".

Windows 10 updates are like a jar of random monkeys. Microsoft used to be good at compatibility and consistency. 
Well, Win7 has done me good for like 7 years so. 
Can you confirm the proper settings to play Mark V with a 144Mhz monitor?

My current config:

host_maxfps 144
vid_refresh 0

QS runs smooth as silk. It's clearly not working in Mark V 1099 and seems a bit stutter-y.

And yes I know 144 breaks physics. I just prefer playing this way. One thing to note: I use the same directory for QS and Mark V and switch between them often. Could it be a cvar I am missing? 
I don't have 144 hz monitor, so beyond:

* vid_vsync 0 + host_maxfps 288 (yes 288, not 144 for 144Hz) ... might get better results ..

Back when I did have a display with a higher refresh rate available, I don't recall it behaving any differently.

Does this alternate version of Mark V do 144 hz smoothly? SDL alt build. There may be something SDL is doing to smooth things, but this falls into the "hard to code for scenario one cannot test".

/Note to self: See if can locate a 144hz display. 
Also might need to manually set the refresh rate in Nvidia Control Panel to 144 when running Mark V or play with some settings there.

Mark V doesn't request a refresh rate.

(Because when Mark V first came out, it looked like 60 Hz was going to all displays, there weren't 144 Hz monitors and the only thing that supported changing refresh rates were CRTs and those were already dinosaurs.) 
Don't forget to add Spike's QSS fix for high fps. 
The SDL version had no change.

Typo above I meant vid_vsync 0

Setting "Highest Available" in the nvidia control panel was the ticket. That was the only option available to me in the CP. Thank you.

I am going to try and get 1099r4 tested on my Windows 10 machine tomorrow to check some of the issues mentioned above since the Spring update. 
Setting "Highest Available" in the nvidia control panel was the ticket.

That fixed the issue?

If so, when I do new version around Christmas I could have Mark V have a refresh rate cvar or command line param and just specify the refresh rate on startup.

Thanks for the feedback, very helpful. 
Good idea. A way to implement it would be:

- If recording a demo, store its filename into the savegame;
- When loading a save, reload its corresponding demo;
- Search in the demo for the frame that corresponds to the current frame stored into the savegame;
- Delete all frames stored afterwards, and resume recording. This new recording could use a different filename to indicate that it's a new branch (like "mydemo.dem", "mydemo(1).dem", "mydemo(2).dem", "mydemo(1)(1).dem", etc.). 
Yep that fixed it. Silky smooth now. 
Full Colors Maps 
Full color maps were briefly brought up in another thread.

Short Video: Full Color Maps

Map Download: halflife.bsp - 239 kb for anyone to try themselves in Mark V.

Will also work in FTE, DarkPlaces, several other engines. 
Full color what, exactly? Colored lighting + 16/32-bit textures? 
Textures Unbound From The Palette 
hlbsp has licensing issues from its toolchain, and the hull size issues makes it generally unusable for quake anyway.

besides, lit files and (same-size) replacements provide all the same advantages and with well-defined compat fallbacks, and without shamblers ending up half-inside walls, and retains overbrights, just with more files (unfortunately).

if really needed then the -bspxlit arg can be used to embed the lit files, and -notex can be used to force external/replacement textures using the same mechanism hlbsp uses for external textures (so should work in the same engines) including support for q1 or hl miptex from a texture wad. 
How To Make A Video In 45 Seconds Expending No Effort 
How To Make A Video In 45 Seconds Expending No Effort ...

0. Do once: Install XVID codec 11 MB. This isn't about the codec, this is about something that works quickly and doesn't come with ads/spyware.

1. Go to a map.
2. Type record thisdemo
3. Walk around for 30 seconds.
4. Type stop to end demo recording.
5. Type capturedemo thisdemo

Your are done. Where is thisdemo.avi? Type folder and it will be highlighted in Windows Explorer.

6. Optional: Drag and drop it on your YouTube page and upload it.

If you are in 640 x 480 windowed mode when typing capturedemo it will be faster than say fullscreen resolution @ 1400 x 900 because 640 x 480 has far less pixels to encode than 1400 x 900. 
"Anyone else using Windows 10 have issues with the engine? "

Not so much in MarkV; but QArack, and JoeQuake specifically take 10 to 15 seconds to initialize in win 10 for me. Where as both engines take under 5 seconds on my XP and win7 machines. Dunno. opengl 1.x emulation? 
I can confirm that startup on Windows 10 is extremely slow on my new tower. I have an Intel 7820 and 32Gbs of RAM. HD is a pretty decent raid from 10,000 RPM drives. Videocard is a Nivida GTX 780.

In Windows 7 - a much older machine startup is near instantaneous.

No audio issues as I have seen on my laptop thankfully.

Is there any way I can help observe/record the startup issue for you? 
1. Is it just the Direct X version?

2. Or is it also true for the WinQuake version also?

3. What about the SDL alternate build? download

It might help me triangulate in on something. 
I'll test this evening and post results. I probably should have done a proper test.

Also a question about Dx9 files you have linked? How do I determine if I need those? 
2x Post 
Sorry yes I was setting up TB2 and only played around with the DirectX version as well as QS and QSS. I'll copy over the SDL alternate and WinQuake versions this evening. 
> How do I determine if I need those?

Great question!

Mfx said he had the issue and said installing those files solved it, but I'm not seeing a description of the message other than "it didn't start up".

Posts 2106, 2109, 2110 -- "mfx - Thx, that download helped, works now." 
Yeah Mark V needs the DirectX 9 runtime support. I don't remember the error message but IIRC it's fairly obvious if that's why it's failing to start.

If you play other games on your computer there's a good chance you already have this installed. If not, it's harmless to install it. 
In the future, I may try to roll DX9 detection/installation into the installer form of the engine distribution.

There will of course always be the plain zips of the engine .exes. 
Report on Mark V Windows 10 delayed launch (and exit)

Mark V 1099r4 delay of 3-6 seconds launching and exit.

mark_v_sdl_gl_gcc - no delay
mark_v_winquake - no dleay
mark_v_winquake_gl - no delay

quakespasm .93.1 win64 - short delay launching and exiting (1-2 seconds)
quakespasm-spiked-win64 - short delay launching and exiting (1-2 seconds)

Mark V 1099r4 has the longest pause of all exes. 
So DirectX Mark V is 3-6 seconds slower starting/exiting. Quakespasm is 1-2 seconds slower starting/exiting.

But Mark V WinQuake, SDL and OpenGL are unaffected.

Trying to unravel that ...

It is possible that specifying a refresh rate on startup slows things down. Quakespasm does this. DirectX Mark V specifies a refresh rate that is the desktop default when requesting fullscreen mode. The Mark V WinQuake/SDL/OpenGL doesn't touch refresh rate.

If I am right ...

Does the following have a difference in start up times ...

a) c:/quake/mark_v.exe -window -width 800 - height 600 // DirectX
b) c:/quake/mark_v.exe -current // DirectX

If it relates to the refresh rate, according to the code it looks like in windowed mode that Mark V DirectX does not set a refresh rate, but for fullscreen mode it does.

/A guess. If this thought turns out not to lead anywhere and it may not, I have a couple of other thoughts but this best matches your test results ...

Let me know ... 
If a 6 second delay is a problem, my engine is fucked.

But yeah, it's always nice to eliminate unnecessary delays. 
A delay at startup does sound like it's changing the display mode for sure; that would certainly do it.

Some info on command-line params used and resolutions of the PCs being compared would help a little more here. 
@baker I need to try this in windowed mode too. But I'll try what you posted above. Typically I stick to fullscreen.

One other thing that might help. Much of the time I am editing and using Necros' GUI to launch ericw's tools and in turn, MV. The tools compile quickly as expected, then there's the delay in launching MV. Then I review the compiled map. Now for whatever reason after I quit MV the cmd windows (which has been running in the bg as usual) stays up for about 3-4 seconds before closing.

I am 99% sure the delay in launching MV happens if I click a shortcut on the desktop without running any compilation so maybe unrelated?


Just remember this is Windows 10 now. My older machine is Win7 and had zero issues on start up and shut down with the same monitor and a very similar video card and same MV version. Also the same command line etc.

1920x1080 144Hz refresh forced by nvidia cp and that's my desktop res and refresh as well so I don't think it's mode switching.

I need to confirm but I'm pretty sure the delay happened before I set the refresh in nvidia to 144Hz

parms are +developer 1 and +gl_clear 1 +load map <map I am editing> (those were the same on other systems) 
It does seem to take a while to load for me too. QS is pretty instant 
Much of the time I am editing and using Necros' GUI to launch ericw's tools and in turn, MV.

Windows programs inherits the CPU affinity and the process priority of the process that launches them. If the launcher is e.g. a single-threaded 32-bit program running at low priority, maybe Mark V needs some extra time to adjust its process' properties. Just a guess. 
Home and testing this now. We're getting somewhere.

Does the following have a difference in start up times ...

a) c:/quake/mark_v.exe -window -width 800 - height 600 // DirectX
b) c:/quake/mark_v.exe -current // DirectX

No delay on the windowed setting above! Fires right up. Also I have QS and QSS in the same forectory of MarkV so they share config.cfg. I'm noticing if I switch between those two the delay in launching and closing them goes away. If I launch MV then QS or QSS afterward the delay on those two is back. Albiet shorter as I said above. 
Can you confirm there is never a delay for windowed mode?

If so, that would be convincing enough evidence to make a test "fix" for DX9 fullscreen mode.

/Probably throwing in a pq_moveup bug-fix that PoorChop spotted. 
Possible DX9 "No Delay" On Fullscreen Startup Fix? 
@dumptruck, fifth + anyone else who experiences a delay on DX9 Mark V startup:

Download: DX9 Mark V - July 11 potential slow startup fix

@dumptruck -- let me know! 
So this July 11 version no change.

Made 2 shortcuts on my desktop to this new exe.

Windowed mode launched 5 times in a row with almost no delay.

Using fullscreen (-current) re-introduced the delay.

I launched this 5 times as well - all the same. The I switched between the two shortcuts twice. Same results.

I tried this new exe on my older Win7 machine and it doesn't have the issue. Launches full screen with only a tiny delay. 
As I said, that is almost certainly a display mode change. Probably 2, switching away from your desktop mode then switching to whatever your selected mode is.

Check your console output log and you should see evidence of it. A bunch of vid_describemodes and vid_describecurrentmode commands can also help.

Yes. I'm aware of the fact that it happens on 10 vs 7, but the fact that it doesn't happen in windowed modes is additional evidence. 
Great! You might also check and see if the fix eliminates the need to set the refresh Hz in the Nvidia control panel for your 144hz display.

It may resolve that, then again it may not. 
/I think dumptruck has easily earned the June and July "Gunter Award For High Quality Beta Testing".

Nothing is less fun with engine coding than issues that require setups not easily available.

Thanks for the high quality beta testing that identified the source of this issue! 
Thanks I am no Gunter tho.

Did you misunderstand though? This did new release not fix the issue. :( 
When You State... 
"Full external texture support, DP naming convention."

Does Mark V use special effect textures as well? Gloss, normals etc? And what about shaders?

Just curious. 
Nvrmnd ^^^ 
I see you have a HD pack using qrp textures, I can derive the answer from that. Apologies 
@dumptruck -- my bad. I quickly scanned the post and only saw the "no delay" and "with only a tiny delay". Missed the part saying the problem still exists for fullscreen. Sorry ... guilty as charged!

I know I vastly prefer the DX9. Maybe mh will come up with some thoughts at some point. The inner workings of DX9 isn't in my knowledge set.

Odd that the OpenGL variants like the WinQuake-GL (WinQuake rendered through Open GL) and the SDL (which is also OpenGL) have no delay.

@damage - Just vanilla replacement texture support like ezQuake, JoeQuake, Qrack.

Mark V supports texture replacement from HUD to Quake models to conback and menu graphics. 
What's Delay 
thingy tho?

ps. sometimes i get the fps locking at 60 
If sounds like you have an app running in the background that is forcing video sync.

All you can do is close the other app.

I've seen it happen before, but I can't remember what it was for me (Netflix?). 
As I've now said twice, it's a display mode change. Probably two. Seen it once, seen it a million times. I don't understand why dumptruck is being resistant to helping diagnose this further, though.

Traditionally Quake engines only track width, height and bpp when matching display modes. Some engines add refresh rate. A real display mode contains other values, however, and it's possible for two or more modes to exist which are the same so far as these traditional values are concerned but which are actually otherwise different.

Don't be surprised if Windows 10 adds additional modes that aren't in 7. It's a higher version of the driver model with extra capabilities.

What's happening is that dumptruck is running with -current but the engine is not starting in the current mode. It's starting in some other mode, which involves a display mode change, then switching to the current mode which involves another.

There's no delay when shutting down because it's already in the current mode and so doesn't need to switch back.

The other engines have a shorter delay at both startup and shutdown because they're doing a single mode change at each.

There's no delay running -windowed because it doesn't do a mode change at all.

In an ideal world that first mode would be a windowed one and all of this would go away - instant startups would be back. But when I tried to do this years ago I got HUGE pushback from the community. Yayy community.

Anyway, I asked dumptruck to check his console debug log which would tell us which mode it was starting in first, which could have been useful information. But once more he's being resistant to helping us to help him, so I guess that's where it's gonna end, unless he comes round.

@dumptruck - just to be clear.

I am NOT saying "you silly person, ha ha ha",

I AM saying "it's an engine bug. Help us to help you. Please" 
Come On Now Mh 
I'm not sure why you're bagging on the one guy who is downloading extra builds and running all sorts of tests on request. If he's overlooked something you asked him to do then you could make that clear. 
I've previously told him twice that it was a display mode change. He responded the first time to insist it wasn't, he ignored the second. I've previously asked for his console log and the output of some vid_describe commands. He ignored that too. So obviously I'm the bad guy here. Yayy Community. Again. 
If sounds like you have an app running in the background that is forcing video sync.

yep, It frequently happens when i run the online widz etc

sometimes it happens just for no reason , switching to desktop and back to the game's solving the issue 
Looks like I need to experience the problem firsthand and see if I can get the problem.

It is possible something non-obvious is going on.

mh brings up bits per pixels and some other factors.

Mark V always tries to use what it thinks are the desktop "current" parameters with -current (ignoring all config settings), but maybe Windows 10 adds some additional parameters I didn't consider.

@mh - Eventually I'll get to the bottom of what is going on. The main issue to trying to find technical info on what Windows 10 updates changes/impacts has been difficult. 

This is happening inside VID_Local_Vsync_Init where a call is made to sysplat.wglSwapIntervalEXT(0) - under OpenGL this is not a display mode change; under Direct3D it is.

Suggested solution: suppress this test if running under the D3D9 wrapper; you can safely assume that vsync control is always available in D3D9. This will shave 3 seconds off the startup time. 
Got it. I'll give that a try.

Thanks, mh! 

In classic Fitz, at the end of VID_Init there is this block of code:

if (COM_CheckParm("-width") || COM_CheckParm("-height") ||
COM_CheckParm("-bpp") || COM_CheckParm("-window"))
vid_locked = true;

This needs to have "-current" added to the list of params checked, otherwise the engine will run the configs during startup and trigger two display mode changes (assuming a clean config, could be more). The first of these changes is slow, the second is fast (in my test the first went from fullscreen to windowed, the second just changed the size of a windowed mode).

In MarkV I think the equivalent is the video_override_commandline_params array, which is missing "bpp" from classic Fitz's list.

Fixing this up shaves a further 3 seconds off the startup time, and startup times are now instantaneous with no display mode changes happening. 
I'll examine that as well.

Yeah, bpp is gone (that's a relic from the 1990s when 65536 color mode was a thing). 
As a troubleshooting tip...

In context_t::PreReset I added the following at the start:

Con_Printf ("context_t::PreReset: %f\n", Sys_FloatTime ());

In context_t::PostReset I added the following at the end:

Con_Printf ("context_t::PostReset: %f\n", Sys_FloatTime ());

I was then able to track when display mode changes occurred and cross-reference that with whatever else was going on in the console during startup, as well as time how long each change took. Makes it very quick for hunting down this kind of thing. 
I don't understand why dumptruck is being resistant to helping diagnose this further, though.

I need to read the rest of the thread above but I promise you I am not ignoring this situation. I can only test after work and family stuff kept me busy last night until pretty late.

Honesty, I didn't notice anything in the console and I was definitely paying attention the other night when I DID test.

So my desktop is set to 144. The game is set to 144 there's still a mode change in FS? I don't get that.

What I will ask is that someone let me know what I can look at in Windows to help troubleshoot. I am not stellar with troubleshooting the OS. 
2nd Post 

There's no delay when shutting down because it's already in the current mode and so doesn't need to switch back.

There IS a delay when shutting down but not 7 seconds. The game will close but the Mark V icon is still in the Quicklaunch bar and the system is unresponsive until it closes.

I will post console logs with the info mh is targeting as soon as I can. 
You don't need to do anything.

mh solved it. It's all on me now.

I want to wrap up the SnapTile editor (yeah, going with the name mankrip chose -- I can't do better) before doing a Mark V fix.

So give me a few days.

When I get close to completing something, I develop a one-track mind where I want to finish it. 
Thanks. And please no pressure on a timeline. Do your thing, happy to wait for your fine work. :) Excited to see this SnapTile project in action. 
Mark_v Takes 7 Full Seconds To Load 
Seems like a lot. Just tested it with latest build.
Windowed mode is instant.

Tried changing my refresh rates and this doesn't change the delay (I have a 144hz monitor).

Closing Mark_V takes 4 full seconds fullscreen and closes instantly when in windowed mode. 
Yeah, we tracked it down.

I owe you an apology for being a dickhead about this. On the other hand, MarkV will get better as a result. 
No worries! Poor Baker though. Coding during the summer. ;) 
I'm only the idiot who wrote the code, Baker's the idiot who has to maintain it! 
Video: High Definition Pack With More Realistic Shadows 
High Definition Pack Video With More Realistic Shadows:

Watch Video

1) r_shadows 3
2) r_waterripple 3
3) QMB on, obviously
4) With HD Pack and Transparent Water .Vis/.Lits Pack

For illustration purposes. 
dumptruck_ds: Thanks I am no Gunter tho.

Hey, you're doing extensive testing and detailed reports to help squash obscure bugs AND getting mh miffed, so you're well on your way! 
Cool shadows. Any chance for lit liquids in the future? 
I can't remember if mh wrote a full fledged prototype or not and if the one or two small but important barriers were solved (i.e. detecting lit water and maybe something else).

I think if he did, it would eventually happen. 
I've solved the detection and posted the solution in some thread here or at InsideQC a long time ago.

The other problem was to compile the maps properly, but EricW solved that. 
Lit Liquids 
Wasn't there an issue with the surface warping making it look really bad? 
Not in my engine.

And in hardware-accelerated engines it should be easy to combine warped textures with non-warped lighting through shaders. 

And in hardware-accelerated engines it should be easy to combine warped textures with non-warped lighting through shaders.

This doesn't need shaders; hardware-accelerated Quake already uses two separate sets of texture coords for difuse and lightmap, so just warp the diffuse coords only but don't warp the lightmap coords.

The issue is that whatever way you slice it, it looks bad.

I do understand where the desire to do this comes from. You've built a map, you have a large water surface in it, the surrounding geometry is nicely lit and shadowed, and the fullbright water looks bad. And you're right, the fullbright water does look bad, but lit water actually looks worse.

The two big problems are (1) when the lighting on the water is sufficiently dark you can't see the warp effect at all i it just looks like a big dark spot, and (2) with translucent water enabled the water just disappears.

This is an example of taking a special case and wanting a general case solution for it, but not properly considering how that general case solution may or may not work outside of the original special case.

"Can I have lit water?" seems a reasonable request, but you also need to be thinking about lit laval, lit slime, lit teleports, how it interacts with translucent water, etc. 
I've already considered all of that years ago and Retroquad has individual cvars for each texture type. I usually keep r_portal_lit and r_lava_lit disabled in Retroquad, because the textures I'm using for them doesn't have glowmaps. But the slime texture I'm using does.

Your mistake is to think that you're the only one who thought about all that. No, you're not, you haven't even thought about liquid textures with glowmaps (QRP has them!), and the worst thing is that you're speculating from a purely theoretical standpoint while I'm speaking from experience.

Lit water does look fucking good. The Unreal engine already has lit water since 1998, and nobody ever complained about it because its maps were created with lit water in mind. Lit liquids in Quake is for NEW MAPS ONLY because the maps need a full recompile from the .map sources for this to work and the mapper must deliberately opt-in to enable it in the compiler.

Your issue is that you don't want mappers to have a chance. You don't want them to experiment and learn how to tweak the lighting in their maps to make lit liquids look good. You don't want them to have artistic freedom.

The "it looks bad" argument is not a technical argument, it's merely an uninformed opinion.

You are not a mapper. 
...and the worst thing is that you're speculating from a purely theoretical standpoint while I'm speaking from experience

I am actually also speaking from experience because I have also written this code and have also seen what lit water looks like.

Here's the Quaktastic folder where I uploaded a bunch of screenshots:

Check the date on them - over a year and a half ago.

Check some examples of exactly what I mean:

Your entire premise is based on the assumption that I don't know what I'm talking about, whereas I actually do. When I say "lit water actually looks worse" you had two options and you instantly reached for the negative one - yayy community. 
I am actually also speaking from experience because I have also written this code

No, you are speaking from MAPPING experience.

I've never made a full map but I often practice mapping to test and learn how new features like this could be used. 
* not speaking 
Not only you used screenshots from other people's maps that were NOT designed for lit water, your E1M2 screenshot shows that you probably didn't recompile them using the latest versions of EricW's compilers, which properly lits the liquids from both sides. The lighting at the edges of the water should be similar to the lighting of the walls that crosses them. 
All your screenshots looks like they didn't use EricW's compilers. Completely missing backside lighting.

I'm on mobile and not at home now, but asap I'll post some screenshots of those maps properly recompiled. 
To me all three of those screenshots you chose mh look quite promising and easy to work around to get pretty lit water with some effort from the mapper (and yeah some compiler magic would obviously help).
Would be curious to see with some high alpha values, as you seem to say it looks ugly, but plenty of other games have lightmaped transparents that look fine. 
OK, I am going to put my money where my mouth is.

This package contains:

(1) A version of GLQuake modified to support lightmapped water.

(2) Source code for it.

(3) A version of e2m5 compiled, using EricW's tools, for lightmapped water.

So now everyone can see it.