Don't forget to add Spike's QSS fix for high fps. 

The SDL version had no change.

Typo above I meant vid_vsync 0

Setting "Highest Available" in the nvidia control panel was the ticket. That was the only option available to me in the CP. Thank you.

I am going to try and get 1099r4 tested on my Windows 10 machine tomorrow to check some of the issues mentioned above since the Spring update. 

Setting "Highest Available" in the nvidia control panel was the ticket.

That fixed the issue?

If so, when I do new version around Christmas I could have Mark V have a refresh rate cvar or command line param and just specify the refresh rate on startup.

Thanks for the feedback, very helpful. 

Good idea. A way to implement it would be:

- If recording a demo, store its filename into the savegame;
- When loading a save, reload its corresponding demo;
- Search in the demo for the frame that corresponds to the current frame stored into the savegame;
- Delete all frames stored afterwards, and resume recording. This new recording could use a different filename to indicate that it's a new branch (like "mydemo.dem", "mydemo(1).dem", "mydemo(2).dem", "mydemo(1)(1).dem", etc.). 

Yep that fixed it. Silky smooth now. 

Full color maps were briefly brought up in another thread.

Short Video: Full Color Maps

Map Download: halflife.bsp - 239 kb for anyone to try themselves in Mark V.

Will also work in FTE, DarkPlaces, several other engines. 

Full color what, exactly? Colored lighting + 16/32-bit textures? 

 

hlbsp has licensing issues from its toolchain, and the hull size issues makes it generally unusable for quake anyway.

besides, lit files and (same-size) replacements provide all the same advantages and with well-defined compat fallbacks, and without shamblers ending up half-inside walls, and retains overbrights, just with more files (unfortunately).

if really needed then the -bspxlit arg can be used to embed the lit files, and -notex can be used to force external/replacement textures using the same mechanism hlbsp uses for external textures (so should work in the same engines) including support for q1 or hl miptex from a texture wad. 

How To Make A Video In 45 Seconds Expending No Effort ...

0. Do once: Install XVID codec 11 MB. This isn't about the codec, this is about something that works quickly and doesn't come with ads/spyware.

1. Go to a map.
2. Type record thisdemo
3. Walk around for 30 seconds.
4. Type stop to end demo recording.
5. Type capturedemo thisdemo

Your are done. Where is thisdemo.avi? Type folder and it will be highlighted in Windows Explorer.

6. Optional: Drag and drop it on your YouTube page and upload it.

If you are in 640 x 480 windowed mode when typing capturedemo it will be faster than say fullscreen resolution @ 1400 x 900 because 640 x 480 has far less pixels to encode than 1400 x 900. 

"Anyone else using Windows 10 have issues with the engine? "

Not so much in MarkV; but QArack, and JoeQuake specifically take 10 to 15 seconds to initialize in win 10 for me. Where as both engines take under 5 seconds on my XP and win7 machines. Dunno. opengl 1.x emulation? 

I can confirm that startup on Windows 10 is extremely slow on my new tower. I have an Intel 7820 and 32Gbs of RAM. HD is a pretty decent raid from 10,000 RPM drives. Videocard is a Nivida GTX 780.

In Windows 7 - a much older machine startup is near instantaneous.

No audio issues as I have seen on my laptop thankfully.

Is there any way I can help observe/record the startup issue for you? 

1. Is it just the Direct X version?

2. Or is it also true for the WinQuake version also?

3. What about the SDL alternate build? download

It might help me triangulate in on something. 

I'll test this evening and post results. I probably should have done a proper test.

Also a question about Dx9 files you have linked? How do I determine if I need those? 

Sorry yes I was setting up TB2 and only played around with the DirectX version as well as QS and QSS. I'll copy over the SDL alternate and WinQuake versions this evening. 

> How do I determine if I need those?

Great question!

Mfx said he had the issue and said installing those files solved it, but I'm not seeing a description of the message other than "it didn't start up".

Posts 2106, 2109, 2110 -- "mfx - Thx, that download helped, works now." 

Yeah Mark V needs the DirectX 9 runtime support. I don't remember the error message but IIRC it's fairly obvious if that's why it's failing to start.

If you play other games on your computer there's a good chance you already have this installed. If not, it's harmless to install it. 

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.