@Baker I was surprised to find that mark_v.exe (Windows GL) runs remarkably well under WINE, so I'll just use that in the meantime.

I don't have in-depth knowledge of Linux either, though I too have used it before. Fortunately these days I think most anyone can figure out most of the user-side stuff by googling.

Anyhow, thanks for all your efforts to bring Mark V to Linux! 

Not certain if this is confined to my PC or not.

On first run, MarkV fails to exec my config.cfg. On exit however it successfully saves and overwrites it, then subsequent runs work.

This is a pretty standard "generated by Quake" config and works fine with other engines. I can provide a pastebin if necessary, but I don't think it's relevant because...

What I've also observed is that on such a failed run it will create a new directory, at the same level as ID1, but named with a random character (e.g. "�", "a", etc) within which there is *another* ID1, that containing a config.cfg.

default.cfg runs OK indicating that it's loading quake.rc and default.cfg fine from the PAK files. autoexec.cfg and all other PAK file content loads OK, and screenshots/etc are created in the correct folder: i.e. it's solely confined to config.cfg.

This is on Windows 10 64-bit, fully patched. The only thing unusual I do is that I have a separate directory for each engine and I use mklink to create hard links/directory junctions for the PAK files and Music directory. 

To try and be clear, in DX9 with vid_hardwaregamma 1, the gamma slider affects everything -- both Quake and my desktop.

With vid_hardwaregamma 0, the gamma slider only affects Quake, and not my desktop.

But txgamma does nothing. It doesn't even return a value.

I'm preferring to use txgamma, since it does not affect the polyblends, and so makes them look correct instead of gamma-adjusting them, which makes them too intense.



About the 800x600 window, it may be related, but it's not the same bug I've ever reported before. The Quake window just completely becomes invisible. I can hear it, but I don't see anything. If I can mange to change the window size back to something else, the window re-appears. And again, if I restart Quake after having previously set to 800x600, then I get an 800x578 window, which is fine, and apparently what DX8 does automatically without turning my window invisible. Though vid_height still reports 600 in both exes -- it's only in the Options menu where DX9 (not DX8, which shows 800x600) reports my resolution at 800x578.

So the main point is: on my 1024x600 netbook, using the menu to set DX8 to 800x600 window works fine, whereas trying to set 800x600 in DX9 via the menu causes Quake to become completely invisible -- no visible window at all, though it still is running, and shown in the task bar.

But if there's nothing that can be done about it, then there's nothing that can be done about it....


I also get a similar glitch if I try to alt-tab away from a full-screen mode in DX9. When I try to go back to Quake, I get invisible Quake with no way to bring it back without restarting it.
If I try to change the resolution without restarting it (by sound) it freezes up (it gets stuck repeating a menu sound). 

@kp - In the WinQuake through GL build, I capped the stretch because I was having frame rate issues at certain larger sizes, which apparently is a total non-issue in your case it would seem.

@kinn - I have to check that out. Haven't thought about it in a while. Seems you have found a map that challenges that limit. I'll investigate at some point.

@dwere - I'll have to take another look at that. I did change Mark V to bypass an openg32.dll living in the Quake folder --- do you normally need an opengl32.dll in your Quake folder?

@damage - Winter + cold and a bit of elation of wrapping up a very complex set of builds sometimes leads to ideas that the next day don't look quite as smart, haha. Anyways --- I haven't forgotten about rotation.

@gunter - Like MH said, nothing about the Direct3D relates to texture gamma at all -- so DX9 doesn't have texture gamma at all because 3 different gamma systems in the same build would have been a headache for me. 

I could have coded texture gamma in Direct X 9 build.

I didn't because of the complexity of having to figure out how to make 3 different gamma systems interoperate.

I wanted to get a build out.

texture gamma will likely be available in a future DX9 build when I have more time to plan it out. 

Mark V fails to exec my config.cfg

I thought I noticed that. Will have to investigate. 

I get 150-200 fps at 1920x1080 with the win build. 

It is important to note that the Direct X 9 build is not "final".

I have outstanding improvements from MH that I have yet to integrate.

I marked this build "Beta" -- suspecting there would be some things that need ironed out. 

I don't need it, and it's not there right now. 

The bad config.cfg is coming from %appdata%\MarkV\caches; every other cfg file runs from com_gamedir but for some reason config.cfg is running from there. 

Is the pure WinQuake build performing nice enough that the WinQuake through GL build is basically not needed?

/It'd always be available as an option, besides it can do one thing that the pure WinQuake build can't --- it can do vid_vsync ;-) 

This block of code in Cmd_Exec_f is where it's happening (based off 1023 source, 1025 seems to have no source release & may be different):

