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 ;-) 

This is becoming an engine to my liking. I'm already using it for the inspector tools (the texture inspector is more handy than DP's in that it highlights the faces instead of just displaying the texture names) and that awesome ffwd/rewind feature in demo playback, but if you keep on "spiking" Mark V like that, I might actually start using it to play, at least for the maps that DP doesn't handle well.

What's the name of that QMB lightning texture? When I try to activate this option in DP, it reverts back to the original polygon lightning, so I guess it's because it lacks the texture and I need to copy/paste it into DP. 

In JoeQuake or Qrack, the name is zing1.tga living inside a pak0.pak somewhere if you wanted to obtain that file.

Mark V has it built-in, the same way Mark V doesn't need any .dlls. 

 

Just done some stepping through a debug build of the latest Mark V and I think I know what's wrong with stencil.

In OpenGL glClear is affected by the various write masks (glColorMask, glDepthMask, glStencilMask).

In Direct3D the equivalent is not.

However, in Direct3D clears are clipped to the viewport rectangle, whereas in OpenGL they are not.

Therefore, if you make a glClear call through the wrapper, and if the previous glViewport was to create a partial viewport, the full window won't be cleared.

This was a very real problem caused by FitzQuake's render-to-framebuffer water where it updates the warp images before calling glClear. The GL_SetCanvas stuff (which IMO needlessly complicates the 2D renderer) sets a partial viewport, then we come along and call glClear and only that partial viewport is cleared.

Result is that only a small square in bottom-left (or top-left, can't remember) of the window gets anything drawn in it during the main 3D render.

To work around this I added code to my implementation of glClear which reset the viewport to the full window before clearing. This was done in the expectation that there would only be one glClear call per frame which would clear all required buffers.

That's obviously not the case in Mark V which clears the stencil buffer before drawing it's mirror sky stuff.

Added complication: in D3D viewport rectangle and depth range are combined in a single state. In GL they're separate states. So resetting the viewport also messes with the depth range.

End result is that both the viewport rect and the depth range are messed-up as soon as you make that glClear (GL_STENCIL_BUFFER_BIT) call.

I'm going to fix this by putting the viewport back to the way it was after making the clear call. With hindsight I should have done this from the outset, but you know what they say about hindsight. 

I haven't had time to load up Windows 8 or Windows 10, but I did testing on Win 7 with and without Aero and so far everything looks ok --- at least in Windows 7 with whatever Direct X drivers came with Win 7 -- I know they aren't the same as, say, XP which may behave radically different.

You may have noticed I added on-the-fly resizable window to WinQuake to make the "let engine decide window borders" into irrelevant issue. The DX9 build was my main reason for wiring up WinQuake to resize-on-the-fly. 

The GL_SetCanvas stuff (which IMO needlessly complicates the 2D renderer)

Don't have much of an opinion on that ...

But I can say it was hard as hell to make WinQuake 2D render identical to FitzQuake.

So when Gunter was saying "original Quake centerprint" it somewhat follows I wasn't that big on the idea initially.

@Stencil clear -- Open GL should have done it that way, which is the better behavior ... and they would have in hindsight ;-) 

This is a case where I think no API gets it right.

Clears being affected by the write masks and the viewport rect are both IMO undesirable behaviours. GL adds the scissor rect to bound the clear, D3D9 lets you specify an array of RECTs but they're clipped to the viewport too, D3D11 has none of this crap so it gets partially there but in the end it fails because it doesn't let you specify a subrect to clear at all.

The ideal API would look something like:

Buffer->Clear (RECT clearRect, int clearMask, int ClearValue);

In other words, you explicitly specify what you want cleared, how much of it you want cleared, and what you want it cleared to. No side-effects from previous state.

I'm dubious about having a clearMask but one feature it does give you is the ability to clear RGB without clearing A (or vice-versa) in the color buffer. I don't personally have a use case for that but others might. 

Man, that %appdata config saving shiz is annoying.

I was trying out the new DX9 build but still had the skybox error as with previous version... took some time to find that and delete it so I could get a fresh start. Which solved it.

Is this by design, cause it takes such a simple concept and fucks it up, imo.

I mean, I just want a config file, saved in my id1/mod directory.

I know other games/apps do this but I don't try out 35 different flavors of those games/apps like we do with Quake ;) 

Damage, this is beta at the moment.

When it works properly, you wouldn't even know it was there because it was meticulously planned.

It was there for 2+ years, not even super-picky Gunter noticed.

Until I slightly broke it recently.

I'm very against advanced-enginitis disease.

