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.
Reply With Quote
Bookmarks