I have developed a radar gauge, which can be found on my web site, and it is fully vector drawn, like the FS2002 GPS. It works perfect, but when I switch to VC mode, it is not drawn. I have also developed a ND gauge for my Airbus panels, which uses both bitmaps (FS2002 SDK macros) and vectorial drawings for TCAS information. In VC mode, the bitmaps appear, but not the vector drawings.I know it is a limitation of FS2002, and I'dlike to know if it has been corrected in FS2004.Thanks for any info !!

Its hard to say as its still in beta, 1 thing i will say is that your a320 panel has compatability problems in its current state. Thats about all im permitted to say. With microsofts NDA, legal stuff etc.I will get back to you on whether or not vector drawn gauges work in the VC if i can...Dave Long

Hello Eric and Dave.Sorry for my delay in providing you with answers. I moved back to Brasil just yesterday and today, so was caught in the midst of that.Eric, yes, vector gauges using either the GDI, GDI+, and DirectX all show up in the VC in FS9.Dave, to draw vector gauges using DirectX, it does not matter what version of DirectX is running, for the stuff you will be using is very basic, as far as DirectX programming is concerned. What I mean to say is that if you had done any vector gauges for FS8 using DirectX, they work just the same in FS9. So you are not using anything that DirectX9 has to offer over DirectX 8. DirectX 7, well, that's another story. Back then Direct3D and DirectDraw were two separate entities. With DirectX 8.0 and above, they have been joined and are referred to as DirectX Graphics by MS.Off the bat, the disadvantage of DirectX is that it has no pre-made drawing functions such as ellipses, arcs, etc. But it is extremelly fast.GDI is the opposite, a relatively slow engine render (no access to hardware acceleration, which is all DirectX Graphics is about), but great drawing functions ready to use.And GDI+ is the GDI with antialiasing capabilities, alpha channels, and gradient brushes. All that to end up being about 5 times slower than the GDI itself.I hope I have made my ideas clear now, but if not, or if you'd like to discuss this further, please ask. I am studying DirectX as we speak (write/read ;-)), so once in a while I run into some pretty interesting stuff.

>Thats about all im permitted to say.Duh! As far as I remember... Are we really...? :-eek

I have read somewhere in this forum that GDI+ uses the hardware acceleration. Regarding what you say, this information looks false.Can someone tell me if GDI+ is hardware accelerated or not?Eric

Yeah... I also seem to remember something like this.Anyway, dude, if this is correct or not, fact is, it is damn slow. :-rollEtienne :-wave

I used GDI+ on my ATR gauges. It's actually about 5 to 10 times *faster* than the old GDI gauges. So GDI+ is the way to go.Regards,HansDreamfleet / Eurowings Professional

Hello Hans.This is shaping up to be an interesting topic. Me and two other developers tested the same gauges, with the same vectors, drawn in bpth GDI and then GDI+. All of us got to pretty much the same results, GDI+ was always slower by an average of 5 times. So maybe there is a difference in the way we are using it.Could you ellaborate a bit on it, possibly with code snippets? I am willing to show you what my code looks like when using both the GDI and the GDI+, and perhaps we will be able to solve this "mistery".

I can only agree to this one.RegardsChris Koegler>I used GDI+ on my ATR gauges. It's actually about 5 to 10>times *faster* than the old GDI gauges. So GDI+ is the way to>go.>>Regards,>Hans>Dreamfleet / Eurowings Professional

Hi Fabio,I'm not sure about the difference in performance between GDI and GDI+, but as you may remember from our phone conversation, this is not only the reason True Display XP is not using any Windows API, but also why there is more than just a drawing API but also a gauge development framework for it. The limitations are not only in the api, but in the way FS handles the ressources to blit them on the panel. Now if only I can figure out a practical way to make it a vendor oriented package...Best,

What does it use *then*? OpenGL? Complete self written graphics engine or what?I by the way am experiencing the same as F

