pouët.net

hmm, i wish this would capture windows GDI DC from a window's client area

thanks ryg <3<3!

aaaand version 0.06b: (the usual right-after-a-minor-version-fix you've come to expect and love!)
http://www.farbrausch.de/~fg/kkapture/

• default video encoder is now vfw avi writer on new setups.
  
• "fairlight hack" switch made explicit (was always on from 0.05 onwards). turn it on for track one and possibly other flt versions, leave it off for everything else, especially 4ks :) (tnx gargaj for reminding me...)
  
• some "new startup instrumentation" fixes (esp. for crinkler 4ks on win64 machines).
  

*bump*

just to say (if I haven't done so beforE) that I have resolved the problem with the blank scenes in Animal attraction. I was doing some sort of weird texture cache warming up. It works fine now that I have disabled it and so it can be kkaptured perfectly.

We've captured a new high-quality video of the demo, and should upload it soon.

ryg, you rule! :)

a new Demo or Die volume with all recent killer demos would be cool then...*wink wink*

sure, that's why i'm so interested in new kkapture versions...

navis: i fixed that some versions ago (cf. changelog, it should work properly with 0.05 onwards), but good to know anyway :)

Thx for the BP invit fix Ryg. Andromeda's demo had the same problem?

a lot of demos had, it just took quite some time for me to figure out how i might work around that kind of problem properly.

hmm, just kkaptured nuoemon at 50.00 fps, but there's a strange thing going on. you can see it the best at the infinite cubes scene, but it's there in the others aswell. often after 2 correct frame, there seems to be one duplicated. it's not 100% duplicated, it's the same scene content as the previous frame, but the bloom filter changed a bit.. i'm not really sure what's going on, but unfortunately this way the playback's not as smooth as it could be...

bartman, that seems to be a general problem with demos that use fmod. i first noticed this with virtually all mfx/kewlers prods, synesthetics prods seem to be affected too. apparently, the timer fmod reports back has very low granularity: seemingly between 40 and 45 updates per second from what i've seen so far, haven't yet determined the exact value.

this is entirely fmod specific and probably only happens with the dsound output device (and by the way also when the demos play in realtime, i got curious after i found this out, and i'm 90% sure it's there though it's hard to be certain without capturing the video using suitable hw which i don't have). not sure whether it happens with fmodex anymore.

in any case, i can't work around this from inside kkapture because it's a fmod bug (ask firelight, maybe?).

really, i should probably start collecting anecdotes and weird trivia i've learned while working on kkapture.

it's become quite a pile by now :)

ryg: Earlier reports i've gotten from firelight was 40hz timer. That's why i stopped using it myself ;)

Firelight said himself that he wouldn't fix it ("fmod is not a timer"), and since you need the sound-streamer position to be able to get _reliable_ sync (hello creative-drivers), there's no other option than to either accept the jerky timer, or switch sound-system. I prefer BASS.

FWIW, our current scheme of choice that seems to work quite well overall: get current time (just use timeGetTime() with a proper period value) on every block you submit to the sound system. each frame, do (pseudocode)



this has about 1ms resolution and automatically resynchronizes every 4k samples (or whatever other block size you prefer). which is enough not to get in serious trouble with timing jitter caused by badly written sound drivers (hello creative indeed). the code is also quite simple compared with some of the kludges we've had in past years while trying to make sense of the utter bullshit some sound drivers report for current play position...

sounds reasonable, however I just watched noumenon on my new PC (e6600+gf7600gt) and it seemed noticably smoother than the kkaptured mpeg... strange.. could there be some influence of noumenon's vsync option or the refresh rate of the screen mode?

no, both are *completely* ignored while kkapturing. once again, kkapture does NOT grab ANYTHING from the screen at all, it reads the backbuffer, and vsync timing can't possible influence the kkapture process.

there might be something else happening that causes additional jerkiness (on top of the fmod stuff), but i can't say what that might be.

the ultimate way to kill timer jerkiness, and can be used with any timer, is to blur it! remember, anything becomes better when you blur.

Actually, it does work really really well.

float t = (float)timeGetTime()/1000.0f; //or your fav dsound timer
DEMOLOOP BEGIN
float newt = (float)timeGetTime()/1000.0f; //or your fav dsound timer
t = t*0.7f + newt*0.3f
DRAW YOUR CUBE(t)
DEMOLOOP END

Sure, you get a tiny delay, but this makes the jerkiest timer go smooth... and of course this is only the simplest possible implementation.

I doubt this method is a good idea to get the best kkaptures, though ;)

"ultimate"

s = rnd(0.0f, 1.0f) ;
t = t*s+newt*(1.0f-s) ;

hail mister montecarlo.
(and i still doubt that this could be at least a vaguely good choice for a timer)

ok, I'm no signalprocessing-wiz or anything, but won't ector's filter result in an increasing lag as time goes on? Sure it's stable, but doesn't it run slower than the actual timer?
(consider if the timer is correct, for each iteration the interval between t and newt will increase... right?)

(...but as the interval increases the effect of newt will increase, and the lag will converge to some fixed value... ok, now even I get it...)

Im gonna capture (kkapture) a demo. What compression is best? that means which have a decent quality but low in size. If there are two or more options just let me know.

Here are the list of my compressions:

Cinepak Codec by Radius
Intel 4:2:0 Video V2.50
Ligos Indeo (R) Video 3.2
Intel IYUV codec
Microsoft RLE
Microsoft Video 1
Ligos Indeo (R) Video Raw R1.2
Microsoft H.263 Video Codec
Microsoft H.261 Video Codec
DivX (R) 5.2.1 Codec
PICVideo M-JPEG 3 VfW Codec
Microsoft MPEG-4 Video Codec V1
Microsoft MPEG-4 Video Codec V2
Ligos Indeo (R) XP Video 5.2
Ligos Indeo (R) Video 4.5
TechSmith Screen Capture Codec v2.0.6
(RAW frames) Hele bilder (ikke komprimert)

Also I have two encoder options, which one should I prefer?

.AVI (Vfw, segmented)
.AVI (DirectShow, OpenDML)

For decent quality and low bitrate, you should capture to HuffYUV, LagArith or some other (near-)lossless codec (just google them), then use VirtualDub to do a two-pass XVid (or x264 if you have the cpu power) encode.