• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

Do you believe in miracles?

Messages
13
Country
us-florida
Yeah I know.. I'm a nobody ;) you don't know who I am, I'm not known in the community, so probably you won't take me seriously... but, just assume for a second, i'm right and I know what I'm talking about :) would you at least give a shot at 'proof reading' it? is the idea clear, confusing? I want to make it public for 'general use' you are of course invited to try ;)

***************************************************************

DISCLAIMER:

What you are about to read CAN PRODUCE UNFAVORABLE RESULTS depending on your particular setup and slider settings, so this is NOT a 'solution' to any problem, this is simply a hidden, undocumented tweak that can be applied to Flight Simulator X to obtain aproximately a 30% performance improvement.

Before I begin, a little background.. I've used this tweak personally, for more than a year, second, I have dedicated considerable time 'understanding' the tweak, its purpose, and specially the 'reasons' why there is such a 'dramatic' performance increase. So please... DO NOT TRY if you have 'issues' or problems in your current setup, only try it *IF* you are absolutely certain that you have a fairly stable setup and that you UNDERSTAND what I'm explaining in the following lines:

Lets first discuss 'how' applications, 'particularly' FSX works (I will keep it simple)
When you 'fly' in FSX, each 'frame' its like a 'photo' it contains certain objects and textures that need to be 'drawn' for EACH 'photo'. When you play this 'photos' in rapid succesion, say, for example 25 'photos' per second, the perceived sensation is that you are 'moving' FPS = Frames per Second, each 'frame' is the 'photo' I'm talking about.

In FSX, the 'rendering' or 'drawing' of this objects, occurs, on a per 'frame' basis.. the higher the frames per second, the higher the number of objects that need 'drawing' This 'drawing' works by having the 'CPU' instruct your 'video card' what to 'draw' on screen. Each 'instruction' the CPU sends to the video card is 'queued' in a 'buffer' FSX, then 'determines' the 'threshold' where that buffer is 'filled' to flush all the commands to 'another' buffer, this one is called the Command 'ring' buffer.

This happens, so FSX can syncronize the CPU and the GPU in terms of instructions proccesed. If this 'buffer' the one created by the application, didn't exist, then you could 'under certain conditions' COMPLETELY CRASH FSX. The reason for this 'crash' is that FSX would have to send the intructions 'directly' to the 'Command Buffer', which is the one that the Video card reads to 'draw' the objects on screen.

If the video card is not fast enough to process the INCREDIBLY high number of 'draw calls' sent by the CPU per each frame (photo), then STALLING occurs. Stalling, means that the CPU 'writes' into the command buffer FASTER than what the video card is capable of proccesing (the command buffer its a ring) its finite it can hold 'certain' number of instructions at a given time, if the video card doesn't read it fast enough it gets overwritten and video corruption occurs (you'll know this because spikes come out from the AUTOGEN)

If you understand the above correctly, then you also must understand that 'application managed' buffers (aka BufferPools) 'cost' some CPU usage, and particularly in FSX this usage is MASSIVE! however, this is NOT a bad thing, its a 'safety' mechanism that the application uses so its almost imposible that it will 'fill' the command buffer with instructions. The 'Aplication managed' buffer, is like a 'middle man' it coordinates what goes into the command buffer and 'how' to keep things in sync so you don't batch an exessive ammount of objects for the video card to process.

So, why does Microsoft includes an 'application managed' Buffer (also called Explicit Vertex Buffers)? they did so, so ANY ONE could use FSX regardless of setup and ensure 'up to a point' that this will perform reliably indepently of hardware. So, DONT BLAME MICROSOFT!! they did the right thing and this is NOT a bug.

