The Direct3D method doesn't need to be the same as the Open GL.

I use gamma and contrast console variables.

If vid_hardwaregamma is 1, uses the Windows screen brightness that affects entire display.

If vid_hardwaregamma is 0, Mark V reuploads the textures with the current gamma setting and then at end of frame renders a contrast polygon over the full-screen. Contrast slider adjusts in realtime, but gamma can be only be manipulated via "txgamma" console command because can be a little slow. Open GL/Direct3D8

In the theoretical Direct3D 9 case, at the end of frame vid_hardwaregamma 0 would instead call d3d9_mh VID_Gamma_Contrast (vid_gamma.value, vid_contrast.value) and it would apply both the gamma and contrast to the buffer before swap.

/No obligation, I'm explaining my concept of how such a thing would work. 

One last thing before I try to wrap up func_illusionary mirrors for pulsar ...

I would suspect that the DX9 would be the main executable for Mark V on Windows. It was only the few missing functions like stencil and CopyTexSubImage2D that caused me to need OpenGL, because I had plans for those.

Add: One more missing feature ... glLineWidth, Mark V does draw lines occasionally. Like the others, it isn't a big deal. 

Direct3D doesn't support variable width lines: http://stackoverflow.com/questions/2280077/direct3d-line-thickness

The thing here is that line width is actually not hardware-accelerated, even in GL, so D3D doesn't offer it at all. 

qmb_particles_quakec_count_30 0

This seems to work.

Maybe the thinking was, "if there are 30 or more particles, it must be an explosion," or maybe it also has to do with how my splash particles are spreading out in different directions from a center point, and that kind of looks like an explosion....

But I don't know where something like that happens in standard Quake, where it isn't already covered by a QMB effect. 

That's the new default value. Now QMB largely behaves in a predictable and non-hacky manner that is friendly to use in QuakeC. About the only exception is don't use colors 73 or 225 unless you want blood effect.

By the way, in investigating c0burn's sprite issue, solved your chase camera previous movetype_none issue. I was never able to find the issue because it was never a movetype issue but an nearly invisible typo in the engine setmodel that only affected sprites that never move.

@mh -- I'm not surprised. Isn't like there aren't other ways to do about the same thing. 

Hm, is it possible my blue particle splashes are being removed because they are created under the surface of the water? If QMB is interpreting them as explosions, it may be ... changing them.... Oh yeah, like how rocket or grenade explosions are different underwater -- they make bubbles and are perhaps a bit less explody looking.

Except in this case, it may be messing up my water splash effect because it thinks its an explosion. 

Type r_drawworld 0. Will help see what is happening. 

requiring a real eye for detail

I don't know. I just saw a vague comment about windows being awesome, but I didn't notice anything particularly special when I was playing. So I checked in QS.

Thanks for fixing it, and thanks for all your work. 

I can't tell that r_drawworld 0 changes anything at all. 

@mh -- I'm not surprised. Isn't like there aren't other ways to do about the same thing.

It can be emulated by drawing them as regular primitives but to be honest that's a place I don't want to go to. Time spent emulating a feature that's not hardware-accelerated or not in the API is time not spent on essential stuff. 

Ugly DX effect with vid_hardwaregamma 0, the sequel:

Size screen down with -

gl_clear 1 fixes it. 

Hey there, congrats on the 1.0 release. I loved playing through Quake the first time using your WinQuake port. From my research that's easily the best way to play Quake as close as possible to DOSBox on a modern system. Thanks for that!

For some reason, though, the OpenGL port has never worked for me, not with the last beta and not with 1.0. It shows the 3DFX logo and then crashes ("...stopped working."). GLQuake and Quakespasm work, although setting a higher resolution in GLQuake crashes it as well. I suppose the problem is on my end, as I seem to have similar problems (Crash when setting older OpenGL games to higher resolution), but I never figured out a reason.
I'm running Windows 10 on a laptop with an i7-5500U with integrated graphics as well as a GeForce GTX 850M, latest drivers. No difference if I set the driver to use either graphics card (although that function doesn't work properly in many games). Any ideas? 

Never saw anything like that in Mark V. 

it shows the 3DFX

Hmmm. I thought that was like a 1990s thing. Google says that company has been dead since 2002 ... do you have any junky .dlls in your Quake folder, like maybe one named opengl32.dll. You might consider deleting any .dll in your Quake folder with an old date (after backing them up, I guess).

Mark V does not need any DLLs.

Anyway, regardless the DX8 should work for you.

Maybe in a future version, I put some sort of junky old opengl32.dll (Glide?) detector.

Well, for now you can use the DX8 build. Does almost everything. Doesn't use Open GL at all.

Let me know how it turns out. 

I think GLQuake comes with some really crusty/obsolete .dlls that don't belong in a proper Quake folder. That'd be my guess.

One more reason to use MH's upcoming DirectX 9 modification as main Mark V distribution executable. 

Func_illusionary mirrors on their way within an hour or so.

In next update, any func_illusionary mirror must have one 1-mirror texture, in the case of a cube the other surfaces will not be drawn, just the mirror.

This will allow for mirror secrets.

Effectively, they will a brush with a mirror on one side, from the other side they don't exist.

Makes your original test map work.

I'm testing out some other things before I release this. 

http://quakeone.com/markv/1019_mark_v_mirrors_pulsar.zip

A func_illusionary that is a mirror should have one mirror surface, the other 5 will not get rendered.

At this time, shouldn't be sloped up or down.

This test build does both of your test maps fine and a test map I made.

/This is a test build. 

It looks like this works for 6-sided brushed only. It works fine in test map, but in the actual map I have func_illusionary with 8 sides (to fit geometry) for example (one face is mirror, others are skip) and it doesn't render as mirror.

While with classic boxes with one mirror side everything seems to work fine. But it doesn't work with boxes with chamfers. 

while solid mirrors work fine on non-rectagular surfaces, I checked it. 

Could you upload that one so I can examine it? 

Func_illusionary mirrors were very complicated to implement in a thorough way.

I discovers ton of special scenarios I had to adjust for. I kept discovering more issues that caused me to have to re-engineer them.

Any example I didn't consider is useful. 

it works fine in test map with non-rectangular mirror but doesn't work in the actual map. Gotta investigate more. 

I do not know what compile tools will do to such a brush, and there are several different compilers that may handle them differently.

That being said, until something very strange is going on, I should be able to examine see what is happening. 

Upload the one that doesn't work right, it will allow me to make a list of "do" and "don't" for func_illusionary mirrors.

It is also possible what you are trying to do should work (but I failed to anticipate a situation) *or* doesn't work for non-obvious reasons that might not involve the shape. 

func_illusionary mirrors don't work in AD. I guess it has somethinf to do with it's entity state system. You can download AD 1.5, place the test map there and test it in AD.