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 

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.