So, what happens when you tell FSX to 'bypass' this 'application managed' buffer and send all the 'draw' instructions DIRECTLY to the command buffer for the video card to process? (instructions are really sent to the D3D API, I'm just keeping the explanation simple for our sarcastic folks out there) well.. what happens is that FSX doesn't need the middleman anymore, what happens is that FSX doesn't need to control what to draw or when to draw it. Now, it simply pumps all the information as fast as it can to the Video Card, and by doing so you FREE a massive ammount of resources that are now allocated to your current flying session!! Now.. Do you understand why this tweak is SO powerfull, but at the same time, EXTREMELY dangerous for stability? It is because you need to have an INTIMATE knowledge of WHAT is going on in your computer!! you need to know 'exactly' how much is 'too' much for the GPU to process.. and this is, where things get interesting.

How can you be 'sure' that your video card is in TOP shape and able to process ANY and EVEYTHING you throw at it? remember... this is NOT about 'raw' power... this is about the card ability to 'process' the commands sent by the CPU, FASTER than the CPU ability to 'send' those commands.. its like a 'race' and the GPU needs to be faster! so, this holds specially true for folks using overclocked i7's @ 4.2 and DONT BELIEVE your GPU % Usage meter! it only shows USER SPACE... it doesn't tell you how much the 'kernel' (system) is using to process commands in the queue.. AND don't compare FSX to Crysis please... those are games OPTIMIZED to make full usage of hardware programable shaders! they are perfectly balanced!

well, you need to start forgeting EVERYTHING you have learned in the past 4 years.. specially things like:

(AntiAliasing) but only when it is controlled by nHancer
(Anisotripic Filtering) again, ONLY if controlled by nHancer
vSync set to ON (this is a KILLER)
Multiple Monitor setups (even clone mode)
The ENBSeries mod

the above, KILL the card ability to process commands 'but not the ability to RENDER or DRAW the objects' so if you absolutely NEED the above, you can stop reading now ;)

So, if you want to give this tweak a try, you need to start by using the application controlled AntiaAlias and Anisotropic filters, you need to also force vSync to OFF, and make sure you are running a single monitor setup. this will ENSURE, that the card is in top shape to process commands 'as quick' as it can... specially, if using nVidia cards (ATI's dont have this problem, more on that later)

One side note: ATI's 5870 vs nVidias GTX 285 they are both EXCELENT cards... but they have completely different architectures, the ATI's have LOTS of tiny 'slow running' shader processors, the nVidias have fewer shader processors (a lot less) but they are TWICE as fast... so, how does this affects the cards ability to 'process' and 'render' draw commands?

well.. its up to you to decide: the ATI's have 1600 small processors, they are called 'shader processors' the more processors you have, the better the card ability to 'multitask' and do parallel processing so, the ATI's are FANTASTIC reading the command buffer faster than ANY card on the planet (even the new nVidias GTX 480, also called by their codename Fermi) so with an ATI you could practically have FSX nirvana if FSX were to send all draw instructions to the command buffer bypassing the BufferPools.. however, THERE IS A CATCH. Since ATI's have more shader processors, they need to run 'slower' (they run at 700Mhz) same as the core clock. so, complex scenery, clouds, add-on aircraft will considerably LOWER your total average FPS. so, again, its up to you to decide... if you only fly default planes, and want EVERY SINGLE SLIDER MAXED out, vsync, nHancer, ENBSeries mode etc. then the ATI is for you, ITS IMPOSSIBLE TO CRASH IT! I could crash mine (I only owned it for like 2 days) no matter what I tried, but I lost 6FPS! to me thats unnaceptable.

Now.. the nVidias, particularly the GTX 285, have exactly 240 Shader processors, they run at 1476Mhz (and some can be overclocked even higher) this card, is a monster... and even though the ATI's (in raw speed) are faster, the nVidias can render 'complex' scenes much quicker (specially things that relay on shaders such as clouds, high water settings, buildings etc.), so the CPU doesn't have to wait for a particular scene to be rendered. Remember, the FASTER the card 'renders' a scene, the faster the 'frames' will be processed and the CPU will keep producing them! so, as you see, there needs to be 'BALANCE'. remember, that any complex system will be limited by the speed of the slowest running member on the system. Now, back to video card comparisons: The downside to the nVidias?? THEY SUCK at reading instructions from the command buffer fast enough, so they can be stalled by the CPU IF you are running high frame rates and using complex autogen (which is what fills the command buffer quicker, specially after SP2 where there is massive object batching per frame) so when using nVidias LIMITING your framerate to 25-30FPS and lowering autogen is paramaunt. (including the steps I have already mentioned) like vsync OFF, single monitor setup, No ENBSeries and application controlled AA and AF. but don't worry.. The GTX 480's will change all that :) they have 480 shader processors :) still much less than the ATI's but enough to give you Flightsim nirvana and turn FSX into a whole new ball game. So, IT IS completely possible to achieve what everyone though was a dream. FULL MAXED sliders and fluidity (I don't include car traffic) MAX 2.0 Water (which is a killer) or bloom (the other killer) but you can still have pretty descent AI traffic and easily achieve 20-25 FPS under the most demanding conceivable situation, thats quite good.

