In the future, I may try to roll DX9 detection/installation into the installer form of the engine distribution.

There will of course always be the plain zips of the engine .exes. 

Report on Mark V Windows 10 delayed launch (and exit)

Mark V 1099r4 delay of 3-6 seconds launching and exit.

mark_v_sdl_gl_gcc - no delay
mark_v_winquake - no dleay
mark_v_winquake_gl - no delay

quakespasm .93.1 win64 - short delay launching and exiting (1-2 seconds)
quakespasm-spiked-win64 - short delay launching and exiting (1-2 seconds)

Mark V 1099r4 has the longest pause of all exes. 

So DirectX Mark V is 3-6 seconds slower starting/exiting. Quakespasm is 1-2 seconds slower starting/exiting.

But Mark V WinQuake, SDL and OpenGL are unaffected.

Trying to unravel that ...

It is possible that specifying a refresh rate on startup slows things down. Quakespasm does this. DirectX Mark V specifies a refresh rate that is the desktop default when requesting fullscreen mode. The Mark V WinQuake/SDL/OpenGL doesn't touch refresh rate.

If I am right ...

Does the following have a difference in start up times ...

a) c:/quake/mark_v.exe -window -width 800 - height 600 // DirectX
b) c:/quake/mark_v.exe -current // DirectX

If it relates to the refresh rate, according to the code it looks like in windowed mode that Mark V DirectX does not set a refresh rate, but for fullscreen mode it does.

/A guess. If this thought turns out not to lead anywhere and it may not, I have a couple of other thoughts but this best matches your test results ...

Let me know ... 

If a 6 second delay is a problem, my engine is fucked.

But yeah, it's always nice to eliminate unnecessary delays. 

A delay at startup does sound like it's changing the display mode for sure; that would certainly do it.

Some info on command-line params used and resolutions of the PCs being compared would help a little more here. 

@baker I need to try this in windowed mode too. But I'll try what you posted above. Typically I stick to fullscreen.

One other thing that might help. Much of the time I am editing and using Necros' GUI to launch ericw's tools and in turn, MV. The tools compile quickly as expected, then there's the delay in launching MV. Then I review the compiled map. Now for whatever reason after I quit MV the cmd windows (which has been running in the bg as usual) stays up for about 3-4 seconds before closing.

I am 99% sure the delay in launching MV happens if I click a shortcut on the desktop without running any compilation so maybe unrelated?

@mh

Just remember this is Windows 10 now. My older machine is Win7 and had zero issues on start up and shut down with the same monitor and a very similar video card and same MV version. Also the same command line etc.

1920x1080 144Hz refresh forced by nvidia cp and that's my desktop res and refresh as well so I don't think it's mode switching.

I need to confirm but I'm pretty sure the delay happened before I set the refresh in nvidia to 144Hz

parms are +developer 1 and +gl_clear 1 +load map <map I am editing> (those were the same on other systems) 

It does seem to take a while to load for me too. QS is pretty instant 

Much of the time I am editing and using Necros' GUI to launch ericw's tools and in turn, MV.

Windows programs inherits the CPU affinity and the process priority of the process that launches them. If the launcher is e.g. a single-threaded 32-bit program running at low priority, maybe Mark V needs some extra time to adjust its process' properties. Just a guess. 

Home and testing this now. We're getting somewhere.

Does the following have a difference in start up times ...

a) c:/quake/mark_v.exe -window -width 800 - height 600 // DirectX
b) c:/quake/mark_v.exe -current // DirectX

No delay on the windowed setting above! Fires right up. Also I have QS and QSS in the same forectory of MarkV so they share config.cfg. I'm noticing if I switch between those two the delay in launching and closing them goes away. If I launch MV then QS or QSS afterward the delay on those two is back. Albiet shorter as I said above. 

Can you confirm there is never a delay for windowed mode?

If so, that would be convincing enough evidence to make a test "fix" for DX9 fullscreen mode.

/Probably throwing in a pq_moveup bug-fix that PoorChop spotted. 

@dumptruck, fifth + anyone else who experiences a delay on DX9 Mark V startup:

Download: DX9 Mark V - July 11 potential slow startup fix

@dumptruck -- let me know! 

So this July 11 version no change.

