Demo Marking

The concept

Back in March 2021 when I joined Quake for Newbies some people were amused by my markDemo chatbind, the purpose of which I will tell you about here. There is a neat piece of software called UDT that allows you to cut QL and Q3 demos into little snippets. It has a feature where if it detects a specified chat message, it can automatically cut a demo from that bit of the game.

The idea is that you have a chatbind with some unique words that the software can recognize. Whenever something cool happens, you press your chatbind key, everyone will see that you have considered the frag or whatever happened interesting.

Creating a chat bind

My chatbind goes something like bind MOUSE5 say "burt, please mArKdEmO", but it would be no good if you would just copy that. You come up with your own chat message, like olmos Marker den frรฆkkert. Then you do a bind like bind x say "message". Everytime you press x now there will be a message in the chat. Just make sure you’re recording a demo and mark your stuff then you’re set for the next step.

Setting up UDT

First, you’ll need to get UberDemoTools. It can be obtained from the official website. You might soon notice this error message that pops up when opening the application.

Error while updating UDT

Update error

To fix it, just go to the Settings and disable the option “Start-up Updates”. Now for the actual demo cutting. First you will go to “Patterns” > “Chat” and create a new chat rule. You can change the parameters but sticking with the preset ones is fine.

Creating a chat rule in UDT

Creating a chat rule

After your pattern is created, you can import some demos into UDT. Of course, you’re not restricted to only use the chat patterns, there are a bunch of other patterns as well that you can mess about with, I just personally am not using those, so feel free to let others know your findings.

Make sure you’re in the “Patterns” > “Chat”or in “Pattern Search” menu. Either drag-and-drop into the sidebar demo list, or use the file option up top to import some.

Cutting the demos

The next step is cutting (or searching). When you click the Cut! button, there will be a window where you can select the offset before and after the mark. You can tweak those for individual frags if it is too short. Default is 10/10, but doing some longer shouldn’t do any harm. After that, UDT will do its thing and put all the cut demos next to the demo they were created from. So if you had a demo foo.dm_91 in a folder, there will be some demos named foo_CUT_CHAT_blah.dm_91 in the folder now.

You can rename those with some scripts if that is your kind of thing, or use an application like Bulk Rename Utility, or alternatively Microsoft Power Toys.

What to do afterwards

When you eventually have all your demos cut, it is time to jump into the game and check them all. Watch each snippet and decide what to keep and what not to. Over time, you can amass a collection of cool frags.

You can use those demos like any other normal demo files, for example, you can render them in Wolfcam, or send them to other people that like to do movies. Or, for Quake 3 demos, you could use my demo rendering script, which might get an article written for it in the future.

Demo Rendering in Quake Live

This guide was originally written a while ago for the folks on the Quake for Newbies discord server. Feel free to join us!

Introduction

My preferred way to convert demos to videos is to use some kind of rendering opposed to just capturing the QL / Wolfcam / Q3 window in OBS.

In quake3e, it is supported to directly pipe the video to the ffmpeg application, which actually compresses the video with your encoder of choice. In most other cases, you will have to create a temporary file and encode that with ffmpeg (or other tools if you want). you can grab ffmpeg here.

Rendering in WolfcamQL

First, grab wolfcam on GitHub (Installation instructions are available in the readme). It is required that you have a copy of Quake Live.

Useful cvars

Set cl_freezeDemoPauseVideoRecording 1 to pause recording of video/screenshots while paused.

cl_aviCodec "huffyuv": The options for cl_aviCodec are uncompressed, huffyuv and mjpeg. I recommend huffyuv as it somewhat reduces temporary file size and doesn’t take much longer to capture in wolfcam. You can use mjpeg if you don’t have much disk space for temporary files, but it will slow down rendering significantly. It could also cause slight jpeg artifacts, although those won’t be so noticeable in the end result.

