I don't want to be the bearer of bad news... but the "QMB_BLOOD 0" bug is still there :P

if you set "QMB_ACTIVE 1" and then "QMB_BLOOD 0" to deactivate the QMB blood, it doesn't work, the command only mix qmb_blood with red particles :/ 

I'm using a clean install and testing lots of old things. I find that a lot of my suggestions have indeed been implemented. Excellent.

Here are some initial issues:


- Using Shader Gamma (the default), switching to any full screen mode that is not at my netbook's native resolution of 1024x600 causes Hardware Gamma to be used. It still says Shader Gamma in the settings, but it's definitely Hardware Gamma - everything gets darker and my desktop gamma is altered. Switching back and forth to full screen 1024x600 from a windowed mode does not cause the issue, and Shader Gamma stays in effect.


- I'm seeing something new: CDAudio: drive ready test - get status failed

Oh, I guess that's because the "External Music" is ON by default.
Ah, the error message does not appear if I disable external music, or if I actually have the music tracks in place... AS OGGs RENAMED TO MP3!!! because you won't allow OGG to be detected by Mark V.... PLEEEEEEEASE do this! I and others prefer to use OGG, and for me it addresses the issue with MP3 freezing up my game for unreasonable amounts of time as the MP3 song loads.... I'm sorry an OGG file killed your dog and burned down your house when you were a kid, but it's time to let it go, man!


- The mouse sensitivity slider now goes to 21, though that's right at the value I feel is good, around 20, so that doesn't leave much range for increasing it any more. The slider should probably go higher to account for users who might like it a bit more sensitive. I'd suggest at least 30 or so.

- Hm, pressing CTRL when the console is down (for ctrl+v) causes me to fire my gun.... Should that happen? I mean, I know it should fire my gun, but not when the console is down. ALT also has this behavior (I tried binding ALT to +jump to test it). Be sure you're in a multiplayer game when you test this, as the console fully pauses a Single Player game.

- Old issue that really needs addressed: the Multiplayer Setup menu, when you are changing your name, the name should not be committed until you are fully done changing it. It's like, for every letter you delete or add, it's doing a complete "name" command (which, among other problems it gives me, spams the console with name change messages).

- Speaking of old issues, r_noshadow_list contains bolt1.mdl which does not exists in Quake.... It's just... not... right!

- Known rendering issues: water surface is drawn on top of shadows, teleporter surfaces are drawn on top of water when viewed through transparent water (see #142 #147). And r_shadows 3 are visible through entities. Fullbright textures can't be transparent, and are made ugly by Contrast adjustment. (I know: all known issues -- I'm just noting that they still exist).

- chase_mode - I know it's an experimental feature, but it should really behave like other console variables. It's confusing because just inputting "chase_mode" causes it to cycle to the next mode instead of reporting the current mode. "inc chase_mode" should be the correct way to do that (though it wouldn't wrap back to 0 after... whatever the max value is).


(I've got a much larger list of preferences/defaults/suggestions I'm working on) 

I was running 1099 and found out in the "customize controls" menu, that "mwheeldown" binding doesn't display in the menu.

I have "mouse wheel down" bound for "next weapon" and it does allow me to bind it just fine, but the menu still displays it as ???, as if nothing wasn't bound (or if I have an additional alternate binding, it only displays it. Both bindings still work).

Anyone else have this problem? 

Well, thanks gunter/mfx/tribal/esrael/jl for the polishing tweaks I need to do! Much appreciated!

I guess going into hibernation mode will have to wait a bit!

But also why I did the (Stable?), thanks for the quality testing guys!!

@Tribal: yeah, I lost the stamina to do it. I hear you and it is important. Can't promise I'll do it immediately, I'm tapped out a bit. But I do appreciate your testing. 

"r_noshadow_list contains bolt1.mdl doesn't exist in Quake"

maybe it exists in hipnotic, rogue, zerstorer or something like that. metlslime put in FitzQuake 0.85 for a reason, but I don't claim to know what single player it is intended for.

hardware gamma

I don't know. It's your computer. I assure you if says "shader gamma", it's using shader gamma.

I'm still rooting for you to spill coffee on your computer, haha. I suggest creating an incident at Starbucks!

ProQuake server list

Dunno. I'll think about it for a Christmas-time release. I want to tune up anything small and take a break. I'm running on empty.

Hm, pressing CTRL when the console is down (for ctrl+v) causes me to fire my gun.. (must be connected to a multiplayer game)

Wow, that's interesting. It sure does! I was going to post "cannot reproduce" and then re-read about connecting to a multiplayer game so I connected to shmack and tried, and yes. 

That's a hell of an awesome catch!

I'd like to think I spot stuff like that.

Baker fail +1.

Now ... what I did was this ... I added ericw controller support. But I didn't want all kinds of joystick buttons showing for people without a joystick, so I made the display dependent on whether or not a joystick was connected.

But I was "too clever by half" ... and a tad not careful enough ... 

http://quakeone.com/markv

Download: Windows - DirectX | WinQuake

Revision:
1) mwheeldown wasn't showing due to a <= vs < typo (esrael)
2) Link to DirectX 9 drivers on homepage (mfx)