Made 2 shortcuts on my desktop to this new exe.

Windowed mode launched 5 times in a row with almost no delay.

Using fullscreen (-current) re-introduced the delay.

I launched this 5 times as well - all the same. The I switched between the two shortcuts twice. Same results.

I tried this new exe on my older Win7 machine and it doesn't have the issue. Launches full screen with only a tiny delay. 

As I said, that is almost certainly a display mode change. Probably 2, switching away from your desktop mode then switching to whatever your selected mode is.

Check your console output log and you should see evidence of it. A bunch of vid_describemodes and vid_describecurrentmode commands can also help.

Yes. I'm aware of the fact that it happens on 10 vs 7, but the fact that it doesn't happen in windowed modes is additional evidence. 

Great! You might also check and see if the fix eliminates the need to set the refresh Hz in the Nvidia control panel for your 144hz display.

It may resolve that, then again it may not. 

/I think dumptruck has easily earned the June and July "Gunter Award For High Quality Beta Testing".

Nothing is less fun with engine coding than issues that require setups not easily available.

Thanks for the high quality beta testing that identified the source of this issue! 

Thanks I am no Gunter tho.

Did you misunderstand though? This did new release not fix the issue. :( 

"Full external texture support, DP naming convention."

Does Mark V use special effect textures as well? Gloss, normals etc? And what about shaders?

Just curious. 

I see you have a HD pack using qrp textures, I can derive the answer from that. Apologies 

@dumptruck -- my bad. I quickly scanned the post and only saw the "no delay" and "with only a tiny delay". Missed the part saying the problem still exists for fullscreen. Sorry ... guilty as charged!

I know I vastly prefer the DX9. Maybe mh will come up with some thoughts at some point. The inner workings of DX9 isn't in my knowledge set.

Odd that the OpenGL variants like the WinQuake-GL (WinQuake rendered through Open GL) and the SDL (which is also OpenGL) have no delay.

@damage - Just vanilla replacement texture support like ezQuake, JoeQuake, Qrack.

Mark V supports texture replacement from HUD to Quake models to conback and menu graphics. 

thingy tho?

ps. sometimes i get the fps locking at 60 

If sounds like you have an app running in the background that is forcing video sync.

All you can do is close the other app.

I've seen it happen before, but I can't remember what it was for me (Netflix?). 

As I've now said twice, it's a display mode change. Probably two. Seen it once, seen it a million times. I don't understand why dumptruck is being resistant to helping diagnose this further, though.

Traditionally Quake engines only track width, height and bpp when matching display modes. Some engines add refresh rate. A real display mode contains other values, however, and it's possible for two or more modes to exist which are the same so far as these traditional values are concerned but which are actually otherwise different.

Don't be surprised if Windows 10 adds additional modes that aren't in 7. It's a higher version of the driver model with extra capabilities.

What's happening is that dumptruck is running with -current but the engine is not starting in the current mode. It's starting in some other mode, which involves a display mode change, then switching to the current mode which involves another.

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

The other engines have a shorter delay at both startup and shutdown because they're doing a single mode change at each.

There's no delay running -windowed because it doesn't do a mode change at all.

In an ideal world that first mode would be a windowed one and all of this would go away - instant startups would be back. But when I tried to do this years ago I got HUGE pushback from the community. Yayy community.

Anyway, I asked dumptruck to check his console debug log which would tell us which mode it was starting in first, which could have been useful information. But once more he's being resistant to helping us to help him, so I guess that's where it's gonna end, unless he comes round.

@dumptruck - just to be clear.

I am NOT saying "you silly person, ha ha ha",

I AM saying "it's an engine bug. Help us to help you. Please" 

I'm not sure why you're bagging on the one guy who is downloading extra builds and running all sorts of tests on request. If he's overlooked something you asked him to do then you could make that clear. 

I've previously told him twice that it was a display mode change. He responded the first time to insist it wasn't, he ignored the second. I've previously asked for his console log and the output of some vid_describe commands. He ignored that too. So obviously I'm the bad guy here. Yayy Community. Again. 

If sounds like you have an app running in the background that is forcing video sync.

yep, It frequently happens when i run the online widz etc

but
sometimes it happens just for no reason , switching to desktop and back to the game's solving the issue