GDI+ analog instuments

[Guest JeanLuc_]

The video and the technical details are looking good Umberto!

[Guest Andy Warden]

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

[virtuali 4,436]

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

[Guest zip]

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...

[n4gix 4,954]

>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.