Abstracting Graphical APIs

[Vinzvega]

Wow, cool down man

I ask to Anton to see FMX because FMX implements a real abstraction of underlying hardware for graphics. And I said that we can discuss about the bad and the good, but it exists and available. I add this sentence justly to avoid the kind of post you do.

Everyone here know that FMX is not a game engine, and it is even write in the Embarcadero's documentation. The question was not to use FMX as is, for Anton, but see how it is done, and get ideas.
And Yes, you can access to the basic layer, throught FMX.Context.DX11, FMX.Context.GLES,FMX.Context.GLES.Ios and so on.

When Anton said "I want to try to put in my engine a well design abstraction layer" you heard "I want to make a powerfull 3d engine"
--> WTF ??

Frankly, I'm tired about that everytime we said the word "FMX" in Pascal community, it will unchain a curious angry. A bit of frustrating ?


Anton, to teach something, do not "Steer clear of" everything that could open your mind a give you a chance to choose.

cheers,

[phibermon]

I don't work for Embarcadero, my interests are in sharing knowledge and helping people to create what they want to create using the best possible tools available - not just the ones belonging to a single company.

I know I spoke mainly of game engines but I'm advising to ignore FMX specifically on abstraction grounds - it's closed source, the user will learn nothing. The general process of API abstraction can be learned from thousands of different sources, studying a closed source API when there's much better and open source examples to study is pointless. After all this site is called pascal *game* development and the user it talking about 3D API's so of course we're talking in the context of 3D game engines. So yes I heard "I want to make a 3D rendering engine" and not "I want to draw buttons on propitiatory platforms". They are two very different goals and the abstractions required are totally different.

FMX is a poor design even when cited as an example of abstraction so I wonder why you've chosen to mention it at all?

Frankly, I'm tired of Embarcadero employees recommending unsuitable Delphi features as if they were perfect for games. FMX may make use of 3D API's but don't be tempted to confuse FMX as suitable for game development just because it does. My lawnmower uses petrol, it's not suitable for the race track.

Recommending somebody dedicate their passion to your product just to shift units is immoral. It is their future in game development, not your advertising platform. The compiler is suitable for game development, the IDE is suitable for development in general and indeed many of the components could be useful as well (for game development, especially if you want to create database driven servers) but FMX out of everything Delphi has to offer is the one thing that definitely is *not* suitable for game development. Not in direct use or as an example of 3D API abstraction.

Just to be clear : you can use Direct3D and OpenGL in Delphi without FMX. I'm not sure if that's true on the mobile platforms however but there's always Freepascal.

[Vinzvega]

I don't work for Embarcadero, my interests are in sharing knowledge and helping people to create what they want to create using the best possible tools available - not just the ones belonging to a single company.

I know I spoke mainly of game engines but I'm advising to ignore FMX specifically on abstraction grounds - it's closed source, the user will learn nothing. The general process of API abstraction can be learned from thousands of different sources, studying a closed source API when there's much better and open source examples to study is pointless. After all this site is called pascal *game* development and the user it talking about 3D API's so of course we're talking in the context of 3D game engines. So yes I heard "I want to make a 3D rendering engine" and not "I want to draw buttons on propitiatory platforms". They are two very different goals and the abstractions required are totally different.

FMX is a poor design even when cited as an example of abstraction so I wonder why you've chosen to mention it at all?

Frankly, I'm tired of Embarcadero employees recommending unsuitable Delphi features as if they were perfect for games. FMX may make use of 3D API's but don't be tempted to confuse FMX as suitable for game development just because it does. My lawnmower uses petrol, it's not suitable for the race track.

Recommending somebody dedicate their passion to your product just to shift units is immoral. It is their future in game development, not your advertising platform. The compiler is suitable for game development, the IDE is suitable for development in general and indeed many of the components could be useful as well (for game development, especially if you want to create database driven servers) but FMX out of everything Delphi has to offer is the one thing that definitely is *not* suitable for game development. Not in direct use or as an example of 3D API abstraction.

Just to be clear : you can use Direct3D and OpenGL in Delphi without FMX. I'm not sure if that's true on the mobile platforms however but there's always Freepascal.

Hi,

I read your response at 11pm 30/01 and decided to drop, because, at this moment, it really hurt me.

this morning, at work, I just see your response again, and I see that you edit it after my read, and you wrote it in a much more diplomatic way.

--> You make an effort, and I decide too make an effort too, and I'm answering mainly because you ask think on me that is not right : you have the right to defend you opinion, and it should be suffisant.


