Interesting screenshot. 

Hm. it gets more interesting....

If r_shadows 3, then you can no longer see the sky through monsters. But that's when you can see shadows through monsters. It's not just shadows leaking through anything -- you can see the shadows through the monsters at a distance, in a very similar way as you can see the sky through the monsters when not using r_shadows 3....

I would suspect a relation, since both these issues appear starting in DX9 1.28, when the new shadows were added.... 

Yeah. Really I think it's more like the sky is shading the monster, rather than the monster actually being transparent to the sky. Er. It's confusing. 

Shadows & sky is an understood problem.

Both have weird interactions with the depth/stencil buffer, and are therefore interacting with each other.

Fixing individual problems as they occur is not going to solve this, so everybody - please stop reporting bugs with it.

I know what the solution actually is, and it involves decoupling the shadow pass from the MDL passes so that the former can be done in isolation and without affecting other stuff, then figuring out the correct draw order placing for it (which will be one of two options).

If you look upthread you'll see that I already said this, but in a bit less detail.

Right now giving me the head space to actually do this is a lot more helpful than piling on the bug reports. 

Let me know if these work and/or what happens.

The same message appears, sorry.

mark_v_winquake.exe works, but it always worked, unlike mark_v_winquake_gl.exe. 

Always start afresh 

@dwere what about the normal mark_v.exe? Does that work ok?

The mark_v_winquake_gl.exe is a discontinued experimental build, it's just like the mark_v_winquake.exe except it uses Open GL to put it on the screen. 

Interesting thing (maybe?) about build 1032.

Occasionally I use a Windows 10 VM on my Macbook to check out Windows things. I've run past mark_v.exe versions in there without problems. This one though fails to run, as does dx9_mark_v.exe. dx8_mark_v.exe and mark_v_winquake.exe work fine.

This doesn't matter much to me since I don't actually play Quake on this VM, but maybe it's an indicator of something you might want to know about. So, FYI:


mark_v.exe fails with this dialog:

---------------------------
Quake Error
---------------------------
Could not initialize GL (wglCreateContext failed).

Make sure you in are 65535 color mode, and try running -window.
---------------------------

(I did try using "-window" for the heck of it; same error.)


dx9_mark_v.exe fails with this dialog:

---------------------------
Quake Error
---------------------------
R_LoadD3DX : failed to load D3DX
Please update your installation of DirectX...
---------------------------


This is a VMware Fusion VM, and in the Display settings under the "Accelerate 3D Graphics" switch (which is on) the description of that option says "Supports DirectX 9.0EX with Aero and OpenGL 2.1". Perhaps the wglCreateContext invocation in mark_v.exe has been changed to require something unsupported in OpenGL 2.1, and dx9_mark_v.exe is requiring something beyond DirectX 9.0EX?

(It looks like if I were to spring for an upgrade to the latest Fusion version I could get better graphics API support, like DirectX 10 and OpenGL 3... hmm.) 

 

@dwere what about the normal mark_v.exe? Does that work ok?

I was talking about mark_v.exe when I said that the message still appears, so no. 

Oh hey I guess the wglCreateContext part of my post is the same thing that dwere was reporting. FWIW, the "dwere build" 1033 behaves the same way as 1032 in my VM. 

The DX9 build requires the latest DirectX runtime installed. There are components of DX9 that were added in subsequent releases but which are not included in DX10+ on a fresh Windows install. This can be safely installed without affecting DX10+.

https://www.microsoft.com/en-ie/download/details.aspx?id=35

For OpenGL startup problems I suggest grabbing the OpenGL Extensions Viewer from Realtech VR. This is a great way of verifying your OpenGL driver.

http://realtech-vr.com/admin/glview

Down the left-hand side of the Viewer you'll see a list of links, with the top one ("Summary") selected.

Please report what it says for "System Info | Renderer" and "OpenGL | Version".

Third one down is "Display modes & pixel formats".

Unfortunately they don't provide a way to search or filter these, but look for pixel formats with WGL_ACCELERATION_ARB set to FULL_ACCELERATION, WGL_COLOR_BITS_ARB 24 or 32, WGL_DEPTH_BITS_ARB 24 or 32, WGL_SUPPORT_OPENGL_ARB True and WGL_DOUBLEBUFFER_ARB True. 

Can either of you post a qconsole.log where the error occurs? Mark V automatically does a qconsole.log. I'm trying to walk through all the small differences between 1020 and 1025 builds. 

