Is it me, or are monsters sort of transparent to the sky?

Like if I look up through a monster at a sky brush, I can see the edges where the architecture meets the sky.

http://imgur.com/a/hTQnc

Not sure if I have some setting enabled to make this happen. 

Hopefully resolved the remaining significant issues, like dwere's context creation failure message.

The message is still there, I'm afraid. 

Verified: you can see the sky (kind of) through monsters, starting DX9 1.28

You can also see shadows through monsters, if r_shadows 3 

@dwere ... Grrr. That's going to annoy the hell out of me for a couple of months. Sorry :(

@gunter ... I did an update to the page including the installer.

I am sort of mixed on doing that considering that dwere, as an example, has an issue and I'm a compatibility hawk and that's like a having a thorn in my boot.

On the other hand, the current build solves compatibility issues on the other side of the spectrum (killpixel, johnny law, pulsar's machine presumably).

/Grumpy cat face!

I'll read the comments every once in a while, all feedback gets read, this Func_Msgboard is awesome in how the layout is conducive to that. 

I suspect you're actually using an older build.

In all of this I'm assuming that you're using DX9. In the most recent code I provided a replacement ChoosePixelFormat that never fails. I need to cross-check the MarkV integration of course, but it seems you're describing something impossible. 

Shadows through monsters with r_shadows 3 is a known issue, that's part of what I meant when I said "it's not robust" and "shadows leak through geometry".

If it can be fixed it will. If it can't be fixed you'll have to take it in the spirit of Carmack's original comment on GLQuake's novelty features: "not very robust but cool to look at". 

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

http://quakeone.com/markv/older/1033_dwere.zip (Open GL, WinQuake version).

If it solves your problem, I'll have a lot more piece of mind.

Let me know! 

He was using mark_v.exe --- the Open GL.

In the above 1033 dwere test, I did 2 things:
1) I requested a 32 bit Z-buffer and an 8-bit stencil to mirror what Mark V 1.20 did. In later versions, I changed to Z-buffer request to 24-bit with 8-bit stencil.

2) Mark V Open GL will route around an opengl32.dll living the Quake folder, largely to avoid the GOG.com crappy one and the fact that a opengl32.dll in the Quake folder is almost always some 1997 relic.

If that is what is going, the dwere build will do a messagebox saying that's what's up. 

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!