What I've observed is that the latest Mark V and latest Quakespasm both take a few seconds to start up now -- longer than I remember from before -- and that Mark V Winquake is still fast. 

I don't have issues starting up the engine but I get pretty poor performance. I've had slowdowns in id maps. Meanwhile my FPS doesn't dip like this in other source ports. Mark V WinQuake is all right but my PC has a hard time getting good performance out of regular Mark V. 

More Windows 10 updates weirding things up ...

Anyone else using Windows 10 have issues with the engine?

/Looks like an investigation is in order, but little surprised this didn't arise as an issue back in, say, April or May. 

Chiming in. Audio issues but I don't have access to that particular machine ATM. I thought it was my crappy hardware but then trying 1099 on an older Win7 laptop confirms there's likely an issue with Win10.

I will have access to another Win10 machine in a couple of days. Will report back ASAP. 

Is there a way to autoconcatenate demos? I never can do demos because I spam quicksave/quickload so often.

Am I admitting I play horribly...not really, but I love to save, do something stupidly crazy, probably die or fall to my doom, then quick load. I like to take huge risks, blast into a room, run around and get 50 baddies to follow me, trail vore balls through the lot, etc.

Is there a way to restart recording on the same demo file on quickload? 

Is there an engine with support to record demos direct to video format? 

Mark V has a way to record a demo to avi. Search for capturedemo above.

Also cl_autodemo for automatic demo recording. But I have not played with it. cl_autodemo 1 for host_maxfps 72 and cl_autodemo 2 for framerates above that.

I know there were some very good demo tools designed for protocol 15 that have wonderful features. I need to go and research them tho. I killed those brain cells with beer long ago! They are all old and may still work. Keygrip was the craziest one. Had an editing UI and everything. I tried getting it to work last year without any luck.

There was one great tool that made a highlight reel from deathmatches. It would eliminate everything but the kills and you could adjust the time before and after.

I am SURE there was one that joined demos. Just have to find it. But probably no way would it work with newer protocols. :(

I have the same issue. I Quicksave a lot and when I am reviewing someone's work I have to go back and reload and start a new demo. 

also if you just want a video and don't need an actual demo file, you could use outside software like Fraps or the Windows "Game Bar" 

There is a command line tool called convdemo for protocol 15 at http://web.comhem.se/bjp/ that can concatenate demos (which may not be a lot of help since everyone uses protocol 666), but you could type "sv_protocol 15" in the console before playing and many maps probably still play with that on.

Mark V you can type "capturedemo demo1" in the console, the Mark V page has a codec that works fast and easy listed.

You can also do a .bat that looks like this and Mark V will exit after the capturedemo is completed.

c:/quake/mark_v.exe +capturedemo demo1
c:/quake/mark_v.exe +capturedemo demo2
c:/quake/mark_v.exe +capturedemo demo3

Mark V doesn't have a demo concat built into it.

Like dumptruck said, the "find" command finds about anything. 

Along the lines of what metlslime said, there are video tools that concat videos.

Probably easier to do that ... 

Drat...screen capture sucks though. Slows everything down. 

Quite a number of quake engines support video encoding one way or another. If you're intent on avoiding demos then my advice to you would be to avoid xvid. ffdshow should have an h264 encoder accessed via the x264 fourcc setting, but as that's patented I have no idea what americans should use instead for streamed video.

If you're okay with a demo, then try fte's capturedemo command. Its an offline offscreen demo capture process, so it'll run as fast as your hardware allows (iirc, dp also has some sort of offline capture, but it doesn't support 666 so w/e).

Which reminds me that I really ought to update fte's ffmpeg plugin in order to make use of nvenc etc properly, which should greatly reduce the overheads - if you've got an nvidia gpu (which should also be a way around patent issues). 

The supplied XVID codec on the Mark V has a few advantages that I have not been able to find in another free download:

1. It is rather fast. (WebM is way slower)
2. It doesn't come with adware.
3. It doesn't come with some other junkware.
4. It is easy to install.
5. It is known to work with the Windows video capture library that AVI capture Quake engines use.
6. Doesn't need a registered copy to encode.
7. It is known to work with the engine.
8. H.264 codecs seem to get overwritten by video apps installing their own special H.264 codec.
9. Doesn't do watermarks for unregistered versions.

For instance, I've found H.264 library and I did get it to work nice, but I had to do a lot of cmd.exe commands and might have had to run it as administrator --- too much to explain.

So I have a downloadable codec that is click, click, click to install.

/Anyway, the H.264 ones I found always seemed to have undesirable characteristics or junkware or put watermarks on the videos. And if it did work, the next video app might overwrite it with its own H.264 codec. Or so I recall. I myself would prefer a hassle-free H.264 codec without spyware or unwanted junk. 

I would just want to make normal demos under protocol 666 or 999 without changing my playstyle. :/ 

add "+cl_autodemo 1" to the command line or type it in the console before the map. It should do a demo every time you re-load from a save.

Then use something like Virtual Dub Mod (free) or some other video app to concatenate the videos together.

Another option is something like Bandicam and record the screen while you play. 

That's cool! Because I often refrain of recording demos because of Saving/Loading. 

Lately I've been having an issue with mouse clicks occasionally not registering. I doubt that it's a problem with my mouse because I've tested extensively in a few other source ports and I never had issues there. 

It's worked pretty flawless from my experience? And I even have an old PC(circa 2010 AMD.

You have plenty of options etc, why is this not mentioned? 

Thanks baker, I'll give it a whirl. 

I play some Quake 3-4 times a week. Never experience mouse issues. And haven't seen any issues like posted in the thread.

I'll keep an open mind, though. 

It could be a Windows 10 thing. One of the updates within the past several months broke mouse look in the SDL 1 version of Quakespasm. I've used Mark V quite a bit but I only started noticing this mouse problem within the past week or so. Or maybe my mouse is failing but coincidentally only when using Mark V. 

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.