Experimental/requested extra builds: Alternate Builds

Question of the day:

Is DirectX Mark V faster than VxQuake (Vulkan)?

I have reason to suspect DirectX Mark V is faster than VxQuake.

(start.bsp beginning has a mirror there that Mark V uses so that is not a good test spot). 

Screenshot: DirectX Mark V sometimes 3x speed of FitzQuake 0.85

And from what I have seen, VxQuake using Vulkan is only about 15% faster than its source base.

But the mh DirectX wrapper is offering a frames per second jump that is vastly greater than 15%. 

There's no point benchmarking an engine in small tight corners with very few polygons visible. This is the same syndrome as "50,000 fps in dm3 - woooo!!!!" - it's a meaningless statistic.

Benchmark it under heavy load, then do a comparison. You'll likely find that D3D9 MarkV is substantially slower than either QS or VkQuake (but substantially faster than Fitz) because it still hand-feeds all vertices to the GPU every frame, whereas QS or Vk store them in on-GPU buffers. But that all depends on where the bottleneck in your system actually is.

For the record, I make absolutely no claim whatsoever that my cobbled-together wrapper is faster than properly written native code, and I would always recommend properly written native code over a wrapper. 

It's OK for Engine A to run at 200 fps in dm3 whereas Engine B might run at 5000 fps.

What matters is how they run in a map like sepulcher. If the same Engine A runs at 150 fps in sepulcher whereas the same Engine B runs at 30 fps, then Engine A is clearly the better performer. 

Waiiiit, Fitzquake had a noshadow list? Hmm, must have been inaccessible to the user, and only existed in the engine code? Ok, in that case, if you grabbed your list from Fitzquake, then it was Fitzquake that had an error in its list. Way back on the old page, I first reported that bolt.mdl was missing from the list, then I clarified that "bolt1.mdl needs to be renamed to bolt.mdl" See, that was just a typo in the original list: it did not contain the actual bolt.mdl but it did contain the non-existent bolt1.mdl (simply, the "1" should never have been there). So that's the reason Fitzquake had it there: a typo, not some intentional inclusion. Of course, even if it was an intentional inclusion to account for some specific mod, I would be against that too (it's not the engine's job to account for every custom model that a mod might use -- the correct option would be for the mod to include an altered noshadow list).... But it sure looks like it was just a typo. You did add the bolt.mdl that I pointed out was missing, but you didn't remove (or more correctly, rename) the bolt1.mdl which was there in its place, so now both bolt.mdl and bolt1.mdl are there... which is just building upon the original mistake instead of fully correcting it.