/Keep in mind that only in this last week was anyone even aware of convenience that made life easy street for 2+ years in Mark V. ;-) 

I just read 2 pages back what was going on behind the scenes! 

I do hate when control is taken away from me without my consent, even in an attempt to "protect me." As I mentioned, a feature like this NEEDS a prompt for user control. It's not necessarily a bad thing... except that it takes away (easy) user control of the cfg file. It would be better with just printing something like, "Your config.cfg file has been altered by outside sources. type 'exec backup.cfg' to load last Mark V cfg settings." But apparently this feature is not currently working as intended or something.... How exactly is is supposed to work?



Ok, looks like we're moving in the right direction. My window no longer gets sent to limbo in any of the previous situations.

But I still have the issue I reported above, where the window gets clamped to 800x578 but it thinks its at 800x600, resulting in some ugly stuff happening.

(seen in the 1st & 3rd screenshot I had posted:
http://imgur.com/a/3NLCg

However, if I press alt-enter, then alt-enter again, that issue goes away and then DX9MV knows it's actually in a 800x578 window again (just like if I start it up in that res to begin with). Then the window looks all correct, like in a previous screenshot I posted: http://imgur.com/a/URhKC

Ok, it looks like the issue is only occurring in the (admittedly unusual) situation where my window has been set to 800x578 (due to the automatic clamping) and then I reset it to 800x600 windowed mode in the Options menu again.

It does not appear to happen if I am making any change from a completely different resolution, whether windowed or not.

And it looks like the "full screen borderless window" mode of 1024x600 no longer works the same. Now it does have a border.... which is causing the clamping of the height to 578 as well, which means I can reproduce the same issue (when already in window 1024x578 then trying to set to windowed 1024x600).

And it seems the full screen modes are... um... not correct. They are displaying the same chopped text as when it THINKS it's in a 800 height window but it's actually in a 578 height window....

So it seems like the full-screen modes are accounting for there being borders or something.... I get this effect even when I first start up DX9MV at the fullscreen res of 1024x600 without any weird res changing

Here's a screenshot: http://imgur.com/a/v5i5h

My scr_conscale is at the weird 1.5 but that alone previously didn't cause the issue, as the 2nd screenshot from DX8MV shows. Oh, it appears the previous DX9 version had this issue as well, so I guess it's not new to today's release.


But with this new version, I am getting a long delay when starting a game -- about 13 seconds. I don't have MP3s enabled. It only takes about 5 seconds to start a game in DX8MV.

This delay happens regardless of my resolution settings. Ah, it seems to be taking extra long for HQ textures to load.... If I disable them, then it loads a new game in about 4 seconds. This delay did not happen in the previous DX9 version.



About r_waterwarp:

Console variable: Toggle the use of the screen warping effect when the player is submerged in liquids. Set to below zero for water warp in GL version, but not in WinQuake version. r_waterwarp 2 in Open GL is FitzQuake style waterwarp.

I find that information confusing, and it doesn't seem to work.

In GL or DX9, you can ONLY get the new effect no matter the setting (though "0" is "off").

In DX8 there is only the old GL warp effect (I understand the new effect isn't in this version).

And in the Winquake version, the water warp is so subtle/slow you can BARELY notice it. 

Addendum:

If I start up DX9MV with 1024x600 windowed having been previously set, it correctly appears to be the borderless window that takes up my full screen, but the distorted text is still occurring.

If I change to 1024x600 windowed mode from any other mode (including just hitting alt-enter twice after starting as above), then the window borders appear and the window gets clamped to 1024x578, but then the text is no longer distorted.... 

... when can we expect the Vulkan version, baaaahahahahha

Why should modern day Quake be relegated to such archaic API's!!! 

http://www.quaketastic.com/files/tools/windows/engines/Direct3D9-Wrapper-2017-01-12.zip

Stencil is fixed, tested & confirmed working in latest Mark V release too.

THIS DOESN'T INCLUDE ANY FIXES FOR ISSUES REPORTED BY GUNTER

I'm still in "investigate mode" for those. I considered the stencil issue sufficiently important to release a new version fixing that, since it affects everyone and currently has ugly special-case code in MarkV.

@Gunter

I asked you above if you had any suggestions for an acceptable fallback if it does turn out that the 800x600 behaviour is something that we don't have control over in software.

I'd really appreciate an answer to that, because I really cannot change the way Direct3D works.

I am willing to put significant work into tuning this to meet your requirements, but I do need to be seeing something coming from you too, and right now I'm not.