>Actually, comparing to todays standard FPS and other type of>games, FSX is somewhere in the bottom/middle middle when it>comes to complexity, unless there is some hidden voodoo I>don't understand and can't see (probably is, considering how>FSX performs). Even amount of content isn't comparable to some>RGP games. I'd like to remind you that FSX nor any of FS>series are proper simulators of anything. They are just plain>old computer games with a couple of more or less convincing>aircrafts and fairly good but boxy representation of>architecture and world.>>Regular flight sim simulators run happily on multiple>computers.>I agree with you 100%, and I don't think that there is any voodoo that we haven't seen. As far as simulation complexity goes, X-PLANE is far more complex than any release in the FS lineup, and yet it runs stunning fast.

>You call FSX a simulator? OK, FSX is simulator just for>argument sake. Game like Oblivion requires high processing>power. However, their programmers used smarter technics in the>rendering engine so CPU cycles can be saved to do other>things. Otherwise, how do you think they are able to put a>million+ tree on a scene and rendering it at 24fps. In the>multi-core department. Valve has already done the engine. Have>you heard ANY initiative from ACES? All I am hearing is that>they are investigating ways to take advantage of DX10? Quite>frankly, which does mean that "Oh, let me start thinking about>it." which means DX10 wasn't even in their game plane since>day one. However, I don't blame them as DX10 wasn't even in>the drawing board when the project started. Which might lead>to the code wasn't designed with shifting of computing>paradigm in mind. So guys, keep your expectation low for the>performance of the DX10 patch, if it ever comes out that is.Interesting you mentioned Oblivion, as it is a program I am very familiar with, which had its own set of growing pains. At release, the official forums were flooded with comments about how they could not run the game on their current system, how trashy the coding was etc etc etc. Not much different than how this community has responded. After a while, the rambling stopped and things returned to normal(and yes, this community is MUCH quieter and docile in my humble opinion on the subject.) Speaking of 24FPS, I am getting an astonishing 17FPS in Seatac and 30-40+ in not so CPU intensive areas. I think that is reasonable, but perhaps we differ there.As for taking ACES words to heart, well that is a different debate for a different time. I disagree with you however, I am more optimistic about the future of FSX and its developers. At any rate, I have a sim I enjoy. Nobody can convince me otherwise."I agree with you 100%, and I don't think that there is any voodoo that we haven't seen. As far as simulation complexity goes, X-PLANE is far more complex than any release in the FS lineup, and yet it runs stunning fast."Lower resolution aircraft models, less polygons, un-detailed aiports, minimal autogen, among various other things such as weather. Like I said, I fail to see how you can compare FSX to X-Plane when the programs are so entirely different and have different aims. Of course the simulator runs great, they focus more on air movement over a moving surface than whether or not a rivet in an aircraft reflects light.

>>As for taking ACES words to heart, well that is a different>debate for a different time. I disagree with you however, I am>more optimistic about the future of FSX and its developers. At>any rate, I have a sim I enjoy. Nobody can convince me>otherwise.>I have faith in the developers in ACES, I just don't have faith in MS and they are in control. I'm sure when the computing paradigm stated to shift, there were a lot of fights took place within ACES. Personnal change is one of the evidences. As a developer and a businessman myself, I saw this coming, just not this bad.

>>I don't blame ACES for this fiasco, there is way too many>>reasons why games are rushed to the market, devs are the>last>>of them.>>I really don't have a comment for this, simply because I don't>see eye to eye with you on the subject. I think the product,>while not perfect is not any worse then any prior release of>FS.All right, you seem to completely miss my point.Pong = sarcasmRegular simulators = level D simulatorsRendering 50 unit radius of very simplified representation of real world and very simplified physics and ONE aircraft (AI has this very useful option of teleportation) = not that big deal, comparing what current games do - so please no more arguments "we render whole world". It was valid few years ago, not now. You still can do loops in B747 with open doors at FL400 tho :).Moving airmasses = very simple camera follow through. Turn it off, you get back FS9 rail flight model :)I don't expect dual core support = I know for sure it will be there (in general not in FSX case, which I am unsure), Intel did great job with Core2, AMD will follow, they've got even more experience than Intel. This is what market dictates. Video game industry has enough money to adapt technologies really quick.

>>However, the catch is, when it is behind and it decides it>has>>gotten behind the renderer and just decides to 'drop' those>>objects, that is a whole load of processing cycles just>>wasted. >>FSX is already doing it now. I can beg that when you are>getting blurries, the textures are half load but FSX designed>to drop them and put blurries on the screen instead of killing>the FR. On the other hand, if the renderer decides not send>those objects to the gfx card because they are not ready, it>is only for the current frame, they will be ready for the next>frame. No a single Hz of CPU cycle wasted.It might well be the case now, I don't know, and like I have said before, I do see the arguments you are making, and I don't want to keep rehashing the same things, but like I said, it's not that it isn't possible to do it across multiple procs/cores, it's just that it takes a paradigmn shift in the way the game is programmed, properly splitting the rendering to multiple threads is totally possible, but has to be done in a way that gets rid of the extra processing and time waits inherent with doing this kind of programming.I'm an electronics/software engineer - and for 6 years I designed robotics (early-mid 90's) and brought my company into the distributed computing age - we had multiple processors to perform distinct different actions on the machines, one to drive the horizontal axis, one to drive the vertical etc, one to drive the handling --- all tied togethor by high speed (custom made) 2-wire serial busses, into central control computers, which were then tied to the overal management system computer. Yes it's doable, but it's a lot of work.Sure, not quite analogous to a computer game, but I do purely software now, and write multi-threaded programs for a living, and it's tricky, but can give enourmous performance leaps when spread accross processors.I have a friend who owns a simulation company, they build everything from simulators for dock cranes (the one's that lift the crates on and off of ships), cruise ships and flight simulators too for the military - there rendering truly is split - the screens are are like a huge umbrella round the front of the viewing area (cockpit) and each part is a rectangular section, each rendered by a powerful computer, all tied into another that synchronizes the display segments, and with the users controls (very important, or you can actually suffer from what is called simulator sickness, like the controls are out of sync with what you see in the 'world' display - kinda like motion sickness!)...fascinating stuff (well to me!).Anyway - to actually get to a point, all I was trying to do was indicate the complexities of doing this type of thing, and not saying in any way it's not possible to do with MSFS - it is, just needs a different way of thinking, like splitting parts of the display to be rendered on seperate CPU's and then put togethor by the GPU.Honestly, in time I think we will see this happen, but again, it takes time for games makers to catch up with new PC hardware, but I think the ACES team will not dissapoint in the future - and maybe they will bring out some updates to FSX to help address it before we get FSXII!This has been a great discussion by the way, I've really enjoyed it!My apologies for the long post :)

Not true. Inter-thread communications are very simple. No locks and special primitives are needed to access the the shared data unless it is write access, and we know that from experience (and Valve's interview) only happens 5% of the time. So multi-threading the FSX code can be very efficient.

>Sound, of all things. There would be better uses, sound just>seems easiest to implement in a separate core...>>"Great sound never sold a bad game." -- John Carmack"Sound" as in good and efficient, different meaning of the word, I didn't mean they were putting sound (audio) on another core.