Question about DirectX and GDI+

[Guest Dash80]

I have limited experience in programming (i.e. C++ in UNIX and VB in Windows).I've been researching all the incredible quality gauges that you can buy for FS2004, specifically the ones from RealityXP and now this TCAS gauge (http://www.leftseatsimulations.com/tcas791.htm). Why do programmers use GDI+? Isn't DirectX an accelerated graphics API that FS runs on? Would vector gauges better function if they were accelerated by DirectX instead of GDI+? Also, does GDI+ do more than just vectors? I'd like to create life sized steam gauge instruments that update at 30-60 fps. Most gauges (compiled, or XML) update far too slowly and are too rough to be useful for IFR training. If GDI+ only does vectors, then I don't think I can create smooth gauges like in X-Plane for non-glass cockpit avionics. Ideally I'd like an ADI that is anti-aliased, and allows precise pitch and roll. It's amazing how often real instruments reflect some kind of motion in relation to their flight simulator equivalents. I think most of this is caused by gauges being so slow to refresh. If you use X-Plane or RealityXP gauges you'll see what i mean in terms of precise flight control. The bigger the instrument, and the faster it updates, the better your aircraft control is.Thanks,Enrique==========================Frequency change approved,Good day.

[n4gix 4,947]

Unfortunately, the panel system for FS is - to be candid - not really a "system" as much as an ad hoc collection of routines that most of the time work together to achieve the desired results.One of the great deficiences of this "system" is it's inability to work with Direct X well. We are pretty much limited to using a single DIBSECTION and performing a bitblt to the drawing surface once per gauge cycle, which at best means 18 times per second.However, the odds are that we won't be able to fully draw all the required elements that quickly anyway, so something as complex as these Avidyne Entegra displays have been 'locked' to a fixed update cycle of 4x per second. As you can see though, there's a lot of data to be displayed, and in these first two the TAS isn't even turned on! ;)These are written with C++ classes and GDI+ for the vector drawing routines, but still use the "classic" FS DIBSECTION drawing surface:http://img71.echo.cx/img71/4501/aviidynepfd1xb.jpghttp://img100.echo.cx/img100/876/aviidynemfd5ec.jpgHere's a pic of the MFD with TAS enabled:http://img260.echo.cx/img260/8327/aviidynemfd010rn.jpg

[Guest JeanLuc_]

Hi,Let me try to shed some light! None of the Reality XP products use GDI+: they use a Reality XP proprietary API named True Display XP (TDXP).True Display XP is a rendering API which draws graphical elements (dots, lines, polygons etc

[Guest _ak]

Nice adverstisement :)Hovewer, for me GDI+ gauges looks a bit better than RealityXP gauges.LOC/GS needles refreshes pretty well. Never has an issue with it. But I use own cycle and not PRE_UPDATE events. "Needle smoothing code" is just one or few filters/predictors and not related directly to graphics. Can be used with any API. Never seen "vibrating numbers" on HSI. If TDXP use some kind or antialiasing, picture will very close to GDI+, if not, numbers will jump with rotating. Pixel precision resolution is something like old FS2k vectors, not antialiased at all. Color blending helps but for calculating proper color at the edges you should account for some things and this is goes to supersampling de facto (results is close). Even if you not using larger bitmaps. I spent a lot time for computer graphics and know, there is no magic, just a lot of math. Line tips can look a bit different on different monitors, epecially when compare old CRT and LCD with ideal geometryFor original poster: yes, GDI+ 1.0 is slow (all operations done by CPU) but this is very clean and powerfull API. I love it for simple to use transformations: rotations, scale, etc. I am familiar with DirectX and OpenGL APIs, they can provide more features and higher speed but coding time will much longer too.

[Guest Dash80]

>There is something to the smoothness of the gauge as well in>relation to the VLOC/GS needles: any gauge I know of just use>the FS SDK variables to get the needle deviation and display>them. The issue is that FS only refreshes them once per second>or maybe twice per second. This is absolutely not practical>for IFR approaches. Jet Line (and the Meggitt in the>Meridian), use a special

[Guest Dash80]

