>The key point is that we can all sit here today and say what>should have been done three years ago. But reality check - Is>today's PC world / processors / graphics / etc - exactly where>you predicted three years ago?Well, we aren't quite at Minority Report level yet, but those multi-touch screens that have been demonstrated are getting us close.That will be the day, when we physically reach out and touch a virtual switch on our virtual cockpit.

>There would be heck to pay if MS were to build the next FS>with a whole new engine. Chances are, a complete re-write>would have very little in common with previous versions. If>that were to happen, a great deal if not all addons from the>previous version would not be compatible. Why would that be? There is little to gain bringing old FS-9 add-ons into FS-X as it is. As long as MS provides tools so add-on makers can convert their old source data to the new format there wil no problems.Also we are talking about the gaming engine. I can't see much performance gains in changing data format but why not.>The Flightsim engine we have now is over 10 years old. It has>pretty much the same file structure... *.BGL, *.AIR, all those>neat extentions as it did in 1995 when FS5 came out.The important question is what do we get when we give up backwards competability. If we get a new flightsim with the current FS-X default aircraft & scenery running a smooth stutter free 60 FPS with all the special effects, full AI, cloud shadows, ground/car traffic, living world and improved ATC as a new basepackage I would go for it.Your old add-ons are for your old sim. Even now when the new add-ons are out the older generation is mothballed and forgotten. Which commercial (not updated) Fs2002 add-on still runs in your FS2004? Most of us have deleted those old things (no clickable VC, missing animations/features, etc). The BACKwards competabilty is holding this hobby BACK.

>It is nowhere near that simple. >>And when using DX9 only 1 thread can issue Draw calls. >>So you have to go thru the entire Sim engine and find what>sort of processing is actually amenable to being forked off on>a thread.>>And the "add a bit of synchronization" drastically understates>the difficulty of multithreaded programming.Ummmmm!! - sorry Phil - but I think that you will find that Silicon Graphics didn't have too much trouble modifying Unix to take into account "n" number of processorsI dont know if they still exist (possible bought out by the GIANT) - but they sure as H_E_L_L got it right at least 15 years ago with 3D modelling of Ore bodies underground using data in the Gigabytes

AHAHAHAHAHAHAAHAHAHAHAHAHAHA!!!!You're comparing Unix on multiple processors to threading the FSX engine on XP or Vista????? :-lol:-lol:-lol:-lol:-lol:-lol:-lol:-lol:-lol:-lol:-lol:-lolYou really don't have a clue do you?Phil, don't worry. You could make FSX cook him breakfast and run at 100fps at the same time and he'd still hate it.

So what happens when FS_ is written for multi-core and the processor manufacturers decide to go back to single-core? It could happen. I mean we are told MS had very little knowledge that cpu manufacturers were going multi-core. How then would any software developer know which way to code the program?SD

You don't actually write code to work on more than one processor. You write your code to perform in more than one thread (or fiber--but that's another story).Then the OS schedules the threads for you...if you have one core, all the threads run on it. If you have more than one core, the OS spreads them around.So your goal is to use more than one thread. But synchronizing between threads is really hard. Plus there is other code that you have to interface with (DirectX) that might not like running in multiple threads. So it takes a lot of work.

Two seperate things. First of all, OS threading and application threading is not the same as load-balancing/clustering to render images. The rendering process is on top of that NOT in real time and back then it took 100 Unix boxes a few minutes to render ONE frame.Silicon Graphics/SGI declined in popularity, because with the advent of 3D boards and the porting of 3D applications to PCs, it was more efficient and cheaper to use PCs. It has nothing to do with the "giant".Please educate yourself first about the subject matter before stating simplified end-user solutions.Sorry, but I am out now on a mission to diffuse all false and incorrect statements that are being made here on this board.Pat

Right on, Pat. But it will take a lot of your time...Leave some time for simming...

>AHAHAHAHAHAHAAHAHAHAHAHAHAHA!!!!>>You're comparing Unix on multiple processors to threading the>FSX engine on XP or Vista????? >>:-lol:-lol:-lol:-lol:-lol:-lol:-lol:-lol:-lol:-lol:-lol:-lol>>You really don't have a clue do you?>>Phil, don't worry. You could make FSX cook him breakfast and>run at 100fps at the same time and he'd still hate it.AHAHAHAHAHAHAAHAHAHAHAHAHAHA!!!!Oh! gee whizz - neither do you OBVIOUSLY - exactly what M$ planet do you come from? lol:-lol:-lol:-lol:-lol:-lol:-lol:-lol:-lol:-lol:-lol:-lolWe are talking about a company that purports to be the best in the World (never mind all the legal cases against it) - a company that actually advertises "Perfection" - what a laugh!Did they actually "invent FS" - NO!Are they making heaps of money from people that trust them - YESIs this wrong because of the false advertising and marketing Male Bovine Excrement - YESWill they "fix" the "problems"? - probably not

>>Then the OS schedules the threads for you...if you have one>core, all the threads run on it. If you have more than one>core, the OS spreads them around.>Inaccurate statement. The OS does not spread them around, per se. It will, literally, fill one CPUs process to 100% before delegating to others. Unless the developer forces it to shift.

If you use the right thread affinity, the thread scheduler will parcel the threads out across all cores.It is a slightly different API call than usual to do this, though, that is true.

>>Sorry, but I am out now on a mission to diffuse all false and>incorrect statements that are being made here on this board.>That sounds like a full time job. And one you're liable to get heckled at to no end. Good luck!

It isn't quite as simple as that.Creating separate threads would mean writing practically all of FS. It has lots of legacy code which is most unlikely to lend itself to threading. There is more than syncronisation to worry about.. There is also the need to ensure that a global variable being used by one thread isn't changed by another. This can be avoided by using "Critical Sections". I don't know if thee's any difference with Vista, on XP and earlier OSs this is done by stopping all other threads while any thread is in a critical section. Similar problems apply to shared resoureces resulting in threads being halted.Multi-threading could have beeen introduced by MS but at a cost. Like any effective commercial organisation MS would have prepared a business plan for developing FSX. This plan would balance the costs of development with the revenue from sales. Introducing multi-threading would have increased the costs. What do you suggest should have been omitted to compensate for this - or should the price have been increased with a reduction in sales?

Interesting that practically everyone responding has a somewhat different view on what sould or should have been done.I wonder who is correct?SD

>If you use the right thread affinity, the thread scheduler>will parcel the threads out across all cores.>>It is a slightly different API call than usual to do this,>though, that is true.True Phil... however we both know most applications don't thus the OS will simply stack 'em until a CPU's schedule is full.