Video (almost) direct from the iPhone
Video of your game is kinda of a must have promotional tool but unfortunately there is no simple, sensible way to capture video from the iPhone. The earlier videos I posted where taken on a digital camera - but the quality just isn't there, even with a tripod and I don't fancy forking out for a flashy camera just to do that. Another alternative is to run it in the simulator and use software which will capture video from the Mac screen, trouble is with a game like Alien Swing that uses a lot of accelerometer control that doesn't quite work either. Still, making video can't be that hard, can it?
So I saddled up with OpenCV, and started capturing the screen with glReadPixels. Hmm... there's two problems here. The first is that the iPhone port of OpenCV doesn't include the video codecs needed. Bah, problematic, but not that critical - I can capture the screen, write it to the iPhone's flash memory and then knock up a command line tool on the mac to convert from this raw data into a sensible video format. Which leaves problem number 2: it's slow. Really, painfully slow. glReadPixels will capture the screen just fine but it knocks the frame rate down to an unplayably slow speed.
The solution: delta compression. We're fortunate in that most of the time most of the screen is unchanging in Alien Swing, this means I only need to capture and store the changes from the last recorded frame and save them off - a process known in the trade as delta compression. So, after a fair bit of effort I have video recorded from the iPhone device with the game running at 60fps (except during screen transitions and when it saves the captured data off). As you can see from the video below, it's not quite there yet - I've a few glitches to iron out - but the video should give you a decent impression of how the game plays.
About Us
Our Games
Site Options
Archives
- April 2010 (1)
- March 2010 (1)
- February 2010 (3)
- January 2010 (3)
- December 2009 (3)
- November 2009 (10)
Categories
- Art (1)
- Coding (4)
- game design (2)
- Games (5)
- General (10)
Recent Comments
- Mr Jack on Video (almost) direct from the iPhone
- Warren on Video (almost) direct from the iPhone
- Mr Jack on Video (almost) direct from the iPhone
- Warren on Video (almost) direct from the iPhone
- Mr Jack on Video (almost) direct from the iPhone
Twittering away
- Getting into In App Purchase, with a little online help: http://bit.ly/16t24n
- @StrawdogStudios marvellous game #SpaceArk is finally released on #XBLA today! http://bit.ly/b9lbJ0 (I did a bit of it) It really is good!
- Kwigbo has stuck the source to Artifice up under a creative common license, see here: http://bit.ly/boInED
February 3rd, 2010 - 18:56
Is there another form of compression given that you control everything? Instead of recording the video record the user input, replay in the simulator with the recorded user input and record your video there? (All presuming there is no unrecordable randomness.)
Well done on getting the game finished, it looks fun.
February 3rd, 2010 - 19:21
Aye, I could record the input and then replay. I use a Mersenne Twister for all the random stuff so I could seed it and repeat all the random elements. I did think about doing that, but I figured there’d be as much work recording and replaying reliably as there would be getting video recording working. I’m not so convinced of that now, but from here fixing up the last few glitches should be a lot less effort than starting again with a new approach.
Thank you. I’m really very pleased with it.
February 4th, 2010 - 11:43
Heh, as it turns out 90% of the glitches were because I was calling the capture code in the wrong place and thus it was capturing for the frame before the one I’d calculated the delta for.
June 16th, 2010 - 17:51
Nice idea. I’m faced with a similar problem in my current app im developing and I thought of the delta compression prior to reading this but I wasn’t too sure how I’d go abouts making that file. I used glReadPixels in a previous app just for one screen shot but if you’re calculating delta pixels is that the function that is still used? You still have to call it, but you’re just saving less data from frame to frame (keyframe (more) -> transitional frame (less))
June 16th, 2010 - 18:03
I work out the deltas from the objects I’m updating. When I move a renderable object, it hands the video capture a rectangle containing the area that it will change. The video capture code combines it with existing regions in a sensible fashion so that it isn’t storing multiple overlapping rectangle.
Then on the capture frame, I call glReadPixels only on those rectangles that I know have changed. Because Alien Swing has a fixed background this works nicely.
June 17th, 2010 - 00:58
Thanks for the reply. Yeah that makes sense. I’ll give that a shot in my code. One last question, did you make your own video file from a scratch binary or using the openCV libraries and offload it FTPing into your iphone?
June 17th, 2010 - 13:05
I’m not quite sure what you mean. I wrote the file to the application data area of the iPhone, extracted it using the Organiser in XCode and then used a little .exe I wrote on the mac using OpenCV to convert to video. Finally, I used iMovie to cut the video together into the final product.
June 18th, 2010 - 15:53
ohh so you couldnt get the video to encode directly on the iphone?
June 18th, 2010 - 16:01
I probably could have done, but the OpenCV port for the iPhone doesn’t support video creation, I couldn’t find a decent library to use and I certainly didn’t want to get into writing my own.
Since it was only for my own use, using an offline tool seemed like a decent compromise.