So... IF you understand the above information COMPLETELY and you are a competent guy that knows how to tweak your fsx.cfg file, then by all means, give this a go.. otherwise, don't even think about trying it, and please, don't private message me because I'll not respond. I'm providing all this information for the benefit of the community.

The tweaks that you need to add to the fsx.cfg file are:

[BufferPools]
UsePools=0 // (note that PoolSize is ignored if UsePools equals 0)

[GRAPHICS]
HIGHMEMFIX=1 // Fixes errors with texture addressing modes in WDDM1.0 and 1.1 when using a lot of video memory

The HIGHMEMFIX=1 you see above, fixes a bug in the FSX engine on how it handles texture addressing modes (Wrap,Clamp) and initial render states on single pass shaders, it will completely prevent textures, buildings and entire cockpits from dissapearing! this 'bug' is triggered when there is a high video memory usage situation. so, enjoy :) this is my way of giving to a community that has given me so much over the years.

SPECIAL THANKS:

To all the guys at Avsim, specially Ryan (from PMDG), David Roch, Stephen, Mitch, David Alexander, J van E, Jjjallen, PingPong, DJJose and all those who supported me since DAY 1, trying stuff, reporting back and being extremely supportive, despite the Party Poopers that tried to (using stupid baseless technical explanations) to discredit me. and guys... I REALLY need a break, so don't freak out if I take a long one! ;) (also excuse any mispellings, english is not my mother tongue)
 
Last edited:
Jesus, great post for optimizing the flying side of FSX! Since the focus of this site is the developing of content, you may not get the same kind of response I see to your posts at AVSIM. I don't think your post had any "ah has" for developing differently. Am I right?

No big deal, just fyi!

Best,
Bob
 
Jesus, great post for optimizing the flying side of FSX! Since the focus of this site is the developing of content, you may not get the same kind of response I see to your posts at AVSIM. I don't think your post had any "ah has" for developing differently. Am I right?

No big deal, just fyi!

Best,
Bob

I can assure that, some developers here have experienced the problem with dissapearing textures and also feel contrained because of the lack of 'CPU power' for developing certain features, so.. on the contrary, I think its good news for them :)

And my secret plan is to draw ex MS from the dark to comment on this issues ;) because I know they lurk around and they ignore me when I write them.. and they know who they are ;)
 
I think anyone who uses FSX whether a developer or not will be interested in anything that improves overall performance.

I suspect that you will have some difficulty in getting comments from MS or ex MS people. As you know most of the ACES team is long gone but are probably still bound by all the NDAs and so on that bound them when they worked on FSX.
 
I think anyone who uses FSX whether a As you know most of the ACES team is long gone but are probably still bound by all
the NDAs and so on that bound them when they worked on FSX.

I understand that, but.. how big of a secret can be commenting on
HIGHMEMFIX for example? my point is that, the effort objective is to make something better, and that 'something' is their own product!

oh well.. Microsoft doesn't care, then I should't be going crazy about it. thanks anyway :)
 