It is a complete self written ansi C (no assembly) portable (microcontrolable) vector drawing API, and scalable (parallelism). No windows API, no Direct X. It represents 4200 lines of code for now! Contrary to the ATR gauges and from what I've been told about them, True Display XP is really a sub pixel rendering API with a floating point precision scale and vector drawing coordinates. It also has a psycho-visual filtering system in real time to render how a CRT / LCD screen looks like (does not look like an antialiased bitmap rotated for example).I don't have any figure to tell yet but as an example, with FS2002 running, the Meggitt EHSI in its most complex representation (TCAS 100%, compass rose, all needles...) renders in less than 2ms on a P4 1.3. Considering that everything drawn is a vector (text are made of multiple lines...) this is pretty good. Jet Line 4 with all 5 screens opened (much more vectors than the Meggitt) renders with no impact on the performances. This is of course due to the API, but also to the framework!As long as you use OpenGL, GDI or GDI+, you basically ask the video card AND the processor to stall to switch back and forth to the drawing context and Direct3D...This is were your bottleneck is for complex EFIS such as the Jet Line 4 for example, along with how you "blit" on screen.Since I'm in a good mood today, here is the typical True Display XP HSI rose compass code, as it is executed in some popular True Display XP gauges lately. This code is called any time the EFIS is redrawn.==================================================================void PFD_BuildARC(float cx, float cy, float radius, float rotation, float step){ float dx,dy, dx2, dy2, nx, ny, radius1, radius2, angle; RXPvertex v1, v2; int idx; RXPOGL_Color(250,250,250); // draw the long ticks radius1 = radius; radius2 = radius - 25.0; for (angle = 0.0 + rotation; angle < 178.0 + rotation; angle += 10.0) { nx = sin(angle * 3.1415926535 / 180.0); ny = cos(angle * 3.1415926535 / 180.0); dx = nx * radius1; dy = ny * radius1; v1.x = cx + dx; v1.y = cy + dy; dx2 = nx * radius2; dy2 = ny * radius2; v2.x = cx + dx2; v2.y = cy + dy2; RXPOGL_LineThick(&v2,&v1); v1.x = cx - dx; v1.y = cy - dy; v2.x = cx - dx2; v2.y = cy - dy2;// RXPOGL_MoveTo(&v1);// RXPOGL_LineTo(&v2,TRUE); RXPOGL_LineThick(&v2,&v1); } // draw the small ticks RXPOGL_Color(230,230,230); radius2 = radius - 18.0; for (angle = 5.0 + rotation; angle < 178.0 + rotation; angle += 10.0) { nx = sin(angle * 3.1415926535 / 180.0); ny = cos(angle * 3.1415926535 / 180.0); dx = nx * radius1; dy = ny * radius1; v1.x = cx + dx; v1.y = cy + dy; dx2 = nx * radius2; dy2 = ny * radius2; v2.x = cx + dx2; v2.y = cy + dy2; RXPOGL_LineThick(&v2,&v1); v1.x = cx - dx; v1.y = cy - dy; v2.x = cx - dx2; v2.y = cy - dy2; RXPOGL_LineThick(&v2,&v1); } // draw the Compass Rose Text Markings RXPOGL_Color(255,255,255); radius1 = radius - 44.0; RXPOGL_SetFont(28, RXPOGL_FONTBOLD, RXPOGL_ALIGNCENTER); // relative size to the working resolution RXPOGL_SetFontHeight(0.9); idx = 0; for (angle = 0.0 - rotation; angle < 358.0 - rotation; angle += 30.0) { RXPOGL_RotateSet(angle,cx,cy); RXPOGL_PrintfRot(cx,cy - radius1,HSICARDCOMPASS < idx > ) ; // edited for AVSIM forums < > idx ++; }}==================================================================Hope this helps!

Bonjour JeanLuc.Thank you very much for this code snippet. This is exactly what I do to draw an HSI's tickmarks, drawing 180