From what I gather... GDI+ seems too slow for anything but vector graphics. I'd want to model old airliner gauges that are non-glass. I figure GDI+ would be very slow when performing CPU based bitmap rotations as opposed to having DirectX do it in hardware. I don't think I can afford to have my gauges use the majority of the CPU since FS has to do its own thing too. To give a real life flying frame of reference... I fly a heavy jet. It's not glass cockpit. Whenever I intercept an ILS or LOC from an angle, the needles make micro-adjustments which the human can detect. I make 1/2 degree changes in pitch to stay on glideslope. However, I watch for trends within a single degree of pitch on the ADI. I watch the airspeed indicator number barrel rotate between each knot of speed. When I detect the barrel rotate over, I change power settings. The same goes for when I fly at high altitudes. For me, there's a big difference between Mach .70 and Mach .72. You can slide through .01 Mach number increments like an SR-71, but for real life flying, the changes are bigger than FS makes it out to be. Simply, the "resolution" of information you get off real life instruments is significantly larger than 99% of FS gauges due to refresh rate and lack of sub-pixel rendering. For me, RealityXP bred new life into FS for me because they are now smooth like real life. (no, I don't work for them). I'm hoping that I can find out if it is possible to do this for steam gauges the same way RealityXP did for glass-gauges.Thanks for providing info.==========================Frequency change approved,Good day.

[Guest Airbuzz]

OpenGL works fine, too, as can be seen by Project Mangenta.The trick is to seperate FS2004 and the Gauges/Panel/VC.For example I want high quality bitmaps for a VC.Thats not possible as FS2004 cripples down Bitmaps like a JPG image with 90% compression.I work on a project were we build an Airbus A380 3D-Virtual Cockpit as a standalone program. FS2004 runs in VC-mode and fills the 4 windows.Using FSUIPC we transmit the pilots view inside our cube to FS2004 to get back the correct FS2004 window pictures.

[Guest otisred]

Very well thought out post...Couple of questions:Is the TDXP available for use by other developers?How do you know that GDI+ uses supersampling?The initial question hinted at using hardward accelerated DirectX. Is TDXP faster than that?

[Guest JeanLuc_]

TDXP can be made available to other developers I guess, as much as Reality XP partners with other vendors to license its products with the vendor's product. How ready it is for being used by a third party developper is a good question too...GDI+ ressemble a scan converter based rendering engine: any primitive is first scan converted (i.e. the left-most and right-most coordinates of the "ideal" drawn shape is stored in a line buffer), then, line after line, the shape is drawn in spans from left to right (it may differ in the implementation but this is basicaly what it looks like). There is an inherent resolution limitation, even a fraction of a pixel resolution. It seems from experience than GDI+ is roughly 1/4th a pixel resolution. It may be 1/8th. You can definitely see drawn elements not keeping their spacial relationship on a rotating EHSI rose when done with GDI+.TDXP is cetainly not faster than Direct X (although I wonder for EFIS like screens), but Direct X, or OpenGL is certainly slow in the context of Flight Simulator, because of FS running in a Direct 3D context. Switching back and forth between these contexts makes it slow.GDI+ is generic: it must draw as simple as a line, and as complex as a wide stipple bezier clipped with overlapping regions... This is where most of the overhead is in this API, in the context of Flight Simulator.Another thing: most of the GDI+ gauges are also using GDI to blit their off-screen buffer to the FS gauge bitmap... This is a HUGE bottleneck. TDXP uses its own software blitter that blits faster, and in the FS gauge color space, while letting the video card hardware blitter free for something more relevant to the FS graphics updates.Hope this helps!

[jcboliveira 1]

How does GDI performs with temporal AA or in other words sub pixel motion?ThanksJos

[Guest otisred]

How long (in terms of milliseconds) does it take TDXP to draw a 400x500 EFIS-like display on a 2.8Ghz machine, including the blitting to the FS image?

[n4gix 4,947]

>How long (in terms of milliseconds) does it take TDXP to draw>a 400x500 EFIS-like display on a 2.8Ghz machine, including the>blitting to the FS image?I couldn't tell you, but it doesn't matter anyway. The fastest ANY gauge will redraw is 18 times per second (within FS), which would 0.0555 milliseconds. ;)Even the huge Avidyne Entegra as shown above has no problem keeping up a steady 18/sec redraw cycle.

[Guest JeanLuc_]

That is a very good question indeed! and the answer is even better: a very complex one, with dozen of airspaces and hundreds of navaids, plus all the usual EFIS like symbols, text, data etc... refreshes in less than 0.5 ms... on a P4 2.8! The good thing is that since it is not using any hardware accelerated feature, hardware GPU is entirely available to FS!It is faster than OpenGL (read: OpenGL refreshed and blitted bitmap backbuffer to a FS gauge with FS running on the same computer), and faster than DirectX or GDI+.0.5ms allows up to 2000 FPS (two thousand!)Hope this helps!

[Guest JeanLuc_]

Bill, you are wrong, and here is why:if your gauge redraws 18 times a second, and to do so takes 1/18 sec = 0.05555 seconds computations per frame (note you wrote 0.05555 miliseconds and got it wrong by a factor 1000) to draw its display, then FS won't have any CPU left to do his work.Speed MATTERS a lot: the fastest the gauge refreshes, the more CPU you leave to FS to do its minimum house-keeping and necessary computations, the less (to the point of unoticeable) impact on the frame rates and the better the user experience!We can all make HUGE gauges refreshing a steady 20 times a second if we are not considering Flight Simulator or user experience. True Display XP is the only technology I know (but I don't know them all) to do it 200+ times a second, without any impact to the FS performance :-)Hope this helps!

[n4gix 4,947]

>Bill, you are wrong, and here is why:Jean-Luc, I will gracefully bow to your superior knowledge on these matters... ;)When I am wrong, I am wrong. That's how I learn. My ego isn't so fragile that I cannot admit a mistake...