i agree up to a point

i build and clock my own systems...that is a pretty good background for tuning and tweaking, some people are looking for a magic tweak for theyre over the counter box....but they prob wont be on this forum...good tech
argument, so ta for that,,ati have a prob with 2d, bezier curvses etc...ime waiting for the fermi to be tested.....jim
 
It looks like I was GPU bound in the first place with my 8800 GTS
- no improvement in frame rates for me :(
 
Hello:

Thanks very much for posting this here ! :)

And many thanks as well for persevering as you have... in spite of FS Community responses, and what one might perceive as ACES' apparent obfuscation and/or lack of documentation on these matters concerning FSX performance (...and limited ongoing clarification after SP1 and especially SP2... as to what one might additionally tweak to optimize one's own hardware / software setup for dealing with this aspect of how FSX works "under the hood" with data loading, rendering, data transfer etc.). :banghead:


IMHO, performance may be even more critical to FS Developers than some recreational FS flyers, as they need a clean and stable setup devoid of glitches, as well as a fast loading /reloading system that can also work at low altitudes in high scenery complexity areas for an extended time without graphical anomalies, and without stutters, lag in scene rendering, or worse yet... crashing. :idea:



FYI for interested readers: A recent thread on related issues with these tweaks:

http://www.sim-outhouse.com/sohforums/showthread.php?t=34485


...And an AVSIM thread with more details on these matters:

http://forums1.avsim.net/index.php?showtopic=280688&st=160




Jesus: Here's hoping you'll discover and share even more insights with us in a "2nd coming" ...after you've taken a well-deserved break ! :cool:

Take care, and stay well.

GaryGB
 
Last edited:
Jesus: Here's hoping you'll discover and share even more insights with us in a "2nd coming" ...after you've taken a well-deserved break ! :cool:

Will do :) next frontier is 'visuals'. I don't think we can get more performance out of this!

Hint: Visuals meaning:

[GRAPHICS]
ALLOW_SHADER_30=1

and shader folder compile function manipulation ;)

Probably FSDeveloper would be a good place to 'discuss' it ;)
 
@ Gary...

Any developer who's trying to provide content that will please the public will not be well served to have an ultra tweaked performance development computer. He will be unable to gauge the performance his product will provide for the majority of his users.

@ Scruffy and Jesus
My previous post to Jesus was made on a simple (perhaps errant) assumption. Which is, everyone here is like me in that we are designing and modelling as our hobby. Thus, the actual FSX is my rendering machine. That's true for me 90% of the time, so how my machine could be optimized just doesn't hit my interest.

Now, all assumptions put me at risk...if the board here is full of folks that don't develop with most of their time, and really work hard at squeezing their frames per second....my apology to Jesus.
 
@ Gary...

Any developer who's trying to provide content that will please the public will not be well served to have an ultra tweaked performance development computer.

He will be unable to gauge the performance his product will provide for the majority of his users.Now, all assumptions put me at risk...if the board here is full of folks that don't develop with most of their time, and really work hard at squeezing their frames per second....my apology to Jesus.

Your point is certainly valid, and is -in fact- the reason why I have multiple installations of FS9 and FSX on my flightsim 'puter!

I keep one version of each sim completely "stock-virgin" just for development and testing purposes.

When I want to just "fly for fun," I use my "full boat, fully tweaked" installations! :cool:

When launching FS9 or FSX from their desktop icons, they call a tiny batch file that simply renames folders as required so the correct .cfg files are used by the sim.
 
Last edited:
Efficient programming, is based on the premise of limited computing resources.. the surplus, is just that ;) an added plus.

Altough I am NOT a Simconnect developer, I am a backend client-server programmer. I don't cater to the general plublic I mostly work with API's and database backends, so.. part of my (real) work, is get the last drop of juice of the hardware I have available.. I aplied this concepts to FSX and the results of my analysis were... positive :)

