Some insights (and maybe why PMDG is so silent on this)...I really apologise for the length of this message, but I don't see how to make it much shorter if it's to be convincing, and make sense.First a (brief?) summary:1) On the day of release, using only the 2D cockpit, I noticed the plane takes a heck of a time to load, and frame rates start OK but after a few minutes drop through the floor (like, 1-2fps). Soon other people start reporting the same thing on the Forum.2) The first clues came from Ray Proudfoot and myself on July 2nd when we almost simultaneously discovered that simply by selecting the aircraft with the 2D panel used over 300Mb of main memory, thus sending many users (including ourselves) into heavy paging, thrashing, virtual memory errors, and so on. This looked like the cause of the poor perfrmance and long load times. Of course, if you were fortunate enough to have huge amounts of memory installed on your machine, you wouldn't see the problems as we did - but your memory was being used up, all the same.3) Various folks speculated that video cards, drivers, the need to do shiny reflections, the complexity of the panel, etc. all could be responsible. Me, I kept plugging away, verifying over and over that the main problem was coming from the astonishing 300+Mb of memory that loading the plane required.4) At least twelve Forum threads were raised on this topic (disregarding the red herring of the VC memory problems and switching back and forth to correct VC problems). Several times PMDG were asked to respond, even pleaded with to respond: were we right? Was this a known problem? Would it be fixed?In all the Forum I can find only one response, and it is this:

You are experiencing something that is not general. When our graphics experts come online they'll help you further diagnose what's happening.Anthony Merton

Then, silence. For an organisation which states