cl_aviFrameRate 60: Set the desired output video framerate here. The actual command for capturing in wolfcam is /video tga wav name render_temp You can replace render_temp with :demoname, and wolfcam will use the demo name as the capture filename. Or any other name, and the video will be saved to that. The rest of this guide assumes that the output name it is set to render_temp. After capturing, the captured files normally are in %appdata%/Wolfcamql/wolfcam-ql/videos (just paste that into your windows explorer address bar).

Encoding to h264

After capturing in-game, we will encode the .avi files to something more reasonable in size. We will use ffmpeg for that.

For convenience, I recommend creating a batch file to render the video. Navigate to the output folder, then Right-click/New/Text file, and name it render.txt. Open it in the text editor. Now, paste this into the file.

@echo off
ffmpeg -hide_banner -i render_temp.avi -c:v libx264 -crf:v 21 -preset:v medium -tune:v film -c:a aac -b:a 384k  "render_output.mp4"

echo.
echo Rendering finished.
pause 

Then, do Save as, set the Filetype to “all files (*.*)” . I suggest naming it render.bat. Double click the batch file and it should start rendering. When rendering is complete, it will say “Rendering finished.”. After that, you can close that window and look at your output. It should now be ready to be used however you like.

Information for advanced encoding

-preset:v medium sets the “speed” of the encoder. It is a tradeoff between compression strength and rendering speed. Sensible presets are “veryfast”, “faster”, “fast”, “medium”, “slow”, “slower”.

-crf:v 21 sets the visual quality of the video (lower means better). Just try to see what is good enough for you, as a lower value will increase file size.

You can visit trac.ffmpeg.org/wiki/Encode/H.264 for more information on encoding h264. If you want to use a different codec, I also recommend looking at trac.ffmpeg.org.

Building Quake3e in WSL

I recently disabled Hyper-V on my main computer because Windows was having some issues with the network adapters. In Hyper-V were two VMs that I used to build Quake3e (a modern Quake 3 source port) from source for Linux and Windows. As those weren’t operational anymore, I needed a new solution.

I briefly considered just moving the existing VMs to VirtualBox (which didn’t work because of networking issues), and after that, WSL came to mind.

After installing Ubuntu 20.04 it was time to get a build environment going. After setting up the github repo, I installed the packages make gcc libcurl4-openssl-dev mesa-common-dev as per the build instructions. After that, I could already build 64-bit dedicated executables.

Next step was mingw for windows binaries. mingw-w64 took care of that.

Now I needed to create 32-bit linux binaries, because Rocket Arena 3 doesn’t have the gamecode as a qvm and therefore requires the executable to load a native library. That only works when the binary is 32-bit.

One might need some 32-bit binaries for windows too, if they are still running a 32-bit machine. For building those 32-bit binaries I tried several different things and found that installing g++-multilib did the trick.

Here are the make-commands that I came up with (replace the “16” with the number of threads you want to use):

# Linux 64bit
time make -j16 BUILD_CLIENT=0

# Linux 32bit
time make -j16 BUILD_CLIENT=0 ARCH=x86

# Windows 32bit
time make -j16 USE_RENDERER_DLOPEN=0 USE_SDL=0 PLATFORM=mingw64 ARCH=x86

# Windows 64bit
time make -j16 USE_RENDERER_DLOPEN=0 USE_SDL=0 PLATFORM=mingw64

And here are all packages that you need to install:

# Generic requirements
sudo apt install git make gcc libcurl4-openssl-dev mesa-common-dev

# Windows
sudo apt install mingw-w64

# Additional for 32-bit binaries
sudo apt install g++-multilib

# For RUNNING 32-bit binaries on Ubuntu 20.04
sudo dpkg --add-architecture i386 && sudo apt update
sudo apt install libc6:i386 libstdc++6:i386 libncurses5:i386

So that concludes my method of building Quake3e. If this is of any help to you, feel free to let me know.

Update 2023-10-8

After further testing, I was able to conclude that running the 32-bit binaries is possible on a fresh Ubuntu 22.04.3 installation with the instructions provided.

Update 2023-12-31

Who would have thought that using more threads speeds up the compile times quite a bit? I’ve added the appropiate -j16 to the make calls.