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 ;) 

Any chance for a Linux version of the 1.99 release? And actually have working external music support? Quakespasm Linux has working music I don't see why the Linux binary of MarkV can't have it.

Also what the hell does "Cache_RLU: NULL link" or whatever even mean? I've never had that happen in Quakespasm. 

Now, mh, YOU KNOW that the paragraph you quoted from yourself in the past is utter nonsense (why are you trying to make it sound overly-complicated by talking about sorting lists and comparing bitrates and acting as though it's a crazy impossible situation if there are multiple formats in the same folder?).

Do you know how I know that you know it's nonsense? Because I just fired up DirectQ, YOUR QUAKE ENGINE, and guess what? It can play both MP3 and OGG files, and if I have BOTH an MP3 and an OGG file of track04 in the same folder, it simply plays the MP3 instead of getting confused by this "crazy-assed situation" and causing the earth to explode. FTE, on the other hand, supports both formats and gives preference to the OGG in the same situation.

So, YOU'VE done this. It was simple, because apparently you did it without even knowing you did it. It just works automatically, easily, and effortlessly for the user. But now you act like it's some impossible insurmountable obstacle to programming....

Are you retarded or something?

See, I don't listen to tards, because they say retarded things that just aren't true.

Just saying! ;) 

Now the continuing report of the weird centerview behavior....

Me and another player on the FvF server experience it working and not working at the same times. I checked the clock and it seemed to be right about 15:30 when it stopped working. On the next map (it starts working again after map change), I watched again to see if it would repeat, and it seemed to stop working again right about 15:30. Then it started working again around 18:00, stopped again sometimes after 20, then stopped again after 21... and stayed that way. At each point I told the other guy and he agreed that it would start/stop working during the same periods it did for me.

I was using Quakedroid with keyboard only, and he's in Linux Mark V using mouse + keyboard.

I tried playing around some more to see if those times would aproduce the bug in single player or local multiplayer, and by restarting a map on the online server and messing with the host_framerate, but I can't really get it to repeat.....

But it's rather odd that centerview (not force_centerview) should be affected by anything the server is doing... at certain times... for multiple connected players... isn't it? We were just standing around in the game not doing anything weird. Pretty sure I don't do anything in FvF that should alter a player's view like that. And as I reported before, after tapping the centerview key, the view will center itself after like 10-30 seconds when the issue occurs.

Weird one. *shrug* 

@gunter ... get me a demo and the time within the demo the problem crops up. Use cl_autodemo 1 or have your friend use cl_autodemo 1.

There are dozens of items used in the Quake view drift calculations, some come from the server or the mod (QuakeC).

It could be so many different things like the server/QuakeC specifying "wishangles" or movetype fly/noclip or an onground flag that without live catching it, there is not a reasonable chance of isolating what is occurring.

Since a demo is the capture of all communication from a server, the information within a demo should be enough for examination to see what variable is the source of what you have experienced.

Other: I'll build the Linux in the next 24-72 hours. The "link active" thing should go away. Although I spent some time examining ffmpeg, too many irons were in the fire and I never got around to adding soundtrack support for Linux nor QuakeDroid because there was too much going on. So that'll happen next time (maybe Christmas).

@fifth - Yeah, split screen is going to happen! Haha! Almost happened this time. Next time is a lock. 

It's ironic that this may happen when I am playing the least amount of Quake for about 10 years.