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. 

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?