The file loading code in 950 beta 1 for Windows is slower than 945. Sometimes. This will be "fixed" in beta 2. Here's what happened:
The scenery system uses a number of small files. .ter files, multiple images, .objs, etc. This didn't seem like a problem at first, and having everything in separate text files makes it easier to take apart a scenery pack and see what's going on.
The problem is that as computers get bigger and faster, rather than a scenery pack growing bigger files, they are growing more files. The maximum texture size has doubled from 1024x1024 to 2048x2048. But with paged orthophotos, multicore, and a lot of VRAM, you could easily build a scenery pack with 10,000 images per DSF.
That's exactly what people are doing, and the problem is that loading all of those tiny files is slow. Your hard drive is the ultimate example of "cheaper by the dozen" - it can load a single huge file at a high sustained data rate. But the combination of opening and closing files and jumping between them is horribly inefficient. 10,000 tiny .ter files is a hard drive's worse nightmare.
In 950 beta 1 I tried to rewrite part of the low level file code to be quicker on Windows. It appeared to run 20% faster on my test of the LOWI demo area, so I left it in beta 1, only to find out later that it was about 100% slower on huge orthophoto scenery packs. I will be removing these "optimizations" in beta 2 to get back to the same speed we had before. (None of this affects Mac/Linux - the change was only for Windows.)
The long term solution (which we may have some day) is to have some kind of "packing" format to bundle up a number of small files so that X-Plane can read them more efficiently. An uncompressed zip file (that is, a zip where the actual contents aren't compressed, just strung together) is one possible candidate - it would be easy for authors to work with and get the job done.
In the short term, for 950 beta 2, I am experimenting with code that loads only a fraction of the paged orthophoto textures ahead of time - this means that some (hopefully far away part) of the scenery will be "gray" until loaded, but the load time could be cut in half.
There is one thing you can do if you are making an orthophoto scenery pack: use the biggest textures you can. Not only is it good from a rendering perspective (fewer, larger textures means less CPU work telling the video card "it's time to change textures") but it's good for loading too - fewer larger textures means fewer, larger total files, which is good for your hard disk.
(Thanks to Cam and Eric for doing heavy performance testing on some of the 950 beta builds!)
3 comments:
Sounds like a good idea!
I think FSX does "packaging" with its .BGL format.
Maybe even XP (or a command line utility) could even auto package files so that scenery files that have not been packaged by authors can benefit from packaging too.
Regards, MatthewS
one question:
what is the biggest size of orthophoto scenery textures? 2048x2048 aswell?
thanx in advance
nimi
How about not pre-loading paged orthophoto textures on initial load (i.e. on X-Plane start-up) at all? That would mean gray terrain all around at first, but during the first two or three minutes, while you're choosing your aircraft, setting weather, and generally preparing for the flight, I think it wouldn't be that bad (apart from looking funny, of course). The overall waiting time until the terrain is finished probably wouldn't be much longer, but you could start your pre-flight preparations much sooner.
Post a Comment