So, yes.. I completely understand your point... :) I can't surely know how other's people hardware perform if I don;t control it, but as developers, is good to know what steps can we follow to make our apps perform better.
 
If nothing else, your contributions at least give us developers something we can suggest to our customers, as methods that might increase performance of our products on their hardware...

...to which therefore I thank thee! :D
 
Last edited:
@ Gary...

Any developer who's trying to provide content that will please the public will not be well served to have an ultra tweaked performance development computer. He will be unable to gauge the performance his product will provide for the majority of his users.

@ Scruffy and Jesus
My previous post to Jesus was made on a simple (perhaps errant) assumption. Which is, everyone here is like me in that we are designing and modeling as our hobby. Thus, the actual FSX is my rendering machine. That's true for me 90% of the time, so how my machine could be optimized just doesn't hit my interest.

Now, all assumptions put me at risk...if the board here is full of folks that don't develop with most of their time, and really work hard at squeezing their frames per second....my apology to Jesus.
Hi Bob:

I agree that some in-house testing of one's projects might best be conducted in part on "average" hardware... with a "default" setup configuration of the OS and FSX; and of course for external testing, one would hope to have a project evaluated on a mix of different systems and setups. :)

While in development, though, I have personally found it necessary with what limited time and energy I have, to optimize my production system(s) so (hopefully) I can achieve more efficient results with less hindrance to the creative process ... and an ongoing learning process.

And wherever possible, I'd do my testing on a mix of "sub-optimal" hardware and OS / FSX setup configurations before I'd contemplate a release. ;)


Certainly the tweaking process can both require and tempt a lot of one's time and energy away from the development process too. :eek:

But, if all goes well, such tweaking only takes place when I'm willfully chasing that fascination ...rather than reconfiguring under duress of performance problems. :o



I believe it would be beneficial to have discussion threads here at FS Developer which explore such FS system performance matters as are presented by the OP. :stirthepo


IMHO, one is more likely to gain some valuable insights through such dialog that might benefit both the Developer and end user alike. :idea:

Perhaps through open discussion by interested parties, we might discover how to maximize our time, since I daresay most FS Developers "develop" in their "spare" time (...and "Time is money, and all that"). :twocents:


But also, we might benefit the FS Community of both FS Developers and end users by identifying the limitations and workarounds for a given version of FS as it relates to system configuration and performance.


Perhaps we might even see here at FSDeveloper, the evolution of a consensus document of "best practices" and "caveats" for FS content creation that will result in both "professional" and "amateur" add-ons that allow for a better FS experience by all.

And perhaps we thereby might see openly accessible "suggested guidelines" based on insight and testing that could assist the development community to avoid creating potentially incompatible add-ons, or add-ons which ultimately compel substantial tweaking by the end-user (whether payware or freeware) in order to be able to use a specific add-on (...or all of a particular group of popular and "performance-demanding" add-ons) with their otherwise preferred FS system configuration. :cool:


PS: I also think it might be a good idea to have a centralized location at FSDeveloper for "Tips & Tweaks" (including hardware OS and FS configuration) that could (within reason, topically) assist the FS Development process, and to have indexes for the on-site search engine at FSDeveloper updated more often; searching all over any individual FS website (or other and multiple FS websites) to find something is currently a necessary evil that can expend vast amounts of a developer's time that could otherwise have been spent, well... developing ! :rolleyes:


GaryGB
 
Last edited:
Well put Gary, and I can't argue with your intentions. As I've sat back and thought about my reaction...I suspect its due to having read too many posts over the last 5 (or has it been 20) years with confusing, contradicting, inconsistent, theories, and it becomes a thing of its own....and to me a major distraction to think about.

Last fall, I built a new computer. Selected an i7-860 on the p55 chipset, gave it lots of ram, one of the top air cooled h/s fan combos and put it in a good airflow case. Then overclocked it mildly (from 2.83ghz standard clock to 3.5ghz). Stress tested it thoughougly, maintained voltages well within intel specification, and temps never measure over 68C even after 8 hours of 100% all cores, all thread using LinX.

