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? 

Some people like to play and get steam messages or popups etc without having to alt-tab. I guess. 

A screenshot is worth a thousand words:

http://imgur.com/a/URhKC

My netbook screen res is 1024 x 600. I either run Quake fullscreen at 1024 x 600 resolution, or (as the screenshot shows) in an 800 x 600 window (which gets clamped to 800 x 578) when I want to be able to switch away from Quake easily so I can look at other things like QView or Func_Msgboard or when I need to make notes in notepad about bugs I encounter, or any other kind of multi-tasking where I can see both Quake and something else at the same time. 

Is there a guide to compiling this with Code::Blocks ? I'm not a developer, and I've only dabbled through the years. I've successfully compiled maybe 4 different engines before, but only via make files.

So far I've installed CodeBlocks 16.01 on openSUSE 42.1.

I assume SDL 2.0.5 library is okay. Or does it specifically have to be 2.0.4?

And what compiler should I choose? It gave me options on first-run, but I only had GCC available. Not even 100% sure what project to load. 

borderless fullscreen means alt+tab is quicker as it doesn't necessitate a video mode change, so textures don't get purged by the os, etc, and yes, its less hostile to other programs too as it doesn't result in the registry saying one resolution and yet currently displaying another.
there's also less risk of windows randomly moving desktop icons around...

big negatives sounds like its using an unsigned negation, eg: ypos = ((unsigned)screenheight-desiredwindowheight)/2;
side note: with d3d, make sure that your d3d backbuffer actually matches the size of your client area. if it doesn't then d3d will be a little more expensive whereas opengl will just resize the backbuffer for you.
this also makes handling WM_SIZE much more annoying in d3d. 

mark.cbp is the CodeBlocks Project File.

You open it in CodeBlocks then ...

1) Click "Build", "Select Target" ->"Linux SDL GL Release" screenshot

2) Click "Build" -> "Build" to compile. screenshot
3) Then it compiles and you get to read about 12 warnings that don't apply and get to see about 100 developer comments of mine.

Requires SDL2 2.0.4 Dev (or later) installed to compile.

To run the engine, you'd need SDL2 2.0.4 (or later) installed.

I hope it works for you. But I have no idea if it will work for you on a different distribution.

I also don't know what version of GCC I used. I used whatever version was already there after I installed CodeBlocks, which I installed out of the Ubuntu Software Center screenshot, which of course is Ubuntu thing.

I hope that helps! 

mark_v.cbp is the CodeBlocks Project File.

You open it in CodeBlocks then ...

1) Click "Build", "Select Target" ->"Linux SDL GL Release" screenshot
2) Click "Build" -> "Build" to compile. screenshot
3) Then it compiles and you get to read about 12 warnings that don't apply and get to see about 100 developer comments of mine.

Requires SDL2 2.0.4 Dev (or later) installed to compile.

To run the engine, you'd need SDL2 2.0.4 (or later) installed.

I hope it works for you. But I have no idea if it will work for you on a different distribution.

I also don't know what version of GCC I used. I used whatever version was already there after I installed CodeBlocks, which I installed out of the Ubuntu Software Center screenshot, which of course is Ubuntu thing.

I hope that helps! 

I'm able to reproduce this undesirable behavior in the DX9 build.

I haven't incorporated all the MH changes yet, I had too many builds/platforms I was juggling around.

I'm generally an ALT-ENTER user and didn't think of testing DX9 with a fullscreen windowed mode.

What you independently verified and what Spike is suggesting as the likely mechanism sounds right.

Short version: I'll see if I can tune up the DX9 version to get to use the all the latest MH 12/30/2016 changes.

Keep in mind, mh is saying that some of this stuff D3D is very touchy about --- so ....

Remember --- you might not actually be able to have everything exactly the way you want it. 

Thanks, Baker!

Turns out I had everything right, except that I didn't know to "Select Target."

Unfortunately, with this build I'm still getting the instant "Segmentation Fault" crash I was with the Ubuntu binary. :/

Ah well. 

Ah, too bad. I wished it worked for you, obviously. At least the Windows version runs under WINE for you on OpenSUSE.

I knew to specifically call it a Ubuntu Linux version. 

install valgrind, drop to a terminal, start via valgrind, eg:
LIBGL_ALWAYS_INDIRECT=1 valgrind ./markv -window -game whatever

then publically shame baker with each and every stack trace that it spits out on its way to crashing...

then you ask baker how to re-enable debug info (if you're lucky then 'make clean && make CFLAGS=-ggdb' will do it), then repeat...


valgrind is so much easier to debug linux programs than gdb, at least if its simple enough that a stack trace is all that's needed.
if nothing else it'll give baker somewhere to look.
the libgl_always_indirect thing is to keep valgrind from tripping up over the graphics drivers poking user-memory from kernel space. you may see similar false-positives from sound drivers.
It might also point out a whole load of other things that someone's overlooked which have so far failed to crash anything, so probably just focus on the last one or something. 

winquake still gets decent fps even at 3840x2160.

THE FUTURE IS NOW 

@kp - awesome

@spike - I have a todo-list you know. ;-) Like my main priority is DX9 integration because MH's time and effort is important to me -- and it is a voluntary surprise contribution on his part, which I appreciate and clearly many others do as well.

I'm also just one guy. And this is a free and open source project for a game.

Despite disagreements about multi-game, I think it is rather clear that on most topics we are in complete agreement.

No obligation or expectations, but if at any point you wanted to contribute as much or as little as you chose, it would be welcomed and used. And if not that, that's ok too!

You've more than done enough to help me over the years, and never think I don't appreciate it.

Anyway, that door is always open and you are always welcome. And like my interactions with MH and his interactions with me --- it's all about developer fun.

So ... I have some DX9 I hope to integrate! And a list of issues presented by others above that I hope to knock off. 

The Winquake version resolves an issue I reported way upthread -- if I set it to an 800x600 window, it now behaves like the GL or DX8 versions and doesn't cut off part of the HUD at the bottom of the screen (along with the usual clamping behavior). Nice.

The Winquake-GL version just shows me a solid white screen no matter the resolution setting, but I can hear the demons running. 

Thanks for the info.

Yeah, the WinQuake GL was not targeted to your machine. If it doesn't have non-power of 2 texture support, it'll explode.

Rare case where I was writing an engine build almost exclusively targeted towards killpixel's machine -- which with that 3840x2160 screenshot shows is pretty decked out. 

This is all valgrind spit out on the binary I compiled, if anyone is curious:

http://pastebin.com/JcTPtmFu

@Baker. Please disregard :P