~ Thank you Jesus ~ Jesus Altuve, that is. * FSX Important *
Results 1 to 22 of 22

Thread: ~ Thank you Jesus ~ Jesus Altuve, that is. * FSX Important *

  1. #1

    ~ Thank you Jesus ~ Jesus Altuve, that is. * FSX Important *

    .
    *All credit for the following goes to the author, Mr. Jesus Altuve. http://forums1.avsim.net/index.php?showtopic=281538 Though English is not his mother tongue he does okay in imparting his thoughts in his own words after investing much time into understanding FSX. Have taken the liberty of correcting many minor gramatical errors, punctuations & capitalization throughout this gem for fluidity...

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    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 approximately 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 especially 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 succession, 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 synchronize the CPU and the GPU in terms of instructions processed. 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 instructions 'directly' to the 'Command Buffer', which is the one that the Video card reads to 'draw' the objects onscreen.

    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 processing (the command buffer its a ring). It's 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 impossible that it will 'fill' the command buffer with instructions. The 'Application 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 excessive amount of objects for the video card to process.

    So, why does Microsoft include an 'application managed' Buffer (also called Explicit Vertex Buffers)? They did so, so ANYONE could use FSX regardless of setup and ensure 'up to a point' that this will perform reliably independently 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 amount of resources that are now allocated to your current flying session! Now... do you understand why this tweak is SO powerful 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 EVERYTHING you throw at it? Remember... this is NOT about 'raw' power... this is about the card's 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 programmable shaders! They are perfectly balanced!

    Well, you need to start forgetting EVERYTHING you have learned in the past 4 years... especially things like:

    (AntiAliasing) but only when it is controlled by nHancer
    (Anisotropic 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 [implementations] KILL the card's 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 AntiAlias 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... especially if using nVidia cards (ATI's don't have this problem, more on that later).

    One side note: ATI's 5870 vs nVidias GTX 285 they are both EXCELLENT 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, IT'S IMPOSSIBLE TO CRASH IT! I could[n't] crash mine (I only owned it for like 2 days) no matter what I tried, but I lost 6FPS! To me that's unacceptable.

    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 (especially 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 [then] 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 paramount (including the steps I have already mentioned) like vSync OFF, single monitor setup, NO ENB-Series 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 decent AI traffic and easily achieve 20-25 FPS under the most demanding & conceivable situation, that's 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. Use 1 if you experience crashes )
    When you see 'toggle' values (1 or 0) it means ON/OFF - UsePools its an ON / OFF value (1 or 0)
    PoolSize its a 'size' value (in bytes) If you 'DISABLE' the pools, you will get increased
    performance, AND ALSO, instability if you don't 'balance' your components and sliders
    appropriately, in case of instability, then simply DO use pools by changing the value of UsePools
    to 1 and 'adjust' PoolSize. BE CAREFUL (and forget everything you have been told about this value)
    It does NOT use video memory, PERIOD. It uses SYSTEM memory, because its a special type of pool
    called Explicit Vertex buffer which DOESN'T GO INTO VIDEO MEMORY unless they have A VERY SPECIFIC FLAG
    (and they don't). More info here: http://msdn.microsoft.com/en-us/library/ff539490.aspx
    You can also do your own tests and see how 'increasing' PoolSize affects the size of the fsx.exe process proportionally.

    [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 disappearing! 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.


    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    OPTIONAL:

    [GRAPHICS]
    SHADER_CACHE_VERSION=1
    Increment this number EVERYTIME you change fsx.cfg (it simply rebuilds the shader cache)


    [DISPLAY]
    TextureMaxLoad=9
    Careful! CAN induce stutters on LOW END systems! Use multiples of 3 *ONLY* (3, 6, 9 etc) perfect for PhotoRealistic scenery and PNW.

    The formula on how to determine your 'optimal' TextureMaxLoad goes like this (credit to Steve Lacey here http://www.steve-lacey.com/blogarchives/2005/11/the_blurries.shtml) [Page not found. ~dw~]

    If UPPER_FRAMERATE_LIMIT exists, then:
    MAX_TEXTURE_DATA = (TEXTURE_MAX_LOAD * (TextureMaxLoad * TEXTURE_BANDWIDTH_MULTIPLIER)) / UPPER_FRAMERATE_LIMIT

    If UPPER_FRAMERATE_LIMIT doesn't exist (UNLIMITED FRAMES) then:
    MAX_TEXTURE_DATA = TextureMaxLoad * TEXTURE_MAX_LOAD

    [Would like to see the above explained more clearly. ~dw~]

    As you can see above, TEXTURE_BANDWIDTH_MULTIPLIER its just that, a multiplier. Evidently, changing it DOES change things, however,
    when running UNLIMITED frames it is USELESS, so you are better of playing with TextureMaxLoad directly. Be VERY CAREFUL, the 'resulting'
    value of this formula (MAX_TEXTURE_DATA) corresponds to the MAXIMUM number of bytes the TEXTURE MANAGER is allowed to 'upload' per
    frame. If the resulting value (in bytes) for MAX_TEXTURE_DATA is TOO HIGH you will spike your GPU! (and cause a stutter), so this is a
    'test and see' value. Ideally, you'll see an impact on COMPLEX high resolution textures sceneries like PNW and/or PhotoReal scenery.
    It is important to mention that THIS value does NOT have an impact on CPU if you are running a Multiple core setup, due to the texture
    manager threads running in the cores responsible for texture loading and object batching (which are the last 3 if you have 4 cores).

    Now, the following requires a careful explanation... please, READ. This 'assumes' you have an i7 with Hyperthreading OFF... so, it goes like this:

    CORE0 CORE1 CORE2 CORE3

    CORE0 is responsible for: Fibers and main scheduler
    CORE1, CORE2 and CORE3 are responsible for the Texture Manager AND Object Batching (Autogen)

    'Fibers' are like small processes that do 'things' cooperatively with other 'processeses' (sorry, I know this is not I high tech explanation).
    I'm just trying to cater for everyone. In FSX. Fibers are responsible for the 'loading' of the terrain system. They need to communicate with the
    main scheduler (which also RUNS on CORE0) to 'coordinate' and cooperatively multitask on terrain rendering every time a 'frame' is rendered.

    Those two, the fibers AND the main scheduler are running on the SAME CORE... now, here's a trick: Fibers are STUCK to CORE0, you can not move them
    out of there, however, YOU CAN move the main scheduler to run on another core!! So, if you do this:

    [JOBSCHEDULER]
    AffinityMask=14

    You are telling FSX to use only CORE1, CORE2 and CORE3... so, what about CORE0? It STILL runs the FIBERS! because they are not bound to the AffinityMask
    setting. So, what you are doing is making things now much more efficient. So now, FSX will run like this:

    CORE0 CORE1 CORE2 CORE3

    CORE0 is responsible for: Fibers
    CORE1 is responsible for: main scheduler
    CORE2 and CORE3 are responsible for the Texture Manager AND Object Batching (Autogen)

    That's great balance (and a little increase in performance too)! That's why so many people say FIBER_FRAME_TIME_FRACTION affects their performance
    when they lower it! Of course it does, we'll talk about that now.

    Now, let's micro-manage the 'fibers' and the terrain loading system. Consider this:

    [MAIN]
    FIBER_FRAME_TIME_FRACTION=0.25

    The above value means that 0.25 (which means 25%) percentage! It's the % amount of 'time' that the 'fibers' will 'cooperate' with the main scheduler
    to 'render' the terrain system. So, assume you run your sim LOCKED to 25 FPS... that's 25 Frames EACH second, correct? 1 second is the same as
    1000 milliseconds. So, if you divide 1000 milliseconds / 25 frames what do you have? You have milliseconds PER frame. That number is 40 milliseconds.
    So now we KNOW that EACH frame takes approximately 40 milliseconds to render (if running frames locked at 25). Now, out of those 40 milliseconds
    PER frame, HOW MUCH time (or % of time) you want the fiber to cooperatively multitask with the main scheduler? Well... if you read re-read and analyze
    what Adam told Phil Taylor you'll see Adam hinted Taylor on 'what' the 'optimal' time is to do just that, Adam 'optimal' value required for the fiber
    to communicate with the thread is 10ms read here: (that's why they came up with the 0.33)

    http://blogs.msdn.com/ptaylor/archive/2007/06/01/fsx-tweak-of-the-week-or-2.aspx

    So, that value should be adjusted according to your frame rate. Of course, it REALLY doesn't have any IMPACT whatsoever UNLESS you are running a SINGLE core machine (so you can not offload the scheduler) or you run tileproxy or something VERY heavy. For cases like tile proxy or VERY complex terrain I assume 10ms is simply not enough so you need to give the fiber MORE TIME
    otherwise, the blurries are going to be TERRIBLE!

    And talking about blurries, terrain and fiber time... we have:

    [TERRAIN]
    SWAP_WAIT_TIMEOUT=10
    And you sure are asking why I have '10' there? 10 what? Frames? Well... according to Phil this is a value between 1-60 'frames'
    regardless of that Phil said, this SWAP_WAIT_TIMEOUT only has an impact when the time allocated to fibers is increased... to me
    SWAP_WAIT_TIMEOUT is not about 'frames' is about 'timeouts' in milliseconds (per frame) so probably it was easier to say it was 'frames' so we would
    not get confused play with it (specially if using HIGH FIBER_FRAME_TIME_FRACTION values) but don't expect a SINGLE frame in performance
    increase... this only helps with terrain loading and blurries. So try to adjust the timeout to the time fraction that it takes for the fiber to communicate
    with the main thread. That's why I have '10' there.

    Now... lets talk about 'frame locking'. You need to understand the following:

    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 succession, say, for example 25 'photos' per second, the perceived sensation is that you are 'moving' at 25 frames per second. FPS = Frames per Second, each 'frame' is the 'photo' I'm talking about.

    So, the above is VERY important to take into account, because in FSX all operations!: terrain rendering, object batching, etc. occur at the single 'frame' level... what does that mean to you? I means, the HIGHER the frames, the MORE work FSX needs to do... so say, for example, that you run your SIM at 30 FPS and you like it... but, then someone got into your head the idea that if its not 60 FPS then it is NOT real. Well... from 30 to 60 FSX will DOUBLE the amount of things that it needs to do! So don't be surprised when you start seeing a Christmas tree and strange spikes coming from the ground. I won't get into the 'FPS eye perceived thing' that has plagued our forums since day 1. Run the sim at the FPS you like! I personally got USED to run at 25, and let me tell you its perfectly fine to me... because I got USED TO IT... I hated it, but after a week you simply 'adjust' your eyes to it.

    So, should you use the FPS limiter or run to UNLIMITED? Well it depends on your flying style. If you run default planes or non CPU intensive planes or only 2-D cockpits then your CPU is NOT going to be overworked. In that case simply go for the frame lock inside FSX, period.

    Now, if you fly COMPLEX a/c specially using the VC you NEED to set it to unlimited! However, there is a problem. What happens with what I just told you about the sim working HARDER the higher the frames? What happens if frames start jumping from 30 to 60 then to 25 and again to 60? Where is the 'balance' here? What if you have "UsePools=0"? What do you expect will happen when you get a 'sudden' jump to 70 FPS? CRASH! Besides, the 'perceived' sensation (because is not real) when frames 'jump' is a 'stutter' so you need 'smoothness' consistency... and that's where the EXTERNAL frame rate limiter can help you, capiche?

    Now, use this as a REFERENCE... especially if using a HIGH SPEED CPU, and simply increase the Scenery Complexity and Autogen one at a time, and run your frames locked either in FSX or with the external limiter and setting the option to unlimited inside the sim. You want to find your 'sweet' spot, or the point where the GPU is not being overworked. I suggest, as 'reference', [that] you use a GPU monitoring tool... again, as reference, because what you see there is NOT 100% accurate.

    .

    SPECIAL THANKS:
    I want to extend a public, sincere thanks to PMDG, because they were the only development group that took the initiative to 'organize' and actively work on ways to find a solution to the texture corruption problems. Without their involvement this could not have been possible. So, show some appreciation guys and buy something from them. I based MUCH of my investigations on Ryan's work and theories... so, please: THEY DO DESERVE CREDIT TOO.

    To all the guys at Avsim, 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 misspellings, English is not my mother tongue). [Have helped you out here, Jesus. Some marked, most not. ~dw~]

    Jesus Altuve, April 2010

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    Spending a couple of more hours getting my head around that info along with messing with the concepts & tweaks in that post(after all, having spent dozens of hours trying to get my wee quad core & rig to run FSX smoothly, what is a few more hours?),for the first time in 16 months of flying FSX: this looks more promising than anything else hands down. Initial results are amazing on my little Phenom X4 quad @ 2.2 Ghz, 5 GB DDR2 ram, nVidia 9500 GT 1 GB & a fat SATA 7200 rpm drive. Have never flown FSX so smoothly, all that remains for me is to find that special "sweet spot" of the video bandwidth multi for my particular system, imo. Most impressive, to say the least. Thank you, Jesus Altuve!

    Jesus Altuve gave us a real gift, imo, & the man has worked very hard over the course of months to help make FSX things better for many of us.

    *They are the first two .cfg file settings he lists that are the most important.*Simple, really.

    Then you can play with the others he mentions, should you so desire. Am here to tell you: This Is Big.

    Now then, after messing around for hours more, am thinking that if Jesus is correct in his assertion of perhaps as much as a 30% increase in performance may be realized then those presently having processors running in the 4 Ghz range may well be able to run all sliders right & still remain above 20 fps in places like London & NYC. Paxx, others: let us know what you think & come up with. If your card is brutally strong & your cpu humming great then this could very well put you over the top.

    Personally, just using nothing but going back to ingame, application-controlled AA & AS (yeah, I know it looks worse than nHanser controlled but hey- for the smoothness I'm experiencing then it's way worth it) as well as employing the first 2 FSX.cfg file tweaks that Jesus lists, staying away from all others for now *except* for the reintroduction of the affinity mask entry (set @ "=14"). My card is the bottleneck right now. Having a much better card that will produce the images faster than the cpu can send them is the next step... but ladies & gentlemen, boys & girls:It Works! My FSX has never been smoother, 95+% of the cursed "micro-stutters" now gone. Am believing that a stronger card for my rig & there will be no more stalling/stuttering whatsoever.

    Read the post of the above link, then study it. Study again & implement the first two... but make sure you got your head around the principles, all layed out in layman's terms, albeit gramatical errors & the like. You'll figure it out with a bit of effort. Best... ~dw~

    .

    ​.

  2. #2

    Thanks. I'm going to give this a go. :salute:

    Ben
    SYSTEM: Windows 7 Ultimate 64bit |PSU - CoolMaster 1000Watt Gold edition |MoBo - Asus Sabertooth X79 |CPU - Intel i7 3930K OC (4.6 GHz) |Display - ATI Gigabyte 7970 HD |3X4GB G.Skill |Controls - TM HOTAS WARTHOG (Serial No. 4523) Saitek Rudder Pedals |TrackIR 4 Pro

  3. #3
    this is very useful!

  4. #4
    Sounds interesting but I just cant live without VSync
    Asus ROG Maximus XI Hero
    i9-9900K
    32Gb Corsair Vengeance Pro DDR4 3200MHz
    MSI RTX 2080Ti Ventus
    Corsair H115i Cooler
    Corsair RM850X PSU
    Phanteks Evolv X case
    Aser EB321HQU 32" Monitor 2560x1440
    Win 10
    Oculas Rift
    Logitek G25
    Saitek X55
    Saitek Pro Pedals
    Saitek Cessna Trim Wheel

  5. #5
    Senior Administrator Roger's Avatar
    Join Date
    Oct 2000
    Location
    EGCD...they bulldozed it!
    Age
    67
    Posts
    9,710
    I'm glad to see this is still being actively pursued at Avsim and Flightsim (well done boxcar) even if it hasn't raised much interest here.
    SYSTEM :
    OS:Win7 Home Premium 64 bit UAC OFF!
    DX version Dx10 with Steve's Fixer.
    Processor:I5 4670k overclocked to 4.4 gHz with Corsair CW-9060008-WW hydro cooler
    Motherboard:Z87
    RAM:16 gig 1866 gigaHz Corsair ram
    Video Card:MSI 1070 8 gig ram
    HD:2Tb Samsung 850 evo SSD

    To err is human; to forgive is divine

  6. #6
    Quote Originally Posted by Roger View Post
    I'm glad to see this is still being actively pursued at Avsim and Flightsim (well done boxcar) even if it hasn't raised much interest here.
    Roger the reason I am not pursuing is that I have no issues. FSX runs fast and smooth and I using the same Gigabyte X48 DQ-6 with a Q9550 OC to 4.0 Ghz. Even with the heavy hitter aircraft on frame rates in PNW I am staying at 36fps locked everywhere inside or outside the cockpit. I think I trust Nick N's advice over Jesus(Oh Lord what have I said ;0)). I haven't seen any major breakthroughs on their site that would make me alter what I have.
    Ted
    <input id="gwProxy" type="hidden"><!--Session data--><input onclick="jsCall();" id="jsProxy" type="hidden">
    Vivat Christus Rex! Ad maiorem Dei gloriam

  7. #7
    Senior Administrator Roger's Avatar
    Join Date
    Oct 2000
    Location
    EGCD...they bulldozed it!
    Age
    67
    Posts
    9,710
    Ted, it seems to benefit those who's systems are no longer leading edge as some of the posts at Flightsim seem to indicate, where real improvements are being realised. It needs much more researching but it appears that Jesus Altuve is on to something.
    SYSTEM :
    OS:Win7 Home Premium 64 bit UAC OFF!
    DX version Dx10 with Steve's Fixer.
    Processor:I5 4670k overclocked to 4.4 gHz with Corsair CW-9060008-WW hydro cooler
    Motherboard:Z87
    RAM:16 gig 1866 gigaHz Corsair ram
    Video Card:MSI 1070 8 gig ram
    HD:2Tb Samsung 850 evo SSD

    To err is human; to forgive is divine

  8. #8
    Quote Originally Posted by Roger View Post
    Ted, it seems to benefit those who's systems are no longer leading edge as some of the posts at Flightsim seem to indicate, where real improvements are being realised. It needs much more researching but it appears that Jesus Altuve is on to something.
    I agree it is possible. Maybe one day in the near future I will get a chance to run an experiment at TechCorp when we are not so swamped. If I do I will contact you with the results. Since it is not a mfgs product I will be able to release info on it.
    Ted
    <input id="gwProxy" type="hidden"><!--Session data--><input onclick="jsCall();" id="jsProxy" type="hidden">
    Vivat Christus Rex! Ad maiorem Dei gloriam

  9. #9
    .
    Thanks, fellas.

    Jesus' post was worth every bit of the hours of painstaking editing (I still missed a few things here & there but managed to smooth out most of it) & every bit of my hours of experimenting to finally, after 16 months of FSX on a wee rig, get her running smoothly.

    My basic specs: AMD Phenom X4 9550 quad @ 2.2 Ghz, nVidia 9500 GT 1 GB, 5 GB DDR2 ram, a fat 7200 rpm SATA HD. Easily 90% of my constant "micro-stutters" were cured with the implementation of Jesus' first two FSX.cfg file changes along with the AffintyMask=14 addition. Playing with others as well as sucking it up to go with a slightly lower, locked frame rate (that had made zero difference before) has me running 98% - 99% smoooooooooooooth. The only time FSX stutters at all now is when the processor simply cannot keep up once in a while when flying low @ 300+ KIAS. A mighty fine accomplishment that I'd never have realized without Mr. Altuve's help.

    .
    In summation:

    Those with wee little systems comparatively such as mine stand to gain much here in trying these things out.
    Those with systems already knocking down acceptable FSX performance will likely gain little or nothing from them.
    Am going to "swag" it & say that those running 2.8+ Ghz quadcores & 3.0+ Ghz duals will likely see little improvement. Would estimate my own rig's improvement at running FSX at no less than +20%, likely +25%. Albeit at a slower frmaerate now, it is now remarkably smooth.


    Have said it before & will say it again: Thank you Jesus Altuve! And thank you all thread participants for a good thread of respectful posts.
    .

    ​.

  10. #10
    I've been running this tweak for a month now. Thanks for the heads up.

    Not only am I getting smoother and much better performance, I can actually run some of the glass cockpits, and portovers without taking as drastic a hit.
    For example, I am finally able to enjoy flying the de Havilland Mosquito from AH with out it cutting my frame rates in half.
    "No, I'm not a good shot, but I shoot often." - Theodore "Teddy" Roosevelt

  11. #11
    Senior Administrator Roger's Avatar
    Join Date
    Oct 2000
    Location
    EGCD...they bulldozed it!
    Age
    67
    Posts
    9,710
    Port-overs really benefited as well as a more stable, overall performance for my mid-range system.
    SYSTEM :
    OS:Win7 Home Premium 64 bit UAC OFF!
    DX version Dx10 with Steve's Fixer.
    Processor:I5 4670k overclocked to 4.4 gHz with Corsair CW-9060008-WW hydro cooler
    Motherboard:Z87
    RAM:16 gig 1866 gigaHz Corsair ram
    Video Card:MSI 1070 8 gig ram
    HD:2Tb Samsung 850 evo SSD

    To err is human; to forgive is divine

  12. #12
    Charter Member 2015
    Join Date
    Nov 2007
    Location
    off the shoulder of Orion
    Posts
    4,026
    Quote Originally Posted by txnetcop View Post
    I agree it is possible. Maybe one day in the near future I will get a chance to run an experiment at TechCorp when we are not so swamped. If I do I will contact you with the results. Since it is not a mfgs product I will be able to release info on it.
    Ted
    <input id="gwProxy" type="hidden"><!--Session data--><input onclick="jsCall();" id="jsProxy" type="hidden">

    Sorry to be dragging up this thread again,Ted, but did you ever get a chance to experiment with this mod? I'm happy enough with my fsx performance as is...but if it'll lead to even smoother gameplay and a little fps boost I'll give it a try.
    I fly because it releases my mind from the tyranny of petty things — Antoine de Saint-Exupéry

  13. #13
    Senior Administrator Roger's Avatar
    Join Date
    Oct 2000
    Location
    EGCD...they bulldozed it!
    Age
    67
    Posts
    9,710
    Don't know about Ted but I have implemented all of Jesus' suggestions except the shaders mod and the end results have made my FsX/Acc experience much less twitchy than before. Micro-stutters have gone and his vsynch mod works well.
    SYSTEM :
    OS:Win7 Home Premium 64 bit UAC OFF!
    DX version Dx10 with Steve's Fixer.
    Processor:I5 4670k overclocked to 4.4 gHz with Corsair CW-9060008-WW hydro cooler
    Motherboard:Z87
    RAM:16 gig 1866 gigaHz Corsair ram
    Video Card:MSI 1070 8 gig ram
    HD:2Tb Samsung 850 evo SSD

    To err is human; to forgive is divine

  14. #14
    Charter Member 2015
    Join Date
    Nov 2007
    Location
    off the shoulder of Orion
    Posts
    4,026
    Thanks Roger.
    It's just that my FSX install is running sweet at the moment and I'm a little apprehensive of messing it up somehow. :d
    I fly because it releases my mind from the tyranny of petty things — Antoine de Saint-Exupéry

  15. #15
    With this tweak, I was finally able to have a very smooth low fly over Manhattan at dusk, on a F16. NEVER HAPPENED BEFORE

    Also, the phorealistic Utah's Blue Sky scenery gained in detail thanks to increased sliders setting, and again: NO appreciable stutter.


    I was prepared to replace my current GE Force GTS 8800, but now I think I can wait.

    Thanks to Mr. Jesus Altuve, and thanks to Boxcar for bringing this in !!! :ernae:

    Ezio
    :wave:

  16. #16
    Senior Administrator Roger's Avatar
    Join Date
    Oct 2000
    Location
    EGCD...they bulldozed it!
    Age
    67
    Posts
    9,710
    Most of Jesus' tweaks made a considerable difference to my FsX but the
    [JOBSCHEDULER]
    AffinityMask=14 caused me issues with 2 of the 4 cores running at 100% after 10 minutes or so flying, causing artefacts and loss of ground & sky textures . I reverted to
    [JOBSCHEDULER]
    AffinityMask=15
    and the issue has gone away.
    SYSTEM :
    OS:Win7 Home Premium 64 bit UAC OFF!
    DX version Dx10 with Steve's Fixer.
    Processor:I5 4670k overclocked to 4.4 gHz with Corsair CW-9060008-WW hydro cooler
    Motherboard:Z87
    RAM:16 gig 1866 gigaHz Corsair ram
    Video Card:MSI 1070 8 gig ram
    HD:2Tb Samsung 850 evo SSD

    To err is human; to forgive is divine

  17. #17
    Jesus actually recommends either AffinityMask=14 or AffinityMask=12. Have you tried that value ?
    Ro

  18. #18
    Senior Administrator Roger's Avatar
    Join Date
    Oct 2000
    Location
    EGCD...they bulldozed it!
    Age
    67
    Posts
    9,710
    Yep, I have a quad core Q6600 and 14 was what I had it set to and changed it back to 15.
    SYSTEM :
    OS:Win7 Home Premium 64 bit UAC OFF!
    DX version Dx10 with Steve's Fixer.
    Processor:I5 4670k overclocked to 4.4 gHz with Corsair CW-9060008-WW hydro cooler
    Motherboard:Z87
    RAM:16 gig 1866 gigaHz Corsair ram
    Video Card:MSI 1070 8 gig ram
    HD:2Tb Samsung 850 evo SSD

    To err is human; to forgive is divine

  19. #19
    Yes, I read your post. Did you read mine because I said that AffinityMask=12 was also recommended by Jesus ?

  20. #20
    Just tried out some of these tweaks......

    [BUFFERPOOLS]
    UsePools=0

    Bufferpools had the BIGGEST impact on my FSX (SP1) install. It got rid of my micro stuttering of my prop textures / prop animation when flying through clouds, AND then allowed me to finally use aircraft self-shadowing, AND also allowed me to add an additional layer of clouds......all this without a hint of micro stuttering. It's like I upgraded my computer without spending a dime!


    The following did not seem to have any impact on my FSX (SP1) install. But I'm not complaining in light of the results I got above.

    [GRAPHICS]
    HIGHMEMFIX=1

    [JOBSCHEDULER]
    AffinityMask=15 or 14 or 12

    I have not gotten around to fooling around with the rest of the tweaks, but I'm VERY happy as is.

    Regards,

    Tommy

  21. #21
    Quote Originally Posted by tommieboy View Post
    Just tried out some of these tweaks......

    [BUFFERPOOLS]
    UsePools=0

    Bufferpools had the BIGGEST impact on my FSX (SP1) install. It got rid of my micro stuttering of my prop textures / prop animation when flying through clouds, AND then allowed me to finally use aircraft self-shadowing, AND also allowed me to add an additional layer of clouds......all this without a hint of micro stuttering. It's like I upgraded my computer without spending a dime!


    The following did not seem to have any impact on my FSX (SP1) install. But I'm not complaining in light of the results I got above.

    [GRAPHICS]
    HIGHMEMFIX=1

    [JOBSCHEDULER]
    AffinityMask=15 or 14 or 12

    I have not gotten around to fooling around with the rest of the tweaks, but I'm VERY happy as is.

    Regards,

    Tommy
    More good news.....

    I originally took a noticeable FPS hit with I upgraded to SP2. so I went back to SP1 as noted above. I figured "what the heck" I'll try SP2 on more time with the tweaks as noted above. We'll SP2 runs just great with the tweaks as noted above; no loss of FPS. Jesus, this is great!


    Regards,

    Tommy

  22. #22
    Members + Mako8841's Avatar
    Join Date
    Aug 2014
    Location
    Originally from Miami, FL
    Age
    64
    Posts
    124

    Thanks Jesus, Thanks a Million!

    After simming for 30 years, FSX was always slow, shaky, stuttering, and very unstable. This tweak is the answer! It is so nice to have a smoooooooth flight for the first time. Thanks a million. To be able to understand, and figure out what MS had in mind with FSX and the programs before, to be able to come up with the right answers, and to give it to us... You are a great man to do such a great thing for us simmers. Ralph (Mako8841)

Similar Threads

  1. Jesus! Anyone seen this?
    By ijay in forum FSX General Discussion
    Replies: 48
    Last Post: May 25th, 2010, 02:41
  2. Has everyone heard the good news from Jesus Altuve?
    By 6297J in forum FSX General Discussion
    Replies: 27
    Last Post: April 7th, 2010, 22:28
  3. How old is Jesus?
    By Lionheart in forum Ickie's NewsHawks
    Replies: 44
    Last Post: December 29th, 2009, 15:25

Members who have read this thread: 8

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •