Yes, I downscaled it.

This is essentially the same kind of problem and same kind of tradeoff as we have with shader gamma. Because it needs to run as a post-process it's slower, so I downscaled it to compensate.

It's a no-win situation because if I didn't downscale it people would complain that it was slow.

My expectation is that cvars could be provided to tune the size, so that you could select downscaling or not, based on your own preferred tradeoffs (and hardware capabilities). But that's not my decision. 

For comparison, this one is full res: http://www.quaketastic.com/files/misc/testing/waterwarptest_DirectFitz_1280x960_noDownscale.jpg 

on my gtx 970 

Just kind of a note, anything that MH wants to do will end up being added to the engine when new builds happen again.

@gunter - if I would have known about the fullbright pixels + alpha, I could have coded a temp workaround.

Spring will be here before you know it. Time flies. 

@Baker: twas reported above in #977 and verified by you in #978 ;)

I might have mentioned it again, but I was waiting to see if it would be resolved along with other transparency issues that were being worked on.

It's not a big deal in any case.


I would request that you make the most recent zip package available on the site at quakeone.com/markv since that's where I always send people to download it. The link here will quickly get lost in the posts on this page.... I know it's "beta" but it's still the best version so far, containing numerous fixes.... I also like having all the platform versions in one zip file. 

Ok, I see you did link to here at the top of the page on Quakeone.com/markv ... though the link doesn't take me directly to the post to download it. A direct link to the zip file would be convenient. 

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.