GDI+ Alternative - C++ Gauge

[Guest fturner]

>I am sorry to insist, but this is not very clear to me. Maybe>my English is not good enough :-(...>What do you mean by "not ready for prime time usage in FS"? Do>you mean it is not usable?>I understand MS uses AGG for whatever image processing, but I>don't understand why it prevents us from using it for vector>gauges. Where is the problem?>>Thanks,>Eric>Someone above stated that Agg is not ready for people to use in FS as it does not, according to him, do "everything" that is needed to make it an alternative to using GDI+.If you think you can make it work Eric, go for it. I'd like to see a panel that completely utilizes agg, as I won't be doing anything as I no longer develop anything for FS because I have lost the interest.... for obvious reasons.Frit

[Guest fturner]

>Frit,>>I'm not worried, because I'm not shooting for the prime>time... Weekday afternoon programming is good enough for me.>;-)>>MartinLOL! thats the way its getting for me ;).Frit

[Rocky 128]

Frit,I really hope I will be able to show a full-AGG panel one day. When? I can't tell, but I hope I will find the time to do it.I regret you lost interest for this...Eric

[Guest fturner]

>Frit,>>I really hope I will be able to show a full-AGG panel one day.>When? I can't tell, but I hope I will find the time to do it.>I regret you lost interest for this...>>Eric>I lost interest about a year ago, then I tried to rekindle it last Jan. but the fire wouldn't light again LOL.Frit

[WarpD 824]

