For making FSX more mult-processor(multi core) friendly, I created a d3d9.dll proxy which intercepts all direct3D calls from FSX and send the data off to a different thread for processing. Along half way done, I decided to do some profiling of FSX's of direct3D. What I found is very interesting. I am running FSX with the system with spec in my sign. When running FSX with everything max out, it only spends between 1/4 to 1/3 of the time sending data to the video card. Also, FSX wasted very little time between frames. In other words, my little project, if sucessful, can only yield at most 30% performance increase. 30% doesn't sound that bad for an average application. However, for FSX, if you are getting 10fps, that will be 13fps, still choppy. I like to here your thoughts on this.

Hmmm...Well my first thought would be, if its that easy, why didn't ACES do it? Certainly everybody's capable of overlooking possibilities to do things better, but I gotta think the people at ACES are bright enough to not overlook something that simple. After all, they've been beat over the head about multi-core support since FSX's release...You say you're half done... have you tested anything at this point to see that its accomplishing the desired result?

I remember you mentioning this back in December. This was one of a couple things you were looking at. ;) Aces has already stated part of the bottleneck is in the amount of API calls.What's are my thoughts on this - glad you've been digging in the bowels of FSX to see if you could help with performance. And my main thought on the issue is - when can I try it !!!Regards'GarettEDIT - Did you get anything worked out with the file open on first try topic?

Thoughts are:Anything helps... We can try it sometime when it's ready and we'll let you know...(for users with dual core cpus of course)

>I remember you mentioning this back in December. This was one>of a couple things you were looking at. ;) >>Aces has already stated part of the bottleneck is in the>amount of API calls.>>What's are my thoughts on this - glad you've been digging in>the bowels of FSX to see if you could help with performance.>And my main thought on the issue is - when can I try it !!!>>Regards'>>Garett>>EDIT - Did you get anything worked out with the file open on>first try topic?Before you guys get your hopes up, assuming BOPrey is able to come up with something, (And I wish him luck) he probably wouldn't be able to distribute it, at least legally! It would violate MS/Ace's Eula! The one that says your prohibited from working around any technical limitation of the software. Manipulating config files is one thing, changing the way the code works would be crossing the line! I don't think that any one in MS or Aces would allow that kind of a mod to be released to the public. I think our best hope is to see what Aces comes up with in SP1!

I dunno,From my understanding of what he's attempting, he's not doing editing or injecting the source code, decompiling it, nor overcoming "its" technical limitations.FSX is making calls to directX and is functioning code untouched. The proxy dll is just intercepting the calls to direct X (which in effect has left the FSX building) and managing/directing the outputs. Heck you can use directx tools to do this, well at least see them anyways. Making this actually work is a whole different story.Lots of directx dll proxys around, all used for different things. What about Fraps, I understand that as brute code injection when you see the little counter on the screen. What if Fraps just happened to improve your FPS at the same time it's showing it to you ....Regardless, it would be a shame to see the EULA deter increasing the perfromance and playablity of the product by manipulating something "outside" of it, instead of stopping piracy and decompiling it for remanufacture as should be intended.Anyways, just thinking out load - and I'm definatly no lawyer.Garett

In a way Creative is doing this in Vista. They created Alchemy to workaround Vista direct HAL access restrictions. The Alchemy intercepts DirectSound calls and routes them to OpenAL.Jos

Patiently waiting. :)

This is a proxy of d3d9.dll. It has absolutely nothing to do with FSX. It might as well bring multi-processor support to other Direct3D applications. Coding has been done on the basic architecture level. There are over a hundred functions I have to work on, and it is going to take a while as my time on this pet project is getting less and less (getting very busy with business). BTW. My original calculation on performance gain is wrong. It should be no more than 50% instread of 30%.

>should be no more than 50% instread of 30%.No, pls leave it at 30-35%, about that. Since it already sounds too good to be true, lol.

Well, IF what you say is true then you could probably sell this patch of yours for $10 and make some real money that way. You might want to spend as much time as you can on this and make a lot of money for yourself and make a name for yourself in the gaming community which could lead to many job opportunities.________________________________________________________________________________________________Intel D975XBX2 'Bad Axe 2' | Intel Core 2 Duo E6600 @ 3.20Ghz | 2 GB Super Talent DDR2 800 | Big Typhoon VX | eVGA 8800GTS @ 565/900 | Seagate 2x320GB SATA RAID-0 | OCZ GameXStream 700W | Creative X-Fi | Silverstone TJ-09BW | Matrox Triplehead Setup

Thnx. But, forget about the job opportunity. I already have my hands full by running one software company.

Please sign me up, e6600's getting mightily abused by FSX, so I'd love to try it. :)

I have an AMD Turion dualcore, and overclocking it by 10-20% makes FSX run noticeably smoother. If just 20-30% of the processing can be done on the second core, it could speed up FSX significantly on my laptop. I'll be eagerly awaiting more news on this.

While I'm still extremely skeptical mainly because this falls under the "too good to be true" category, I guess I feel like there is a specific reason not to expect a performance gain:While making the D3D call requires CPU time, the problem, as I understand it, is the sheer number of calls-- I can't imagine that each D3D call (individually) takes much time from the CPU (otherwise what's the point of having a GPU?). The problem with your idea, I suspect, is the added work required to transfer the call to another thread will be comparable to the time it would take to just send the call directly to the card.Analogy: Say you have an assistant at your job that does a lot of little jobs for you. But let's say you decide you are wasting too much time assigning tasks to your assistant. Therefore, you higher a task assigner assistant to assign the tasks to your original assistant. The problem? You still spend just as much time telling your task assigner assistant which tasks to assign to your original assistant.Do you have reason to believe this is not true?