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. 

Ok, actually there is more happening than just window position. It seems that after changing the resolution to 800x600 windowed via the menu, not only does the window get sent to limbo offscreen, but it looks like this (top image):

http://imgur.com/a/3NLCg

And it THINKS it's at 800x600, even though it's not.... The screenshot comes out at 800x600 resolution, even though the game window size is exactly the same as the earlier desktop screenshot (Oh... that must be why the menu text looks wrong in the former case, though I didn't capture that text, but it's definitely missing some rows of pixels). And I bet the added black bar at the top makes up the extra pixels from 578 to 600.

The lower image is how it looks after restarting Quake. No weird black bar at the top, and the image resolution is 800x578.

So it seems to me that upon startup, DX9 Mark V checks the resolution stuff and sets everything correctly (even when clamping the window size is needed), but when changing it via the Options menu, it does not perform the same checks or something, and stuff gets messed up. And the window position gets sent to limbo.

I believe Spike mentioned something possibly related:

"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. "


So it seems things are correctly set at startup (even if I set -height 600 on the command line and clamping is needed), but not when changing the resolution in the menu if window size clamping occurs and you get a window smaller than expected. 

EDIT: Added a 3rd screenshot (desktop rather than in-game) that better shows how Quake thinks it's in 800x600 when it's really in 800x578, as described above. You can see it's chopping off rows of pixels in the menu text.

http://imgur.com/a/3NLCg

Ok, now I'll shut up until a new version comes out. ;) 

Source code posted in post #900 is working for me using the KDE desktop environment. 

That works for me, too. Thank you for taking the extra time to sort that out!

Quake feels new again with a new engine to play with ^_^ 

Thanks for your help and feedback.

I tried it on Unity, Gnome and KDE Plasma just now.

Unity was an A+++, Gnome was a A-, KDE Plasma was mixed for me --- but my KDE Plasma may not be update to date plus I rarely use it so I have no idea on how to tune KDE Plasma settings -- so hopefully is just me. 

If you don't mind, could you tell me if these binaries happen to run on your machine ...

http://quakeone.com/markv/older/1025_linux_binaries.zip

May need to chmod them first, obviously. 

Ok, I was wrong. I have more things to report.

Ehhh... but I am having trouble doing testing now. Mark V won't let me delete my config.cfg file in the FvF folder to blank out my settings. It keeps re-loading the cfg from some backup place. I dislike the loss of control over my cfgs! heh Something like that necessitates a prompt for user control, "do you want to load cfg from backup?"

It seems I can delete the config.cfg file in id1 just fine though, without the settings persisting.


Mirrors do not get along well with skyboxes in DX9. Just activate a skybox and go peek in the Start map window mirror from various angles and you'll see....

Hm, and mirrors don't work at all if you use a different game dir....

For example, make an empty directory called "none"
Run DX9MV and start a new game. Go look in Start map mirror. Then change "game none" and start a new game and repeat. No more mirror. Change back to "game id1" and the mirror works again.... Results are the same when starting with "-game none" (or any other game dir -- I noticed the mirrors weren't working when I was running FvF). 

Those 2 binaries appear to run just fine (with my 5 minutes of testing for each heh).

The only *potential* issue I notice in those (as well as the ones I compiled) is minor, being the apparent lack of mp3 music audio. But that's not a game-breaker. 

@jimbob - There are few things I have to do research into for the Linux build.

It's not too bad for a build that is not quite 2 days old yet, haha.

Make it run first, make it great later. It's how coding is done.

@gunter - I have various homeworks to with some of the things you've pointed out.

With some luck, I'll have DX9 current and test things and see where everything stands with up-to-date code. 

True! It's not bad at all. And I'm happy to have something that's playable.

"mirrors don't work at all if you use a different game dir" - Gunter

Just want to confirm that this quirk also occurs in mark_v_sdl_gl_gcc . 

If someone makes a map pack and they want mirrors ... you call the texture "mirror_whatever".

One of the Arcane Dimensions maps by pulsar has a mirror in it, for example.

The window02_1 in the start map and E1M5 in standard Quake is an homage to the original GLQuake with the feature.

But if someone is playing Soul of Evil or Travail or something and some random texture is pointlessly a mirror because it is window02_1, that would be annoying as hell ... 

That makes sense.

Guess I got confused by the r_texprefix_mirror cvar.

Also I blame Gunter ;P 

Config.cfg

This is the same as the problem I reported.

If you do:
* Start
* Run
* %appdata%

You'll find a "Mark V" folder which also contains a config.cfg; delete that too.

Display modes/etc

I'll need to take time to reread your posts more carefully. It seems to me that the most probable cause is that when changing modes, alt-tabbing, etc, GL requires you to write your own code for some things that D3D doesn't, and D3D requires you to write your own code for other things that GL doesn't. What that means is that there is going to be something where either (1) in-engine code is fighting against an automatic behaviour, or (2) in-engine code is missing for something.

I'm inclined to suspect (1) from experience. For example, in GL the AppActivate function vontains code to explicitly restore display modes and minimize the window on Alt-Tab events. D3D requires none of that, and in fact changing the display mode this way will cause trouble for D3D.

In the most recent code I gave Baker I rewrote AppActivate, and provided new wrappers for ChangeDisplaySettings and EnumDisplaySettings, designed to avoid all of this. I'm not sure how completely he's integrated these yet, but if he still has work to do with them it would be consistent with your experience. 

the alternative is to support EGL+GLES2 on windows and grab the dlls from ANGLE(or chrome/firefox), and get it running in either d3d9 or d3d11.

how angle works around d3d9/dxgi quirks I've no idea - maybe it just creates a nested/child window and does all its rendering to that... 

I've got MH's latest DX9 integrated.

Annoyingly the shader gamma off by 1 pixel has returned -- but instead it stretches, hard to notice except when in options. At first I was thinking it might be a matrix calculation issue in the menu canvas somehow, sometimes the 2D matrix needs a 0.5 kick to get the rounding right -- if I recall. Perhaps something in that ballpark is happening here?

Had to address ...
1) A border painting issue.
2) Made the window centered on ALT-ENTER and video mode switch.
3) The windowed mode window was staying topmost after a fullscreen. Baker addressed.
4) Made resized window stay in the same place during resize.

Need to double-check the ALT-TAB modifications MH made and ensure I did them right in the engine code.

Everything else looks great except if stencil was anticipated to work -- I don't know either way -- does not seem to work for me (doesn't in DirectFitz either) ....

So I made a single #ifdef in the code near the top of quakedef.h to toggle compile with DX9 stencil on or off.

I need to double check some things before I do a DX9 version update, but it very close. 

Mark V Build 1026 - Direct X 9 | Source

A screenshot of a few things combined together as a test ...

Screenshot

Mirrors, non-power of 2, external textures, particle effects, alternate HUD, lightning gun sparks, QMB flames, DX9 depth test level, gamma shader, vid_vsync, resizable window, combine, alpha, texture matrix. The .png screenshot was written via the DX9 accelerated screenshot API.

(* about 9 things the DX9 wrapper does that DX8 didn't)

@gunter - the sky will not show up in mirrors in DX9 in this build, stencil isn't seeming fully operational. I did a trick or 2 to obtain most of the effect ;-)