How to Record High Quality Video of Your Game using a Slow Computer
Do you see issues with this article? Let us know.
I wanted to make a game play trailer for my original arcade puzzle game Futile Tiles (http://www.futiletiles.com). The game is very fast and I needed to achieve high framerate and quality for the video, which is challenging using a slow computer. Low recording frame rate can also distract controlling the game actions.
This article teaches recording game play videos with maximum resolution and framerate. The solutions presented are quite easy to code, but not very obvious at first thought.
Comments
September 08, 2014 04:52 PM
Programmer time is expensive. Why would you ever want to spend programmer time developing a solution to a problem which has already been solved dozens of times with existing software? Got a slow computer? Get a faster one. Most game developers have/should have great hardware. Hardware doesn't cost much these days and over the course of time, it saves hours and hours of time and prevents you from having to use work-around solutions like this one. The business case is a solid pitch.
Ignoring all of that, what about grabbing the video stream directly off of the video card? I know that the latest video card drivers from nVidia currently support streaming video directly via "ShadowPlay" (no additional programming required).
September 08, 2014 05:07 PM
As the previous poster mentioned, just use Shadowplay if your hardware supports it. But as the title mentions "slow computer" it might be better to use a capture card such as BlackMagic Intensity. Probably best is to use another computer/laptop that has this card and forward the video output to that card in the other computer. That way there is basically 0 overhead and your local harddisk also doesn't need to store the video data.
Such capture cards/equipment are pretty cheap (around 100 euro I think).
I guess if you are serious about making a game you should be prepared to invest some money into it, for example to make good marketing material.
September 08, 2014 05:25 PM
*clears throat*
So if we do the math...
(Avg program worth per hour 15.00-50.00) So lets use the min a programmer makes to do the math...
8-15hrs (2 days of about 8 hours a day) = Est. 150-250 dollars just to write something your going to use no more then a week.
If you ask me, you may as well buy one of those game recorders those Chinese manufacturing companies are barfing out. and use your time to make a good game. Basically, "if you need to break rules to get to your goal, then maybe your not doing it right."
Cant afford one a game recorder? Then maybe your should be in a job that utilizes your skills with higher pay.
September 08, 2014 10:56 PM
Why not just record the sound as-is and then add it to the video? Recording the sound from the computer takes little processing power and no additional hardware (set the source in the recorder to "internal mix" rather than "microphone").
Also, if you've finished a game and want to make a trailer for it, take this as an excuse for yourself to get a decent nVidia card with ShadowPlay support.
September 09, 2014 09:54 AM
Contrary to popular opinion i think this is a good idea.
I would make this into a full fledged replay system though. Add the Option to save images a 16000x9000 resolution at 1000fps maybe. If you are already planning to incorporate a replay system and a HQ Screenshot Option the saving oft the frames shouldnt be that mich extra work anyway.
September 09, 2014 11:16 AM
In every private project I want to have undo, redo, replay anyway. Programming a "redo last 4 minutes without dropping frames" should be easy. Sound capture may be a bit special. I do not know about current APIs but I would guess one can capture one frame worth of sound and then pause the recording should be easy. And slow hardware could mean: I want to set all options to extreme, 4k res, 5 channel audio so that it still looks up to date in 2 years.
September 10, 2014 12:17 PM
The better way to do replay is to record either player input and random state or to record game events. This way you can also re-trigger sounds and every other event in the game. Because you're doing it via events this is also good for automated testing as it can help ensure that the game systems are behaving correctly.
Use libavcodec/ffmpeg/etc. instead of dumping pngs and you can have your game record proper video with full sound, too.
Use libavcodec/ffmpeg/etc. instead of dumping pngs and you can have your game record proper video with full sound, too.
September 10, 2014 04:44 PM
There are other advantages of recording game state.
First of all, you can rerender everything higher quality (increasing render time greatly), secondly you can also replay game state captured on other systems.
So it's very useful for finding problems, and it *also* can be used to record gameplay.
September 12, 2014 03:28 PM
as SeanMiddleditch said, your solution to B is a bit flawed, simply record your inputs, then replay those inputs on the correct frame(make sure you use the same random seed as well.) simply turn on your frame recorder at that point, and let it run.
September 13, 2014 10:23 PM
Jarmo's solution isn't flawed; it's just based on different trade offs.
Recording state instead of input does have advantages. For one, it's resilient to minor changes in gameplay behavior. e.g, if you just record input but then a designer tweaks the player movement speed to be a meter/second faster then replaying the recorded input will produce a different result and likely a broken replay. Recording the states of the objects will ignore that kind of change.
You can still get input-recording to be resilient (also record pertinent object configuration data; keep two copies of the data; etc.) but it's much harder and more fragile.
Ultimately it comes down to what you want to do with replays. If the in-engine replay data is meant to be short-lived because your long-term replay data is a movie, input recording is IMO superior. If this is a replay system that you expect to support in-game playback a long time after the recording, a more stateful approach makes sense.
One way to make state-based recording work better would be to ensure that you can also record events and replay any of their effects that does not modify object state. e.g., the PlaySound event. This way you get the robustness of state-based replays and all the information necessary to generate sounds, VFX, and so on.
I don't believe that there's a good reason to need that kind of stability, though. For long-term replay storage, upload a movie to Twitch or the like. If you then only need short-term use of in-engine replays you can use input recording and get the other advantages it offers like its use for system tests and bug reports.
Recording state instead of input does have advantages. For one, it's resilient to minor changes in gameplay behavior. e.g, if you just record input but then a designer tweaks the player movement speed to be a meter/second faster then replaying the recorded input will produce a different result and likely a broken replay. Recording the states of the objects will ignore that kind of change.
You can still get input-recording to be resilient (also record pertinent object configuration data; keep two copies of the data; etc.) but it's much harder and more fragile.
Ultimately it comes down to what you want to do with replays. If the in-engine replay data is meant to be short-lived because your long-term replay data is a movie, input recording is IMO superior. If this is a replay system that you expect to support in-game playback a long time after the recording, a more stateful approach makes sense.
One way to make state-based recording work better would be to ensure that you can also record events and replay any of their effects that does not modify object state. e.g., the PlaySound event. This way you get the robustness of state-based replays and all the information necessary to generate sounds, VFX, and so on.
I don't believe that there's a good reason to need that kind of stability, though. For long-term replay storage, upload a movie to Twitch or the like. If you then only need short-term use of in-engine replays you can use input recording and get the other advantages it offers like its use for system tests and bug reports.
September 14, 2014 12:15 AM
Programmer time is expensive. Why would you ever want to spend programmer time developing a solution to a problem which has already been solved dozens of times with existing software? Got a slow computer? Get a faster one. Most game developers have/should have great hardware. Hardware doesn't cost much these days and over the course of time, it saves hours and hours of time and prevents you from having to use work-around solutions like this one. The business case is a solid pitch.
Ignoring all of that, what about grabbing the video stream directly off of the video card? I know that the latest video card drivers from nVidia currently support streaming video directly via "ShadowPlay" (no additional programming required).
I heard ShadowPlay has some problem recording OpenGL apps
September 17, 2014 05:27 PM
One solution I used was to record without video compression. You need quite some free HDD space, but takes a lot of load off your CPU
October 26, 2014 05:40 PM
Man, recording with a slow computer is the worst, but you nailed some good tricks here. I’ve also found that adjusting resolution and bitrate helps a ton. Oh, and if you’re doing anything GPU-related, make sure you dont have a bottleneck, if so www.mygpuprice.com is your friend!
September 27, 2024 03:01 PM
I wanted to make a game play trailer for my original arcade puzzle game Futile Tiles (http://www.futiletiles.com). The game is very fast and I needed to achieve high framerate and quality for the video, which is challenging using a slow computer. Low recording frame rate can also distract controlling the game actions.
Advertisement
Recommended Tutorials
Advertisement
Other Tutorials by Indium Indeed
Indium Indeed has not posted any other tutorials. Encourage them to write more!
Advertisement
It does sound like a lot of trouble where two better solution arise:
- Acquire the proper hardware (computer/video card)
or
- External capture (using a webcam for example)
I'm trying to find a scenario where the suggested solutions would be more efficient and simply can't...
(If you could enlighten me, I'd be able to peer review this...)