When I loaded fsx, the machine at 2.83 ghz was still chunky with lots of high settings. At the O/c Settings, fsx really runs nicely. Sure, I can chunk it up still with bloom and stuff like that, but I just don't use bloom and stuff like that.

And that's with no tweaks. Right out of the box with the SPs and Accel installed.

I"m sure it could be better if I studied tweaks, but I don't want to bother. Now, I read Avsim pretty frequently, and I read fsdeveloper multiple times every day. I find it soothing not to wade thru tweaker posts here, and I know JUST where to go to find them.

In fact, Jesus has explained in great detail the same info here as he had previously at Avsim. Does every site have to serve every topic?

Bob
 
Hi Bob:

You've made some very good and practical points; as I ponder the situation further, I'm inclined to agree even more with your ideas. :)


Jesus' / bojote's AVSIM Topic: "[BufferPools] PoolSize=0 the holy grail of FSX performance..."

http://forums1.avsim.net/index.php?showtopic=275328

...reportedly set an all time AVSIM forum traffic record of 47,652 views with 1,061 replies before it was brought to a benevolent and courteous conclusion on 7th April 2010 - 12:36 PM via a last post by moderator David Roch.


Jesus was very kind in having summarized his findings in a document similar if not identical to the OP of this thread in a stickie pinned onto the "Important Topics" section atop the AVSIM FSX Forum first page:

http://forums1.avsim.net/index.php?showtopic=281538


I must admit I did not have time to follow all of that original thread, and I was concerned that eventually I'd have to do what I often have to do when trying to figure out an arcane FS SDK issue... read that thread and all the other threads that it spawned there and elsewhere all over the FS websites trying to achieve a consensus from vast amounts of posts and various opinions. :rolleyes:


BTW: I believe that having to search all over the internet seeking clarification on FS topics is possibly the absolute worst aspect of profound disorganization that plagues the FS community from the standpoint of time expenditure, and worse yet... lost "spare-time" productivity.

The AVSIM "hack" nearly lost one of the most extensive repositories of assets created by the hard working "FS Community"; that freely shared work (hosted online by AVSIM in exchange for incidentally earned advertising revenue), was IMHO callously given short shrift by AVSIM's appallingly inadequate security and backup protocols.:alert:

To this day I continue to receive spam from a specific FS retailer that I have traced to the reported security breach of the AVSIM registered user e-mail database, and I continue to see screenies and attachments pertinent to threads deleted from forum threads rather than being archived along with the rest of the content created by the FS Community members; this on top of having a "time limit" imposed by AVSIM on how long one has to edit and/or correct info in our own posts! :mad:


Thus, I do see the need for some redundancy of important archives being kept in a number of locations, and to the extent that Jesus would be so kind as to contribute his "summary" documents on various aspects of the topics he is pursuing, I'd hope to see them "archived" here at FS Developer somewhere in the WIKI section.

I also think there could be some benefit in placing copies of such "summaries" at Flightsim.Com and the Scenery.Org website (although they occasionally make me nervous when the former says "all nodes are busy", and the latter has "alerts" stating that due to inadequate support by visitors, the website has / is at risk for going... offline).

http://www.scenery.org/design.htm



But, to be sure, I am very grateful that the topic the OP has presented here has surfaced initially at AVSIM, and has led to extensive exploration of what we might further do to optimize our FSX systems; I hope such exploration will continue to be an ongoing process that expands into other areas (as Jesus has intimated may already be underway there and elsewhere). :D


Jesus has subsequently been able to establish a good base of cooperative investigators via his AVSIM threads, and has established a good working relationship with the PMDG group (and I presume some others) that may lead to some excellent problem solving for particularly demanding add-ons.



