Virtual Cockpit....

[Guest sidewinder]

Why is the gauge refresh rate in Virtual Cockpits so slow,compared to 2D panels ????I ve never understood why gauge refresh rate perfomance in VCs is so poor.Thanks

[Guest PhLem]

That's because there is more to render in VC mode than in the standard 2D-view. You can also try changing the setting in FS for the cockpit textures ( I think ).Udo.:-wave

[Guest JeanLuc_]

Hi Sidewinder,the main reason is that MS should read Code Guru.com more often. Actually, the rendering engine of FS2002 is not meant for performance. Here are some facts I recently discovered:all the bitmaps are internaly rendered in a 555 format. Whatever the bitmap source in the gauge, it will be processed as a 555 bitmap. The problem arises when displaying this bitmap on screen. From your current FS resolution / bit depth, your graphic card might need to convert on the fly the 555 bitmaps to a let's say 888 one (24 bits / 32 bits display modes). This is where the memory bandwidth problem occurs especially with an MX type of card (nVidia), and lead to poor performances. Also, due to a lack of consistency in the panel.dll module, when switching from 2D to VC then back to 2D, the VC gauges are kept in the update loop of the panel.dll hence they are drawn for nothing except eating cycles and gfx card memory bandwidth. Last but not least, it is a well know performance killer to lock() unlock() a DirectDraw surface too often. Acutally, on modern processors (P4 / Athlon) it litteraly stall the CPU. It looks like the FS2002 graphic engine lock()/unlock() its direct draw surfaces (the bitmaps that are displayed) for each bitmap display update!! that is 500 times the FPS if 500 bitmaps are present in the gauges displayed on the panel!!!!!!This is a very hard flaw to overcome since it is the direct 3D code in FS that is not optimized to the level other games are optimized. In fact, I've built some very advanced rendering functions for gauges that updates in less than a 2 ms cycle concurently with FS running, this including the full update cycle (erase / draw / blit). 2ms = 500 FPS. however, FS is so much locking the video card memory bandwidth that it requires clever workarounds to avoid such a bottleneck with FS.So the best advise is to set your FS resolution to the native internal format of FS2002 (16 bits) and avoid swithing back and forth the 2D and the VC.Hope this helps!

[Guest sidewinder]

Thank you very much, that was very informative :-)

[badderjet 181]

DUDE!!! :-eekYou a real psycho. :-)"I've built some very advanced rendering functions..." What should that mean with the 500 fps?Are you familiar with the DirectX SDK?Sorry for those stupid questions, but I'm just a simple, beginner gauge programmer... *:-*http://members.lycos.co.uk/fs2k2/avsim/sig.jpg

[Guest JeanLuc_]

Hi Etienne,I would'nt say I'm a direct X guru. Not at all. Actually, I'm quite a beginner Direct3D programmer.It just happend that there is some knowledge shared on the internet that explains how to stall your CPU and application with Direct3D and locking() unlocking() direct draw surfaces (used for textures) is one of the process to stall the CPU and the rendering engine.Actually, this look like what is happening within FS2002 from what I've looked at in its inner working (g3d.dll and such). This makes the VC gauges refresh slowler that what they could with a little bit more of performance care when designing the rendering engine. Each VC gauge is first drawn (rendered) to a surface (as in 2D). Then, the surface is "plastered" on another "panel wide" surface. Then, the rendered and composited panel bitmap is "plastered" to the 3D polygon that define the panel in 3D as a texture (in 2D, it is a similar process but the composited gauges are blitted to the screen over the panel bitmap one after the other). You can quickly stall you CPU and video card memory bus if you do not take care of optimising (scheduling) the bit blits, especially on an MX flavor of video cards particularly if you lock() unlock() the surfaces as far as I've understood, and especially if you render to a 32 bits depth screen (while internal FS2002 draws everything in RBG555 - this is also one of the reason whatever the quality of your 32 bitmap in Photoshop / PSP, if there is a gradient there is a great chance it will show banding).Don't get me wrong, the lock() unlock() mechanism is necessary and part of how the DirectX system is designed. I suspect it has some limitations when dealing with a high number of surfaces to blit, like in FS2002, and one of the reason we have poor refresh rate with the VC. There are other reasons such as one I've described that is the VC gauges and the 2D panel gauges keep there "PRE_DRAW" event eventhough the VC ones are not displayed.As for the 500 FPS, a refresh cycle of 2ms means you can do it nominally 500 times per seconds (1000 ms / 2 ms = 500 Hz). This is what actually some piece of code I've built to "vector draw" gauges achieve, in its complete cycle while running concurently with FS2002 (cycle = erase the surface, draw the surface then blit the drawn surface to the backbuffer of FS2002). Practically, because of the video card memory bottleneck, it never gets refreshed at 500 FPS on screen !! (not even speaking with the monitor refresh rate of course). It is however still very fast despite these constraints.Should you want to get more information, there are very good ressources here to start from: http://www.gamedev.net/reference/list.asp?categoryid=24#53I'm writing this to bring some knowledge as to understand the current limitations I've discovered when dealing with gauges for FS2002 that are not within the standard types (image, sprite ...). I hope more will join in to share their experience in this matter. It is a very important subject considering the venue of FS2004 for wich a lot of people say the VC will be the norm for panel design.Hope this helps!

[badderjet 181]

Oh, I didn't even know there's a way to look into such DLLs... And lotsa thanks for the URL. Will check it tomorrow (my holy last day of fall vacations...) :-)Etienne :-wave