PMDG is commited to solve any problems our customers report[/EQUOTE] this seemed very odd indeed. It was clear that at least some of the threads were being read by the PMDG team, because they responded to side issues raised in them, but the main problem has gone totally unanswered.I believe I now have a clue as to why.To understand you must follow me through a further experiment. Either accept what I write here, or try it yourself to be convinced.1) Start FS2002 with the default Cessna loaded. Using Windows task manager measure the memory being used. (My system: 365Mb)2) Locate the file panel.cfg which is in your FS2002aircraftPMDG737-700 folder and make a backup copy of it.3) Using Notepad, Wordpad, or whatever, edit the panel.cfg file and replace all 'gauge' by '//gauge'. Save it. (You are commenting out all the commands to load the gauges for the panel.)4) Back in FS2002, select the PMDG 737-600 base aircraft, with no VC. Measure the memory. (My system: 389Mb.)In other words you can forget all that stuff about the complex exterior, reflections, and so on. That ain't the problem. It's the gauges! But is it one special gauge that's the problem? 5) Switch back to the Cessna. Re-measure the memory. It won't be the same as last time, but it should be close.6) Now un-comment a bunch of gauges, say the 9 gauges used on Window00. Re-select the aircraft, re-measure the memory.7) Repeat (5) and (6) until you have the full plane back in operation.If you do this you will become convinced, as I was, that every time you enable another gauge, the memory used takes a jump upwards, until with them all enabled you see the full memory required by the 737TNG. (My system: 695Mb.)It's the gauges. It's each and every gauge. They all munch memory.Now locate the gauges, inside your FS2002GAUGES folder. They have names like PMDG_737NG_OHD_PROBE_HEAT.gau In Explorer, right-click the file and select 'Properties'. (This works on Win2K, I hope it does on other systems but I can't check.) In Properties, select the Version tab. Look at what you see. A quiet Ah Ha! is justified at this point.Item name: Bluesky software developmentValue: created with EasyGauge, a WYSIWYG gauge editor. Visit www.bluesky-net.deThere are other items of interest but here we've reached the nub of our problem, and, I suspect, PMDGs. And why PMDG isn't talking to us about this becomes, perhaps, a little clearer.- Pete

Very interesting expose Pete.Thanks for taking the time to dig a little deeper. I follow the technical aspects of your discussion just fine, but I have not idea what implications it has for the final product (as in, is it necessarily a negative that a WYSIWYG was used). If EasyGause is to gauge development what something like MS Visual Studio is to Windows development, then perhaps it is understandable. However, if this is a shortcut of some type, then maybe it explains a few things. It is hard to say at this point.Jeff

(Edit for spelling)Hi,Interesting fact!

Ok I'm intrigued now - I saw the long load times after selecting the aircraft too and I assumed it was part of the anti-piracy checking etc...I tested something different Pete - the EasyGauge created gauges vs. the PMDG_737NG_Main.gau file, which is not tagged with an EasyGauge mark. This file seems to contains the LCD screens, FMC, MCP etc - the real bulk of the NG cockpit.Here's what I did:1. Loaded the C172FS mem usage: 39MBTotal Commit charge: 168MB2. Loaded the NG 600 2D only with all gauges commented outFS mem usage: 112MBTotal Commit charge: 240MBThis should be the resultant hit from the visual model correct? The plane loaded very quickly, no long wait like usual.3. Loaded C172FS mem usage: 82MBTotal Commit charge: 209MB4. Loaded NG with all non "Main!" gauges commented out (only the EasyGauge ones enabled)FS mem usage: 138MBTotal Commit charge: 279MBPlane still loaded very quickly, almost no noticable load time5. Loaded C172FS mem usage: 104MBTotal Commit charge: 229MB6. Loaded NG with all "Main!" gauges uncommentedFS mem usage: 340MBTotal Commit charge: 449MBExperenced 30+ second load time in the aircraft select screen and in game the video/sound chopped up when switching to the external view - makes perfect sense - I have 512MB of RAM and the chop up was it thrashing to virtual memory to load the textures for the external model, cause it had saturated the physical RAM.I won't dare draw any conclusions here until we hear from the PMDG guys on this issue. To me it looks like the main gauge file is causing the huge memory load, not the EasyGauge ones anyway. The main file is definitely not made with a WYSIWYG editor. (everyone would be making those beautiful PFDs and NDs if it was! ;) ) As Lars said, it may just be that it's standard to use something like EG for easy things like radios, light switches etc. I don't have any other addons installed at the moment to check and see of anyone else uses that program though.Very interesting though - it could (and probably does) mean nothing, but nice detective work nonetheless Pete!Ryan

Hi there,I am the programmer of EasyGauge, but I do not have the PMDG so I cannot check if the framerate problems depend on the EasyGauges.Generally, the gauges created with EasyGauge do not take more resources than other ones. They are the same and cannot be really optimized - please do not compare this program with other ones like gmax or so where you can optimize a lot. EasyGauge simply writes the source code of the C++ gauge - it is like Paint where you can set the color pixels visually instead of changing the RGB values in the file. And the bitmap is not getting slower because of this.I think the problem are the Vector Gauges. They are programmed in GDI (maybe also in GDI+) and take most resources - but they need to. You also cannot accelerate them - the more complex a cockpit is, the more complex are the update routines. Imagine a moving map: every point must be calculated, the navaids database must be checked, all the lines have to be drawed - this is a huge work load for your computer. And now add the systems which are simulated.I am not the programmer of the vector gauges so I cannot say if they are framerate friendly programmed or not. But here "framerate friendly" programming is definately possible.King Regards,Marcel Burrchief programmerbluesky software developmentwww.bluesky-net.de www.easygauge.net

Gentlemen,Thanks, all, for your inputs. Based on what Ryan wrote I revisited my analysis I had not checked all of the gauges for their origin, and got misled. Ryan's right - there's no reason to point the finger at the EasyGauge gauges. I hope, Marcel, that you will forgive me if it seemed that I was suggesting your product was at fault. In fact, I wasn't: I was speculating that PMDG and Bluesky were in deep discussion on how PMDG could fix their problems, and they were keeping quiet on this Forum until they'd got an answer.But that leaves us with Ryan's analysis and the finger being pointed directly at the 'main' gauges. What Marcel describes about vector gauges would explain things if the plane was a CPU hog. But it isn't - it's a memory hog. I just proved it, as I describe in another message, by upgrading my machine from 512 to 1024 and watching all my frame rate problems go away.So we're still left with two questions: (1) why are just some of the gauges using 300+Mb of memory (it's a hell of a lot!); (2) why won't anyone from PMDG comment so that we can end the speculation and instead wait for a fix?- Pete

Actually Pete, I'd add a third question... why are so few people reporting this as a problem. The gauges must be using the same amount of resources for everyone, and the number of people with 1Gb must be in the minority, so why isn't there more bleating about this and an apparent fixation on the VC snag.

Pete,no problem so far.The gauges have to load all the navdata and other large data into RAM. It is also possible that the programmer forgot to delete GDI objects after using them and they are generated new all the time - but these are only speculations. It is also possible that the systems and displays are so complex that they need so much space, I don't know. Please do not ask why EasyGauges are a lot smaller than the main gauge - it is a very complex one with a lot of difficult source code and not to be compared with the easy gauges of EasyGauge.King Regards,Marcel Burrbluesky software

well guys now that u are talking that much about gauges I have a big problem with the panel and I want do fix it but I have tried all with no succes the problem is that the fmc (cdu) is not working you can change the contrast and stuff but it is all black so I can't use the plane, with out it. does any one know why and how to fix it.I have install all the sid's and star and it is not an electrical problem everything is running but it. thanx in advance.Omar Ortega.

Hi Andy,I too have the slow 5-6 fps issue with the VC, and with 1G of PC-2700 too. I haven't been writing here about it as I assumed that someone was looking into it, and I'd rather have them doing that work than reading my messages about it. It may be that PMDG doesn't yet know what's wrong, but is still researching it- but that doesn't imply that it won't be fixed at some point. My take is that we may see a fix when the FS2004 version comes out- but I still have lots of enjoyment just using the 2D panel for now. This plane really rocks!!Thanks,Bruce.

Well all I can say is that I use just the 2D panel version since I have only 512mb. It does indeed take a lot of time to load the plane and also when I minimise the screen from full screen mode and go back it takes a lot to redraw the panel. I've noticed a long time for FS to shutdown..for instance it close ok but the FS2002 icon will remain on the desktop for several second and in that time frame the PC is very slow!Using VC I do get low FPS and my VC quality is set to low. But I only tested it for a little while. I have refrained from posting also because I know they said they're looking into it so I didn't want to add anything useless to the thread, but now I just did! :-))Ragards,Bjorn

Forgive me, Bruce, but I think you're missing my (possibly inarticulate) point. There are two issues that I am aware of regarding poor performance. One is the problem of decaying frame rates once the VC is selected. The second is generally poor fps and l-o-n-g load times, even when the 2D only variant is loaded.The point is that PMDG have acknowledged the first, but they have never mentioned the second. Accordingly, I think it is extremely pertinent to keep mentioning it until some official acknowledgment is forthcoming. I would be perfectly content to sit back and let them work on fixing a problem that they admitted to and indicated that they were working on. However, as the issue does not seem to be universal, and as they have stated that they are working on the VC snag only and have not mentioned this problem, I am concerned that I may continue to suffer even after the patch. And my point remains... why is reporting of this not more common?

Pete.. you make it sound like a conspiracy .. "and then... silence"We've told the community we are working on a patch. We just don't repeat anything that is pinned at the top of the forum.VinPMDGwww.precisionmanuals.comhttp://www.vinscimone.com/dancnkid.gif

Even with complex gauges and navdata, etc., 300MB is really pretty outrageous. Does PMDG say that 512MB is a requirement? I don't recall seeing memory requirements, but I might have missed them. What's using all that memory?767PIC is a complex panel. I don't know the number off-hand, but I'd be surprised if loading that panel uses 10-20% of that 300MB.Yeah, I know, 767PIC doesn't have gauges with anti-aliasing, but that doesn't explain 300MB. I wrote an IVSI/TCAS "vector" gauge with my own custom anti-aliasing code (I prefer its output to that of GDI+), with at least three 32-bit pixel layers double the resolution of the gauge, and I doubt I use 1MB for that gauge, so I don't think anti-aliased vector gauges explains it.I'm trying to figure out what PMDG is doing with 300MB. I've written complete speech recognition systems that use less than 40MB.:-hmmmLee Hetherington (KBED)

Vin,Thanks for coming in to bat. The reason why some of us are still concerned is that you have indicated that you are working on fixing a problem with fps related to the VC version only. The problem under discussion here is not related to the VC at all...it is present whether or not the VC version of the ac is selected. Long load times and seemingly abnormal virtual memory usage are being experienced by quite a few people and I have not seen anyone from PMDG acknowledge that this is a problem. If you have done so, then I apologise, but I have been following the forum regularly.Thanks,