Looks like I need to experience the problem firsthand and see if I can get the problem.

It is possible something non-obvious is going on.

mh brings up bits per pixels and some other factors.

Mark V always tries to use what it thinks are the desktop "current" parameters with -current (ignoring all config settings), but maybe Windows 10 adds some additional parameters I didn't consider.

@mh - Eventually I'll get to the bottom of what is going on. The main issue to trying to find technical info on what Windows 10 updates changes/impacts has been difficult. 

THE FIRST DISPLAY MODE CHANGE

This is happening inside VID_Local_Vsync_Init where a call is made to sysplat.wglSwapIntervalEXT(0) - under OpenGL this is not a display mode change; under Direct3D it is.

Suggested solution: suppress this test if running under the D3D9 wrapper; you can safely assume that vsync control is always available in D3D9. This will shave 3 seconds off the startup time. 

Got it. I'll give that a try.

Thanks, mh! 

THE SECOND AND THIRD DISPLAY MODE CHANGES

In classic Fitz, at the end of VID_Init there is this block of code:

if (COM_CheckParm("-width") || COM_CheckParm("-height") ||
COM_CheckParm("-bpp") || COM_CheckParm("-window"))
{
vid_locked = true;
}

This needs to have "-current" added to the list of params checked, otherwise the engine will run the configs during startup and trigger two display mode changes (assuming a clean config, could be more). The first of these changes is slow, the second is fast (in my test the first went from fullscreen to windowed, the second just changed the size of a windowed mode).

In MarkV I think the equivalent is the video_override_commandline_params array, which is missing "bpp" from classic Fitz's list.

Fixing this up shaves a further 3 seconds off the startup time, and startup times are now instantaneous with no display mode changes happening. 

I'll examine that as well.

Yeah, bpp is gone (that's a relic from the 1990s when 65536 color mode was a thing). 

As a troubleshooting tip...

In context_t::PreReset I added the following at the start:

Con_Printf ("context_t::PreReset: %f\n", Sys_FloatTime ());

In context_t::PostReset I added the following at the end:

Con_Printf ("context_t::PostReset: %f\n", Sys_FloatTime ());

I was then able to track when display mode changes occurred and cross-reference that with whatever else was going on in the console during startup, as well as time how long each change took. Makes it very quick for hunting down this kind of thing. 

I don't understand why dumptruck is being resistant to helping diagnose this further, though.

I need to read the rest of the thread above but I promise you I am not ignoring this situation. I can only test after work and family stuff kept me busy last night until pretty late.

Honesty, I didn't notice anything in the console and I was definitely paying attention the other night when I DID test.

So my desktop is set to 144. The game is set to 144 there's still a mode change in FS? I don't get that.

What I will ask is that someone let me know what I can look at in Windows to help troubleshoot. I am not stellar with troubleshooting the OS. 

Sorry.

There's no delay when shutting down because it's already in the current mode and so doesn't need to switch back.

There IS a delay when shutting down but not 7 seconds. The game will close but the Mark V icon is still in the Quicklaunch bar and the system is unresponsive until it closes.

I will post console logs with the info mh is targeting as soon as I can. 

You don't need to do anything.

mh solved it. It's all on me now.

I want to wrap up the SnapTile editor (yeah, going with the name mankrip chose -- I can't do better) before doing a Mark V fix.

So give me a few days.

When I get close to completing something, I develop a one-track mind where I want to finish it. 

Thanks. And please no pressure on a timeline. Do your thing, happy to wait for your fine work. :) Excited to see this SnapTile project in action. 

Seems like a lot. Just tested it with latest build.
Windowed mode is instant.

Tried changing my refresh rates and this doesn't change the delay (I have a 144hz monitor).

Closing Mark_V takes 4 full seconds fullscreen and closes instantly when in windowed mode. 

Yeah, we tracked it down.

I owe you an apology for being a dickhead about this. On the other hand, MarkV will get better as a result. 

No worries! Poor Baker though. Coding during the summer. ;) 

I'm only the idiot who wrote the code, Baker's the idiot who has to maintain it! 

High Definition Pack Video With More Realistic Shadows:

