parklez
commented
6 years ago - A cvar to "stopsound" every level transition to potentially fix some obnoxious sounds demos can produce during runs.
- A cvar to stop capturing after a queue of demos are over, even though the game loops them. Possibly in combination with the new function that enables >32 demos.
- Perhaps a way to detect and use distro's ffmpeg, probably not a better solution than a custom program.
YaLTeR
[ ] Detecting and skipping broken frames. There are some broken frames in the beginning and end of a demo of the view jumping around. These are especially bad when sampling is used. Sometimes a frame of the main menu is captured in the beginning.
[ ] A way to capture many demos at once. Standard
startdemossupports up to 32 demos which isn't enough in many cases. Combined with broken frame detection it could be used for close to automatic segmented run capturing.[ ] GPU acceleration in windowed mode. Currently the GPU acceleration depends on the game using a FBO and drawing to a texture, which by default only happens in fullscreen. It's possible to force FBO usage in windowed mode but that breaks resizing the window. Possible solutions are either fixing the game's FBO on window resizes, or creating a new FBO to draw into (perhaps even every frame?).
[ ] Some indicator of whether the GPU acceleration is being used. Currently it's not really possible to tell if the GPU acceleration is being used. Adding an indicator could help people figure out if they haven't set something up properly (for instance, haven't installed the GPU-specific OpenCL).
[ ] Downscaling setting. A setting that makes the game render at a higher resolution to ease (and, in some cases, make possible) capturing at resolutions higher than supported by the user's monitor. This one is complicated because an engine restart is needed to change the resolution correctly (as some parts of the client library store it on initialization and then never refresh). Since engine restarts aren't a problem for capturing, this is mainly a usability and convenience question. Preferably the user shouldn't have to interact with the game while it's being downscaled as big resolutions make the console too small to be readable.
[ ] NVidia encoder integration. This would theoretically allow encoding straight out of a GPU texture thus removing a GPU-CPU-GPU roundtrip present when using nvenc via FFmpeg.
[ ] Variable framerate. An option to output variable framerate video, for example to output less frames per second when live capturing lowers the framerate.
[ ] Capturing MP3 sound. MP3 sound uses a different sound system or something, currently it's not being captured (or affected by capturing in any way).
[ ] Encoding in a separate program. Making a separate program that receives frames from libhl-capture and encodes them would result in clearner separation of the code and enable the use of 64-bit FFmpeg. This will both ease up the installation (as some distributions don't provide 32-bit FFmpeg packages) and allow encoding videos of very large resolutions (8K60) which typically require a lot more RAM than the amount available in a 32-bit Half-Life process.
[ ] An automatic graphical launcher. Making a launcher could ease up a major part of the installation process by detecting environment variables and paths required to run Half-Life as well as hl-capture's dependencies. It could fully automate and replace the current installation instructions (editing a shell script).