Yup, will try/report various things later today. 

OpenGL Extensions Viewer quits silently in the middle of loading extensions.

Maybe my system just sucks - I had to "temporarily" install a shady Win 7 distro with some features disabled. The list of disabled features looked innocent, but I had some video driver installation problems. In the end, I just reinstalled everything with a driver that I knew worked fine, and left it at that.

All 3D games I tried so far worked fine, including Quake source ports (Quakespasm and mark_v.exe dated 2016/12/03).

I tried to reboot from an old HDD with Vista installed, and the latest mark_v.exe started without any problems. But I have different drivers there.

Can either of you post a qconsole.log where the error occurs?

Command line: [ ]
Log file: D:/Games/Quake/id1/qconsole.log
Fri Jan 20 00:02:40 2017
Mark V Windows (Build: 1033)
Exe: mark_v.exe (1327 kb)
Exe: 00:44:32 Jan 19 2017
Caches: C:/Users/User/AppData/Roaming/Mark V/caches
UDP4 Initialized: INADDR_ANY, 192.168.1.67
IPv6 Initialized: [fe80:0:0:0:9459:106d:2bee:97d8%12]
Exe: 00:44:04 Jan 19 2017
256.0 megabyte heap 

Maybe my system just sucks

If an earlier Mark V worked, I'm not going to be happy until this one works.

I did install DirectX June 10 SDK, which may have changed some libraries.

Need to meditate on this a bit. 

Fitz 0.85 works fine on my XP VM but MarkV fails with the same error.

It's XP on a Windows 10 host, but I believe the core guts of the driver are the same: VMWare Tools provided Mesa/Gallium driver.

I have a full development environment on this VM so I'll have the fix identified soon! 

Another thing going on here, you also have the problem with winquake_gl -- which doesn't even use Visual Studio to compile, it uses CodeBlocks/gcc/mingw and winquake_gl is an SDL build, so it uses SDL functions to set the pixel format and create the opengl context. 

The DX9 version works after installing that runtime package.


In the OpenGL Extensions Viewer:

- "System Info | Renderer" is "Gallium 0.4 on SVGA3D; build: RELEASE"

- "OpenGL | Version" is "2.1 Mesa 8"

- In the pixel formats, WGL_DOUBLEBUFFER_ARB is sometimes False, for some values of number in the spinner there (don't know what that number is). For 7-12 it's True, for 19-24 it's True, stopped looking at that point. For some of those, color bits or depth bits are 16, but others match all the desired values you mentioned.

Let me know if there's other digging around I should do in the extension viewer. I copied the text from the Report pane to https://dl.dropboxusercontent.com/u/11690738/temp/extensions_report.txt


qconsole.log from trying to run mark_v.exe:

Command line: [ ]
Log file: C:/Users/joel/Desktop/Quake/id1/qconsole.log
Thu Jan 19 13:16:05 2017
Mark V Windows (Build: 1032)
Exe: mark_v.exe (1327 kb)
Exe: 10:00:00 Jan 18 2017
Caches: C:/Users/joel/AppData/Roaming/Mark V/caches
UDP4 Initialized: INADDR_ANY, 172.16.229.128
IPv6 Initialized: [fe80:0:0:0:a48d:1a8a:5eb0:7e8b%8]
Exe: 09:59:32 Jan 18 2017
256.0 megabyte heap 

Fucking awesome!!

Yeah, since I can't experience the problem firsthand, I'm not able to get my hands dirty as I would like. 

qconsole.log from build 1033 is the same except for obvious differences in build number. 

An obscure change is that current Mark V uses /J compiler option - make char be unsigned char.

Wanted to mention that, although I do not believe this relates to the issue. 

Another small change is that Mark V uses /DELAYLOAD:opengl32.dll

I can't see how that would relate to this, but anything is possible with something odd like this. 

It's because you're delay-loading.

See https://groups.google.com/forum/#!topic/comp.graphics.api.opengl/AVqQjWFAIBI for a prior example; wglCreateContext fails with error 2000 which is exactly the same as MarkV does.

The quick 'n' dirty fix I did was to pop in this little line of code before setting up the pixel format:

GetProcAddress (LoadLibrary ("opengl32.dll"), "glBegin");

You'll probably want to #define it for the GL build, but that forces opengl32.dll to be loaded and then everything works. 

Thanks MH!

Where did you insert that line in your test?