Recording game play

[anthony]

Hi,

I'm not sure if this is the correct place to ask the question, but it does say "ask newbie questions" so here goes.

I've seen a few videos online of people recording game play or videos of academic simulations. I was wondering if anyone knows how that's done? Is it something that people code themselves or are the applications that will record video from a window?

Thanks,

Anthony

[Joseph Duchesne]

It's not to difficult to output TGA, BMP or TIFF files every frame but this can slow your app down on an older computer. An easier way to do this is just to use software like snapz pro: http://www.ambrosiasw.com/utilities/snapzprox/ or something like it.

[Zwilnik]

It depends on the quality you need. The easiest method with vaguely ok quality is to take the S-Video output of a Mac into a suitable video camera input or video capture box/card into another Mac. It's not particularly hi-def (actually it's pretty lo-def) but usually the frame rate is watchable. Rather handy for debugging btw ;)

There are capture apps (I think Ambrosia's Snapz records video), but they tend to be more useful for office apps and not so good for recording gameplay.

If you need to do serious gameplay capture for promos etc. then there are some pretty high end capture rigs that syncronise to the video output and capture in hi-def. but They're expensive! (assuming Apple don't build them into iMovie at WWDC today of course)

[Najdorf]

for windows Fraps is pretty awesome

[EdwardT]

iShowU works well:
http://www.shinywhitebox.com/home/home.html

[kordova]

iShowU works well:
http://www.shinywhitebox.com/home/home.html
I second this.

[TomorrowPlusX]

I wrote my own gl-capture recording API -- if what you're interested is in recording the output of your own game/3d app, it will probably work well enough for you.

Here's an example recording: http://zakariya.net/shamyl/etc/ParticleApp.mov

If this is what you need ( e.g, recording the output of your own app ) you can find the source here ( as part of a larger framework ): http://zakariya.net/shamyl/etc/SGF.zip

It's C++, threaded, and requires boost; If that doesn't turn you off ( there's a lot of c++ haters out there ), it should be easy-enough to separate from the rest of the framework, should you want to integrate it.

[AnotherJake]

Hey TomorrowPlusX, that's excellent! It's been a while since I looked through your game framework. I was thinking about writing a movie capture class just a few weeks ago but decided against it because the whole screenshot thing is so slow that I couldn't imagine actually doing a movie! So I have some questions for you:

1) is it actually fast enough to be of any real use (even without compression)?
2) it appears that all of your movie stuff is in the recording group, is this true?
3) you don't mind if I rip off your recording code do you? I'd have to re-write it to exorcize the C++ of course... :sneaky: (I don't hate C++, I just can't/won't work with it.)

[unknown]

this is better than Snapz in my opinion http://www.shinywhitebox.com/home/home.html

[AnotherJake]

this is better than Snapz in my opinion http://www.shinywhitebox.com/home/home.html
Is that like the one EdwardT was talking about?

[TomorrowPlusX]

Hey TomorrowPlusX, that's excellent! It's been a while since I looked through your game framework. I was thinking about writing a movie capture class just a few weeks ago but decided against it because the whole screenshot thing is so slow that I couldn't imagine actually doing a movie! So I have some questions for you:

1) is it actually fast enough to be of any real use (even without compression)?
2) it appears that all of your movie stuff is in the recording group, is this true?
3) you don't mind if I rip off your recording code do you? I'd have to re-write it to exorcize the C++ of course... :sneaky: (I don't hate C++, I just can't/won't work with it.)

It's all yours! Do with it what you will.

Answers:

#1) The performance is good, but not great. IIRC I can capture 800x600 on my MBP at 30fps without stress -- a better programmer than me would be able to make it faster. That being said, compression is done by Qt on a separate thread while grabbing. As a side note, I experimented with direct serialization of the framebuffer to disk, and I was bottlenecked by my MBP's hard drive write speed. The bottleneck now is Qt's compression. I profiled the actual grab of pixels and was able easily to get 60fps in fullscreen (IIRC, again). It's doing something with that data that is trouble.

#2) More or less correct. 99% of it's in there, but there are likely a few helper bits outside. Shouldn't be impossible to extract.

#3) It's your pet peeve. My warning: I'm using boost for smart pointers and threading. I use smart pointers pervasively, so you'll have to take that into consideration. Boost.threads will be easily replaced with pthreads. If I were you, I'd just write a C wrapper to it...

I know people have their reasons to hate C++ :D, but hell, I say use the right language for the job. I use C, C++, ObjC and python all the time.

[AnotherJake]

Awesome! Looks like it's worth the trouble then. I'll probably look closely through the code since I'm curious how you did it anyway. Looking at your screenshot code, your coding style/problem solving is very similar to mine, so I might be able to figure out what you're doing with the movie code. I might just write a wrapper for it though, as per your suggestion, I don't know. I can easily use pthreads so that won't be a problem. Heck my stuff's almost always threaded already anyway, so Cocoa is already in threaded mode (thinking out loud). I might just be able to drop it in. We'll see. It's not high on my priority list at the moment, but movie capturing has been something I've been thinking about. Hopefully I can get to it within a week or two.

Thanks! :D

[TomorrowPlusX]

Hopefully I can get to it within a week or two.
Thanks! :D

Let me know how it goes. If you have any questions, PM me and I'll give you my email so we can discuss.

[Fenris]

We're not worthy! :D

[TomorrowPlusX]

Eh.. BAD NEWS. Perhaps somebody can help me, and do some testing, but it seems that the upgrade to Quicktime 7.2 has broken my recording code.

I'm not certain. All I can tell is this:

1) All my apps using my recording code crash now, and Xcode can't tell me where ( thanks, xcode ).

