Maeyanie

Bug report video for you, in a few hours when it finishes uploading: http://youtu.be/Qs49pu112Eg This actually is showing several problems. - Despite being only at a tiny amount of throttle, KCA goes wild with engine pulsing, gimbles, and reaction wheels, and drains my battery in seconds. - When the battery runs flat, it doesn't seem to notice, and the ship starts to spin. - The ship spins in the direction where it's completely symmetrical and balanced. So KCA is actually creating an imbalance in that direction which would not exist otherwise. I recorded this with a test setup with only KCA, LLL, and MechJeb installed.

It wouldn't lose any detail, .png uses lossless compression. But you're right that it wouldn't save any more memory.

It should run fine on a LiveUSB, so long as you have the proper video drivers installed and don't mind a horrifically long initial game load. BuGLe seems to do the job pretty well, though it's a little more complex than FRAPS. I compiled it from source, installed the example filters/statistics files, and ran it using BUGLE_CHAIN="logfps". The logfile it spits out isn't in CSV, but it's fairly easy to convert with awk or sed or whatever.

Sure, here's a chart up to frame 9000. That cuts off slightly before the first spike there, and gives better vertical resolution than 10000. After sleeping on it, I also figured exactly why the 64-bit seems to "take longer"... because the X axis is in frames rather than seconds, so of course the one that spits out frames faster will have spit out more frames by the end.

Here's another chart, mainly for informational purposes. I noted the Linux version came with 32-bit and 64-bit executables, so was curious just how much it mattered. These are done on Linux, using BuGLe for FPS capturing. So it's probably not directly comparable against FRAPS speeds. In particular, BuGLe doesn't (so far as I could tell) support starting and stopping the capture with a key, so I had to run it the whole time and trim the start and end. Both datasets are from the same system: Core i7 920, stock speeds, triple-channel low-latency memory, hyperthreading off, running Fedora 20 alpha. Interestingly, I got about half the speed when I tried it on Mint Linux. I have no clue why, but it's probably my fault. (Data files) So why did the 64-bit version run much longer, despite being significantly higher FPS? Probably because I did that one first, and I was better at the staging the next time. I did do a few practice runs first, but it is fairly hard to see what's going on with a face full of rocket exhaust, and I don't have all day to get it perfect.

Here's another chart, mainly for informational purposes. I noted the Linux version came with 32-bit and 64-bit executables, so was curious just how much it mattered. These are done on Linux, using BuGLe for FPS capturing. So it's probably not directly comparable against FRAPS speeds. In particular, BuGLe doesn't (so far as I could tell) support starting and stopping the capture with a key, so I had to run it the whole time and trim the start and end. Both datasets are from the same system: Core i7 920, stock speeds, triple-channel low-latency memory, hyperthreading off, running Fedora 20 alpha. Interestingly, I got about half the speed when I tried it on Mint Linux. I have no clue why, but it's probably my fault. (Data files) So why did the 64-bit version run much longer, despite being significantly higher FPS? Probably because I did that one first, and I was better at the staging the next time. I did do a few practice runs first, but it is fairly hard to see what's going on with a face full of rocket exhaust, and I don't have all day to get it perfect.