I have a machine that I think now has all the updates for Windows 10.

Probably next week I'm going to see if I can experience any Windows 10 issues and see if I can locate a list of behavior changes for the "Spring Update".

Windows 10 updates are like a jar of random monkeys. Microsoft used to be good at compatibility and consistency. 

Well, Win7 has done me good for like 7 years so.

https://i.imgur.com/QOz79l2.png 

Can you confirm the proper settings to play Mark V with a 144Mhz monitor?

My current config:

host_maxfps 144
vid_refresh 0

QS runs smooth as silk. It's clearly not working in Mark V 1099 and seems a bit stutter-y.

And yes I know 144 breaks physics. I just prefer playing this way. One thing to note: I use the same directory for QS and Mark V and switch between them often. Could it be a cvar I am missing? 

I don't have 144 hz monitor, so beyond:

* vid_vsync 0 + host_maxfps 288 (yes 288, not 144 for 144Hz) ... might get better results ..

Back when I did have a display with a higher refresh rate available, I don't recall it behaving any differently.

Does this alternate version of Mark V do 144 hz smoothly? SDL alt build. There may be something SDL is doing to smooth things, but this falls into the "hard to code for scenario one cannot test".

/Note to self: See if can locate a 144hz display. 

Also might need to manually set the refresh rate in Nvidia Control Panel to 144 when running Mark V or play with some settings there.

Mark V doesn't request a refresh rate.

(Because when Mark V first came out, it looked like 60 Hz was going to all displays, there weren't 144 Hz monitors and the only thing that supported changing refresh rates were CRTs and those were already dinosaurs.) 

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 ...