Although I would like to see a FS Developer "System Optimization Tips & Tricks" forum and some "summary" documents on such system optimization topics in the WIKI area, I suppose it might be best for most of the ongoing high bandwidth volume dialog and research on this FS system tweaking to continue where it has been at AVSIM and sites elsewhere that are better supported by advertising revenues.

That way, IMHO, FSDeveloper.Com (which I assume to be a privately operated server that may earn some revenue to help pay for its hosting and bandwidth via its modest advertising revenue on a much smaller scale than ex: AVSIM) ...can continue to economically maintain its web presence as a primarily FS Development discussion, problem solving, and reference type of website. ;)


And then, those inclined to leave the relatively peaceful (yet still amazingly creative and innovative) environment of FS Developer can still put on their hip waders and body armor to go off into the AVSIM forum "arena" (where, IMO, all too often "no good deed goes unpunished") in pursuit of some FPS excitement. :p


< Hmmm... "FPS": -was it "First Person Shooter" -or "Frames Per Second" ? oops, maybe there's not much difference in some hotly contested AVSIM threads ! :rotfl: >


So, may I suggest as an updated proposal, that we test the waters gently here... with an emphasis on "summaries" of what is known "110 %", along with concise indications of what is "un-certain"... and which subjects merit further inquiry when it comes to such FS system optimization topics as may arise here at FSDeveloper in addition to other FS websites. :duck:


Also, like most FS Developers in need of optimized time expenditure more than anything else, I would be very appreciative if all participants in such discussions would please clearly indicate at all times possible, whether something does or does not apply to systems using AMD single or multi-core CPUs, ATI GPUs, and Windows XP platforms versus Intel CPUs / NVidia GPUs / Vista / Win 7 OS platforms.


Hope these ideas help ! :idea:

GaryGB
 
Last edited:
The tweaks that you need to add to the fsx.cfg file are:

[BufferPools]
UsePools=0 // (note that PoolSize is ignored if UsePools equals 0)

[GRAPHICS]
HIGHMEMFIX=1 // Fixes errors with texture addressing modes in WDDM1.0 and 1.1 when using a lot of video memory

A few questions:

1. Will (should) this work on a laptop?

2. All I have to do is add the above to the fsx.cfg for the effects to (hopefully) come into effect?

3. If it doesn't work, all I have to do is remove the above from the fsx.cfg?

Thanks
 
I'd like to add an observation. Don't get my wrong, I believe in tweaks.

But.... since my last upgrade, I'm one of those people who haven't meant a tweak that does measurable good. Not that I have a great machine, or that I'm an expert a setting it up. Every time I come across something, I give it a shot. Of course these things work for others. That's a good thing. Just not for me. And that's OK, too. For the most part, I'm happy with my sim. We all want the best we can get. I keep my eyes open. Isn't it interesting, the wide variety of results we get.

Just an observation...


Bob
 
All I can say is that ever since adding the suggested entries to my fsx.cfg file, I've had FSX running 24/7 for nearly two full weeks with nary a hiccup, stutter, or hint of texture loading/display issues...

...and an average 30% increase of frame rate as a cherry on top!

Kudos, to Jesus for his and his intrepid testers for their tireless work! :cool:
 
Hi All:

I just implemented this in my FSX.Cfg file (I changed nothing else; and I use no explicit "BufferPools" statement either) :

[Graphics]
HIGHMEMFIX=1
STALE_BUFFER_THRESHOLD=2147483647



On this hastily built FSX test system (running on an HD3300 integrated graphics chip set) I am now able to able to fly FTX PNW at 1600 x 1200 x32 at 20 FPS with no micro-stutters, and without the prior occasional nagging slow ground texture resolution issues (these would display as water or striped textures on the ground in some custom land class texture polygon areas... mostly sloped hillsides). :shock:


This is definitely worth a try (...as always, YMMV) ! :idea:


NOTE: To disable it, just put a double slash " // " at the beginning of the line in FSX.Cfg; a double slash turns any text to its right into a comment.


Thanks again, Jesus ! :p

GaryGB
 
Last edited:
Back
Top