2) My last provably successful recording was made may 3rd ( the creation date of the demo recording I linked to ).

3) I checked out of SVN the last version of SGF before may 3rd, and it crashes, too.

I guess there is no step four. All I can tell is that it used to work, and now it doesn't. I've spent the last hour and half picking through my svn changelog and can't find anything I've done since may 3rd which even *touched* my recording code. Once I got recording working reliably, I basically left it alone.

I assume this is a quicktime 7.2 issue.

[PowerMacX]

Quicktime seems to be doing additional checks on movie files now:
http://docs.info.apple.com/article.html?artnum=305947

This (supposedly) only applies to Rosetta, but just in case:
http://docs.info.apple.com/article.html?artnum=306043

[AnotherJake]

Well it's been a headache of a morning getting SGF and family up and running, but here's where I'm at with it:

I actually tried installing Boost and it took almost an hour building and installing everything on my Intel Mac Mini to... nowhere! I forgot to sudo for write permissions to usr/local :blush: So the second time around I figured out that I could just build the thread lib by itself, which was a relief, and only took a few minutes for just the thread lib, plus installing all of the Boost headers. Problem is that apparently they changed the naming conventions for Boost 1_34, compared to whatever version you're using (and header install location goes to /usr/local/include/boost-1_34/boost by default too). So I took the closest one, named libboost_thread-mt.a, made a copy and renamed it to libboost_thread.a so the project could find it. Seems to work fine! I probably should have just (re)included the correctly named new lib instead, but whatever...

BTW, For anyone else interested in Boost for use with SGF, you really don't need to actually install Boost if you don't want to, you just need to build the boost thread lib wherever you want, and then make sure you have a copy of the headers somewhere convenient, and be sure to tell SGF projects where to find the headers. All it takes is reading the installation instructions carefully and setting the right options for ./configure

Getting Boost set up was a pain, but moving along to get SGFAppModeTest running:

GLEW has been giving me grief (or so I *think* it is GLEW). I have zero experience with GLEW so I have no idea what I'm doing. What I've had to do so far is comment out any instance of glActiveTexture and glBegin/end blocks using glMultiTexCoord2i in GuassianCombineFilter.cpp. I've been able to replace glActiveTexture where absolutely needed with glActiveTextureARB. But other than that, it works! Woohoo!

One of the first things I noticed is that your glView does not get properly copied to the window's backing store during miniaturization (cmd-m).

Onward to RecordingTest:

Same thing with glActiveTexture in RecordingApp.mm, had to replace it with glActiveTextureARB. But that runs too! Until I pressed the record button that is...

Crash occurred at glGenBuffers on line 147, in QTRecorder::createBuffer EXC_BAD_ACCESS. Cmd-double click and it's a GLEW define again. I don't know what to do about that one, so I guess that's where my testing ends for now. I would assume that is probably not the same cause of your crashing though.

Other things of note:

My version of QT is still 7.1.6 for whatever reason (My system is still 10.4.9 too)

I get a couple of noteworthy warnings from QTEncoder.mm:
--> NewGWorld is deprecated
--> QTEncoder.mm:163: warning: passing negative value 'kQTNativeDefaultPathStyle' for argument 2

[TomorrowPlusX]

Crash occurred at glGenBuffers on line 147, in QTRecorder::createBuffer EXC_BAD_ACCESS. Cmd-double click and it's a GLEW define again. I don't know what to do about that one, so I guess that's where my testing ends for now. I would assume that is probably not the same cause of your crashing though.


