:(  :mad:   Now you ruined my day! Thanks for nothing!

 

I really don't think so. With 2.3 they're improving GPU performance, but they also need to look at CPU performance before we start looking at frame rates of 60 FPS.

 

I read in some post on AVSIM, more cores, better performance.  8 cores Intel will definitely be a miracle for P3DV2.3 (I mean real cores, not threads)

I read in some post on AVSIM, more cores, better performance.  8 cores Intel will definitely be a miracle for P3DV2.3 (I mean real cores, not threads)

 

I think that actually the best solution would be fewer cores, higher clock speeds. Prepar3D is hardly any better than FSX when it comes to multithreading (yet). Physics, AI, aircraft systems and more are still running on the main thread.

Honestly ladies and gents, some of you are missing the point ... it's really not about FPS, the key is time between frames and keeping that consistent.  If the time between frames can be consistent I can fly all day at 15 fps (below that then input lag starts to become an issue).  Somewhere, sometime, someone seems to have implied that 60 fps is required ... it's really not and it's nothing to do with Vsync.

 

Anyway, with that said, I'll post a video tonight flying around Hawaii at 72-90 fps and record at 60 fps and upload a very small segment at very high bitrates so you can get to see how the water looks at various altitudes -- I know it doesn't matter how good "I think" it looks, someone will pull it apart (that's just what humans do) ... but I'll get something up tonight and let you folks have fun with it.

 

Regardless, it's good to see the enthusiasm be it positive or negative.

 

Cheers, Rob.

Honestly ladies and gents, some of you are missing the point ... it's really not about FPS, the key is time between frames and keeping that consistent.  If the time between frames can be consistent I can fly all day at 15 fps (below that then input lag starts to become an issue).  Somewhere, sometime, someone seems to have implied that 60 fps is required ... it's really not and it's nothing to do with Vsync.

 

Anyway, with that said, I'll post a video tonight flying around Hawaii at 72-90 fps and record at 60 fps and upload a very small segment at very high bitrates so you can get to see how the water looks at various altitudes -- I know it doesn't matter how good "I think" it looks, someone will pull it apart (that's just what humans do) ... but I'll get something up tonight and let you folks have fun with it.

 

Regardless, it's good to see the enthusiasm be it positive or negative.

 

Of course the frame times are equally as important, but after experiencing Microsoft Flight at 60 FPS, I'd love Prepar3D to do the same one day. Not saying it won't be done, but unless they work on eliminating the CPU overheads that are still in there we are going to need some crazy hardware to do that.

 

And thanks for the video, I'm glad you're uploading it at a high bitrate.

And thanks for the video, I'm glad you're uploading it at a high bitrate.

I am just a bit curious. You do a lot of posting and offering advice. What type equipment do you have and please tell me that you even own Prepar3D. Rob is a pro and he knows that 60 FPS means nothing. Please help him stop the insanity. Comparing Microsoft Flying Circles in the Sky Game to Prepar3D is like saying that you didn't like watching TV till you saw a squirrel in the tree. It means nothing...notta......

 

Rob has done a lot to help us and LM and we own him a great deal of respect. So again, your equipment you are using and what version of P3D ya running.

Edited July 30, 201411 yr by n4gix
Fixed the misplaced reply.

Agree with all that stuff about time between frames and that you don't need 60fps for smoothness. I my case, if its a smooth 20 FPS I'm happy too. I have a very good experience with a practically constant 30fps and 1/3 refresh in FSX. However as always I am disagreeing that FPS is not important. In my case it is important I have flown in P3DV2 at 60FPS at low setting with no stutters and the FPS makes a huge difference to my eyes. This whole argument reminds of the seen in Dallas where Sue Ellen Catches JR in bed with another woman and he denies it and says to her; "Who are you going to believe? Me or your lyin eyes!" 

 

Any sorry for of topic:-)

 

 

but unless they work on eliminating the CPU overheads that are still in there we are going to need some crazy hardware to do that.

 

There can only be "one" main managing thread that says "ok, got everything I need to render the next frame" ... this will run on a core.  It doesn't matter if you have 8 cores, 16 cores, 32 cores, 64 cores ... if the managing thread (it's the traffic cop managing all spawned threads) has to wait for 1 required thread/core to finish, it still has to wait.  This is why you will never see 100% utilization across all cores on software that is governed by a real world "clock".  The simulation is hostage to the slowest running process that must report back before the next frame can get rendered.

 

Here is an example of what I mean:

 

Suppose you have an AI aircraft who's position (in the world/viewport) is being calculated by another thread on a different core, if not restricted (by a main manager thread) lets say it can calculate AI position 20 times in 50 milliseconds.

 

Now you have your own aircraft (in the world/viewport), because it's a more complex (more going on in your aircraft that an AI aircraft) the thread takes longer to process and can only manage to calculate it's position 5 times in 50 milliseconds.

 

If there were NO managing main thread (why you see one core with much higher CPU utilization), the AI aircraft would be flying thru the world 4 times faster than your aircraft even though they are actually traveling at the same speed ... this needless to say would NOT be realistic.

 

So there HAS TO BE a SINGLE managing thread that synchronizes everything so that it makes sense in a "Time based" global world of flight simulation.  So if this single managing thread is having to wait for one other thread to "finish", it doesn't matter how many cores you have, you will still have to wait.

 

Obviously this is over simplified technically, but the concept is the key -- there is one managing thread and there always will be one managing thread so long as we're dealing with a global time clock that needs to "make sense".  Now don't take this to an extreme, more helper cores/threads will basically get more accomplished but you can never exceed the limits of the main managing thread.

 

I've seen Word Not Allowed and others keep repeating that the CPU cores are not being utilized and they "Should be" utilized, this is just not accurate.  Now that doesn't mean, there isn't some further optimizations that can be done ... one can try to break out a logic process into small process on more threads, BUT that can only be done if they are independent enough to not require each other -- the logic may just NOT be there to allow further break down of threads.

 

Cheers, Rob.

 

 

there are only so many hours in a day and I end up working my "real job" into the late evening

 You're doing a real job here.  I really appreciate someone taking the lead for the P3D user team.  These threads keep me going; very much looking forward to 2.3.  Thank You Rob.

 

 

However as always I am disagreeing that FPS is not important. In my case it is important I have flown in P3DV2 at 60FPS at low setting with no stutters and the FPS makes a huge difference to my eyes.

 

I didn't say that FPS is not important ... I said it's "not about FPS".

 

The speed of motion will most likely dictate what fps your eyes will enjoy/require.  If one is using TrackIR with a twitchy profile where their head motion is unrealistically exaggerated going very fast from left/right and/or up/down (I've seen this on many videos) then one is going to need a higher fps to make that experience less nauseating.

 

Test case, sit at an airport, don't move ... can you tell the difference at 15 fps vs. 60 fps?  If you say yes here then your eyes are lying  Now move at a rate of 1 mph forward, do you see a difference between 15 fps vs 60 fps?  Repeat the process ... 2 mph, 5 mph, 10 mph, 50 mph ... at some point you will start to see the difference.  It's about the motion ... it's that motion that sets the fps requirement ... and it will be different from person to person.

 

Cheers, Rob.

 

 

it's really not about FPS, the key is time between frames and keeping that consistent

 Exactly Right.  

 

 

 

Somewhere, sometime, someone seems to have implied that 60 fps is required

 This comes from the high-action gaming communities.  For years Crysis, 2007, on Cry Engine was the visual candy to beat, but it is only just about now coming to being 60fps, then not without stutter.  All other engines have been trying to find a ballance.  The 60fps is a scientific finding embraced by the gaming communities as being what needs to be reached before "realistic" and "playable" is achieved.  We don't really need that.  Like you say even 15fps is workable (I remember being happy with that with vector based FS graphics) as long as it's not "interrupted" in any way in it's pace with a stutter, 'lest framerates become "noticed", and depending on the user's state of mind, annoying. 

 

 

Of course the frame times are equally as important, but after experiencing Microsoft Flight at 60 FPS, I'd love Prepar3D to do the same one day.

 

It can, try P3D2.2 around a small island with no Ai, road traffic or realtime weather in a small GA aircraft with few systems modeled I get way more than 60 fps in that scenario.

 

I would have loved to see Flight handle a complex aircraft into a large fully modeled airport with 30 or so Ai running along with ATC.

MS Flight! ran well because there really was not that much going on at all.

There can only be "one" main managing thread that says "ok, got everything I need to render the next frame"

 AFAIK the kind of fibers P3D is using does not use messaging/semephores, but is based on timing alone.  This cuts down about 15-20 overhead.  There is no waiting for finished parts, but a sampling of what is available.  No sense of real world clock, just bits of memory and clock ticks, AFAIK.  What I get concerned about is whether MS did it right, or did it wrong and knows it and is why they've farmed out ESP use.  

 

 

 

the logic may just NOT be there to allow further break down of threads

 True.  I see my CPU at max on all threads often, so I think we'll just have to wait for faster CPU's.   Making fibers smaller can help, as there isn't much more overhead to making more of them to do the same work, but it's not going to recover that much more cpu. 

 

 

 It's about the motion ... it's that motion that sets the fps requirement ... and it will be different from person to person.

 

Rob, as much as I prefer Prepar3D, I still occasionally fire up MS Flight, because it still conveys the feeling of motion in flight better. For the past month or so I've been trying to put my finger on exactly what Flight does differently. So now you have me wondering how much of that feeling is due to the higher frame rates, and/or more consistent frame rates.

http://www.microsoft.com/Products/Games/FSInsider/developers/Pages/GlobalTerrain.aspx

 

This is still in place in ESP and P3D v2.x as far as I know.

 

To quote that article (last paragraph is important):

 

 

Regarding Threads, Fibers, and Multi-core Architectures

Many of the tasks performed by the terrain engine, including the ones described in this paper, cannot be started and run to completion in the interval between consecutive rendered frames.

Some of them would take several seconds to run even if 100% of the processor time was devoted to them.  What's the best way to execute these tasks without negatively impacting the frame rate or its stability?

One possible solution is to run them on threads separate from the main render loop.  In practice, however, threads alone may not be the best solution.  The main reason is because the terrain engine's tasks are processor intensive and they can easily starve the game's main loop of processing time.  Worse yet, the terrain tasks come and go intermittently which would cause the frame rate to fluctuate.

In theory, lowering the priority of the terrain threads should prevent the main game thread from being starved.  However, the game thread is also pretty busy so that would increase the risk of starving the lower priority terrain threads.

A better solution, based on our experience, is to run most of the terrain engine tasks on Win32 fibers.  Fibers are similar to threads in that they each have their own context (i.e. register state and call stack).  However, the scheduling of fibers is entirely up to the application using them.

With fibers, Flight Simulator can schedule the terrain tasks to run in the interval between iterations of the main game loop and not during rendering or other time critical operations.

Fibers do have their down side, however.  Flight Simulator's fiber scheduler is cooperative, which means the fiber tasks must periodically call back into the scheduler to see if it's time to yield.

While this takes some getting used to when writing code, it does simplify the job of synchronizing data between fibers and the main game loop because all of the possible points of preemption are known.

Recognizing the increased availability of dual-core processors, we plan to execute some fibers in a single thread on the second core.  Fiber tasks that exchange data only with other fibers on the same core can still lightweight synchronization, but any data exchange with the main game loop or other fibers running on the primary core must be fully synchronized obviously.

 

Cheers, Rob.

 

 

So now you have me wondering how much of that feeling is due to the higher frame rates, and/or more consistent frame rates.

 

It's depend on your motion (be it head tracking or flight motion).  60 fps will have shorter time between frames ... so any variance are likely to be smaller also (not always the case, but very likely).  Less variance = better "feeling" of motion.  If you travel at 500 Kts at 500 AGL then you'll need higher frame rates (around 230-240 fps if you want absolute fluidity) than if you travel at 500 Kts at FL330 (so add distance from points of motion in this equation also).

 

Cheers, Rob.