pouët.net

.kkapture 0.01 - demo capturing made easy (hopefully)

category: code [glöplog]
Ahh.. Thank you :) Must test it out tomorrow :)
added on the 2006-01-28 00:21:19 by Sapphire Sapphire
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 :)
added on the 2006-01-28 12:15:12 by bartman bartman
bartman, thanks. relais/interceptor: that sucks, because I can't debug that on my machine (no nv card).
added on the 2006-01-28 17:05:53 by ryg ryg
ryg: tried this? http://www.scene.org/showforum.php?forum=6&topic=61492
didn't know myself until shiva posted the link :)
added on the 2006-01-29 17:09:55 by bartman bartman
bartman, that still doesn't change the fact that I have a radeon 9600 in my machine ;)
added on the 2006-01-29 17:29:03 by ryg ryg
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 :-)
added on the 2006-01-29 19:18:16 by minas minas
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...
added on the 2006-01-29 21:55:53 by bartman bartman
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).
added on the 2006-01-29 23:23:13 by ryg ryg
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)
added on the 2006-01-30 16:03:02 by Gargaj Gargaj
Hi
I new to .kkapture.
Can I help with tests?
I have a programmers skills.
added on the 2006-03-02 13:03:42 by nissim nissim
The requested URL /~fg/kkapture was not found on this server.

Is there any chance you could put it on your server again??
added on the 2006-03-02 13:25:05 by Muerto Muerto
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.
added on the 2006-03-02 21:51:56 by scamp scamp
gargaj for (temporal) president!
added on the 2006-03-03 00:08:35 by mrdoob mrdoob
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?
added on the 2006-03-03 11:02:55 by hollowman hollowman
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 :)
added on the 2006-03-03 11:06:06 by Preacher Preacher
Traction videos? Yes, Please Yes :)
added on the 2006-03-03 22:40:15 by Sapphire Sapphire
FLT-Deadline Demo does not work with kkapture.. black Screen, hardcore PC Crash :( http://pouet.net/prod.php?which=24188
added on the 2006-03-08 23:50:59 by Sapphire Sapphire
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?
added on the 2006-03-09 00:25:49 by kelsey kelsey
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.
added on the 2006-03-09 02:47:31 by ryg ryg
Also make sure your .avi file is under 2GB's if you're using FAT32.
added on the 2006-03-09 02:58:49 by Gargaj Gargaj
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...
added on the 2006-03-09 09:05:19 by hfr hfr
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?..
added on the 2006-03-09 09:15:05 by hfr hfr
wow ryg, thanks for the explanation, the same thing happened here. I'll give it another go I think :)
added on the 2006-03-09 09:44:10 by kelsey kelsey

login