Jane's
IAF
A Layman's Guide to the Shimmering Effect
Why does the terain in Jane's IAF shimmer? There have been lots of theories since this bug became apparent, and it seems that this is actually the most common complaint regarding this simulation. Let's try to clarify a few points:
Q: WILL CHANGING MY SCREEN SETTINGS HELP?
No. The game always runs at a resolution of 640x480 with 16-bit color depth, regardless of your Desktop screen settings.
Q: MY GRAPHICS CARD / SCREEN ARE NOT TO BLAME, RIGHT?
Almost all players reported seeing the shimmering effect, and they all had various cards and screens - the logical conclusion would be that their hardware is not the cause. And it's true... to a certain extent. I'm no hardware specialist, and this bug's source is indeed totally in the software, but I personally saw bug differences between a few brands of graphics cards; without mentioning specific names, as a general rule (and a very sad one for over-budgeted people like me) the newer, faster and more features-pumped your card is - it's also usually the better.
Q: SO WHY DIDN'T THEY TEST THE GAME BEFORE SHIPPING IT OUT?
Short-story time. When various components of IAF were first joined together into one cohesive skeleton, literally thousands (!) of bugs were discovered in one glance alone. As a result, Pixel created its own modest testing team to supply instant feedback in real-time during the actual development and not afterwards. However, this team mostly tackles ''real'' bugs and playability issues and is not concerned about, nor equipped for, testing the game on many versatile platforms (except for the planned ''Minimum Platform'' of course), and so the main testing of the game is done by Electronic Arts' own testing team, using its own huge (??) computer farms; and EA probably does check the game on as many diverse platforms as it possibly can...
But the obvious Achilles' Heel in this procedure is that versatility-related hardware bugs aren't tracked and crushed at the moment of their appearance: EA's vast resources are utilized only after the simulation is sent from Pixel at least half done. This is problematic if you find that a bug originates from an elementary part in the program's core, or worse - if you can't isolate at all the bug's origin within the elaborate code-structure.
Q: YOU MEAN NONE OF THEM EVER NOTICED THIS?
Personally, I think this was a classic case of oversight. I imagine (though this is only my own worthless conjecture) that they simply didn't think people would pay attention to such a behavior of the terrain, compared to the low (?) graphics quality of older simulations.
Which leads me to...
Q: WHAT THE HELL IS THE ORIGIN OF THIS BUG ANYWAY?
IAF's terrian uses (quote) ''actual stereoscopic satellite data at 10m/pixel, with true terrain elevation and coloring--the most realistic you can get before it becomes classified information.'' By the way, a stereoscope is an instrument for viewing a pair of photographs of a scene or object (taken at slightly different angles), each with one eye - thus producing by the combination of these images an impression of depth, distance and solidity.
The problem revolves around something called 'mipmapping', it's a technical term and I won't explain it in depth, but here's a little demonstration: Let's say we have a 3D surface with various colors. Now let's rotate this surface a little, 45 degrees for example. You can see the result - from a 2D point-of-view the surface has ''shrunk'' and as a result the original colors are more ''squeezed''; up to a certain point it's still ok (all the original colors are still represented - only in smaller 2D areas). However, as we gradually get closer to 90 degrees (where we won't be able to see the surface at all), these 2D areas become smaller and smaller until finally there is some substantial color loss - there's simply not enough area to display all the original colors of the non-rotated surface. And at such a rate, after rotating the sorface 89 degrees we get maximum color loss in comparison to the non-rotated surface!
The terrain-rendering engine of the simulation has a certain area of 3D terrain data, and it even knows what portion of the 2D terrain graphics should be rendered on it; but it also needs to decide exactly in what way to compress the graphics according to (A) your distance from this area and (B) your angle of sight (how ''flat'' the terrain appears to you). In other words, based on these factors it asks itself the question ''Which colors should be more dominant right now in the display calculations?'' If your plane was stationary this wouldn't pose any difficulty since you would see a single unchanging picture which would look just fine, however since you constantly move in the space of the simulation world your view of the terrain is also constantly changing.
IAF's faulty terrain-rendering engine faces a problem: it is over-sensitive to this change in your location. Sometimes it needs to compress the obviously-complicated graphics of the terrain into a very small 2D area: this may result in coloring a few pixels with a certain color, and a split-second later coloring them using a different color (due to the different interpretation of the situation and hence the different answer to the question mentioned in the above paragraph). And if this process repeats itself the result is a ''blinking'' effect in a few areas at any given time - an effect which is better known as the Terrain Shimmering Bug.
Phew...
Q: NAH, IT HAS TO BE A PLOT OF DARKER FORCES.
''I'd heard the original terrain was quite good but the paranoids-that-be demanded a 'tune down' ... Result was a sucky terrain model that looked okay from above 10-15K but was truly 'psychedelic' below this.'' This is in fact true (for more details, read Pixel's Unofficial Profile in the site features section), but not at all the reason for shimmering. When you're flying at an altitude of 20,000 feet, any relative elevation differences (between a hill and a valley for example) seem almost irrelevant, and the result is a 99% flat terrain de-facto with no complex calculations which affect the graphics; on the other hand, flying NOE (Nap Of the Earth) at 100 feet AGL (Above Ground Level) inside a canyon means you see a whole lot these graphics-manipulation calculations, and consequently a whole lot of calculation mistakes.
And in defense of this IAF policy of tuning down the terrain mapping quality, I can only say that at least one friend of mine got very excited when he managed to identify and fly over his neighborhood - so one must ask himself what dangers this poses to the really sensivite installations of a country which a jet can cross in no more than 5 minutes...
I truly hope this helped in some way to understand this whole issue a little better.