I mean it's very jerky, to the point of being uncontrollable. On my old XP machine it was fine at 16 fps for control, only lacking a little smoothness.
Can anyone explain to me why 16 fps works fine on my 5-year-old Win-XP laptop with no video card, but my bran new Vista machine with a video card and a faster processor looks terrible with anything less than 30 fps?
This is not surprising -- see the original post in this thread. Also, use VistaBoost if you're not already.Win 7 (64) too. No matter what I do, I can't get beyond this ceiling; FPS ~= 25, occasionally breaks 30 momentarily, and with occasional dips into the high teens. That applies whether I'm on a takeoff roll with scenery whizzing by me, or in deep space looking at nothing. And there seems to be some hidden parameter set to "jerkiness = max." CPU is AMD Phenom 9600 (quad core 2.3 GHz), GPU is NVidia GTX 260+, Orbiter is base '06+P1.
Sorry for your troubles, but relieved it ain't just me. I've also got another PC with XP where Orbiter runs just dandy, so I ain't too worried.
I think I'm just confirming what others have already said (but when it comes to graphics tech I'm pretty clueless) ... Various GPU benchmarking and stress programs send the GPU temp up, as expected; Furmark seems to be worst case and causes it to peak at 80C. But Orbiter (on the Win 7 PC) doesn't warm up the GPU at all. I don't thiink that's any earthshattering news, but just in case that somehow helps someone, there it is.
SAM
Also, use VistaBoost if you're not already.
Hielor said:The main problem with this application is that it’s coded to be efficient on operating system, processors and video card hardware that were common back in 1998 (DX7 class hardware), these days the techniques it’s using are not very common and as you can see, have quite the performance impact. XP is better at running this application because of the GDI acceleration and cheaper D3D/GDI interop, these paths were deprecated when we moved to Vista / WDDM.
Hardware support for D3D/GDI interop was dropped in Vista to enable hardware manufacturers to move forward without always needing to support ten-year-old features that hardly anyone uses. That's the key here, that Orbiter is one of very few programs that uses this method. Modern games did not suffer the performance hit that Orbiter did.
I don't have an exact answer for you, but I believe that the GDI interop was removed from hardware because it was a feature that was extremely rarely used even in games written back when DX7 was new, and that most games written back when DX7 was new would have plenty of CPU processing power available for this since they weren't particularly complicated and were only using the GDI interop for a few simple things.Well my question is this: Why the hell move the GDI interop into emulation? What possible advantages has it given? If you look DX10 is only marginally faster than a well-coded DX9 game for example. So it doesn't seem to really benifit DX10, the whole reason MS took a wrecking-ball to things.
You know what they say: If it ain't broke don't fix it.
For GPU manufacturers, yes--they no longer need to support a legacy, little-used feature, which saves some hardware and software for them.But is it really any easier to code for Vista because of this?
Or perhaps they require "exponentially more powerful hardware" because they're doing "exponentially" more? Compare modern games to games of three or four years ago and it's not hard to see why they need more power (hint: it has nothing to do with "poor coding techniques").In the end I don't think it really matters because modern games seem to be requiring exponentially more powerful hardware because of poor coding techniques (*cough* PORTING *cough*).
Huh? What does time between OS releases have to do with dropping support for features that no one uses anymore? It's the same with 16-bit apps, they're not supported on 64-bit versions of the OS. This is how computers work. You move on and drop support for stuff that people aren't using anymore.Maybe if MS didn't wait so long to release an OS a less drastic solution could of been worked out.
Your current computer has worse hardware for playing music than your old one, and you blame Microsoft for a worse experience when listening to music? Yeah...that's not MS's fault.Speaking of emulation, I especially love how when my CPU reaches 100% in Vista, my audio freezes for a split second, causing pops and sputters, because the sound is processed through the CPU. Try listening to music and run a program like Prime95 that will take all your CPU cycles, and then browse your computer. 2009 and we can't make a computer play audio without problems. MS loves taking steps backwards.
Sure, sound cards may not have been good for much, but at least on XP with my Audigy 2 ZS I can listen to music without the 'needle skipping'
Assuming that the 60fps is synchronized to the refresh rate of the monitor, then there will be no perceivable difference between 60 and 140. In fact, with 140, it may look worse due to tearing effects due to not being an exact multiple of the refresh rate.
It's worth noting that the machine I have Orbiter on back home (dual core 3 GHz with an ATI 256 meg graphics card, forget the exact model), tops out at exactly 60 Hz when running Orbiter, probably some sort of synchronization thing.
The externalMFD i can understand since it's doing a lot of GDI drawing, but the performance meter/scenario editor doesn't make sense to me, especially the part about them causing problems "even if they are off." Do you mean that they cause framerate hits if they're active in the modules pane but not currently open?Orbiter stays very fluid. there is only a few moments close to the ground near Cape Canaveral that the frame rate slows a bit. However the thing that will absolutely kill my frame rate is not polygon count, certain MFD's, or objects but it't the Windows menu's. Like the scenario editor, performance meter, and especially the externalMFD window. These are frame rate killers even if they are off. They drop my frame rate in half or more.