sda capture blog

F1: ||||||



F2: | | |



F3: | |

in the above picture each | represents one frame. this drawing depicts one complete cycle and only one complete cycle, so the first frame not shown is the first frame of the next cycle. it would be solid blue like the first frame of this cycle.

oot is d4 f3. from the f1 original i was going to f2 first, then to f3 to avoid odd (deflickered) frames (shown above with a bar through them). otherwise i have to use retard bob which does a marginal job of undoing the deflickering and takes exponentially more cpu. more on deflickering in these two blog entries (incidentally this is the same reason i put up this topic).

the frame marked with blue is fine. the problem as i understand it is that sometimes instead of the motion happening in the green frame it happens in the purple or red frame (and gets lost as you can see on the f3 line). in these cases the pattern of motion in f1 is:

K D D K D D or
K D D D K D respectively, instead of
K D K D D D

where K is a motion frame and D is a duplicate (no motion). when i was testing this i saw only sequences of the last type which are ok. but there are often sequences of the first or second type. and once this starts it apparently continues for some time, thus the long, painful stretches of f6 people are seeing.

so basically the game isn't dropping frames at regular intervals. sometimes it will be ok to go -> f2 -> f3 but usually not.

the good news is that i think i've worked out a solution with the help of donald graft's decimate():

changefps(f1/2)
decimate(cycle=3)

this seems to be picking the correct frame (either green or red) from the f2 constellation, probably because it's checking to see that each frame is unique. this means i probably won't have to go back to the horrid retard bob.