I was at least as surprised as you will be to discover that...
..when you pop back to your starting location using replay mode, the airport appears (belatedly - see the previous blog entry) almost five times faster if you turn off texture compression!
What the hell?!?! :-) It's almost as if some idiot programmed X-Plane to load scenery five times slower if texture compression is on. Oh wait...that was me.
The problem is: how to balance the importance of keeping the framerate up with the importance of loading airports before you get there? All background work involves stuff we might do in the background (if you enable the rendering setting), maybe on a second core/CPU if you have one, and also some talking to the graphics card. We can only talk to the graphics card between drawing frames* and doing so stops rendering.
It turns out that in X_Plane 8.30 when we developed background loading, I put in the "go 5x slower" option because compressed textures visibly halts the sim as the graphics card stops rendering and compresses each texture. Without this 5x slowdown in background work, flight becomes stuttered and bumpy. The problem is that the 5x slowdown means we're going through airports at a much slower rate than we should be.
I am working on airport tuning now...there will still be a delay before you see airports if you use instant-replay to move around fast enough (this delay is about the length of time the sim would have spent halted during scenery load but now no longer does) but the responsiveness should be a lot better.
(Here is a discussion of dual-core for Flight Simulator X...tdragger explains the issues well, and I think they apply to any graphics-intensive real-time or near-real-time simulation, so it doesn't surprise me that both X-Plane and FSX offload similar types of work to extra cores.)
*Newer OpenGL drivers get around this limitation to various extents; we will eventually support this in X-Plane.
No comments:
Post a Comment