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
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: 
3 posts not shown on this page because they were spam
First | Previous | Next | Last
Post A Reply:
Website copyright © 2002-2017 John Fitzgibbons. All posts are copyright their respective authors.