>I am sorry to insist, but this is not very clear to me. Maybe>my English is not good enough :-(...>What do you mean by "not ready for prime time usage in FS"? Do>you mean it is not usable?>I understand MS uses AGG for whatever image processing, but I>don't understand why it prevents us from using it for vector>gauges. Where is the problem?>>Thanks,>Eric>Eric,Frit is misrepresenting my point and it's becoming confusing. There are certain functionalities missing from AGG and AggPlus. The ability to render a polygon is not in AggPlus. The ability to clip even the most basic of rectangular areas is not in AggPlus.If you want to render bitmaps, AGG and AggPlus are mostly ready for use. If you want to do true vector graphics (no bitmaps), you'll need both polygon and clipping support first. Since it's not part of the AGG/AggPlus API... it will make it extremely difficult to code a complex glass gauge.

[Guest Patrick_Waugh]

Yes, this thread was great. I am surprised at how many are deeply into programming and even know what a render pipeline is.I have to laugh, on and FSX video Mircrosoft was talking about how they check various forums and that on AVSIM, where they are known for "no holds barred" (or something like that) I was thinking what are they talking about?Now I know. hahaha

[Guest fturner]

>>I am sorry to insist, but this is not very clear to me.>Maybe>>my English is not good enough :-(...>>What do you mean by "not ready for prime time usage in FS"?>Do>>you mean it is not usable?>>I understand MS uses AGG for whatever image processing, but>I>>don't understand why it prevents us from using it for vector>>gauges. Where is the problem?>>>>Thanks,>>Eric>>>>Eric,>>Frit is misrepresenting my point and it's becoming confusing. >There are certain functionalities missing from AGG and>AggPlus. The ability to render a polygon is not in AggPlus. >The ability to clip even the most basic of rectangular areas>is not in AggPlus.>>If you want to render bitmaps, AGG and AggPlus are mostly>ready for use. If you want to do true vector graphics (no>bitmaps), you'll need both polygon and clipping support first.> Since it's not part of the AGG/AggPlus API... it will make it>extremely difficult to code a complex glass gauge.Ed, you have just proven that you know nothing about Agg.... Agg DOES support drawing polygons, ellipses and so on filled and none filled, double lined, different coloured edges, arced edges, chamfers, textured, gamma colour ranges and so on and so on and so on...... and agg does in fact have basic clipping support...... how do you think I'm drawing the PFD in the first place............ with my fingers???????Aggplus may not directly support that as you say, which now after reading this post of yours abviously has shown me you probably don't even understand aggplus either.No WONDER I got fed up with the FS world.... people making statements like the above that have no clue what they are talking about.Frit

[WarpD 824]

>Ed, you have just proven that you know nothing about Agg....>Agg DOES support drawing polygons, ellipses and so on filled>and none filled, double lined, different coloured edges, arced>edges, chamfers, textured, gamma colour ranges and so on and>so on and so on...... and agg does in fact have basic clipping>support...... how do you think I'm drawing the PFD in the>first place............ with my fingers???????>>Aggplus may not directly support that as you say, which now>after reading this post of yours abviously has shown me you>probably don't even understand aggplus either.>>No WONDER I got fed up with the FS world.... people making>statements like the above that have no clue what they are>talking about.>>Frit>I suppose I should have added more words to my statement to make it clearer. AggPlus, the direct plug-in replacement for GDI+ does not support either polygons or clipping. Thus to support it, a basic requirement for glass gauges, would require a great deal of work on anyone's part to bring AggPlus up to the level of actually being a replacement.As well, I don't believe AGG supports path clipping, something I utilize in several gauges.Like I said, my point is that AGG is designed for imaging, not games. AggPlus is not complete and missing two critical items. Text rendering is slower. Caveat emptor.I have not, nor will I insult you. A shame you're unable to avoid behaving that way yourself.

[Guest fturner]

Path clipping.... yup..... no sweat. As for text.... well I did use GDI+ for the text portions... until I built a routine that compiled glyph paths for all the fonts I wanted using path arrays, and by golly, the guage began to react alot faster once I dumped gdi+, and all I needed to do was call one function with a string and the location of that string in respect to the pixel location I wanted it at, WITH the option of appending it to a storage path.So far everything you have stated that Agg cannot do, it actually does. Lets go further. I have several polygons that I need to transform by rotating and alter perspectively.... whoa there, guess what, it does do it and very easily.Your argument for agg being designed only for images and not gaming.... well let take a look at GDI+ shall we.... last look it was not designed for gaming either, but more for a very high level api so folks can do charts etc just like in excel, and easily.I haven't insulted you, I'm just pointing out your errors as you list them here....... Your out to trash agg every way you can because obviously you think GDI+ is a very superior product to use. Agg can do everything gdi+ can do only better and faster... at the expense of a little more complexity to develop it. I'm game to keep my customers happy.As for imaging, well how come 95% of the functions within agg are for vectorial type graphics? The answer is..... several folks wanted an alternative to using other vectorial api's that cost a fortune to license and did not have everything they needed...... and had performance issues, with gdi+ being such a very limited beast for such.You have made it very clear that you will not endorse agg in any way.... so be it, stick to gdi+ as obviously you understand it better. But you don't need to tell people that Agg doesn't do things, when in fact it does do them.In the end, its up to the other developers if they want to learn and use agg because it does have alot of potential for gauges, and heck I've only scratched the surface. So lets leave it be between us 2, you stick to GDI+ and I'll stick by Agg and help those that are interested in using it.To the others, I apologize that this thread that was intended to be an intro to something new and exciting has led to this. I feared that the direct put downs on supposed short comings of agg that turned out to not be a short comings where going to turn alot of you away from agg, so I needed to set things straight.All I ask for the rest of you to keep an open mind and try out agg by using my sample for a base, and work out for yourselves what you prefer. Join the mail group for agg, and you will find all the support you will need to use it and the response is very quick.With best regards, and loads of regret for ever starting this.Frit

[WarpD 824]

>Path clipping.... yup..... no sweat. As for text.... well I>did use GDI+ for the text portions... until I built a routine>that compiled glyph paths for all the fonts I wanted using>path arrays, and by golly, the guage began to react alot>faster once I dumped gdi+, and all I needed to do was call one>function with a string and the location of that string in>respect to the pixel location I wanted it at, WITH the option>of appending it to a storage path.Having to spend the time to create your own text rendering routine goes against the concept of an API ready to use. As for path clipping, sorry I can not locate that in the AGG documentation. Of course the documentation is positively horrendous, to be honest.>>So far everything you have stated that Agg cannot do, it>actually does. Lets go further. I have several polygons that>I need to transform by rotating and alter perspectively....>whoa there, guess what, it does do it and very easily.Wow... even GDI+ does that... what's your point? Honestly.>>Your argument for agg being designed only for images and not>gaming.... well let take a look at GDI+ shall we.... last look>it was not designed for gaming either, but more for a very>high level api so folks can do charts etc just like in excel,>and easily.>Umm... I never said GDI+ was designed for anything. Almost all AGG examples are written to manipulate images, because that's it's strong point and what it was originally designed for.>I haven't insulted you, I'm just pointing out your errors as>you list them here....... Your out to trash agg every way you>can because obviously you think GDI+ is a very superior>product to use. Agg can do everything gdi+ can do only better>and faster... at the expense of a little more complexity to>develop it. I'm game to keep my customers happy.>Yet again, you prove my point. AGG isn't ready-to-use. Nor is AggPlus. Both will require a significant amount of developer effort to fill in the 'holes'. For those that want to spend the time, sure... fine. However, you're here touting it's a ready-to-go replacement for GDI+. It is not. And it's not a "little complexity", not by a long shot. ;)>As for imaging, well how come 95% of the functions within agg>are for vectorial type graphics? The answer is..... several>folks wanted an alternative to using other vectorial api's>that cost a fortune to license and did not have everything>they needed...... and had performance issues, with gdi+ being>such a very limited beast for such.>Once again, I'll point to the examples... image manipulation.>You have made it very clear that you will not endorse agg in>any way.... so be it, stick to gdi+ as obviously you>understand it better. But you don't need to tell people that>Agg doesn't do things, when in fact it does do them.>I certainly can't endorse it as a ready-to-go replacement, it's not.>In the end, its up to the other developers if they want to>learn and use agg because it does have alot of potential for>gauges, and heck I've only scratched the surface. So lets>leave it be between us 2, you stick to GDI+ and I'll stick by>Agg and help those that are interested in using it.>I'll stick to what provides the most capability with the least manhour/maintenance cost. Your PFD code is about 10x the size of mine.>To the others, I apologize that this thread that was intended>to be an intro to something new and exciting has led to this. >I feared that the direct put downs on supposed short comings>of agg that turned out to not be a short comings where going>to turn alot of you away from agg, so I needed to set things>straight.>Why is it pointing out shortcomings of software, and pointing out that when someone offers it up as a direct, ready-to-go replacement for GDI+ a putdown? Reality is, AGG offers a lot of potential. However, it's not as flawlessly perfect and insta-replace as you continue to imply.>All I ask for the rest of you to keep an open mind and try out>agg by using my sample for a base, and work out for yourselves>what you prefer. Join the mail group for agg, and you will>find all the support you will need to use it and the response>is very quick.>>With best regards, and loads of regret for ever starting>this.>>Frit>When AggPlus is fleshed out to provide all the functionality of GDI+... then AGG and AggPlus are ready. Until then, you're talking about a lot of development time to fill in the holes.I myself would like to move to AGG... but I have deadlines on projects and they don't have space for months worth of finishing off a half-finished API and writing my own text rendering routines.Unless you have lots of free time and no constraints... I would recommend against moving to AGG or AggPlus until they are truly plug-and-play replaceable for GDI+.Now Frit, I know this response upsets you... but the fact is... there are indeed two sides to this issue and it's not about what I WANT... it's about what I see and what you're not saying. I see people in this forum struggle with XML, GDI+ and the basic C++ default coding for gauges. AGG is not for most who post in this forum. AggPlus is not a direct replacement for GDI+, I even had to modify my PFD code to even get it to start to compile, and then polygon support wasn't even available from AggPlus. Because I point this out doesn't mean AGG and AggPlus are to be avoided by all. It has to be decided based on all the info, not just yours.

[Guest fturner]

Ok, I give up...Frit

[tiberiu11 55]

>>Path clipping.... yup..... no sweat. As for text.... well>I>>did use GDI+ for the text portions... until I built a>routine>>that compiled glyph paths for all the fonts I wanted using>>path arrays, and by golly, the guage began to react alot>>faster once I dumped gdi+, and all I needed to do was call>one>>function with a string and the location of that string in>>respect to the pixel location I wanted it at, WITH the>option>>of appending it to a storage path.>>Having to spend the time to create your own text rendering>routine goes against the concept of an API ready to use. As>for path clipping, sorry I can not locate that in the AGG>documentation. Of course the documentation is positively>horrendous, to be honest.I agree with you, the documentation that AGG has is very bad, that was my reason for abandoning Agg 6 months ago. Now look at Fraser's post. He is offering to help anybody that wants with problems like this. I think that this is a generous offer that replaces the documentation, since he is a real person and not a book.>>I haven't insulted you, I'm just pointing out your errors as>>you list them here....... Your out to trash agg every way>you>>can because obviously you think GDI+ is a very superior>>product to use. Agg can do everything gdi+ can do only>better>>and faster... at the expense of a little more complexity to>>develop it. I'm game to keep my customers happy.>>>Yet again, you prove my point. AGG isn't ready-to-use. Nor>is AggPlus. Both will require a significant amount of>developer effort to fill in the 'holes'. For those that want>to spend the time, sure... fine. However, you're here touting>it's a ready-to-go replacement for GDI+. It is not. And it's>not a "little complexity", not by a long shot. ;)Ok, maybe you do not understand this, but Fraser is right. Let's take a very good example: Reality XP. They developed their own API just like GDI+ and Agg, but much faster and better than GDI+. Look at what they achieved with it, now they can really brag about having the best and smooth gauges, because they are. As an owner of their Jetline 2 and 4, I was impressed by their near minimal frame rate impact and of their smoothness. It is worth to develop the AGG api(not AGG plus, I am not talking about that), as when you are stuck with a project that requires 8 GDI+ gauges, nobody can help you optimize that, since there is not much that you can do. This effort can lead to having users that are satisfied with the product, that praise you for good frames, not unhappy ones that always say that the frames are low, that they have stutters, etc. Do not look at Agg from your arguments, think outside the box, there is much more that Fraser wanted to say and express with his example, not how easy or hard it is for the developer, but how it can lead to a better product, which should be the developer's number one goal. I would rather do a little more work than to have angry users.>>As for imaging, well how come 95% of the functions within>agg>>are for vectorial type graphics? The answer is..... several>>folks wanted an alternative to using other vectorial api's>>that cost a fortune to license and did not have everything>>they needed...... and had performance issues, with gdi+>being>>such a very limited beast for such.>>>Once again, I'll point to the examples... image manipulation.>>>You have made it very clear that you will not endorse agg in>>any way.... so be it, stick to gdi+ as obviously you>>understand it better. But you don't need to tell people>that>>Agg doesn't do things, when in fact it does do them.>>>I certainly can't endorse it as a ready-to-go replacement,>it's not.Let's not forget AGG's advatages when compared to GDI+. Everything has a bad part in it, but in AGG, you can change that by having the source code, in GDI+, you are stuck with it. Ok, a person that has time and knowledge can do whatever he wants with AGG, but a person that really needs a FD asap, should stick to GDI+, as that offers speed. (honestly, I learned GDI+ very fast and I also was disappointed by the examples, documentation, etc of AGG.) But now that I think of it, Agg is freeware, so most of this can be explained. GDI+ is also freeware, but Microsoft is behind this, not a person that has a family and a job.>>In the end, its up to the other developers if they want to>>learn and use agg because it does have alot of potential for>>gauges, and heck I've only scratched the surface. So lets>>leave it be between us 2, you stick to GDI+ and I'll stick>by>>Agg and help those that are interested in using it.>>>I'll stick to what provides the most capability with the least>manhour/maintenance cost. Your PFD code is about 10x the size>of mine.>>>To the others, I apologize that this thread that was>intended>>to be an intro to something new and exciting has led to this.Well, I was interested in learning more aobut Agg from this thread, not seeing arguments againt it. By doing this, nobody benefits from the purpose of the thread, to promote a product that can help programmers.Ok, let's take a practical example. The first person that can prove that he can convert his PFD from GDI+ to Agg without any tradeoffs or failures will prove that Agg does indeed have potential. I am talking about a complex PFD here, not just an AH. I am not asking anybody to do this, just saying what I think that would be the best course of action in order to settle this.I did not come here for any flame wars, or to argue with anybody since I have better stuff to do, like to work on my projects.Sincerely,Tiberiu Nicu

