Fixing the relative positions of vector graphics

[nickpike 0]

Hi, have almost completed an Avidyne PFD/MFD combination gauge in XML, and most of the graphics are vector type including rolling numbers, etc. this is a complex gauge with a lot of information showing.Problem is, when resizing or switching windows modes, the relative positions of the vector graphics change a little. Anyone know if there is a way to 'fix' these relative positions. I have been advised that if bitmaps are used, this problem does not occur.Thanks,nick

[Varmint007 2]

Nick,I've found that by far the best way to deal with that is to design the gauge at the lowest resolution you want to support and then let internal scaling take care of higher resolutions. That alone won't solve the problem but it will help.Second, make sure you're not using integer math for any translations. The "partial" pixels will be helpful once scaled.There's no way to completely eliminate the problem (particularly with text), but it would also help if as many objects/point sizes as possible are evenly divisible by 2.Just a few things I've found useful is reducing the problem.Cheers,--Jon

[n4gix 4,947]

I'm not aware of any "method" to rescale the drawing dynamically, as it has always worked automatically for me, as long as I have followed the tips pointed out in the previous message... :)Every vector drawn gauge I've ever made in XML has rescalled itself automatically... I wonder why your's arent?One of the reasons why we coded our Avidynes in GDI+, so we could make use of translate_transform and rotate_transform...I don't know if it is possible to obtain the dim from a gauge in XML (that is, the on-screen dimensions).In GDI drawing (which is what XML actually uses!), the only way to absolutely control the scale of vector drawn images is to multiply the pixel coordinates by dx & dy, where dx is the product of dim.x/width_x and dy is the product of dim.y/height_y... i.e., the ratio of actual drawn size to the designed size.Example:width_x = 400 //(pixels)height_y = 300 //(pixels>dx = dim.x / width_xdy = dim.y / heights_y

[nickpike 0]

Thanks guys. it's late and I have my stupid head on. Are you talking C++ as my original message points out this gauge is in XMLJon, can you explain a little more please.>design the gauge at the lowest resolution you want to support and then let internal scaling take care of higher resolutions.Scaling has me a bit foxed. Are you referring to ImageSizes=. I believe that graphics cannot be resized this way, and all bitmap graphics have to be made to their correct reletive sizes.>Second, make sure you're not using integer math for any translations. The "partial" pixels will be helpful once scaled.I presume 'translations' means object movements. Please explain integer math (I know what this means but not in this context) and the partial pixels.>as many objects/point sizes as possible are evenly divisible by 2.Basically, does this mean that object dimensions and positions should be divisible by 2?Cheers, and thanks for your patience,nick

[Varmint007 2]

>Thanks guys. it's late and I have my stupid head on. Are you>talking C++ as my original message points out this gauge is in>XML>Jon, can you explain a little more please.>>>design the gauge at the lowest resolution you want to support>and then let internal scaling take care of higher>resolutions.>>Scaling has me a bit foxed. Are you referring to ImageSizes=.>I believe that graphics cannot be resized this way, and all>bitmap graphics have to be made to their correct reletive>sizes.No, I'm just refering to the natural scaling that takes place when resolution is changed. For example I build my gauges with pixel dimentions which correspond to 1024x768 (3 pixels on the screen is 3 pixels in the gauge code). But I fly at 1600x1200 (3 pixels in gauge code is 4.6875 pixels on the screen).I've just found that when vectors scale UP rather than down it seems to work better, even though it seems counterintuitive.>>Second, make sure you're not using integer math for any>translations. The "partial" pixels will be helpful once>scaled.Bad choice of words, I just mean don't go out of your way to round into whole numbers. Those fractional offsets for pixels may mean the difference between one or more pixels at higher resolutions.>>as many objects/point sizes as possible are evenly divisible>by 2.>>Basically, does this mean that object dimensions and positions>should be divisible by 2?That's what I meant, but in thinking about it, it's worthless advice and wouldn't help at all:) There is no correlation between various resolutions and '2'. There isn't even a common ratio between all screen resoutions.But there IS a common ratio between 1024-->1280--1600 which is 0.8, so perhaps dimentions based on that ratio would provide perfectly even scaling. /shrug--Jon

[n4gix 4,947]

>Thanks guys. it's late and I have my stupid head on. Are you>talking C++ as my original message points out this gauge is in>XMLNick, I'm fully aware your question referred to XML. In fact, the first three paragraphs addressed XML...What I was pointing out is how XML is actually implemented by the parser (which translates XML into GDI drawing code) and HOW that translated code will autoscale the drawing for you.Also, it's worth noting that even a C gauge drawing GDI vectors will suffer from the same scaling problems. It is because GDI doesn't scale well that these problems arise... ;)I know my message doesn't really "help" solve the problem, but at least now you know WHY it IS a problem!

[nickpike 0]

Yes, thanks Bill. I've made the gauge smaller and introduced some bitmaps into the problem areas and all seems mostly well now. Thanks for your help. The only 'problem' I have now is a broken circle used to show range will show ok until the flightplan is loaded and this hides the circle (map code is after the circle). If I place the circle bitmap after the map code the circle shows but on top. Is there a way to get the map code to be transparent?cheers,nick

[n4gix 4,947]

>If I place the circle bitmap after the map>code the circle shows but on top. Is there a way to get the>map code to be transparent?>cheers,>nickNo, unfortunately, since the return from fs9gps.dll is a pre-formatted, non-transparent bitmap. Because of this, everything from the map must be the lowest element (i.e, the first drawn)...As you've no doubt discovered, it's nearly impossible to get rid of 'black artifacts' from any bitmap that overlays the base GDI bitmap returned from fs9gps.dll...BTW, are you developing this as payware or freeware?

[nickpike 0]

Yes, I remeber now seeing some earlier posts where the HUD application was no good as it was not transparent.cheers,nick.I emailed you, BTW