.kkapture 0.01 - demo capturing made easy (hopefully)
category: code [glöplog]
Seemingly Gargaj has now made his own separate patch for Antimoney. I have no idea why, but hey: http://scene.org/file.php?file=%2Fparties%2F2000%2Fltp4%2Fin64%2F3s-money-patched.zip&fileinfo
I'm having problems kkapturing Chaos Theory at a high resolution (2560x1600). Running the demo itself at this res is fine, and kkapturing at a lower res works as well.
I really just wanted to pull some screens for wallpaper use, any idea what I should do?
I really just wanted to pull some screens for wallpaper use, any idea what I should do?
Well, I just switched to compressed output via ffdshow and it's working...good enough!
If it's only to take screenshots, FRAPS is probably good enough anyway.
Does anybody know if there is a method to set up resolutions higher than the resolution of the attached screen on Windows 7 x64 + nVidia GTX560? I have a 1600x1200 screen and it is impossible to run any demo in 1920x1080, even if the screen supports it (the aspect ratio is wrong of course, but I don't care) and the resolution is properly set up as a custom resolution in the nVidia Control Center. It still doesn't appear in the list of supported modes in demos, though.
On my old machine (Windows XP + nVidia 8600M) this was possible without any problems. I could even set up (and kkapture at) Quad-Full-HD resolution: The desktop size was 3840x2160, but only a 1280x800-pixel rectangle of it was visible at any time, following the mouse movement. How can I enable this feature on a current machine?
On my old machine (Windows XP + nVidia 8600M) this was possible without any problems. I could even set up (and kkapture at) Quad-Full-HD resolution: The desktop size was 3840x2160, but only a 1280x800-pixel rectangle of it was visible at any time, following the mouse movement. How can I enable this feature on a current machine?
Nevermind, I worked around that problem myself -- by tweaking kkapture so that it makes applications think the desired resolution is supported:
http://keyj.emphy.de/kkapture-fake-screen-res-patch/
Works nice in windowed mode on the few random demos I tried it with, but YMMV. Would be nice if this (or a different implementation of it) would find its way into the official upstream version of kkapture ... ryg? ;)
http://keyj.emphy.de/kkapture-fake-screen-res-patch/
Works nice in windowed mode on the few random demos I tried it with, but YMMV. Would be nice if this (or a different implementation of it) would find its way into the official upstream version of kkapture ... ryg? ;)
KeyJ: With nVidia, there's another solution - NV Control Panel -> Resolutions -> Add Custom Resolution -> Set Timing to "Manual", choose any high resolution (eg. I can do 4096x2048 without problems) and set the back-end resolution to the native resolution of the display. If everything works out, you should get an oversize screen that scrolls.
hooray for really slow-burning easter eggs :)
don't tell me you expected anyone to spot it when actually running the demo in realtime... :)
we deliberately picked texture resolutions so the demo would still look good at 4k*2k, and some of the geometry you really only see at that resolution. as for the "hund", it wouldn't be there if it wasn't meant to be seen, now would it? :)
hmmm.. i am having difficulties using kkapture on exe-files that uses .avi files as content. is there some circular bugs here?
i don't intercept any video reading or writing functions - why would i?
i still have to discover the irish pub though, where the fuck is it :PPPP
ryg, my code is at fault. it seems that the exe only runs on my box :)
had problem withiso gains power
when i run it with kkapture the bg effects seem to be running much faster compared to the fg things, also it never goes forward from the first screen and just loops there..
when i run it with kkapture the bg effects seem to be running much faster compared to the fg things, also it never goes forward from the first screen and just loops there..
version 1.02 released at the usual location: http://farbrausch.com/~fg/kkapture/
main new features are kkapture_mod functionality - sorry KeyJ for taking so long :) - and added D3D11 support.
i've also migrated the repo to github to simplify the logistics on my side a bit. the repository is now at https://github.com/rygorous/kkapture.
in other awesome news, chrome apparently classifies all kkapture binary downloads as malware. great.
main new features are kkapture_mod functionality - sorry KeyJ for taking so long :) - and added D3D11 support.
i've also migrated the repo to github to simplify the logistics on my side a bit. the repository is now at https://github.com/rygorous/kkapture.
in other awesome news, chrome apparently classifies all kkapture binary downloads as malware. great.
What does this "fake additional screen resolution" do? I tried it with "Poem To A Horse" and it only messed up my screen while capturing, like my card was broken - the capture was still in the original demos resolution (without the glitches).
Wasn't that for recording in a higher reso than your screen could cope with?
BTW it would be cool if kkapture could force AA. :)
The "fake additional screen resolution" adds the given video mode to the list of enumerated modes and prevents the target app from changing the video mode (which would fail if the target resolution wasn't supported by the HW). That means the video mode will show up in the resolution selector if the target app has one. If the target app always sets the same video modes or makes you choose from a built-in selection of video modes, that won't help you.
Actually forcing the app to run at the target resolution would be nicer, but that's way easier said than done. Changing the size of the back buffer is fairly easy, but if the app internally creates a texture of the same size (e.g. for postprocessing or read-back), that texture will now have the wrong size and blits will fail. Also, the app will probably still use the same viewport - so now you're recording (say) a 4k video with only the top left 1920x1080 pixels used. So hack the viewport as well? Well, when the viewport is set, I don't yet know which render target will be rendered to. And what's the right thing to do anyway? Substituting full-screen viewports is reasonably easy, but it gets messy fast if the app also uses smaller viewports somewhere.
Next up, render targets. You can change the size of the back buffer, but a lot of demos (including most of ours) render almost nothing directly to the backbuffer - most if it goes through extra render targets. So make all of them bigger as well? Or only some? What with filters that actually work in pixel space, and actually need more passes (or at the very least different texture coordinates) if they're running at a different resolution?
I went down a substantial part of this whole tree at one point (years ago), and it was a complete disaster - every problem you fix exposes three nastier ones underneath. I can promise you now, this is never gonna happen. Enumerating extra video modes and doing the sleight-of-hand to make that work is totally reasonable. But trying to change the resolution of a non-trivial app behind its back? That way lies madness. You end up having a separate set of hacks for every single demo. I've done this on occasion (there were some throwaway versions of kkapture with really ugly hacks to capture certain demos, mainly for the scene.org Awards) but I'm certainly not gonna ship that as supported functionality :)
Same with forcing AA. If an app only renders to the backbuffer, it's reasonable (and you can mostly make it work with some demos from the really early 2000s), but nobody does that anymore. And there's a bunch of things you can do with regular render targets but can't do with antialiased ones (including using them as textures directly). Again, tracking what is what, although nowhere near as bad as for the "different resolution" case, is an unholy mess, and not worth it. Also, there's a bunch of things that just plainly stop working if AA is involved (e.g. if you force AA in a deferred renderer, you will screw things up badly).
Actually forcing the app to run at the target resolution would be nicer, but that's way easier said than done. Changing the size of the back buffer is fairly easy, but if the app internally creates a texture of the same size (e.g. for postprocessing or read-back), that texture will now have the wrong size and blits will fail. Also, the app will probably still use the same viewport - so now you're recording (say) a 4k video with only the top left 1920x1080 pixels used. So hack the viewport as well? Well, when the viewport is set, I don't yet know which render target will be rendered to. And what's the right thing to do anyway? Substituting full-screen viewports is reasonably easy, but it gets messy fast if the app also uses smaller viewports somewhere.
Next up, render targets. You can change the size of the back buffer, but a lot of demos (including most of ours) render almost nothing directly to the backbuffer - most if it goes through extra render targets. So make all of them bigger as well? Or only some? What with filters that actually work in pixel space, and actually need more passes (or at the very least different texture coordinates) if they're running at a different resolution?
I went down a substantial part of this whole tree at one point (years ago), and it was a complete disaster - every problem you fix exposes three nastier ones underneath. I can promise you now, this is never gonna happen. Enumerating extra video modes and doing the sleight-of-hand to make that work is totally reasonable. But trying to change the resolution of a non-trivial app behind its back? That way lies madness. You end up having a separate set of hacks for every single demo. I've done this on occasion (there were some throwaway versions of kkapture with really ugly hacks to capture certain demos, mainly for the scene.org Awards) but I'm certainly not gonna ship that as supported functionality :)
Same with forcing AA. If an app only renders to the backbuffer, it's reasonable (and you can mostly make it work with some demos from the really early 2000s), but nobody does that anymore. And there's a bunch of things you can do with regular render targets but can't do with antialiased ones (including using them as textures directly). Again, tracking what is what, although nowhere near as bad as for the "different resolution" case, is an unholy mess, and not worth it. Also, there's a bunch of things that just plainly stop working if AA is involved (e.g. if you force AA in a deferred renderer, you will screw things up badly).
btw it would be nice if kkapture would allow to set a time from which capturing begins. Reason: sometimes a capture is disrupted by accident or because another application pops tu the front. It would be nice to be able to continue a disrupted capture. Connecting both parts can be done later in a video editor.
Or, you could close all of your apps and do the capture again...
Any updates? Been a while since the last version was released? ;)
And... what exactly should those updates contain? I think ryg is pretty much "done" with kkapture.