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 

Next update, I'll have the option to disable pthreads.

And tell you what to do to take another swing at this.

Mark V does not use pthreads very much.

Now this doesn't guarantee that even with pthreads disabled that it will work.

But maybe it will work. ;-)

/Either way, I'd say you fit in here just fine as a beta tester!

(And thanks to Spike for providing the suggestion.) 

 

I believe I know the issue.

I use pthreads.

I normally don't do SDL builds, I try to go native. SDL has some sort of threads feature.

SDL's threads feature and pthreads fight.

I'm about ready to upload the new source for JimBob. 

Thanks, Baker! I'll be sure to check in on this thread now and again. 

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

Also when you compile, instead of selecting the Build->Select Target->SDL release you might select SDL Debug instead, which will keep the debugging symbols intact (more information becomes available). 

Hey! It runs now! And looks great! Thank you, Baker :)

Only problem I see now is mouse drift (or looseness). It's like I have an uncalibrated joystick, except I don't have a joystick or gamepad at all. It keeps spinning or drifting even when my mouse isn't moving.

Clicking a mouse button will stop it (until I move the mouse again).

Windowed mode didn't help.

Tried this command line to no avail:

./mark_v_sdl_winquake_gl_debug_gcc -iplog -noforcemaccel -noforcemparms -zone 2048 -noipx -nojoy -dinput -m_smooth

Tried a different mouse -- same issue.

Tried darkplaces again (just to be sure) and it's not happening in that engine.

Anyhow, I'm just reporting this to report it. This could be a rabbit hole for all I know. So whenever/if-ever you (or another coder) can find the time to look into it is fine by me. 

Can we safely overwrite a previous install or is it better to make a new clean install?