I've commented on how SP1/SP2 texture loading does not measure up to RTM, even on a dual core, but it seems that may only be true in some cases, while false in others. I mostly fly where I'm whizzing through the trees, and it seems that in extremely low flight texture loading does not work as good as it did in RTM, but I just did some testing at very high speeds with altitudes that are a bit higher, and I'm very impressed.These screens show me flying from one end of Oahu to the other... AT 1300 KNOTS!This must be the work of the second core, as there is no way textures could load so well at these speeds on my 2.8GHz single core, not with RTM or SP2.I do find it interesting how SP2 texture loading at this speed is so spectacular, while texture loading in other types of flight can seem to be only on par with, or even inferior to RTM. I guess it has to do with the way the calculations are done?http://sio.midco.net/FTP4/1300kts.jpghttp://sio.midco.net/FTP4/1300ktsb.jpg

I assume you mean Acceleration texture loading. SP2 has not been released.fb

>I assume you mean Acceleration texture loading. SP2 has not>been released.>>fbThe Acceleration package contains SP2.

I find it an improvement too - SP1 was a backward step over RTM for texture loading with photoscenery for me, though with some tweaking was acceptable as long as speeds were kept low [200kts or less]With Acceleration SP2 I can fly a 500kts + and though not perfect i.e. still get some patches of blurriness, on the whole it remains very sharp and it is very enjoyable flying fast a low through the valleys of Snowdonia National Park in the F/A-18.

Have you determined what altitude the system breaks down (i.e. 1000ft - no good, 1100 feet - fine)?Mark.

I discussed this a bit on fs.com.SP2 did try to strengthen the IO handling, in a bid to reduce blurries. However, there is still a case with older FS9 style photoscenery that might use an authoring style that essentially conflicts with how SP1 operates. This is a consequence of parallelizing the file IO in SP1 to make better use of cores, that means the file system can get pounded on more at the same time. In comparison, the sequential loads of RTM mean it both was easier on the file system but also had a hard limit on how far performance could go in the best case. So this change is in general a win. The fact that other photo-scenery operates means the product and phtoto-scenery add-ons do work together. That existence proof means there is a special case where the change in SP1 isnt a win, not that the change is inherently bad.The special case is an add-on that stresses the file system with an excessive number of file loads. We have updated the SDK with an article that talks to this, and have confirmed with another photo-scenery author that the technique we describe is roughly similar to what they do and by and large their forums are free of any complaint of the blurries.I dug a bit further into this to understand and confirm, and it really does come down to how many distinct textures there are in the product. Since SP1 parallelizes file IO for the texture loads, on any core configuration if there are an excessively large number of file IOs this can cause textures to fall behind. It might be possible that the texture timeout tweak can help with this, but there are still going to be cases where the file system and texture compositor cannot keep up with that many loads. In one of the leading photo-scenery vendors' forums a moderator showed an analysis of another product that performed ~140k loads to ~3k loads for their product, and pointed to that as why the product he was moderating for did not exhibit the blurry issue and the other one did. That is a lot of file loads to expect and get real-time performance. When one looks at those numbers, it seems clear there is a level of loads between 3k and 140k that is going to work and that 140k is just a lot. What I suspect is going on is that some products have a 1:1 authoring style where the final textures map 1:1 with the source data. This authoring style just isnt going to work if the number of source textures is very large. If the scenery author grouped a 4x4 block ( or larger ) of these original textures, that would present a drop by 16x ( or more ) in texture loads, to around the 9-10k level. That should work.So the issue is understood, and explainable. And the scenery vendors have guidance on what to do to correct the problem if they read the updated SDK. Once SP2 is out, I intend to blog on this. And yes, that will include references to the said forums with this analysis thread, I have permission from this photo-scenery vendor to do so.

BTW, where is the updated SDK for sp2?scott s..

Thank you, Phil, for the detailed response. It's good to know that there's hope. On a practical level, could you tell us which vendor did the analysis?

I've noticed this too. I'm running a single core AMD3700 / 6800XT machine but the graphics quality of FSX is amazing now. Crisp and sharp, well done!

What does RTM mean?

You'll have to wait for my blog post on that one ;-)

RTM=releaase to manufacturing, when the bits get shipped to make DVDsso FSX RTM is the Oct 2006 original release.

It will be released soon. Those who have the Acceleration SDK have the same information.

>It will be released soon. Those who have the Acceleration SDK>have the same information.thanks for the update Phil.scott s..