.kkapture 0.01 - demo capturing made easy (hopefully)
category: code [glöplog]
Ahh.. Thank you :) Must test it out tomorrow :)
great, insert coins now works, september&snowfall now doesn't crash but only gives black screen (seems "time" stays at 0.000s).
to add something to the compatibility list from the source.zip:
195/95 doesn't work, has same resolution bugs as 0.03 with most plastic demos (however with my resfix it works in 0.03)
che guevara works with 0.04 alpha
mfx/kewlers xmix2004 works
lkcc^bauknecht-perfect love works
kolor-relais and blackmaiden interceptor only work with bmp/wav output. with avi output they freeze and avi is invalid
outracks-blockbuster works
plastic-final audition works
kkapture RULEZ :)
to add something to the compatibility list from the source.zip:
195/95 doesn't work, has same resolution bugs as 0.03 with most plastic demos (however with my resfix it works in 0.03)
che guevara works with 0.04 alpha
mfx/kewlers xmix2004 works
lkcc^bauknecht-perfect love works
kolor-relais and blackmaiden interceptor only work with bmp/wav output. with avi output they freeze and avi is invalid
outracks-blockbuster works
plastic-final audition works
kkapture RULEZ :)
bartman, thanks. relais/interceptor: that sucks, because I can't debug that on my machine (no nv card).
ryg: tried this? http://www.scene.org/showforum.php?forum=6&topic=61492
didn't know myself until shiva posted the link :)
didn't know myself until shiva posted the link :)
bartman, that still doesn't change the fact that I have a radeon 9600 in my machine ;)
I also had the time stuck at 0s bug with synchroplastikum. In my case, it was a problem with waveout usage. It turns out that kkapture expects the WAVEHDR structure passed to waveout to stay valid for the duration of the buffer playback, whereas I just had it in a temp local variable, which got filled up with stupid stuff later, and thereby somewhat disturbed kkapture. I guess a fix for this would be to make an internal copy of the WAVEHDR structures passed to kkapture, since the Win32 API seems to have no problems with disappearing structures (although I must admit that this is somewhat dubious API usage, but I guess just about all demos do that :-)
well, i thought the only reason they don't work on ATI was the same that they don't work on Gf6x, that the EXT_colortable is not supported...
minas: good to know, that should be easy to fix ;)
bartman: nope, shiva uses nv vertex array range and register combiner extensions (and probably some others aswell).
bartman: nope, shiva uses nv vertex array range and register combiner extensions (and probably some others aswell).
Quote:
not yet checked with new timing code, working with older timing (alphabetical order):
- spectrum/ümlaüt design
check - the timing code havent changed in later demos (sync to bass.dll)
Hi
I new to .kkapture.
Can I help with tests?
I have a programmers skills.
I new to .kkapture.
Can I help with tests?
I have a programmers skills.
The requested URL /~fg/kkapture was not found on this server.
Is there any chance you could put it on your server again??
Is there any chance you could put it on your server again??
Farbrausch's servers are currently in the process of being moved. All members involved currently are outside this country. I guess this will be fixed after they return next weekend.
until then: http://umlaut.intro.hu/~gargaj/temp/kkapture/
gargaj for (temporal) president!
none of the video codecs i have installed show up in the pick compression dialog, but premiere for example can find them. any ideas whats wrong?
Apparently (I haven't tested) the new version of our previously buggy timing code works fine with kkapture. So, if anyone wants Traction videos bad enough to port them to the new engine and/or recompile, contact me :)
Traction videos? Yes, Please Yes :)
http://www.farbrausch.de/~fg/kkapture/ now works again.
FLT-Deadline Demo does not work with kkapture.. black Screen, hardcore PC Crash :( http://pouet.net/prod.php?which=24188
quite a few crash. the most annoying was when I was making a kkapture of a ~20 minute long demo or something (Memories from the MCP, as far as I remember), and it crashed after rendering the whole thing. It took me 2 hours or so, and it didn't like the ending... so it crashed. great, huh?
It's usually a good idea to kkapture demos in windowed mode when possible. Most "hard crashes" when kkapturing are in fact normal Win32 app crashes with a dialog box and everything. In fullscreen demos which use page flipping, that dialog box is often invisible, causing the PC to freeze with a black screen (but immediately returning to responsive once you press Return to confirm the invisible dialog box).
Also, quite a few demos crash when being kkaptured during deinitialization, but after the .AVI file has been successfully written. This has something to do with the way kkapture initializes and deinitializes (or actually with their points in time) and is near impossible to fix without performing at least rudimentary code flow analysis of the target program - and seriously, I've got more interesting things to do with my spare time.
Somewhat problematic are Video codecs which have some encoding statistics window (XVid and DivX for example). First off, they usually create this statistics window and move it to the front on creation of the AVI file. In kkapture, this happens after the graphics API has been succesfully initialized, particularly after the switch to fullscreen in fullscreen apps (I can't do it earlier because there's no way to know which resolution the demo is going to use). This is a big problem for demos that pause on losing focus. The only way to work around this is do DISABLE this statistics window or use a codec that doesn't have one. Another problem with those stats windows is that codec deinitilization is called on ExitProcess, which is somewhat late and irritates some codecs.
Seriously - don't use "complex" codecs while kkapturing. Use uncompressed or HuffYUV or something like that and re-encode the resulting AVI with VirtualDub afterwards. This is far less error-prone. It also makes for a lot faster kkapture sessions (...if you have a fast HD, that is) and less time spent waiting for demos to kkapture that crash in the end.
Also, quite a few demos crash when being kkaptured during deinitialization, but after the .AVI file has been successfully written. This has something to do with the way kkapture initializes and deinitializes (or actually with their points in time) and is near impossible to fix without performing at least rudimentary code flow analysis of the target program - and seriously, I've got more interesting things to do with my spare time.
Somewhat problematic are Video codecs which have some encoding statistics window (XVid and DivX for example). First off, they usually create this statistics window and move it to the front on creation of the AVI file. In kkapture, this happens after the graphics API has been succesfully initialized, particularly after the switch to fullscreen in fullscreen apps (I can't do it earlier because there's no way to know which resolution the demo is going to use). This is a big problem for demos that pause on losing focus. The only way to work around this is do DISABLE this statistics window or use a codec that doesn't have one. Another problem with those stats windows is that codec deinitilization is called on ExitProcess, which is somewhat late and irritates some codecs.
Seriously - don't use "complex" codecs while kkapturing. Use uncompressed or HuffYUV or something like that and re-encode the resulting AVI with VirtualDub afterwards. This is far less error-prone. It also makes for a lot faster kkapture sessions (...if you have a fast HD, that is) and less time spent waiting for demos to kkapture that crash in the end.
Also make sure your .avi file is under 2GB's if you're using FAT32.
since i'm usually capturing demos for dvd-usage, but most demos are not supporting pal resolutions, it might be a good idea to include a simple resizing-filter to kkapture (optionally including a letterbox-option for overscan-compensation).
so one can simply capture at the highest resolution available without wasting huge amounts of discspace.
in this context i also found it useful to make kkapture interlace two frames.
for now i've hacked this to a custom-version of 0.03 but was yet too lazy to properly add this to the gui ;)
additionally a 16:9-toggle might be useful, resizing to either 4:3 or anamorphic output...
so one can simply capture at the highest resolution available without wasting huge amounts of discspace.
in this context i also found it useful to make kkapture interlace two frames.
for now i've hacked this to a custom-version of 0.03 but was yet too lazy to properly add this to the gui ;)
additionally a 16:9-toggle might be useful, resizing to either 4:3 or anamorphic output...
Quote:
Use uncompressed codecs and re-encode the resulting AVI with VirtualDub afterwards.
This is far less error-prone and less time spent waiting for demos to kkapture that crash in the end
so how about a dummy-pass for testing kkapture-compatibility without creating output at all?..
wow ryg, thanks for the explanation, the same thing happened here. I'll give it another go I think :)