To be clear, no, I'm *not* an EMB employees. Sorry Sherlock.


I'm working in financial stuff in Geneva, mainly in calculation in c language, in hpc/gpu tech, and, sure, a bit of delphi for our GUI.

So, I'm not working in fpc or lazarus, because we do not need it, simply, even if we have linux in server side, so we need rad for our gui. So we got delphi. So, Yes, I like delphi for years and I really believe that I can freely speek about delphi here. Even if it is a commercial product.

I apologize really that I found FMX cool about abstraction side of the system and graphics : This match for me the K.I.S.S. mode, it is working, easy to aprehend. So I speak about : that will never happen again here, I promise.

FMX have bad design and must be burn by the Inquisition, Okay, I noted.



I make new design very rarely, and, I confess, despite all my years in coding, I have always diffulty to tag bad or good design in code that I worked on : If the code is efficient in matter of support and modification it will survive. Simple. And I can say to you that quality is not really correlated to its design.

I understand too that the really main problem for you is the fact it is not game oriented 3d engine and it is close sources, and private held.
I forget this 2 importants facts, and see only the abstract side : You right, I Apologize.

--> Certainly, if FMX was open source, you'll find it technically much better ?! LOL (p.s : it's a joke, do not call Torquemada again and ignore this sentence !!)


No. The main problem for me, and it's really worring me : Why have you need to pass your message in a such condesendant way ?
Consdescance confirmed after, when, aparently, you are nominating yourself as a keeper of immorality, and keeping "young" people away of bad choice.

--> You know, when somebody is able to read, he's able to make is own choice without you.

You are showing the path, and that is your honour, But you didn't build it.


As you said, we are here because we all love Pascal and game, and that is suffisant : Useless to try to transform it in a holly mission.

Hope we can exhange later in more positive way.

[SilverWarior]

I must agree with phibermon about the fact that FMX is not best example of abstracting Graphical API.
The main reason for this is the fact that in FMX both graphical and logical part are tightly coupled together while most grahpical engines try to keep graphical and logical part uncoupled.
Keeping logical and graphical parts uncoupled means that logical part won't be slowing down the graphical part or vice versa. Not to mention that it is much easier to implement multithreading support when you have graphical part decoupled from logical part.

Do you want example to see how logical part can affect graphical part in FMX?
Simply create a FMX form with let us say 200 panels positioned on it. Compile the project and then go and rapidly move the mouse over the form and you will see significant increase in CPU utilization. On my laptop this is enough to lower FPS below 15 and having 400 panels on the form I can easily lower the FPS to single digits. And don't think that my laptop is weak. It is still powerfull enough to run farCry3 with athleast 30 FPS on medium graphical settings provided that I disable the AntiAliasing and MultiSampling.


Anywhay when I first tried FireMonkey I was verry exited but got quickly disapointed with its performance.
And what disapointed me even more is that even with that fraction of FMX code that Embarcadero made avalable (mosty source code for certain components) you can't help yourself much if you decide to go and try creating some custom components.
So in the end I ended up making my own UI library which is on hold for about a year now. I don't like talking about it to much becouse I feel ashamed that I still haven't gotten it to a usable state even thou I started working on it about two years ago if not even earlier.

[Vinzvega]

I must agree with phibermon about the fact that FMX is not best example of abstracting Graphical API.
The main reason for this is the fact that in FMX both graphical and logical part are tightly coupled together while most grahpical engines try to keep graphical and logical part uncoupled.
Keeping logical and graphical parts uncoupled means that logical part won't be slowing down the graphical part or vice versa. Not to mention that it is much easier to implement multithreading support when you have graphical part decoupled from logical part.

Do you want example to see how logical part can affect graphical part in FMX?
Simply create a FMX form with let us say 200 panels positioned on it. Compile the project and then go and rapidly move the mouse over the form and you will see significant increase in CPU utilization. On my laptop this is enough to lower FPS below 15 and having 400 panels on the form I can easily lower the FPS to single digits. And don't think that my laptop is weak. It is still powerfull enough to run farCry3 with athleast 30 FPS on medium graphical settings provided that I disable the AntiAliasing and MultiSampling.


Anywhay when I first tried FireMonkey I was verry exited but got quickly disapointed with its performance.
And what disapointed me even more is that even with that fraction of FMX code that Embarcadero made avalable (mosty source code for certain components) you can't help yourself much if you decide to go and try creating some custom components.
So in the end I ended up making my own UI library which is on hold for about a year now. I don't like talking about it to much becouse I feel ashamed that I still haven't gotten it to a usable state even thou I started working on it about two years ago if not even earlier.

