Sign in to follow this  
Guest Andy Warden

GDI+ analog instuments

Recommended Posts

Hi everyone!I am happy to see that GDI+ rendered instruments are being widely used. But to this day I haven't seen a single smooth-moving analog instrument.(say an ADI)Where is the problem?

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

Hi,I think there are two reasons:1) GDI+ isn't straight-forward to program2) See point 1:(I do know what you mean though - fluidity in analog FS panels is severely lacking.Best regards,Vulcan.

Share this post


Link to post
Share on other sites

I made some ASIs and stuff a few years ago in some tests, but it wasn't worth the framerate issues the slower comps see.

Share this post


Link to post
Share on other sites

>Hi everyone!>>I am happy to see that GDI+ rendered instruments are being>widely used. But to this day I haven't seen a single>smooth-moving analog instrument.>(say an ADI)>Where is the problem?>Try the RealAir Simulations SF260 (Euro 24.00). It has the smooth rendered instruments you're looking for - with no noticible framerate penalty! I am amazed other companies aren't licensing their "Smooth Guage Technology." You won't believe your eyes. Apart from the instuments it's also a fantastic aircraft with superb flight modeling.You can find additional info and purchase here...http://www.realairsimulations.com/msfs-air...2005/index.htmlGood luck,EG

Share this post


Link to post
Share on other sites

>Try the RealAir Simulations SF260 (Euro 24.00). It has the>smooth rendered instruments you're looking for - with no>noticible framerate penalty! I am amazed other companies>aren't licensing their "Smooth Guage Technology." Er, those are simply XML coded gauges. The XML code is embedded in the model file, and the "parts" are modeled in 3d.However, RealAir didn't "invent" the technique......Microsoft did!You simply put the XML "gauge code" in the MakeMDL.parts.xml file and apply the tags to the relevant parts in the GMax model... :)Granted, RealAir expanded the MS idea and broke some fresh ground with things that hadn't been done in any of the default a/c, but it is nevertheless MS's "idea."

Share this post


Link to post
Share on other sites

Hi Bill, do you know if it is possible to make the aircraft and gauge parts in FSDS, and then run this through makemodel to take advantage of the makemdl.parts.xml file?Also, anyone know when FSDS is to be updated to allow the use of XML code. This has been rumoured for some time.nick

Share this post


Link to post
Share on other sites

>Hi Bill, do you know if it is possible to make the aircraft>and gauge parts in FSDS, and then run this through makemodel>to take advantage of the makemdl.parts.xml file?Not directly, no. MakeMDL.exe will only compile .X files...>Also, anyone know when FSDS is to be updated to allow the use>of XML code. This has been rumoured for some time.I provided some information to Louis Sinclair over three months ago in an effort to help his understanding of how the process works. Since then, I've not heard anything further from him, either pro or con.Being an optimist, I choose to believe that my explanation and example files were brilliant, and he has been able to find a way to implement this in FSDSx, but recognize that may not be the case at all... ;)

Share this post


Link to post
Share on other sites

Let me also add that this technique, or better said, using the available SDK possibilities to do this, has been documented in a forum almost when FS2004 was released. I guess few vendors are using this, like Bill explained in another thread, because this applies ONLY to the VC. When offering aircraft with both a VC and a 2D panel, this in turn would mean that the vendor has to do twice as much work for the same product (two versions of the gauge, one set for the VC and one set for the 2D panel), and this will be reflected on the price.Furthermore, this applies only to "needle" type of gauge. Anything EFIS like (GPS with a screen, EADI etc...) cannot use this approach.The best would be a technique allowing smooth gauges, like True Display XP technology driving the Reality XP Sandel SN3308 or Jet Line, but for steam gauges. That would make them as smooth, but in both the 2D panel AND the virtual Cockpit!Hope this helps!Jean-Luc

Share this post


Link to post
Share on other sites

All good things come to those who wait. :)CheersShad

Share this post


Link to post
Share on other sites

Thanks for the insight. I was simply responding to the original author's quest for smooth analog guages - the RealAir SF260 provides that. Are there other manufacturers acheiving sharp and smooth guages through different methods?Thanks again,EG

Share this post


Link to post
Share on other sites

Well, there also exist quite a limitation to these techniques, which is why I won't even try them. Although the gauge graphics might be held in the panel, the mechanism driving the needle is still part of the modelfile. This means that it cannot be changed to read your personalized tooltip, add compatibility with some of your own other gauges you might have installed, fix any failure handling, or even replace it with a digital gauge if you wanted so.You might get smooth gauges, but the cost is far too high for me.

Share this post


Link to post
Share on other sites

I'm developing the Caravelle for Cloud9, due out in the next months:http://www.fscloud9.com/php/projects.php?lang=EN&id=48100% analog panel, all GDI+, absolutely smooth. In fact, the instrument refresh rate is not longer limited by the standard 18 hz gauges, so if the PC is running a 30 fps, the instruments will all refresh at that frame rate. Even more, if the PC can handle it.It's the only airplane in FS were I'm able to handfly an ILS just by following the Flight Director bars, because thanks to the smooth refresh, they become easier to follow.And, some interesting effects, like shadows for all needles, and, as you can see from the screenshots, glass effects *over* the needles.This panel will probably destroy the "GDI+ is too slow to make a complex panel" myth I keep reading on many places, since it displays a lot of gauges without slowing down. If will probably be the first GDI+ analog panel, both available in 2D and VC.No, it's not using any of the SDK, XML or GDI+ known techniques, I had to program an entire new C++ framework from scratch, because the handling of the graphics for an analog gauge in GDI+ is totally different compared to a glass gauge. Even more so, if you don't want to slow down the frame rate to unusable values.cheers,