It looks like Quakespasm copied your early noshadow list (as stated here: http://quakespasm.sourceforge.net/Quakespasm.html#ss6.5 ) and never fixed the error (they don't have their own Gunter to point these things out to them!), as you can see in its code (i.e., bolt1.mdl instead of bolt.mdl): https://sourceforge.net/p/quakespasm/code/HEAD/tree/trunk/quakespasm/Quake/gl_rmain.c



Hardware Gamma: Ok, then it is still using Shader Gama when it says Shader Gamma. The problem is that switching to any non 1024x600 fullscreen resolution resets my desktop hardware gamma setting just as if I were using the Hardware Gamma setting in Quake. i.e., normally my desktop gamma setting is adjusted up a bit, and that applies to Quake as well, so I don't have to adjust Gamma in Quake up by a lot. Using Shader Gamma in Quake in a window or fullscreen at 1024x600 doesn't alter my desktop gamma at all. Using the the Hardware Gamma setting in Quake, either in a window or in fullscreen, resets my desktop gamma, meaning I have to ramp up the gamma in Quake to make it brighter, then I have to reset my desktop gamma when I quit Quake.... The same gamma reset happens when using Shader Gamma, but only for full-screen resolutions other than 1024x600 (native).


And just a note: you don't have to connect to an online server to test the CTRL/ALT buttons in console; just do New Multiplayer Game locally.

Hey, would it at all be possible to allow mouse selection of text in the console for CTRL+C (copy text)?


Oh, and there's little chance of me spilling coffee on my netbook... I don't drink coffee ;)
Who would want to deal with a caffeinated Gunter?? 

And on the Second Day, Gunter posted his long list of feedback over here: http://www.fvfonline.com/forum/viewtopic.php?f=12&t=3811 

FitzQuake's no-shadow list was indeed hard-coded into the engine.

Compare it with the tempent parsing code and it seems evident that progs/bolt1.mdl was a typo/bug; the tempent code (correctly) has progs/bolt.mdl but does not have progs/bolt1.mdl; meantime the no-shadow list doesn't have progs/bolt.mdl; I don't think we need to debate this one. 

Hi,
first of all I'd like to say a big thank you for this excellent source port. I love playing the WinQuake version.

A few months ago I made the following changes to the old 1036:
* Fixed a bug in single player where a saved game wasn't properly reloaded after death (you fixed this too in 1050)
* Changed all the defaults to make WinQuake look and feel exactly like the original
* Hid all the customization menus but without removing the variables, so if a mod needs them, it will work
* Limited the maximum resolution to 1280x1024

Ever since I made this, I've been following your changes and keeping my little fork updated, but I haven't uploaded it anywhere yet.
Since Mark V isn't on github or a similar site, I didn't want to just upload it and make it look like I'm the author so I wanted to ask if you're planning on uploading Mark V on github or a similar site, so I can fork the project and give you the credit that you deserve. 

Heyyy, I like the idea of having a fork that "Changed all the defaults to make [Quake] look and feel exactly like the original"... to a certain extent; I mean, I see no need to remove menus that allow for easy customization, and if a user wants a higher resolution, there's no need to prevent them from selecting it.

I have no problem with making all kinds of changes (I enjoy tweaking and playing with settings... which is why I break so many things in bugtesting!), but the default Quake look and feel should always be the starting point (which was the vast content of the post I just made on my forum -- all the actual reasons why I would like many settings to be reverted to the Quake Default, as they produce unwanted behaviors for me).

In any case, no disrespect to Baker, who is the true mastermind behind Mark V, but I (and others) would absolutely prefer use a fork which addressed all the issue I have with altering Quake defaults. AND maybe dosse91 would remove the intentional blocking of OGG support! :D

Don't worry, I'd still bugtest here ;)


Though I might run into issues with dosse91's fork trying to make everything like WinQuake whereas I prefer hardware-rendered Quake.... 

MAKE YOUR OWN github repo call it sporkV or something then not its a test fork of markV with a link to Baker's website. or make your github private and only show it off to baker? or no just compare notes. 

Ah, I don't care about credit -- I don't even have "Baker" on the Mark V page nor in a text file with the executables (or on most other things like the QuakeDroid page) because I don't care.