Hi SilverWarrior,

Yes, I'm aware of quick performance deprecation you can have with this product : Even in 2D. There are no acceleration structure, so, FMX performance on "stress" is very bad.

In fact, I spoke about low level part (FMX.Context and FMX.Context.[Platform]) but, even if we consider only this part of the product, certainly many issues could be pointed : More or less, the easyness of technology access seduce me.

But as I said juste before, and As I recognized, talking about this subject here was a mistake.
The subject could be closed.


Scuse me cause I'm not understand : When you speak about your UI library, you build it upon which framework ? OpenGL ?

Kind regards,

[SilverWarior]

When you speak about your UI library, you build it upon which framework ? OpenGL ?

The basc design of my UI library is not to directly interface with graphical API's but instead with already built graphical engines. This is done through special abstract layer which serves as interface between my UI library and the graphical engine being used. This would hopefully alo it to be used with most graphical engines out there wheter they are pascal based or not.
So in a way it is more like an extension for existing graphical engines. The reason why I chose this approach is that at the time when I was starting to work on it there were several good pascal based graphical engines available like Asphyre Sphinx 3 or ZenGL.

So basically I'm focusing on high level development. I will leave midle level development (special abstract layer) to the developers or users of specific graphical engines since they have best knowledge of them. It would probably be posible to even develop the middle layer so that it directly interfaces with graphical API's for certain things.

Anywhay I'm afraid I'm still far from finishing it. It turned out to be much more difficult than I imagined, and my original design has already been replaced a few times

[phibermon]

I apologize if I caused offence and yes I was not very diplomatic much to my shame. I'm sorry.

Embarcadero and FMX is very much a hot topic for me - Like many Pascal developers in England I was taught Object Pascal and Delphi at School, College and University - Borland were making a big push to get the language recognized throughout the industry and we were all assured through our national institutions backed by the commercial might of Borland that Object Pascal had a future and it *did*, we all dedicated ourselves and our initial careers to Delphi. And all looked good until Embarcadero took over. Their lack of vision and effort followed by a series of poor quality control decisions that has allowed things like FMX to persist despite *repeated* failures and widespread criticism, things like IOS + Android support delayed for many years and Linux support *totally ignored*? these things basically say to the tens of thousands of people across the world that were counting on Embarcadero : We don't care about your future.

Delphi was the only thing keeping mine and many other peoples career prospects open. Just a few years ago Delphi jobs were abundant! and they still would be if Delphi had moved with the times.

Instead of a mighty cross platform system that works on all major platforms with a first rate library to match that of any C++ suite? We get a product stuck on Windows with poor cross platform support that was years and years late (and still woefully incomplete) and FMX : far from being the future of Delphi represents all that is wrong with the decisions made over the past few years. It's slow, badly layed out when compared to the *standard* VCL and enforces a design that makes game development next to impossible on IOS and Android (in pipeline as well GPU resources locked) you know Embarcadero, games? the number one source of revenue on Android and IOS? Thanks for that, really helpful.

So yeah, not a big fan of FMX on either technical or even general grounds. We should of had enterprise class database development on Linux, seamless RAD across all platforms, Android/IOS support *the moment* those systems came out. We should of had a professional, world class compiler and tool-chain. Instead we get animated buttons on IOS. Great. So for me the push for FMX is why Delphi is *no longer* the worlds greatest database client development tool and why mine and many thousands of people's careers have been ruined.

I wouldn't mind having support for other platforms years too late, I wouldn't even mind the total lack of Linux support (you know Embarcadero? the world standard in database servers? Delphi was the world standard for database client development? are you literally not seeing this?) But for FMX to be so *badly* designed as to be unsuitable for exploiting the main revenue streams on the platforms it was designed for? it's nothing short of insulting given the dedication that I and many people have shown in the past.

I hope FMX turns into some amazing fully capable system and we see support for spinning, hardware accelerated buttons on all major platforms and I wish all of its users happiness and joy.

But I won't be recommending FMX for games development and indeed I wouldn't recommend any other proprietary tech that ships with Delphi. It's too much of a gamble on a company that doesn't care about your future. Use open-source / standard libraries and API's even with Delphi - that way your hard work and effort will survive any poor commercial decisions.

I do want to see a brighter future for the language and for those looking to develop games in Pascal I do want to be able to recommend and advise what I objectively see as the best options.

