I just posed on this in the main technical feedback thread. I confirm I also get the blurries on terrain texture tile loading. Never had these with RTM. BTW this is with big photo scenery tiles...

But as others have reported, turning>off autogen doesn't seem to help, so that kinda blows that>theory out of the water...Really, this is the most baffling thing I've encountered. The first night with SP1, I was getting incredible performance with my "way higher than I should be using" sliders. But then it slowly started to degrade to the point that I reinstalled from scratch. And ever since then, performance has been quirky at best. Like getting incredibly smooth "6.5" frames a second but oddly jerky "35" fps somewhere else. At least I can fly KPIT-KDCA without DC turning into a slideshow or getting out of memory errors 20 miles out of Pittsburgh, and that's the important part right now. But I'd sure love to be able to get a consistent performance out of it, even if I ultimately have to turn settings down. Getting 15 fps over KMIA with almost every slider maxed and also 15 when everything's dropped to the floor? Also I don't have the frame rate locked at 15. That dog don't hunt, no sir.Additionally, which slider do I need to turn down to keep me from being able to see across all of Florida? Granted I've only flown down there once, but I know I couldn't see Tampa from Jacksonville at 35,000 feet en route to Miami.

Sorry, superfetch off doesn't help.

>Boy I hope they come up with a fix. I'll have to go back to>Pre SP1 just to have a useable game. >>I just hope the developers are not stumped and leave us high>and dry on this. I will say one thing concerns me looking back on the run-up to the release of SP1. There was a lot spoken about how the tile texture system would burn CPU cycles on additional CPUs. But there was much less spoken about the benefit it would produce. The implication, I suppose, was better FPS-- but something that didn't add up in my mind was that Phil/ACES indicated that at times, at least, all 4 cores of a quad core would be fully utilized-- "The more the merrier," he said. I questioned this on his blog, because if you think about it, in RTM tile textures would be give a max of 25% of CPU usage with a FIBER_FRAME setting of .33. If suddenly you have 3 more full cores almost entirely devoted to texture tiles work, if the CPU cycles were being used just as efficiently as with the RTM system, you process tiles at approx 10 times the rate as with RTM. So my question was basically, is there really that much texture work that needed to be done? So, in short, I wonder if the goal of making that little multi-core CPU usage graph sing might have been given more attention that making sure that every CPU cycle burned was used efficiently. That's really presumptuous on my part, but on the other hand not entirely unbelievable. For example, say they were late in the SP1 cycle, had already announced the multi-core work, yet only then concluded they would not be able to get the new tile work nearly as cpu-cycle efficient as RTM. What would they do? Delay again? Scrap the multi-core work? Either way the community probably would have been burning them at the stake.Anyway, I'm not unsatisfied with SP1, but then again my problems don't seem as dramatic as you are describing. By lowering the target framerate and raising FIBER_FRAME (against ACES's advice and probably needlessly), I found the tile-loading tolerable, at least. Personally, I certainly am seeing more benefit than "cost" with SP1. Plus, I'm expecting to be able to compensate for the problem once I put in the dual core chip I just got. But obviously its not fair to expect everyone to go out and get dual-core chips to avoid texture performance regressions with SP1, either.

I am curious because I am not getting the blurries.My fiber frame is set to 2.0 for tileproxy, I have a single core (PIV 3.2), and I usually don't use autogen. I will try some experimenting but I am wondering if any of these 3 variables are a factor....e.g. single vs. multicore/fiberframe setting/lack of autogen.http://mywebpages.comcast.net/geofa/pages/rxp-pilot.jpg

Sorry to sound so obvious, but the sure fire way is by reducing your textures and probably opting for bilinear graphics...that's what worked for me, I compensated by fiddling with my graphics card control panel to give good performance for anistrophic and aa.

>...and probably opting for bilinear graphics...Not sure about that part. I think the filtering is only going to be applied after it is sent to the vid card. The "blurries" problem reported here seems to be that higher res textures aren't being sent to the card.

I was also getting more blurries after installing SP1 (but a significant increase in FPS).I have managed to reduce them to a minimum but it's still not quite as good as pre-SP1, sometimes displaying 2m textures or even 5m ones, especially around densely populated arease.I added to my fsx.cfg:TEXTURE_BANDWIDTH_MULT=60[bufferPools]PoolSize=5000000FIBER_FRAME_TIME_FRACTION=0.50(make sure to add them to the proper section and if the line is already there, just change the values).I also kept my FPS locked at just 16. This may seem low, but it both helps with loading scenery faster, and it gives me a more constant FPS that doesn't jump between low and high figures. This is still a major improvement over RTM, which would never go above 12-15 FPS in the first place.I have an Athlon64 3500+ (single core), 1GB of RAM and the X800XT 256MB card. Running at 1280x1024, 2x AA/8x AF, most sliders maxed except cloud distance, water (2.x low), and traffic. I use 38m mesh, 1m textures.

Yep... we're almost clones of each other. Very similar system (3500, 8800GTS, 2GB), and even after compensating for blurries (.50 and 22fps is what I did-- but I don't have my sliders as high as you), it is still a clear improvement over RTM. I've read it mentioned a couple places that you don't want TEXTURE_BANDWIDTH_MULT over 40. I don't understand why, but I have mine at 40 now. Also, I think I'm going to put FIBER back to .33 and fps down to 20 because of ACES suggestion that lowering fps will have the same effect on blurries, but help prevent fps fluctuations.