Everyone's work is a fork of Carmack's anyway, isn't it? /end joke

My only interest is conveniently being able to play any Quake mod in the context that was meant in a resolution independent and preferences independent way and be able to use as close to anywhere as possible (all major desktop platforms, all major mobile platforms) -- with the start demos working nice and properly which no other engine has ever taken the effort to do it because it is tedious and unrewarding (stuff like bizarre behavior of the start demos if the menu is opened when the start demo switches, etc. etc. It's like 25 things. Hence almost all engines hide the start demos because the problems are so hard to address.)

Settings is no win. Some people think Quake is GLQuake or ProQuake (like gunter) and some people think Quake is WinQuake/DOS and others prefer say the FitzQuake feel or (insert another engine).

There is no winning with settings, only trying to make the major ones available -- even with things like mouselook, always run, animation smoothing, stair smoothing.

I tried to make it easy to compile so someone wanting to compile themselves would be able to do that. 

Warm weather now. I'll check the thread sporadically in read-only mode, unless someone finds an Earth-shattering mistake or such.

Main difference from last year, is I think I get to vanish with no annoying bugs like last year tool_inspector being broke.

/Freedom! 

 

See you again for v2.0, mate! You deserve a break after this update marathon, I guess. We can all play AD in the meantime. With Mark V, ofc. :P 

Well, dosse91, Baker's outta here for now, so it looks like you need to make your fork available for download and create your own thread here on Func so we bugtesters can take a crack at (breaking) your version and provide feedback :D 

Two points on Baker's last thoughts as he ran out the door:


"My only interest is conveniently being able to play any Quake mod ... and be able to use as close to anywhere as possible."

Would it not be so much more convenient and compatible to allow OGG support then, for people who have OGG Quake soundtracks (it seems to be a common format for Quake users), and for people who have computers that don't handle MP3 well though Mark V for some reason (like me!)....? Just saying! OGG support would serve both the stated goals there: more convenient, and more compatible.



"Settings is no win. Some people think Quake is ..."

Indeed, which is a good argument for leaving all settings at the Default. Then you are sure to please at least one (rather large) group of people: people who expect Quake to act/look/feel the way it always has (whether that's Win or HW version).... Other people who want to change that can do so, to their own tastes. But having the engine set SOME settings to different defaults (some old, some new, some Fitzquake) has no chance of getting it just right for anyone... except people who don't care.



... hey... how do you people make your quoted text appear grey?? Is it a secret function for registered users?? bbcode obviously doesn't work here.... 

Huh, ya know, come to think of it, there are already those options at the bottom of the Preferences page:

Set to Mark V
Set to Fitzquake

Why is there no "Set to Quake Default??" That should revert everything I complain about to the standard Quake Default settings ;)

And that should be the Default settings, heh, and then people could easily apply your Mark V recommended settings if they wanted. 

Quoting from #1763 for your benefit.

I obviously can't speak for Baker but this wouldn't be just 3 extra characters. It's only 3 characters if you directly replace the existing .mp3 support with .ogg support, but of course you then lose .mp3 support.

Adding multiple file format support would involve enumerating files of multiple extensions, sorting them into lists, making decisions such as which format has priority over others (not so clear-cut - how do you decide between a high bitrate inferior format vs a low bitrate superior format?), and how to handle the inevitable crazy-assed situation where someone has multiple formats in the same folder (some of which may even be multiple versions of the same file in different formats).

Adding this support is not as easy and clean as you think it is.

Replacing the existing MP3 support with a different format - easy and clean.

Adding support for two or more co-existing formats - messy, troublesome, hard decisions to be made.

You say "just saying". Well you've said it; over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and Sweet Baby Jesus Make It Stop.

You want people to listen to you? Return the favour and do some listening back yourself; I don't think that's too much to ask for. 

I haven't been keeping up with Quake recently, good to see so much work still going into MarkV. Can't wait to play some split screen when it happens ;)