Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

3 Neutral

About WaarEagle

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hmm, that's interesting. Does this happen when Power management mode is left at the default "Optimal performance" or when it's changed to "Prefer maximum performance"?
  2. All of my flights have been in 11.41... the log shows it; but I guess I should have mentioned that at the outset. Have not tried the TBM in any of the betas; but I may make an attempt soon. I agree that X-Plane requires very few driver tweaks. The only settings I change are Vertical Sync, Display Mode, and Power management mode. I'm not convinced that Display and Power management really do that much; but it doesn't hurt anything, so I go ahead and change them to the appropriate mode. I've deactivated unused scenery in the past; then did some bench-marking and found that it made li
  3. Okay... let me try to explain. This is somewhat technical so I'm going to to simplify some things (I don't really want to address topics like frame buffers, latency, etc.) and hope I don't misspeak as a result. The reason you are seeing long frames (which is the proper term for a micro-stutter) with all your aircraft is because you are not limiting your frame rate. Without a limit, X-Plane will produce the best frame rate it can based on the complexity of the scenery, graphics settings, type of aircraft, etc. This may be 50 fps at times, it may be 40, it may dip into the low 30s if the sce
  4. Actually, disabling Vsync was one of the first things I tried when troubleshooting the long frames; but it didn't have much effect, so I didn't mention it. I just ran the identical scenario (middle of nowhere with minimal 3-D objects) without Vsync and averaged 50 fps; but there were still long frames due to the background fluctuations. I understand what your saying; but I don't think it applies in this case. I find it interesting that Goran asked why I prefer to lock at 30 (on a 60 Hz monitor). Is the concept familiar to you or do I need to provide more explanation?
  5. Okay... last test. All plugins disabled except gizmo, scenery is completely default, and positioned at an airport in the middle of Kansas with no 3-D buildings (about as flat and isolated as you can get in the U.S.). I even turned the scenery complexity down to minimal before taking the screenshot. I'm still getting the sawtooth performance curve. Notice that both the screen frame rate and the sim frame rate average 30 (they'd probably be pushing 100 if I disabled vsysnc); but the sim frames are down and up, down and up, etc. - this is what causes the micro-stutters (and no, I do not consi
  6. I didn't just compare it to the C172, I also compared it to the FF A320 which is every bit as complex (if not more so) than the TBM. Scenery should make no difference unless one is inside a highly complex scenery area; but if it puts that argument to rest, I'll go ahead and clean out my custom scenery folder and report the results in a couple of days.
  7. Log posted as requested. I loaded up a new flight with all plugins removed except Gizmo. Background sim is still very choppy: Log.txt
  8. In addition to my response in another thread, I wanted to post some screenshots comparing the TBM's performance to other aircraft in X-Plane. The first is the lightweight C172, the second is the hard-hitting FF A320, and the third is the TBM. The setup is identical for all 3 aircraft: Same parking spot, same time, same weather, same add-ons, etc. The sim is running full-screen, 1920X1080, with frames locked at 30 using 1/2 refresh rate vsync in the driver. The pinkish orange line is the visual refresh rate, while the darker orange line is the background "simulator" refresh rate. I'm think
  9. I'm not looking for an immediate solution; but add me to the list of users that noticed the micro-stutters appearing in the last few versions. The TBM was much smoother prior to December of last year... so if you're looking for the cause, look at the more recent changes that have been made. Frame-rates are steady, so it's not because of overloaded hardware; but there is definitely some background process that is giving the TBM a "hitch in its git-along".
  10. I've never had any problems taxiing the TBM. Even before the latest version, it only became really skittish at higher speeds... now it handles well at all speeds.
  11. After making several test flights, I'm 99.9% sure that (in my situation) the conflict is occurring between the TBM and ActiveSky. I tried a flight with World Traffic 3 disabled and experienced a crash within 30 minutes. For the next flight, I re-enabled World Traffic and changed the weather generation from ActiveSky to X-Plane's internal real-world weather. Since then, I have not had any crashes at all. Based on reports from other users, I'm not inclined to believe that the problem is caused exclusively by ActiveSky (since others are experiencing the occasional exception handler fault w
  12. Understood. For my part, I'll make some flights without World Traffic running to see if it eliminates the crash. Since I experience the exception handler reset regularly, it may help to pinpoint the conflict. Will report back.
  13. But that log entry appears to be generated by the TBM... are you saying that it's coming from another source?
  14. The TBM's exception handler continues to reset on 1.1.9 (at least it crashed on the taxi out instead of toward the end of the flight this time). It's now been several months and the incompatibility still has not been identified? My gut feeling is that the TBM is either not getting along with external weather apps (ActiveSky, FSGRW, etc.) or World Traffic... but that is really just a guess. On the plus side, really loving the improved ground handling in the latest update. I don't plan on disabling any plugins (since they play nice with every other aircraft except the TBM); but I'm attac
  • Create New...