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. 

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.