Abstracting Graphical APIs

[phibermon]

The design chosen for FMX is totally unsuitable to base a game engine on in my opinion, it's an abstraction too far if you're looking to implement rendering techniques commonly used in game engines - you'll hit wall after wall. If you only use Delphi and you don't care about lighting, shadows, deferred rendering and anything else that you need to write custom shaders for then go right ahead but bare in mind that FMX is designed *only* to provide a hardware accelerated GUI across windows/osx/mobile to allow smooth animations etc.

To the best of my knowledge you have no direct access to the underlying graphics API and no control over what valuable graphics memory FMX uses, no control over multi-sampling and other OS specifics, where in the pipeline FMX renders, how it renders etc

For these reasons an engine co-existing with FMX is a world of compromise - it just wasn't designed with game developers in mind and that's fine because FMX's target audience are app developers who either don't know how or want to save time in creating hardware accelerated animation effects, something FMX does well enough to make it an attractive option for some.

There are plenty of existing 3D engines and of course you can write your own and if you want a funky GUI then it should be one designed to 'plug-in' in a generic manner to *any* rendering paradigm rather than one that tries to *be* the rendering paradigm.

My own JUI does this (designed from the ground up to be the UI of a 2D/3D hardware engine) and you'll find a number of other GUI's in the C++ world that you can use as dynamic libs if you're looking for a GUI to use with your engine.

But from the point of view of an experienced 3D engine developer? Steer clear of FMX! it's a very poor app-centric design that makes little to no concessions for shared use of the hardware.

Ogre3D is your friend. It's arguably the best multi-purpose 3D engine in existence (only being beaten by engines such as Unreal/Tech when it comes to first person, high density BSP style mesh / texture games)

Unity is popular but only because it does all the hard work for you, it doesn't actually do that hard work in an optimal way that can contend with technical engines such as Ogre.

--

But as stated, I'd just forget about DirectX if I were you. OpenGL is just as fast when used correctly and has a more logical design that's industry standard for everybody outside of Microsoft. The PS3 and PS4 both use GL so I'd say its credentials are good.

The only reason DirectX support would ever be considered worth the time and effort to add (to an engine that also targets non Microsoft platforms) is that certain older built-in laptop graphics adapters have crappy OpenGL support. Nothing to do with the API and everything to do with the drivers. If you're only targeting windows and are absolutely sure you never want to operate outside of the Microsoft eco-system then DirectX is a logical choice plus should you also develop in C++/.NET and wish to target the Xbox or Windows mobile platforms then it's not wasted knowledge.

However anything from Nivida/AMD is fine with OpenGL as are Intel chips from the HD3000 onward, the days of poor OpenGL support in drivers are long gone.

For WindowsRT support you can use a lib that converts OpenGL calls to DirectX (https://code.google.com/p/angleproject/) (and you can't yet target WindowsRT with any of the Object Pascal Compilers plus it'll all change again with Windows 10) and you can totally forget about Xbox support for non-microsoft compilers outside of the hacking scene.

Don't waste your time basically, target OpenGL and have fun developing your engine rather than spending 80% of your time hacking away at a working abstraction between two API's for no benefit.

[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

[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

[SilverWarior]

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

Wait what? Did I read this right? Are you realy waiting with the release of yours as to give me a batter chance of sucsess?