I apologize again for my tone, it is unjustified unless you actually have an affiliation with Embarcadero - I just don't want anybody else's careers ruined on the promises of a company that can't deliver and the thought of an Embarcadero employee pushing FMX as suitable for games development in light of this made me angry. In such a context it is nothing short of greedy lying at the cost of people's future. Given that I can't see how anybody but an Embarcadero employee would recommend FMX? I assumed you were.

I'm sorry. I will now go and write a tetris clone with FMX as way of penance

[Vinzvega]

Hi Phibermon,

Thank you for your gentle response. I understand much better your reaction now.

Sorry on my side to not understand that more quickly.

I understand now too at what level you suffer about all the 5 last years of delphi actuality. I lived that with more distance, because not directly stuck with this market : I confess that when EMB bought the FMX technology from a component supplier and out DXE2 with IOS support throught FPC I honestly believe that was a proof of opening, and was very excited about. I was wrong. Sincerly, I'm just a little more optimist (naive ?) than you

You now, I grow up too with turbo pascal and Delhi1/2/3 and it was a fabulous period : I was angry when people compare it to VisualBasic, in this time already, Delphi began to be not well understood : Native compiler, advanced VCL : tremendous.

Today, Delphi change (not the VCL, despite the fact it is alway supported, good point !) RTL change, low level change and this new GUI library. Then, come the first problem with compiler deprecation and FMX "yoyo" quality, and persistant bugs. I excused all of that for 2 reasons : FMX was young technology and EMB was (is) alone in the market to get a chance to put Pascal again in front scene. All the other compiler, despite their top technical quality, is far behind. It is sad, but it is.

So, I shared near of all your technical analyze of EMB act about delphi : It is unfortunally true. But when you enumerate all the problem in one time, it is so hard to hear :/
In fact, the fact that EMB target only money (It is a Fund, behind EMB, and this is terrible for a firm, nothing count unless money behind the corporate action holder decision) is a kind of justification of the sad way taken by delphi today.

But I want to be more optimist : Perhaps, from those bad seeds, could grow again a beautifull and strong tree ? I hope. And for me, community is very important for that, but I see here and elsewhere (torry, Delphi.de) that community is less and less present. That is entirely the consequence of EMB act. You right again.
The worst, is that after all this heavy delphi break, EMB try with a new brand (appmethod) to get new people : I think this a loss of energy : Hope it will have good consequence on Delphi EcoSystem, but I doubt.

Hope, as you do, all will be better later. After the war, there are rebirth. Normally..

If, as a redemption, you make a Tetris in FMX, I'll install FPC (command line) and start make OpenGL stuffs with it right this afternoon !
(Ok, it is not really a punishment, but what to do else ?)

By !

[Anton]

Anywhay we are getting a bit off topic here. I just hope that we haven't scared Anton with to much information here

@Anton
How ever you decide I'm sure you can count on the help from more knowlegable pepole here on PGD when you will need it.
Unfortuantely I can't count myself into that group but if you will need any help in working with classes I belive I could be usefull as I belive I have pretty god knowlege about them. Not so much about interfaces but that is mostly becouse I myself don't see the need to use them. So far I have always managed to solve everything with classes alone.

Oh, on the contrary, I find everything very interesting. I didn't post anything since I solved my problem by not making such a layer. Thanks for your help. I'm now writing a small library for rendering in D3D11. About interfaces, for the last year or two I began to love working with interfaces.

As for FMX I can't really comment, since I have no experience with it. The only thing I know is from other people that it is heavy in terms of performance.

My passion is for my game engine I'll hopefully get some appreciation for my engine one day and I can live with downplaying my UI work so that you may get the maximum respect for something you're passionate about too

This is very interesting. Can you tell more? What features do you plan/support in your engine /do you have a demo video?

You now, I grow up too with turbo pascal and Delhi1/2/3 and it was a fabulous period : I was angry when people compare it to VisualBasic

it should be right up there on the front page of Slashdot, not laughed about in some random comments at the bottom of a post about alternative languages.

Yeah, this is sad. Very often I meet people with novice skills on programming (in lets say C/C++) to tell me that it Delphi/Pascal is not a serious language (more like something which someone invented because he had much free time) but maybe this is more a mainstream unconscious view, rather than objective. Most of the times when I mention "Delphi" often people ask me "Does anyone use this anymore?" BTW, I have seen forums with people fighting C against C++, so what's left for C++ against Delphi.

[phibermon]

So in the end I ended up making my own UI library which is on hold for about a year now. I don't like talking about it to much becouse I feel ashamed that I still haven't gotten it to a usable state even thou I started working on it about two years ago if not even earlier.

looking forward to seeing it! I wish you'd release it I've not released mine specifically so I don't step on your toes