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

Regarding ne_ruins:
I am OK with adding parameters, but the reproducable crash with succubi resurrections sucks. 

Nice to see this engine still being actively worked on, I think you've added a ton of useful features. I did come across some possible bugs though. OS is Win 7 64 bit, GPU is AMD 6870, driver version 4.12.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I have a few others but that's probably enough for now. Let me know if you need more info about my PC or config when investigating those bugs. 

@nightfright --- I'm committed to getting your problems with hipnotic and ne_ruins solved. I'll do some thinking and investigation.

@THERAILMCCOY

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

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

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

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

5) Give stuff. Will investigate and fix if needed. 

Baker, please disregard my report about broken SoA sounds. I checked again and realized I had a custom PAK in my MP1 folder with resampled sound files after all.

It has nothing to do with your port - after removing that file, everything works fine. My apologies for the confusion! 

Unfortunately, transparent statusbars still cause visual glitches on PNG screenshots.

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

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

Curious what will happen once I reach Nehahra. JoeQuake crashed pretty badly after defeating the boss when running out of edicts or something with all the gibs flying all over the place... 

the latest build is running like charm
and the mention issues have gone, thats nice 

Probably a false alarm, but FWIW Baker, MSE claims that the Beta 9 zip is infested with "TrojanDropper:Win32/SpamThru.gen!A". 

Windows OpenGL + WinQuake

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

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

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

Regarding h), it should be easy to reproduce on the Mac build, I was able to with the recent Mac build you posted.

Also, if you want, you should be able to reproduce the issue in Visual Studio as well with the "/arch:sse2" flag. IIRC this will still make a 32-bit exe, but will require a Pentium 4 or better. Info on that flag: https://msdn.microsoft.com/en-us/library/7t5yh4fd.aspx 

I was able to with the recent Mac build you posted Sounds like when I boot up that Mac that'll be easy then (most of past attempts failed because the screenshots of the issue had no name and I looked at a few mapjams and didn't see issue ... was frustrating). The BSP compiler actually does the calcs using doubles so your fix is a natural extension of what Q engines should be doing already.

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

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

Note #2: I wish I knew an easy way to have WinQuake use vid_vsync. That uses a wgl function on Windows. I could make WinQuake use OpenGL only for buffer swapping, but then exposes WinQuake on Windows to bad OpenGL driver issues. 

ditch mgl so that you can use directdraw directly.
use directdraw's vsync stuff, then you won't need to copy textures twice nor suffer from missing gl drivers. 

I wasn't aware DirectDraw had vsync somewhere in the API, although I'm not using mgl nor DirectDraw but rather just BitBlt/StretchBlt.

[I copy the buffer using BitBlt on Windows derived from what initially started as MH's pure API WinQuake and still has some of that left. The Mac WinQuake renders to texture in OpenGL via proxy texture and draws the texture to the entire window.] 

The link above for the updated package should be http://quakeone.com/proquake/interims/mark_v_20150419_windows.zip 

The impetus for getting rid of DrawSequentialPoly in qs was ijed's RRP map telefragged.bsp... The first main room, after you leave the entrance room and go through a corridor, has several large brush models in the PVS (a train outside, and moving bridges, inside). I was getting something like 17 fps on my laptop (while not a gaming laptop, high-end enough that it should breeze through anything quake. i.e. i7 quad, geforce 650gt).

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

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

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

The other nice thing is, that refactoring paved the way to using a VBO to store the world and brush model (which is isolated to just one drawing function), but it's certainly not necessary to use VBO's to get a good performance boost from eliminating DrawSequentialPoly, at least in cases like ijed's map that make heavy use of brush models. 

Unfortunately, Mk V currently fails at the very same spot as JoeQuake does when playing Nehahra:

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

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

Here are some savegames to check (no autodemo this time, sorry). The quicksave will bring you to the time right before Nehahra goes down, just keep shooting at it and see what happens. 

I'll take a look at that and resolve. 

Pleased to hear the additional text editing shortcuts might make it in soon. =)

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

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

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

Gamma range

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

Give - more items, quoth, nehahra, etc.

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

Extra editing keys

Those are in the next one.

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

Hehe, 'pak' and 'zip' exist just to expose those for testing. I don't expect them to be there in the end, and didn't expect them to be noticed ;-) 

Items like quad are given by impulse commands, but Quoth does implement named aliases for these commands, for example "quadcheat" in the console performs impulse 255 and gives you the quad. These should autocomplete when the engine supports it - as fitz085 does I'm sure Mark V would as well... 

I am actually wondering why that Nehahra crash happened. Didn't you raise the limits for RRP already, including edicts? That should have avoided this issue. Was using the April 19 snapshot after all. Anyway, maybe Nehahra is handled differently.

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

Side note: Is there actually any chance you are able to add the missing fog effects or is that something Mk V simply cannot pull off? 

Not Nehahra's fault, engine's fault. Reason is long-winded and technical. I'll try to explain.

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

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

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

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

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

fog

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

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

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

Like I said, there was a reason. Now, I need to remember why ... 

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

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

@baker:
better the client disconnects than the server crashes.

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

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

Fog isn't just different on every engine, it's also potentially different on different hardware, drivers and even APIs.

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

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

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

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

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

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

It's also possible to implement fog by drawing the depth buffer as a full-screen quad over the scene and deriving a fog formula from the values stored in it, but that of course will fail for anything that's not written to the depth buffer (particles, translucent water, etc won't be fogged). 

Well, putting max_edicts "8192" into autoexec.cfg enabled me to get past "Nehahra's Den" with existing savegames. The problem is that while Nehahra's gibs are flying around, the exit elevator breaks through the ceiling, and with all the glass shards and debris raining down while gibs are still visible, it's just too much with low edicts settings.

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

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

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

Possibly more after that, provided my free time allows it.