[martinboehme 493]

Pardon, j'avais oublie ton post... merci pour l'explication, maintenant c'est clair!> Thank you also for your feedback on the lack of "marketing" about TDXP!> Inspite of many information on the website, it seems the market reads> "GDI+ = smooth" while I'd prefer it reads "TDXP = fluid" ;-)Actually, I didn't mean to imply that there was a lack of marketing... just that all of the information about TDXP on the website was shrouded in "marketing speak", so it was kind of hard to tell what TDXP really is. Check this, TDXP has "an advanced psycho-visual filtering stage"... wow! ;-) Not intended as criticism, quite the contrary... that's the kind of stuff that's _supposed_ to be on a website. ;-) Just makes it hard for inquisitive types like me to find out what TDXP really does...Your performance numbers sound pretty impressive... I've thought about getting your FlightLine N/T gauges on several occassions... it's just that I don't do a lot of GA flying (I'm more of an airline type).Martin

[Guest fturner]

For those that are interested in trying out Agg and learning more about it, and not have to get lost in pointless arguments are more than welcome to join us over at http://www.cfstudios.com/forum It turns out there is several of us who feel Agg will work, as it has been proven already and we want to keep the fun and challenges of learning something new as well :).See you on the flip side to having some fun.Frit

[Guest JeanLuc_]

no no, I really thank you for the feedback: it means marketing failed to expose clearly the advantage of the technology!The psycho-visual filtering stage is a kind of filter effect supposed to render the look and feel of a CRT, with a subtle glow from the drawn pixels and a couple other subtle effects. This goes one step beyond just painting pixels on the screen with a color, and should give a closer to EFIS look to the result.The hard part about this filter is to make it not too apparent, and of course, with almost nil CPU penalty. It indeed has nil CPU penalty because it is "interleaved" with the pixel alpha blender at near no instruction cost.With the latest TDXP (in development for our FSX products), we have also totally eliminated 2/3 of memory bus useage needed by the FS panel system. Simply put, we are able to draw in a backbuffer, and have FS seamlessly use this backbuffer directly when it need to redraw the gauge, while other API implementations almost always require to 1) draw in a backbuffer, 2) convert backbuffer to FS destination surface color space 3) transfert the backbuffer bits to the gauge element bitmap allocated memory 4) have FS take this bitmap allocated memory and render it to the screen.The numbers above are reference to drawing then blitting the mentioned typical display to a Windows window (this adds 1 step that the gauge context does not have) :-)