Recently I have begun to notice my monitor will "flash" to a black screen during a flight. In that moment, not more than 1/10 of a second or so, the screen becomes black and I catch a glimpse of what I believe is the white box that we all see when our textures are loading during the period between selecting a flight and the cockpit coming up on our monitors. The timeframes are too short for me to even recognize what is being presented on the monitor's screen. After that, all returns to normal and the flight continues as though nothing happened. This activity does not follow a pattern. Some flights it doesn't happen at all. I am flying GA flights in Orbx's PNW in generally unpopulated, mountainous areas.I believe FSX might be loading some additional scenery textures or something that it needs that is also apparently not being loaded fast enough as the flight is progressing.I have no bufferpools. Internal FPS limited to 30. Settings on the high side. Flying either Carenado's C185 or Quest Kodiak. System is listed below.Any idea what it might be?Thanks

You could try:-[bufferPools]PoolSize=0..as you are running the 580's, John. Your proc isn't fast enough to feed them, but at the moment it still uses the default bufferpool. Setting it to zero will bypass the pool altogether. Secondly - I assume you have HIGHMREMFIX=1 in your [GRAPHICS] section?

Make sure all screen savers are turned off.Also check your power options. There is a setting for the screen to go blank after X minutes. Make sure this is disabled.

Hey Paul,I do have the HIGHMEM fix in my cfg file. Something strikes me that what I have in the cfg file is not spelled correctly though. I notice you have spelled the entry "HIGHMREMFIX" and I am not comfortable that I have spelled it that way. I will check when I get home.I will also go in and establish a bufferpools entry and set it to zero. I did not realize no setting in the cfg file would cause the use of a default bufferpool. Actually, to be honest, I didn't realize a default bufferpool existed.I read with much interest, you post to Mindyerbeak's thread about stutters and I was hoping you were about to answer the above.Thanks, my friend!BTW - I know this is off-topic but - how is the "Chippie" cockpit coming along?Thanks, Marc. I thought of that and that was the first place I started.

Sorry, John - you're right - next time I'll just cut n paste!!HIGHMEMFIX=1 is what it should be.. Duh!https://www.dropbox.com/gallery/52676345/1/Chipmunk%20Cockpit?h=aaf690

Edited January 26, 201214 yr by Paul J

OK, buddy - not a problem. Thanks for clearing that up. I'll go home tonight and try the bufferpool entry. So that I understand, do you believe the problem could be caused by the processor not being able to keep up with the 2 580s in SLi mode and that is why I am seeing a fraction of a second of loading going on? Thanks also for the link to the chippie cockpit. I'm telling you, you have done a marvelous job!Thanks again for sharing your expertise.

Hi John; No - I'm not saying it IS the cause - more that it could be the culprit.The 'ideal' would be a situation where the speed of the processor system matches the speed of the video system: i.e. if the ability of the processor to manage all of the raw pc and 'fsx' functionality, was matched by the ability of a video card to process and manipulate the video textures, vertices, etc, applying them to frames to be pushed to the monitors, such that the processor doesn't have to do that job - the result would be a 'balanced ' system. In your case you have a gpu setup that can paint faster than it might be able to get data. I'm not 100% sure that this is the case, but we've never experienced the above scenario. We've always had small-memory video cards with little or no processing power: here we are in 2011/12 and the reverse is - in your case - pretty much true. That buffer is not neede when the gpu outstrips the cpu. If it's the other way around, but close - we'll say a 4.4 gig proc, with a 480 for sure, and maybe a 560 - we might need a small buffer to takeup the larger blocks of texture/vertexes/indices, giving the gpu a breather so that it can finish off processing what it has in gpu memory right now. This is the reject threshold.

Thank you Sir. I really appreciate the information and your way of making it easier for me to understand.