Share this post


Link to post
Share on other sites

Sounds really great!!Looking forward to - any chance of a video?Or would a video just destroy any FPS advantage?

Share this post


Link to post
Share on other sites

>Or would a video just destroy any FPS advantage?That's exactly the problem I had. There's no way to create a video that would be able to give the exact feeling of the running product.First and foremost, the frame rate, I haven't managed to use, say, Fraps running at 30 fps or better without resorting to have a very low resolution during capture.And, since the panel, having vector antialiased needles, and true type antialiased fonts, looks better and better the higher resolution you use, any usual internet video will destroy the impression of quality, short of using HDTV perhaps, with hundreds of MB of data just for the video!cheers,Umberto Colapicchioni - VIRTUALI s.a.s.http://www.virtualisoftware.com

Share this post


Link to post
Share on other sites

Yeah thought so too :-(Have you thought about releasing a demo gauge just like reality xp did?Say an ADI that will run on its own?

Share this post


Link to post
Share on other sites

The video and the technical details are looking good Umberto!

Share this post


Link to post
Share on other sites

Umberto, it sounds awesome!Which is the best way I can get in contact with you? I'd like to talk to you about something. Do you have MSN messenger or ICQ? I'd really like to talk to you about something.ThanksAndy Warden

Share this post


Link to post
Share on other sites

I think the best option would be just providing the full airplane as a try before buy option. Doesn't make much sense to ask people to download a 100 MB video, just to advertize a 50 MB actual product!cheers,Umberto Colapicchioni - VIRTUALIhttp://www.virtualisoftware.com

Share this post


Link to post
Share on other sites

GDI+ can be quite fast depending how it's used. Some ideas:1) paint multiple gauges in a single paint and gauge file (= make single set of callbacks ). This saves A LOT of CPU cycles that you can instead use for drawing.2) think of a rendered gauge as a dynamic texture - render the gauge to a bitmap that is layered over the VC as a texture for example (allows same version of gauge to be used in 2D and VC)3) borrow a technique from sprite based games - heavy use of cache (bitmaps stored in memory) for "prepared" bitmaps to blit into position as needed, avoids having to render complex effects all the time for every frame - only prepare the bitmaps when they need to change - transparency is your friend, make sure you use the alpha channels - drawback is you need to keep track of which bitmap is which, and your memory footprint goes up, dynamic allocation and FS hate each other. The cost of compositing your layers is usually less than creating a new image from scratch.4) only paint when you have to - not when FS says you need to paint - the eye will normally not notice anything faster than 24FPS, but in practice and depending on what you draw, you really don't have to recreate a frame at every draw cycle - blit a cached image when FS needs a paint. If you update a gauge 8 times a second (8FPS) it's usually more than sufficient.5) only paint what you have to - don't re-create the entire thing if you can help it - construct the gauge in layers and only redraw the layer you need - I call this the onion peel principle - a good example is lighting effects or to lighten/darken a gauge.6) keep the GDI context open between calls (another huge CPU saver)7) use an event based model to draw asynchronously on cached bitmaps - while a pain to program, the main advantage is that your gauge will always update at the same rate independently of your FPS output.8) you can pre-render complex images with their alpha channel stored in the gauge as a resource (don't use a BMP format - use something like PNG which is friendly to transparency, size, and GDI+). This can be used for example to layer on top of a gauge a shaded glass cover. This is easier with a 2D panel than on the VC.9) rotate/scale via matrix, make color changes using the color matrix. Example is an arrow - draw the bitmap with an alpha, scale and rotate as needed - usually faster than drawing an actual arrow). Cache the matrix transforms as well so you can re-use them.I've also tried, but not been quite succesful yet at using DirectX to draw on bitmaps. DX is VERY fast, and you can get a context from any panel (2d or VC), but the issue is that thus far I end up really messing with the repaint cycle and I can't seem to get rid of visible artifacts. The other thing is that drawing in DirectX these days has become a major time sink. It's like writing in assembler, fast, but not so fast to code and hello debug! I'm exploring the OpenGL side now to see if it's less problematic with sync in FS. Thus far, it's not been worth the headache.Happy coding...

Share this post


Link to post
Share on other sites

>I've also tried, but not been quite succesful yet at using>DirectX to draw on bitmaps. DX is VERY fast, and you can get>a context from any panel (2d or VC), but the issue is that>thus far I end up really messing with the repaint cycle and I>can't seem to get rid of visible artifacts. The other thing>is that drawing in DirectX these days has become a major time>sink. It's like writing in assembler, fast, but not so fast>to code and hello debug! I'm exploring the OpenGL side now to>see if it's less problematic with sync in FS. Thus far, it's>not been worth the headache.Nice summary, Ettiene!Here's two things I learned while speaking with Susan (lead gauge/panel programmer) and Brian (team leader) while at Oshkosh this past month:1) Forget OpenGL. FSx will have even less support than it does now (which is practically none).2) Learn all you can about DirectX v10. The word is that will be the new standard in FSx.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this