A first glimpse at Prepar3d v2.3

[ChaoticBeauty 6,692]

Remember about the legacy stuttering issue that occured at 40-45 FPS and 60-90 FPS which was supposedly fixed in 2.1? Maybe that problem resurfaced in 2.2 or something.

[yorgosGK 7]

 Something is causing the delay around frame 2128 ... I hope LM can at least identify that something.

 

Cheers, Rob.

 

Rob thanks for the graph, I've been monitoring your posts and use your settings from your site!

 

Could these spikes maybe be introduced because some products are not specifically for P3D v2.x and only have triple installers that only "work"...Are you beta testing 2.3 completely default? 

[Guest]

I agree that 20 fps is smooth when you are getting a frame every 1/20 of second and I agree that 30fps is smooth when getting a frame every 1/30 of a second and again agreed at 60FPS a frame every 1/60 of a second. However, under these conditions 20,30, 40 or even 50 FPS does not do the same to my particular brain that 60FPS does. Whether it is on a conscious level or not ( I suspect subconscious) 60FPS is enough to fool me and on some level at 50fps my brain blabs out "SLIDESHOW". Even when I cognitively know that its just as much a slide show at smooth 60fps or even 120fps somehow there is not enough there for me to suspend my disbelief at a smooth 50fps and there is at a smooth 60fps. I am not just speculating here will I was working on those videos in earlier post I tried settings that could sustain 50fps at a 50hz refresh rate and the experience was not as convincing or immersive as 60FPS.

 

Honestly this discussion goes far beyond P3D. The spectrum or results that will satisfy from one individual to the next is vast. Generally, the character of this kind of discussion is that the participants view their own particular experience and being objective and as a result when all those divergent objective experiences clash in the ongoing contextual environment of a forum all hell brakes loss. There you go in a nutshell; why its much harder to agree online than it is in person. Not that agreement is easy to come by in person either.

 

That's what you call a tangent to a square!

[Guest]

 

 

Could these spikes maybe be introduced because some products are not specifically for P3D v2.x and only have triple installers that only "work"...Are you beta testing 2.3 completely default? 

 

This particular time frame sample came from a BASE clean install of V2.2 with V2.3 beta applied ... no add-ons at all and this flight was done around the Langley default airport using the default F22 ... no controllers, just used Keyboard to fly around.

 

Cheers, Rob.

 

 

Generally, the character of this kind of discussion is that the participants view their own particular experience and being objective and as a result when all those divergent objective experiences clash in the ongoing contextual environment of a forum all hell brakes loss.

 

