Are the sprites bubbles?
Do you have QMB effects enabled?
Do the sprites have replacement textures with alpha transparency? 

Um... we noticed on the FvF server that e5end (from DOPA) does not appear to have properly viss'd transparent water in Mark V, but sometimes it does or used to or something weird. r_novis 1 makes it look transparent, of course.

I just tried it in Quakespasm and in Proquake, and the water looks correctly transparent in both those....

It just doesn't in Mark V.

What's up with that? Something weird about that map? 

@c0burn - Can you provide a way for me to create that scenario, I'll like to check it out.

@dwere - in the jump map where the issue exists, could you type viewpos and post where in the map the issue exists?

@gunter - is this easy to find? 

Next I do an update, I need to make it so any time somoene does a screenshot, it writes the game, mapname and map coordinates in the meta data in the PNG.

I looked at the Jump map, noclipped all around the place and can't find this location in your screenshot, but I'd sure like to check it out and see it.

So if you can post the "viewpos" coordinates I'd like to look at it.



@gunter - Justed loaded up e5end. The autotransparency detection waits a few frames before beginning to check. Something about being located above the water and immediately falling in is tricking it. 

Frankly, I don't even remember myself which window it was.

But it shouldn't matter, because all windows are opaque for me. I deleted my config and autoexec in case I screwed up the settings somehow, but nothing changed. 

@dwere - looks like its just scenario in the engine where entities that are both .alpha and have alpha masking.

I must not have anticipated a scenario where both of those would be going on with the same entity.

Excellent engine test case!

The map author did everything right and the map is very designed. I'll address that one when I resume working the end. 

I just tried it in Quakespasm and in Proquake, and the water looks correctly transparent in both those....
Note that quakespasm defaults to gl_clear 1 so HOMs render as solid grey, and transparent water on maps that are vised for opaque water will render as grey-tinted. There's nothing special in QS about detecting water vis, so it was probably rendering against the grey void. 

Gunter found a automatic water transparency start of map mistake.

Mark V waits a couple of frames before implementing a water transparency check.

In the d5end scenario, Mark V discards the fact it already has seen evidence that the map has transparent water because it doesn't start check for a couple of frames.

I probably have it ignore a flag or reset the water check data after 0.1 seconds, when it shouldn't. 

bubbles again, haha. 

dopa e5end solved.

What's funny about -- Mark V's automatic underwater transparency detection shouldn't ever fail.

But due to an oversight, I wasn't letting it do its job.

In the renderer:
1) Determine surfaces visible
2) -- If surface in your field of view? Continue ..
3) ----- Do automatic transparency check

Well, for dopa end, you spawn and fall into water and are looking straight ahead. Maybe by dumb luck the water comes into view before you hit it.

Corrected version:
1) Determine surfaces visible
3) -Do automatic transparency check
2) -- If surface in your field of view? Continue ..

It was failing in that circumstance because it was checking your view instead of your surroundings. 

Random sparks.

Set qmb_particles_quakec_count_30 0

I do not know the nature of what QMB is trying to have that do, but it appears to view a particle count of 30 as special. So I made it a cvar. I think it may have been intended to relates to the scrag attack, but can't be sure. I may end up defaulting that to 0 in the engine. 

Download at usual location:

http://quakeone.com/markv

Mark V can now be resized on-the-fly in a complete and autosizing way that hasn't quite been done in any other Quake engine, although FTE may have something close. Video/input rewritten from ground up in 2014, but never quite completed until now.

New ...

- Resize window on-the-fly with the mouse (no DX8).
- Issue with window in "Jump" by gotshun resolved (dwere)
- Missing waypoint sprite resolved (c0burn)
- Removed QMB unwanted sparks by QuakeC (gunter)
- Automatic water transparency oversight on e5end.bsp resolved (gunter)

Each of the above bug reports were very awesome. Often hard to spot, extremely rare (gunter, c0burn) or ones requiring a real eye for detail (dwere) often don't get noticed and reported for long periods of time.

Remaining: not in this build, but coming up next -- func_illusionary mirrors fix for pulsar. 

