Hi guys,having recently had a new computer custom-built for FSX and trying to get my head around the incredible amount of info out there about tweaks and overclocking etc etc, all in the name of getting FSX to run at a decent FPS, I have a question......(I am not a computer expert, by any means....you're all welcome to laugh at this if you like...)My new system : Intel i7 990x @3.47GHz 6 core/12 thread, Sabertooth x58 MOBO, nVidia GTX 580 1,5 GB graphics, 24 GB DDR3 RAM, 1 TB HDD (nothing overclocked yet)One of my first flights on my new system was from ORBX's Cessnock to Tamworth on the MILVIZ C-310 and using REX2 for some weather. Having assigned REX2 to a different core using FSPS, my computer delivered a beautiful flight at 60FPS (locked at 60, same as my screens refresh rate). The way I understand it, assigning REX2 to use another core from the one running FSX is the reason it ran so well, and possible because REX2 is an executable (.exe) which runs outside of, and parallel to, FSX. My question is, what if add-on aircraft and sceneries were developed the same way? (as executables, running outside of and parallel to FSX) Theoretically I could then assign a different core/2 threads to each add-on I need for the flight? For example a flight from ORBX's Melbourne to Brisbane, using PMDGs Jetstream 41 and REX2 for weather. If I were able, via a simple software interface, to assign FSX one core, Melbourne another, Brisbane another, the J41 another, and REX2 another, would the performance of the whole lot not be great??? I would then have the power of each core running a seperate element of the flight. Just an idea.......could it not be done that way??Thought I'd throw that out there and see what you guys think? Or am I on the wrong track alltogether? As I said before, not much of a computer expert........

Have you tried running without setting REX2 on another core? I'm sure it'll still run at 60fps.Oh btw..24GBs of RAM?! WOW!!

Have you tried running without setting REX2 on another core? I'm sure it'll still run at 60fps.Oh btw..24GBs of RAM?! WOW!!

No, I haven't. Try that when I get home....I just know I uninstalled REX2 from my old 4-core setup because any clouds would kill the frame rates, so it was clear blue skies for me. FSX runs on my new one using just one core, as per normal, I think when I load REX2 onto that same core it'll probably slow things up badly. I'll give it a try though. Using two different cores sure got some jaw-dropping results though. Which gave me the idea about doing all add-ons that way. Cheers!

Good luck trying to run FSX on a Intel i7 990x @3.47GHz 6 core/12 thread CPU based system! Kidding you of course. Guys like you that have systems like this DESERVE to have problems. Karma?

Really...............helpful....................! No, I'm cool. Just think that externally coding our add-ons would make life easier, no? :(

I think everyone gets too hung up on FPS, reading tons of these types of threads in recent years/months, people always quote things like, oh i can get 100FPS or i can get 30FPS, or i only get 6FPS in busy airports. Granted FPS plays a part of the FSX experience, but the key should really be smooth flight. I have my FPS set to unlimited and i use FPS limiter to achieve an average FPS of 20 (as advised by Bojotes tweaking utility). Remember that typically movies play at an FPS of 25. So why would you want 60 when the naked eye cant percieve the difference. As I said before I have my rig at 20FPS and I get smooth flight, no issues. It goes without saying that low FPS will result in jumpy flight, but anything more than 25-30 IMHO seems pointless. My goal always has been to achieve smooth flight, but i have never tried to get my machine to give me super high FPS.My rig,Dual Core E8500 @ 4GHz - (overclocking gave me the most noticeable performance increase!!!)4gb Corsair Memory320Gb HDD for Win7 64bit1TB Samsung Spinpoint for FSX512MB Geforce XFX force 9800 GTX+Numerous addons and scenery packages etc - with smooth performance and good graphics. Obviously not having directly compared my machine to a more modern example i wouldnt know how good FSX may or may not be, but i have totally acceptable performance on a computer that is now 3 years old or so.Just more food for thoughtTom

I think everyone gets too hung up on FPS, reading tons of these types of threads in recent years/months, people always quote things like, oh i can get 100FPS or i can get 30FPS, or i only get 6FPS in busy airports. Granted FPS plays a part of the FSX experience, but the key should really be smooth flight. I have my FPS set to unlimited and i use FPS limiter to achieve an average FPS of 20 (as advised by Bojotes tweaking utility). Remember that typically movies play at an FPS of 25. So why would you want 60 when the naked eye cant percieve the difference. As I said before I have my rig at 20FPS and I get smooth flight, no issues. It goes without saying that low FPS will result in jumpy flight, but anything more than 25-30 IMHO seems pointless. My goal always has been to achieve smooth flight, but i have never tried to get my machine to give me super high FPS.My rig,Dual Core E8500 @ 4GHz - (overclocking gave me the most noticeable performance increase!!!)4gb Corsair Memory320Gb HDD for Win7 64bit1TB Samsung Spinpoint for FSX512MB Geforce XFX force 9800 GTX+Numerous addons and scenery packages etc - with smooth performance and good graphics. Obviously not having directly compared my machine to a more modern example i wouldnt know how good FSX may or may not be, but i have totally acceptable performance on a computer that is now 3 years old or so.Just more food for thoughtTom

Hi Tom, thoroughly agree with you about high FPS. Around 30 and smooth is just fine. My point is, when you try to land at an airport that is modelled as realistically as ORBX Tamworth for example, at high graphic settings a computer will slow down enough to make it unenjoyable. High frame rates at altitude will slow down drastically when you approach an airport or a city. I would like to prevent that from happening. If Tamworth, for example, or any other airport/scenery was being driven by it's own dedicated core, as it were, the slowdown shouldn't happen, and you could maintain smooth flight all through landing and taxiing in. With the standard of add-ons out there today, this is hardly possible at decent settings to get the most realistic effect, especially with weather and traffic going on. A lot of people are waiting for the 737NGX or Captainsim 777. How are those going to perform at airports like Melbourne or Brisbane? If these things were running externally on dedicated cores however.....Thanks for your reply!Regards, Wolftrack777

I think the problem is that, while gauges could maybe run on a different core, stuff like model, textures and all that has to be interpreted by the FS graphics engine and as such can not run outside of FS without having to run multiple copies of FS's graphics engine. It'll be the same thing for airport sceneries. The bgl files have to be interpreted and displayed by FS's graphics engine and as such can not exist outside of FS. What can be done, and FSDT did this, is have an external scripting program that you can call FS to load, perhaps on a different core. This engine can then modify the scenery by moving stuff around, but that's basically it.I think we might be really in luck with the PMDG 737NGX, by the way. I have read that for some testers it performs better than the J41, which, incidentally performs great for me around FPS intensive places such as OrbX's Melbourne and Canberra. Brisbane, however, is a complete and utter framehog for me and I hope they will release a v2, like they did for Melbourne.

If I were able, via a simple software interface, to assign FSX one core, Melbourne another, Brisbane another, the J41 another, and REX2 another, would the performance of the whole lot not be great??? I would then have the power of each core running a seperate element of the flight. Just an idea.......could it not be done that way??Thought I'd throw that out there and see what you guys think? Or am I on the wrong track alltogether? As I said before, not much of a computer expert........

Unfortunately, no. While the idea is a good one, all aircraft models must run "in-process," meaning that they could not be compiled as an application to load outside the sim.

Remember that typically movies play at an FPS of 25. So why would you want 60 when the naked eye cant percieve the difference.

Try trackIR and let me know if 40FPS makes no difference vs 25, and 60 vs 40 :(

Unfortunately, no. While the idea is a good one, all aircraft models must run "in-process," meaning that they could not be compiled as an application to load outside the sim.

It's surely possible to offload parts of airplane code on external processes, fact that nobody usually does that, doesn't mean it can't be done. Especially with airplane logic, which can be easily processed in an external application, and interfaced back with FSX either using Simconnect OR by setting L: variables the model or the gauge can respond to. It's always the same principle of "gauges must be as dumb as possible", which I always suggest to follow as a best practice. If gauges are doing complex stuff and calculation on their own, there's something wrong with the very design of the product. Gauges should ideally only *display* data, which was calculated elsewhere, and if the user presses a button on the gauge, the gauge itself shouldn't do anything other than simply pass the event to another process which will implement the effect.We are doing this with sceneries, we have a separate interpreted language that runs in an external application that runs alongside FSX, which means we can do very complex logic, without impacting a bit on the FSX process, and Windows itself will schedule our process to weight on free cores (and our executable is multithreaded as well on its own), but the same principle can be applied to airplanes too, we were toying the idea of making an airplane with its whole logic written in Python, with the interpreter running on its own core. Of course, a scenery rarely does something very complex procedurally, most we do right now are the various kind of docking systems or things like custom runway lights like THL, FAROS, the real advantage of this approach will be seen on our upcoming GSX program, which has quite complex pathfinding systems and even an internal IK solver, and all of this will run on multiple cores without affecting FSX at all, but an airplane, especially with instruments with complex logic like custom Autopilots, FMC, GPS, will surely benefit from this approach.Of course, this all covers offloading complex *logic*. If an airplane or a scenery is too complex *graphically* and is impacting FSX because of this, multithreaded programming will not help.

Try trackIR and let me know if 40FPS makes no difference vs 25, and 60 vs 40 :(

Spot on, for me anything below 30fps becomes sticky, more so if frame rate fluctuates when panning.Bryan.

Brisbane, however, is a complete and utter framehog for me and I hope they will release a v2, like they did for Melbourne.

They wont update YBBN, as far as ORBX are concerned there is nothing wrong with Brisbane.Bryan.

I don't understand why we keep hearing 25fps is the limit of the naked eye. Clearly it is not in video games / rendering!24fps works in movies because of the motion blur between frames.....at least that's my understanding of it.To get the same effect as film you need around 40 fps