Not sure all hell has broken loose ... just demonstrating with real world data what I consider a "real stutter".  The testing processes is very simple, you log in milliseconds how often a frame is displayed (note I don't say rendered) and then show the time variance between each frame that is displayed ... it really is that simple.  Finding the cause, well that's not so simple and I wish LM the best of luck here.  

 

But I just wanted to demonstrate that stutters do exist and that they have nothing to do with Vsync.  Vsync stutters can/do exist but they are not relevant to what is being displayed above in my time between frames chart.

 

Cheers, Rob.

[Guest]

Agreed Rob, That is definitely an objective example of measuring a stutter that is not a Vsync related!

I am not being particularly serious or particularly referring this thread with that comment :smile:

[mgh 89]

 

 

The testing processes is very simple, you log in milliseconds how often a frame is displayed (note I don't say rendered) and then show the time variance between each frame that is displayed ...

 

Can you clarify what you are logging -is it  the interval between P3D rendering a scene internally or the time between the disply driver/monitor showing on the screen..

 

My understanding that:

 

when P3D  renders a frame  Howver, as long as P3d it calls IDXGISwapChain::Present() or Present1() to copy the  back buffer to the front buffer  to update the display driver/monitor

 

P3D is asynchronous and can copy the back buffer when it's ready to render the scene

 

the display driver/monitor runs synchronously, typically at 60 Hz, so there could be a further delay beween P3D rendering the frame to the time the  frame is actually displayed on the screen. The delay could be 16.66 msec ( ~60 Hz) in the worst case?.

 

It seems to me possible that this may affect stutters though I'm not sure of the effect and may need further thought.

[Guest]

 

 

Can you clarify what you are logging -is it  the interval between P3D rendering a scene internally or the time between the disply driver/monitor showing on the screen.

 

As I understand it FRAPS triggers a frame time when the DX call completes ... hopefully LM are using IDXGISwapChain1::Present1 and not IDXGISwapChain::Present per the MSDN documentation here: http://msdn.microsoft.com/en-us/library/windows/desktop/bb174576(v=vs.85).aspx to quote:

 

 

 

Because calling Present might cause the render thread to wait on the message-pump thread, be careful when calling this method in an application that uses multiple threads. For more details, see Multithreading Considerations.

 

I don't believe FRAPS has any way to determine how long the monitor takes to display -- assume you are talking about monitor pixel clock speed and/or response rate (for example my HP LP3065 response rate is 12ms and pixel clock speed is 275Mhz)?... which would vary from monitor to monitor?  DX can only work with vertical signal (60Hz for example) -- putting Gsync aside for the moment.

 

But either way, the FRAPS testing is relative ... so long as FRAPS doesn't change what triggers a time frame value in the logging (which I'm almost certain they don't) it should be reasonably accurate (certainly no major variances like one would see in the chart I presented above).

 

Pixel clock speed and/or response rate that is too slow tends to induce a "blurring" effect, not a stutter -- but I'm not sure if that's what you are referring to?

 

Cheers, Rob.

[Guest]

EDIT: I should also emphasize this "long frame" (aka stutter) could also be an nVidia driver issue ... if that's the case LM would need to approach nVidia with relevant information/questions.

 

FRAPS time frame logging is a relatively primitive tool compared to nVidia profilers ... nVidia profiling support needs to be integrated into the source code, compiled, and tested to be used effectively.

 

Cheers, Rob.

[SteveW 1,785]

Hey Rob,

 

I found that in 2.2 Flaps seem unable to be assigned an Axis. The axis becomes assigned to the action in the settings screen, but fails to work the flaps in the sim. I wondered if you have tried that in 2.3?

 

There seems to be a general response lag in some controls, like views, rotating switches.

 

I also find there seems to be an underlying grating upsetting the sim timing similar to that you describe. Looks kind of like it's only ever showing the prior-most frame all the time.

 

VSync, AA, and fps, all seem good.

 

 

regards

Steve

[Guest]

 

 

I found that in 2.2 Flaps seem unable to be assigned an Axis. The axis becomes assigned to the action in the settings screen, but fails to work the flaps in the sim. I wondered if you have tried that in 2.3?

 

There are some bugs in the controller assignments thru all version from 2.0 to 2.3 ... I'll setup my controllers, exit P3D, go back into P3D and Axes and Button assignments I removed (deleted their assignments) have come back to life which of course conflicts ... they were being assigned back to my Logitech G27 wheel??

 

The basic process I seem to have to keep going thru is remove all Axes and button assignments from Mouse Look, Mouse Yoke, Logitech G27 Wheel, Logitech G27 pedals, make sure my GoFlight TQ6 has no button mappings or axes mapping (all handle via GoFlight module loaded in the EXE.XML) ... I seem to have to do this twice anytime I do a complete wipe/initialize of P3D.  After the second go around of clearing assignments, it seems to "stick" and the issue doesn't happen again.

 

So all I can suggest is that you double check you Axes and Button Assignments ... my hunch is some may have come back to life preventing the assignment of flaps.

 

I've also noticed the Export of the controllers doesn't seem to work correctly, it doesn't save "non-assignments" ... meaning any default assignments I've removed (i.e. like my Logitech G27 stuff) ... if I Import the controller.xml (the one I just saved) again the deleted assignments come back to life.

 

I think this has been reported to LM a while ago.  I'm still trying to get an official list of what items were fixed in this current Beta (no luck so far, and I have asked) ... kinda difficult to test "fixed" items if I don't know what they are.

 

Cheers, Rob.

[gboz 157]

Edit the standard.xml file directly and there should not be any relapses.

Save a copy for the next install.

 

gb.