For reference I capped my framerate at 10fps, and textures STILL do not load in. I also went back to the the 158.22 whql driver, leaving all CP settings at default and application controled, which had no effect on the issue. And I tried all of the tweaks below with no change. AffinityMask=1PoolSize=5000000TEXTURE_BANDWIDTH_MULT=400FIBER_FRAME_TIME_FRACTION=1.0 (& 0.33)I feel no amount of tweaking is going to fix this issue, it must be fixed at the source. I saw no improvement at all, the textures simply don't load.

Blurries and Neon green boxes.The reason the FSX results in blurries (and also neon green textuers)is because the SP1 patch has extended the old FS9 way of doing texture meshes to use dual-core, and beyond - to many core.Simplified explanation...You can write a program to do everything in order, I move plane, Iload new view + load textures. repeat. You can only use one CPU,and the FPS is dependent on every operation finishing, and you getno blurries or pre-texture neon green squares. This is because thetextures have to load and finish rendering before the next frame. So you end up with FPS that fall sometimes very low. Threaded version.FS9, and now patched FSX use threaded scenery. In FSX they have movedmuch more onto threads so it can utilize up to 32 processors (windowslimit), or 256 (current FSX limit). A thread is bit of program thatget along on its own and passes results over to a control when it isdone. You can start any number of threads in a program and on multiple. FS9 appears to only have one major scenery thread, FSXwill happily use all the CPU available. BUT, if a threadis not finished, then you don't get its results. So if you moveplane, start threads to load scenery, (traffic etc), and the threadtakes too long, then the scenery draw is not complete - The extremeextent is that there are missing textures and you get the defaulttextureless square (neon green in FSX and purple in FS9). Ie - they have solved the performance issue (due to waiting foreverything in a single calculation) by farming out bits of calculationto threads - other CPU. I assume they went the single principle thread route for the vanillaFSX as it is simple to set up for the user, they have one setting, and to make it nice you throw a bigger computer at the problem.They have also fixed a lot of other performance issues too - so it is worth it for single core.But, you have to tweak your system (fsx.cfg) to get things workingas you want it. You MUST compromise now, you must understand thatyou either go for max FPS and the occasional blurry + green square -or back of on the FPS and allow more time for the scenery to keepup. You cannot have both.Solutions... There is no single solution to fix all computers with a singletweak since this is dependent on FSB speed, graphics memory, CPUspeed, number of CPU, speed of disk, how you fly, how much youwiz you head around (virtually). You cannot "have your cake and eatit", there is just no solution to flat out FPS and all the scenery being perfect. You will have to modify the FSX.cfg load balancing parameters to get what you want from the simulation. This stuffis personal and what you think is important.So, to reduce FPS + reduce blurries + green squares : give more timeto the scenery. (look at all the suggestions made on doing this).To increase FPS but with some blurries then reduce the time to thescenery fraction. Enjoy the simulation - I wish I had the horse power some peoplequote here, this is just cutting edge software so it is difficult to get the best. SP1 made it easier for computers to reach that wow factor,but you may have to get under the hood to really get the perfectsolution for yourself.RegardsTom

Chris, after installing SP1 I couldn't run FSX, so I did a complete FSX re-install. I've found that after installing SP1 on a clean FSX installation the blurries are significantly worse. There definitely is a problem here.Single core P4, 3.4GHZ, 2 GB RAM, Windows XP.Best regards, Chris

I agree. I'm also thinking of uninstalling SP1. After applying SP1 to a fresh FSX installation I also see more blurred textures. I've increased the fiber setting from 0.2 to 0.33, but no obvious texture improvement and frame rates are down a bit. I'll try increasing the fiber setting, but it may be that I will completely lose the SP1 frame rate improvement (about 30%) and still have inferior texture performance. If so, and if there's no fix, I will be uninstalling SP1. It's pointless having high frame rates with blurred textures.Best regards, Chris

After increasing PerfBucket in fsx.cfg by a factor of 10,FSX finally seems to dedicate more resources to the terraintexture loader.TileProxy consumes 10% of CPU time now instead of 2% priorto the tweak. Additionally it helped a great deal to lock theframe rate - then extra CPU resources go into terrain jobs(texture updates).My current theory on this: The PerfBucket seems to be the smallest increment (quantum)of CPU horsepower by witch the Job scheduler in FSX givesjobs to different threads. However the I/O in the textureloader takes so long, that it exceeds the performance (time)limits and therefore only does very few texture loads in eachwork unit.Increasing the PerfBucket seemed to help a lot, as nowthe terrain work units are allowed to take longer and thuscan get more work done.Not sure about any side effects. And I could be way off herewith my speculation.If I am right, award me the Nobel PrizeUPDATE: In addition to the PerfBucket tweak I have also setmy FIBER_FRAME_TIME_FRACTION value pretty high. Before thePerfBucket tweak this had next to no effect on Tileproxy activity,after the PerfBucket tweak TileProxy is way more busy.UPDATE2: yes, this is it. TileProxy performance is now quite satisfactory at 100 knots zipping through San Diego. Not perfectyet, but satisfactory.

Try the PerfBucket hack - multiply whatever you have there with a factor of 10. This should have quite an effect.