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? 

Type nomouse 1 in the console or add -nomouse to the command line for now to disable the mouse.

Out of curiosity are you using Gnome or KDE or something else? 

I think using SDL_SetRelativeMouseMode(SDL_TRUE) will fix JimBob's mouse issues.

This will hide the cursor for you and start sending the application relative mouse events read from the system's raw input API's on linux and Windows (I started a mac implementation which I need to polish up and get the SDL people to merge..), it's the right way to get mouse input for FPS games with SDL2. 

Will do!

I'm using KDE with Plasma Shell v5.5.5. 

I'm currently putting together a Windows "skeleton app" which will just create a window and initialize Direct3D. This will enable me to do another bunch of testing and determine which issues are coming from Direct3D (which we don't have control over) and which are coming from the engine (which we might have control over).

I see from your screenshot that your netboot is running XP. I have access to an MSDN subscription so I can spin up an XP VM in VMWare Player which should be representative of your netbook's hardware, then do a bunch of testing there too.

I do know that behaviour of so-called "fullscreen windowed" modes, interaction with the taskbar, etc changed at some time in the post-XP timeframe. It may be the case that special-case code is needed for XP versus post-XP. I assume that nobody gives a toss about Vista, so establishing the behaviour on XP and 7 seems like a good place to start.

I have doubts about the best way to handle this. Right now I have a bunch of code that checks the window size and will throw errors, but I wouldn't seriously propose that as a solution. I'm not even certain that it's appropriate to handle it in the wrapper, although if the D3D behaviour is sufficiently different to GL, it might be.

If you have any suggestions I'd be interested in hearing them. Assume for the moment that I can't get it working - what would an acceptable fallback be?

Until then I suggest run it with -height 560 or thereabouts. 

Here is what is funny -- back in 2012 when I wrote the "single frame mouse code" for Mark V, I had SDL 1.2 and Linux in the back of my mind.

SDL2 either didn't exist or was a concept or upcoming project.

And the undesirable "grab the pointer position" and "center the mouse in the window" method was what most Linux Quake engines did.

Current code isn't very accumulator friendly.

Haha.

@JimBob -- just tried with KDE/Plasma --- yeah KDE sure hates the mouse code.

I can switch between Gnome and KDE rather easily, if you are able to load up Gnome it may work.

KDE no like the current mouse code. 

Hmmm ... actually Ubuntu uses Unity which works fine, if I switched to pure Gnome which also hates the mouse code.

So look at the moment that the SDL2 library only supports some of the new functions in 2.0.4 and 2.0.5 on Ubuntu's Unity?

As a Linux novice this is my interpretation of what I am seeing.

More work to do.

Well, I can say this the Ubuntu Linux version is quite nice running on Ubuntu with Unity -- has a resizable window and about 99% of the Mark V niceties.

But at present time, the other desktop environments and current SDL2 do not seem to play nice with the current implement of the Mark V SDL2 mouse code. 

Well, I guess if I get too impatient I can try this:

http://download.opensuse.org/repositories/X11:/Unity/openSUSE_Leap_42.1/

But I'm afraid I'll break something if I do. 

I'll wait till Baker releases a new version to see if he fixes any of the issues (Spike put him on to a possibility).

Just to try and be clear, since everyone seems to be talking about different things, I am not using one of the borderless windowed full-screen modes. That mode actually works fine for me (1024x600 windowed, my desktop res). I can alt-tab away and back to it with no issue.

Oops. I spoke too soon.... Ok, if I have JUST set it to 1024x600 windowed via the Options menu, then I can alt-tab away from it and see any other window, then alt-tab right back to Quake with no issue....

However, if I close and restart DX9 Mark V so that it starts up in that mode, then Mark V seems to be "always on top" and it blocks the view of any other window that I give focus, unless that other window is also set to "always on top." I can see the Start menu if I cause that to pop up via the Windows key, but DX9 Mark V blocks other windows that I give focus to....

All kinds of fun weird things happening.... This doesn't happen in DX8 Mark v.


Anyway, if I am in any fullscreen mode in DX9 Mark V, an alt-tab results in my Quake "window" being sent to -32000,-32000 and it won't come back when I try to give it focus again. If I then exit Quake (I can hear the menu sounds to navigate to "Quit") I get a "Quake Error" popup that says "context_t::CreateTexture: unable to create a texture"



But as far as using an "800x600" window, That works fine as long as I don't try to change it to that setting using the menu in DX9 Mark V (ie, if I set it by command line or just restart after having changed it to that, it works as expected, just clamping my window at 800x578).

However, If I use the menu to change it to that, it does create the window, clamped at 800x578, but the window gets repositioned at 108,32767 -- way off the bottom of my screen, but now that I know this, I can use right-click commands to move the window back onto my screen, as I mentioned in my previous post.



Anyway... I guess I'll wait for Baker to release a new version to see if any of this has been addressed....

I'll just reiterate that the problem isn't about the window being clamped to 578 height when I tell it to set to 600. That's all fine. 578 fits my screen res (1024x600) well enough (shown in the screenshot above). And Mark V seems to handle the window just fine at that size. The problem is that when I try to set that windowed mode (800x600) via the menu, the window gets sent to limbo way offscreen at coordinates 108,32767. This only happens in the DX9 build. It looks like it should be created at 108,-17 (that's where it appears at startup using the same settings).

So (this issue anyway) just to be a matter of window positioning....

Can you replicate this by setting your virtual WinXP to a resolution of 1024x600 then trying to set windowed 800x600 in DX9 Mark V by the menu? 

SDL2 with Relative Mouse Mode accumulator, as ericw suggested.

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

Better than even chance this solves the mouse problem for KDE + company.