GL_ARB_texture_env_combine is implemented, with the exception of interpolate combine mode and constant color.

I'm a bit wary of default values for many of the combine states: I don't set them, but then neither does the GL spec appear to give them, so I'm interpreting that as meaning that the onus is on the programmer to be explicit.

Fixed a nasty performance-sapping bug with quad particles.

The overall performance increase is looking to be quite significant. Unfortunately I didn't benchmark the D3D8 version, but with 9 it's currently running at almost twice the speed of my initial port.

Speaking of managing expectations, it will - of course - be entirely up to Baker regarding how he wants to integrate this. I can see one of 3 options: (1) do nothing, (2) drop D3D8 and offer only D3D9, or (3) offer both D3D8 and 9. I'm keeping the same interface to the wrapper so (3) should be possible with minimal work, and I suspect that is what Baker would prefer.

Either way I'll probably do an independent release of the modified DirectFitz incorporating the new wrapper anyway. 

Most of these are things I don't care too much about, but for the sake thoroughness ...

1) Multisample. Maybe useful if, say, the HUD or the console were drawn with a non-integer scale like 1.88. Or maybe not. But it's a difference.

2) Resizing window real-time. I don't remember what the main barrier was. Of even if there wasn't one in the DX8 wrapper or if it was just on my side.

3) License. It would be nicer if were GPL 2.1 or later. Or maybe even BSD or MIT license. Doesn't really matter, if I recall seemed like there was 1 thing about GPL 3.0 I didn't like, but I don't recall what it was. It's not really a big deal.

4) Built-in full window gamma/contrast. In Open GL 1.2 ... as Gunter can attest to, the contrast on-the-fly and texture gamma as the "txgamma command" isn't too bad. But since you are using DX9, might as well do it DX9 way. ;-)

5) GL hints? If DX8 doesn't do. I bet it already does.

I always thought it was great that after making very few changes to the DX8 wrapper, including a little bit of abuse to get to it to accept vsync changes (windowed mode only?), that it did not need any special treatment except in the most minor of circumstances. 

Multisample
D3D supports this but last time I looked at it the initialization code was horrible. This is an API difference between GL and D3D: if you ask for an unsupported pixel format in GL, it will degrade gracefully; D3D will just fail. It means video startup can involve a lot of "test every possible combination in a loop until you find one that works", which is fun for nobody.

Resizing Window
Should be possible. I don't think there is a barrier in the API. It does involve mode changes though (when you think about it, a window resize is actually just a mode change).

License
I'm not a fan of the GPL in any incarnation and prefer more permissive licensing if possible. No decision but that should give you an idea of how I'm thinking.

Gamma/contrast
I'd need to review how you're doing it in GL before making any comment.

Hints
D3D, any version, doesn't offer hints. API philosophical difference: in D3D you must explicitly state what you want. The D3D8 wrapper has the fog hint implemented, but no other. Some hints are impossible: e.g. D3D enforces perspective-correct texturing and gives you no control over it. 

I would probably keep the DX8 build as part of the source, but only distribute the DX9. At least for a while, then the DX8 build would likely be removed ... so if it used a compatible interface that would be great.

void VID_Renderer_Set_OpenGL (void)
{
.. eglAlphaFunc = glAlphaFunc;
.. eglBegin = glBegin;

void VID_Renderer_Set_Direct3D (void)
{
.. eglAlphaFunc = d3dmh_glAlphaFunc;
.. eglBegin = d3dmh_glBegin;

(a few oddball fake Windows functions in the mix like ewglMakeCurrent = d3dmh_wglMakeCurrent, etc.)

Note: At one point I did combined Direct3D + Open GL builds. The fake function ChangeDisplaySettings had to be renamed in the wrapper to allow both to co-exist.

I cannot recall but if it doesn't already do so, the ability to completely shutdown the Direct X without restarting would be helpful. With Mark V's video code, shutting down a renderer and switching to another one would not be hard at all.

Would be one less .exe to distribute too. And with Visual Studio /DELAYLOAD, the combo build could run even if in a no Open GL drivers scenario and default to Direct3D. 

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.