Fake screen resolutions in kkapture
(Disclaimer: This posting is likely of no interest to people outside of the demoscene :)
The small tool kkapture by ryg of Farbrausch is the only sane way to get a video dump of demos, intros and similar stuff. By grabbing all video and audio output directly from their respective APIs (OpenGL/Direct3D and WinMM/DirectSound) and simulating a fixed time base for the client application, it produces perfect-quality smooth video files suitable for Blu-ray Discs, for example. kkapture doesn’t alter the demos in any other way, though – in particular, the screen setup code from the demos is left untouched, with the result that it’s not possible to kkapture most demos in resolutions higher than the display currently attached to the computer. I did a little modification to kkapture’s code that changes this and allows things like 8-megapixel kkaptures.
But why is high-resolution kkapturing a problem anyway? The first and foremost reason is that modern demos have a resolution selector that lets the user choose from the resolutions supported by the graphics chip and monitor, as reported by Windows’
EnumDisplaySettings API. For obvious reasons, a mode like 1920×1080 is missing from the list if a 1600×1200 display is connected.
But since kkapture is already in the business of hijacking API calls for its audio/video dumping and synchronization functionality anyway, altering the output of
EnumDisplaySettings isn’t a big deal either. So that’s what I did: I added code (and a UI) for appending one additional mode to the list returned by that API and voilà, that mode appears just nicely in most demos.
However, some additional bases had to be covered to make demos actually run in this mode: First, fullscreen mode isn’t possible, because the demo would then request a display mode the display driver doesn’t know of. For OpenGL demos, I circumvent this by neutering the
ChangeDisplaySettings API call, which means that the demo runs in a borderless window instead of fullscreen. In Direct3D, things are a bit different though. Since I don’t know enough about that API, I did not implement a similar hack, meaning that Direct3D fullscreen mode does not work with custom resolutions, period. But that’s usually not a big deal, because most demos offer an option to run in windowed mode anyway. The modified kkapture version also makes sure that the demo can actually create a window that is larger than the screen. (Normally, Windows limits the client area of application windows to the screen size; this is worked around by intercepting
DefWindowProc and making sure that
WM_GETMINMAXINFO returns sufficiently high values for
Here’s a modified version of kkapture:
kkapture_mod.zip (185k) (obsolete, see update below)
It has a new option to fake an additional screen resolution. When using it, make sure that you run the demo in windowed mode, otherwise weirdness may ensue.
Included in the archive is a
.diff file showing the changes relative to the current (as of 2011-09-27) Git version of kkapture. In addition to the fake video mode changes, it contains two minor fixes to make kkapture compile on Visual C++ Express 2010, but these shouldn’t break stuff for other VS versions either.
Update [2012-08-21]: The feature discussed in this article has now been integrated into the upstream version of kkapture, so please get a current binary (or sources) directly from the official kkapture page.
As for Debris, Fiver2 did quite a bit of work to make sure the textures looked good even at very high resolutions (and of course there’s real geometry for all the windows, they’re not just textures). I think it paid off :) – you have to go beyond 4k to get widespread pixelization/blurring. (Though some of the crumbling houses are hardcoded to use a single 512×512 texture for each side, which I now regret)
Good work, I’m sure I’ll have use for this modified kkapture one day. I’ll keep it in mind!
Thanks so much for this. Exactly what i was needing!!
Btw do you know if there is a way to capture bitmaps with an alpha channel?
pond: Currently, kkapture uses 24-bit RGB internally, for two reasons, I guess: First, compatibility. There seem to be many codecs that accept RGB, but not RGBA as input. Second, most of the codecs that do support RGBA don’t care about alpha either and simply discard that channel. Fortunately, HuffYUV is a notable exception, so RGBA kkapturing is actually feasible, given the following two code modifications:
1. Patch kkapture to use BGRA32 instead of BGR24 as it’s internal color format (and accept that this might break it for some codecs – or better yet, make it a run-time option).
2. Patch HuffYUV to make it not drop the alpha channel in applications other than After Effects.
hey KeyJ, thanks for the super quick reply! ive been camping so im a bit late…
do you think it would be very difficult for a non programmer like myself to patch? the only codec i use is the .bmp writer. if i could capture 32bit bitmaps i would be so happy! im grateful for any help you can give me
just to give you a bit more info – im using kkapture to capture .bmp’s from “programs” i make using ZGameEditor(i think that is the developer, Ville, who posted further up and who pointed me to here).
its a really great open source game engine, kinda minimalistic with a focus on procedural creation – i dont actually make games just visuals and it is my first step into this kind of thing so I am pretty newbie.
i take the bmp’s into gimp and it would open up a lot more opportunities if i could capture on a transparent background
pond: If it is difficult for a non-programmer to patch in 32-bit support? Hell yes! kkapture’s code is by no means overcomplicated, but without some knowledge of C/C++, the varios graphics APIs kkapture intercepts, the file formats kkapture generates and their APIs, you won’t be able to do much with the code.
oh well, i can only hope some genius coder is really bored one day and finds this