Actually, it might be the same thing. I think we all here can remember an occasion when Xcode simply won't tell you where your crash occurred. Can you send me a complete stack trace?


Other things of note:

My version of QT is still 7.1.6 for whatever reason (My system is still 10.4.9 too)


Well, there goes my patented just-blame-apple-for-my-own-damn-mistakes approach :p


I get a couple of noteworthy warnings from QTEncoder.mm:
--> NewGWorld is deprecated
--> QTEncoder.mm:163: warning: passing negative value 'kQTNativeDefaultPathStyle' for argument 2

Unfortuntately, there's nothing I can do about this ( yet ). QTKit does a lot, but it doesn't let you create an empty clip and add frames to it. To do that, you've got to use deprecated code. Well, at least I can blame apple for that!

P.S. GLEW is by and large pretty good. Don't write it off yet. That being said, in my experience, glActiveTexture will crash on the intel 950 ( or whatever it is the mini and macbook use ) whereas glActiveTextureARB works fine. I should have replaced all my calls with the ARB versions, but I was lazy.

If I can fix this, I'll let you know. SGF was really just meant to scratch an itch for me, it's not a game "engine", just an easy way to get a window on the screen and do common stuff. Since I wrote the build I released, I've improved it a bit. Except for crashy recording.

So, please send me the stack trace from Xcode. I need to see the error and the line it occurred on. Since Xcode won't tell me on my mac.

[ThemsAllTook]

Unfortuntately, there's nothing I can do about this ( yet ). QTKit does a lot, but it doesn't let you create an empty clip and add frames to it. To do that, you've got to use deprecated code. Well, at least I can blame apple for that!
If that's the case, how does Apple expect you to create new clips in memory on x86-64, where those deprecated APIs don't exist? :blink:

[PowerMacX]

If that's the case, how does Apple expect you to create new clips in memory on x86-64, where those deprecated APIs don't exist? :blink:

From Apple's Leopard Technology Overview (http://developer.apple.com/leopard/overview/):
QuickTime Improvements

Working with video using QuickTime has long been a strength of Mac OS X. Now, it’s as easy to build video capture into your application as it is to work with pre-recorded video. By using the QTKit Capture API, you can capture video from an iSight, USB (VDC) and FireWire (IIDC) devices, and DV cameras. The API even lets you output to multiple outputs.

Maybe QTKit Capture implements whatever is needed for that? In this page (http://developer.apple.com/wwdc/sessions/handson.html) it says:

QTKit, the premier method for Cocoa developers to access QuickTime, offers significant improvements for Leopard. Come see how to use QTKit for high-definition playback and to programmatically create movie content and capture video.
(click on "416 - Integrating QuickTime Support into Your Application with QTKit")

[AnotherJake]

So, please send me the stack trace from Xcode. I need to see the error and the line it occurred on. Since Xcode won't tell me on my mac.
I sent you a PM for email.

BTW, I'm running these in release mode with debug symbols turned on. I was unable to get the debug mode of the test app to find the boost headers for some strange reason, so I've just been running in release (for now). Maybe that's why it's picking up for me; I've had that happen before with other projects.

Meanwhile, whilst I'm waiting, I've been messing around more with GaussianCombinerFilter and I just don't know enough about it to make it work. I had to replace glMultiTexCoord2f/i with the ARB versions just so it wouldn't crash, but the rendering gets whacky. Things just aren't working in that class on the GMA950. So I simply return at the top of GaussianCombinerFilter::display for now to bypass it.

Does anybody know how to output the stack trace from Xcode? I've never tried, and I can't seem to figure out how to myself. :\

[TomorrowPlusX]

Thanks to AnotherJake, the bug is solved. It has nothing to do with Quicktime 7.2, so I apologize to Apple for impugning the quality of their updates.

For future reference, in case this ever bites anybody: Boost 1.33_1 builds libboost_thread.a, where boost 1.34 builds libboost_thread-mt.a. I was linking against the old one!

[AnotherJake]

Thanks to AnotherJake, the bug is solved...
Hehe, it was pure dumb luck, based upon my laziness, and the fact that I didn't have a prior version of Boost installed. Had I not been so lazy as to rename the 1.34 library to match the old one's name, instead of (re)including the newly named 1.34 lib, as I should have... Well, I can't imagine the pain and suffering TomorrowPlusX would have endured trying to track that one down. Win a few, lose a few I guess...

[TomorrowPlusX]

To serendipity!