Watch Video

1) r_shadows 3
2) r_waterripple 3
3) QMB on, obviously
4) With HD Pack and Transparent Water .Vis/.Lits Pack

For illustration purposes. 

dumptruck_ds: Thanks I am no Gunter tho.

Hey, you're doing extensive testing and detailed reports to help squash obscure bugs AND getting mh miffed, so you're well on your way! 

Cool shadows. Any chance for lit liquids in the future? 

I can't remember if mh wrote a full fledged prototype or not and if the one or two small but important barriers were solved (i.e. detecting lit water and maybe something else).

I think if he did, it would eventually happen. 

I've solved the detection and posted the solution in some thread here or at InsideQC a long time ago.

The other problem was to compile the maps properly, but EricW solved that. 

Wasn't there an issue with the surface warping making it look really bad? 

Not in my engine.

And in hardware-accelerated engines it should be easy to combine warped textures with non-warped lighting through shaders. 

Detection: http://forums.insideqc.com/viewtopic.php?f=12&t=5835

And in hardware-accelerated engines it should be easy to combine warped textures with non-warped lighting through shaders.

This doesn't need shaders; hardware-accelerated Quake already uses two separate sets of texture coords for difuse and lightmap, so just warp the diffuse coords only but don't warp the lightmap coords.

The issue is that whatever way you slice it, it looks bad.

I do understand where the desire to do this comes from. You've built a map, you have a large water surface in it, the surrounding geometry is nicely lit and shadowed, and the fullbright water looks bad. And you're right, the fullbright water does look bad, but lit water actually looks worse.

The two big problems are (1) when the lighting on the water is sufficiently dark you can't see the warp effect at all i it just looks like a big dark spot, and (2) with translucent water enabled the water just disappears.

This is an example of taking a special case and wanting a general case solution for it, but not properly considering how that general case solution may or may not work outside of the original special case.

"Can I have lit water?" seems a reasonable request, but you also need to be thinking about lit laval, lit slime, lit teleports, how it interacts with translucent water, etc. 

I've already considered all of that years ago and Retroquad has individual cvars for each texture type. I usually keep r_portal_lit and r_lava_lit disabled in Retroquad, because the textures I'm using for them doesn't have glowmaps. But the slime texture I'm using does.

Your mistake is to think that you're the only one who thought about all that. No, you're not, you haven't even thought about liquid textures with glowmaps (QRP has them!), and the worst thing is that you're speculating from a purely theoretical standpoint while I'm speaking from experience.

Lit water does look fucking good. The Unreal engine already has lit water since 1998, and nobody ever complained about it because its maps were created with lit water in mind. Lit liquids in Quake is for NEW MAPS ONLY because the maps need a full recompile from the .map sources for this to work and the mapper must deliberately opt-in to enable it in the compiler.

Your issue is that you don't want mappers to have a chance. You don't want them to experiment and learn how to tweak the lighting in their maps to make lit liquids look good. You don't want them to have artistic freedom.

The "it looks bad" argument is not a technical argument, it's merely an uninformed opinion.

You are not a mapper. 

...and the worst thing is that you're speculating from a purely theoretical standpoint while I'm speaking from experience

I am actually also speaking from experience because I have also written this code and have also seen what lit water looks like.

Here's the Quaktastic folder where I uploaded a bunch of screenshots: http://www.quaketastic.com/?dir=files/screen_shots/LITWater

Check the date on them - over a year and a half ago.

Check some examples of exactly what I mean:

http://www.quaketastic.com/files/screen_shots/LITWater/e2m5_litwater.jpg

http://www.quaketastic.com/files/screen_shots/LITWater/e1m5_litwater.jpg

http://www.quaketastic.com/files/screen_shots/LITWater/e1m2_litwater.jpg

Your entire premise is based on the assumption that I don't know what I'm talking about, whereas I actually do. When I say "lit water actually looks worse" you had two options and you instantly reached for the negative one - yayy community. 

I am actually also speaking from experience because I have also written this code

No, you are speaking from MAPPING experience.

I've never made a full map but I often practice mapping to test and learn how new features like this could be used.