if (String_Does_Match_Caseless (line->args[1], CONFIG_CFG))
{
const char *check_string = va("// %s", ENGINE_FAMILY_NAME);
cbool is_our = String_Does_Start_With (file_text, check_string);
//int len = strlen(check_string);

// cbool is_ok = false;
// Baker: Make sure it is a Mark V config
if (!is_our)

So my reading is that Mark V is attempting to detect if the config was created by itself (using the presence of a comment at the start as an indicator) and refusing to exec it if not. 

I can't get it working with any version of Mark_V. Seems to work fine with Quakespasm, not sure what seems to be causing it. I'm sure this was fixed at one point. 

@fifth - you're probably using ogg, try mp3.

@baker - winquake seems to run great. the stuttering issue from before is gone. however, there may be a brief "hang" that seldom happens that I didn't detect in the wingl build. Don't hold me to this, I haven't found time to sit down and really test them. 

@mh - Yes, exactly. Mark V writes a backup config to prevent a loss of settings.

I need to revisit it and double-check everything there and combined with what Johhny Law identified as a scenario --- give it a thorough look over.

Source code

http://quakeone.com/markv/older/1025_mark_v_beta_source.rar

re Linux: I use CodeBlocks with SDL 2 Dev 2.0.4 package installed to compile.

/It is possible that at some future date, a Linux makefile may become available if I can determine a way to automatically have CodeBlocks generate it via a plug-in. 

OK, so I played around a little more with windowed modes in the DX9 wrapper; this is my own development version which is a coupla steps ahead of what Baker currently has.

First thing to check was window resizing. Is it possible to resize a DX9 windowed mode to something equal to or larger than the display resolution? The method used to test this was to drag the window down so that it is partially offscreen, then attempt to resize via the top border.

Answer is "no": either the driver, the DirectX runtime or the OS are intervening and clamping the window size.

I cross-checked this with MarkV GL and I get the same behaviour there. I then cross-checked with MarkV software and confirm the same there too.

I then checked a Notepad.exe window and got the same there too.

My conclusion is that clamping the size of windowed modes is totally outside of the control of the application; most likely the OS is enforcing that.

On a 1920x1080 monitor, I attempted to start with heights ranging from 1000 to 1080. From -height 1054 onwards I got a grey screen instead of the standard window with the game running in it. On this PC the taskbar is 40 pixels high, so I think we can rule that out. So within 36 or fewer pixels of the destop vertical resolution, you cannot run a windowed mode.

I used AdjustWindowRect and determined that with a client rect height of 1053, top was -31 and bottom was 1061.

I cross-checked with some other D3D9 code I had, which contains debug assertions that verify the window client rect is the same size as the requested mode. In this code the client rect is clamped to 1053. I removed the assertions and did further testing which determined that Direct3D was indeed setting the backbuffer size to the requested mode, but was clamping the window client rect.

I cross-checked with some D3D11 code I have and determined that the client rect was likewise being clamped to 1053.

Finally I tested some OpenGL code and determined that the same clamping behaviour existed, but in that case to 1063. For the sake of completeness I attempted running with height 1080 and 1090, both of which clamped to 1063.

Finally I wrote a skeleton Windows program (just WinMain and WndProc), created it's window at 1080 height, and observed it being clamped to 1041.

It's notable that there were differences between the window styles of all of these programs - I could repeat the tests using the same styles but I don't feel too inclined to, because the data I have is sufficient. However, and just to be absolutely complete, I modified the last program to use WS_POPUP where the window height was not clamped, but was occluded by the task bar.

So there you have it. I can spend more time testing other combinations, different Direct3D versions, other OpenGL programs, but I honestly think that at this stage it's not a productive use of my time - I'd be better off watching Japanese porn.

Final conclusions. Above certain values the OS *will* clamp the size of a window, unless you use specific window styles, but even in that case it *will* be occluded by the task bar.

So to repeat: don't do it; just don't. 

Is in mp3 format 

don't you have a virtual drive installed? it used to be the cause of the si,inlar problem with mp3 playback in mark v 

Maybe a naming issue? e.g. track_002 as opposed to track_02.

I had an issue with music too that ended up being something simple that I overlooked, can't remember what it was though. 

I just have C: and D: drives (both SSD's, quake is on D:) E: is my blu-ray and F: is my removal mechanical. 

are track02.mp3 to track11.mp3 in id1/music 

I use .ogg files and so, I converted track02.ogg to .mp3 and instantly had music in the opening demo. These are in id1\music.

User setups at error here? 

If you haven't already, check out the music section of the readme and see if you can spot a discrepancy between what you're doing and what it says. Music works for me. Strange :/ 

"My conclusion is that clamping the size of windowed modes is totally outside of the control of the application; most likely the OS is enforcing that."

The clamping is fine. I don't really mind if I tell it to set Quake to an 800x600 window and I actually get an 800x578 window. Close enough.

Also, I found that if I set -width 800 -height 600 in the command line, I don't get the strange behavior. I just get the nice, clamped window as usual.

The problem I am seeing is actually a bit more interesting than I thought.... My Quake window isn't being made invisible -- it's being moved WAYYYYY off screen!

I downloaded this tool so I can keep track of my window position: http://www.catch22.net/software/winspy-17

(Chrome throws a fit over that file and won't let you download it... but it's legit. I'm sure there are other tools to do this as well).

So I run DX9 Mark V and select its window to keep track of in WinSpy++ (though it doesn't track the position in real time -- you have to hit F5 on WinSpy++ to get an updated window position after moving it).

No problems so far. I can move the window around and refresh WinSpy++ and it will tell me the position of the DX9 Mark V window.

Now I go into the Quake Options menu and change the resolution to 800x600 windowed... and ... where did my window go? It's vanished! Sooo, refresh the WinSpy++ information and guess where my window is located? "108, 32767" ! Every single time, the same location... wayyy off the bottom of the screen.

Then I can right-click on the DX9 Mark V indicator in my windows taskbar and select "Move" then tap an arrow key to grab it, then move the mouse up, and pull it right back onto my usable screen area... (it jumps to the mouse cursor position).

So that's weird, right?


Let me test to see if this is what's happening when I alt-tab from a fullscreen mode....

Wow! Even better, when I do that, Quake gets sent to limbo at -32000,-32000

And I can't seem to make it come back.... Though it may be a bit different, because I can't refresh my WinSpy++ when the fullscreen Quake has focus... way off in limbo where I can't see it, I assume. 

What is the specific reason that people want to have the game run in a window that's the same effective size as the desktop resolution? I feel like I must have missed a post explaining the need for it.

In any case, I don't personally know much about it, but many games support a "borderless window" mode that is almsot indistinguishable from fullscreen, but is techincally a windowed application. Would that be an acceptable solution, assuming it can be implemented?