If this is your first visit, be sure to check out the FAQ by clicking the link above. You have to register before you can post.

If you have recently signed up, please make sure you log in so that your activity is registered. This is required for automatic promotions to work and to ensure your account is not deleted during the registration process.

AthenaOfDelphi

Moderation Process Reminder

Since this appears to be a problem, please be aware that some areas of the site are moderated. When you post to these areas, you will be told that your post is awaiting moderation.

You will not be able to see posts that you have made that are waiting to be moderated.

Do not think that because your post has not appeared that an error has occurred. If this happens an error message will be displayed (you should note this and report it in the 'Site News/Feedback' forum.

If you are interested in good steady game performance then I'm afraid FireMonkey isn't the best choice. You see FireMonkey is primarily designed for application development. While you can stil develop games with it it FireMonkey isn't the best choice for this.

By the way Firemonkey and Vulkan are two completely different things.
Firemonkey is a set of libraries that allows development of graphic rich applications. In order to do this Firemonkey uses advanced graphical API-s for content rendering like DirectX or OpenGL instead of using GDI rendering as the VCL does.
Vulkan is one of those advanced graphical API-s that allow programs to communicate with graphics card efficiently similar to DirectX or OpenGL.

As for Idera/Embarcadero adding Vulkan support to FireMonkey I seriously doubt this would solve all performance issues FireMonkey has. The main reason for this is the way how FireMonkey is developed internally. If FireMonkey performance would be only affected by the graphical API the FireMonkey uses for rendering the it should be reaching similar performance to other DirectX or OpenGL based graphical engines but it does not.

Thank you for your reply. I am very surprised about your answer and, to be honest, I cannot believe everything. I always thought that the main limiting factor for performance was the graphics card. Delphi does not anything else than every other 3D graphics engines. It sends out vertices to the graphics card. Delphi is even more respective to the underlying system architectures. For Windows it uses directX. I can't see where the performance could be freined. Even JavaScript achieves good 3d performance. I can't believe that Firemonkey in a compiled language could be slower than JavaScript scripts or C# bytecode. It does not anything else than sending vertices to the graphics cards, by an abstraction of the underlying graphics API. It can be true that very high level controls in Delphi are not programmed with the necessary performance. But for the main 3D functionality Firemonkey should be the same level as C++ OpenGL, on Windows even faster because of directX. With the Vulkan libraries support there should be the same performance as in C++ Vulkan applications. That was not even my original question. This was already clear for me. Therefore I am very surprised that you even disagree in my first suppositions. Do you have any informations or tests? That would be very strange. My question was only about the gain of performance of the Vulkan libraries themselves.

I am very surprised about your answer and, to be honest, I cannot believe everything. I always thought that the main limiting factor for performance was the graphics card.

Raw computational power of your graphic cards means nothing if the Graphical Engine is poorly implemented and doesn't use it properly.

Originally Posted by gerdich

Delphi does not anything else than every other 3D graphics engines. It sends out vertices to the graphics card. Delphi is even more respective to the underlying system architectures. For Windows it uses directX. I can't see where the performance could be freined.

According to my observations it does. I'm not sure what and how since Delphi doesn't ship with full source code for FireMonkey but I could never achieve performance of FireMonkey which would be even close to some other graphical engines.

Originally Posted by gerdich

I can't believe that Firemonkey in a compiled language could be slower than JavaScript scripts or C# bytecode. It does not anything else than sending vertices to the graphics cards, by an abstraction of the underlying graphics API. It can be true that very high level controls in Delphi are not programmed with the necessary performance.

How could you then explain the masive performance difference seen with Asphyre Sphinx 3 game engine when you were using built in rendering and ran very fast versus FireMonkey rendering which was about 20 to 30 percent slower and was required if you wanted to use FireMonkey controls for UI development instead of designing your own UI from scratch.

Originally Posted by gerdich

But for the main 3D functionality Firemonkey should be the same level as C++ OpenGL, on Windows even faster because of directX.

FireMonkey could never reach same performance as working directly with DirectX or OpenGL. Why? Because FireMonkey represents just another abstract layer on top of these API's. And as we all now each abstract layer costs some performance.
I also see you are one of those people who are convinced that DirectX on Windows is much better than OpenGL. Well it is not. Instead they are pretty much equal. Sure if you are using graphical drivers that sip with windows then you don't expect to get muc performance when using OpenGL. Just another Microsoft attempt to keep DirecX relevant. But if you install vendors drivers for your graphics card then you are good to go.

Any way in the end performance greatly relies on how optimized is the games graphical engine for working with specific graphical API. This is why some games run better in DirectX and some run better in OpenGL.

[QUOTE=gerdich;148967]Do you have any informations or tests?

Unfortunately I don't have any test available any more since it is some time from when I was evaluating FireMonkey for usage in game development. But in my last attempt I couldn't even make a complex UI for economic based sim game (lots of graphs and lists) without lowering FPS below 60. And this was only UI without the actual game scene.

Originally Posted by gerdich

My question was only about the gain of performance of the Vulkan libraries themselves.

Here is another misconception people have about the Vulkan libraries. People think that switching to Vulkan will magically improve performance. But that won't happen.
So how do then some games run much better when using Vulkan API in comparison of using OpenGL or DirectX?
The reason for this is the fact that Vulkan allows much better control over the rendering pipeline and thus allows much better optimizations. Without that additional optimization there would be no performance gain whatsoever.

And now for your question of whether FireMonkey performance would increase if FireMonkey starts using Vulkan API. I seriously doubt it. Why? Because if you want to get most out of the graphical engine then you need to optimize that graphical engine for its specific needs for specific scenario. But FireMonkey on the other end tries to support as many possible scenarios as possible. And it is practically impossible of optimizing something for so many possible scenarios because when you try improving performance for one scenario you may be hurting performance for another.

"OpenGL or Vulkan" would be reasonable question. The one you are asking doesn't make sense because Firemonkey is Embarcadero's take on making cross platform gui applications easily while Vulkan is API for communicating with graphics card. Apples and oranges.

I have to make a new application (C ++ / Qt), integrating a graphical interface. I am facing a big dilemma and I would like your opinion because I do not think I have enough perspective. Will Vulkan really replace long-term OpenGL? Which is the most profitable according to you?
thank you in advance.

Vulkan has *extremely* high entrance threshold. Many menial tasks the OGL / DX driver performs "under the hood", tasks you never had idea exist (like syncing memory access between rendering stages), Vulkan requires you to program explicitly. Thus, even to make a rotating cube work you have to have very good in-depth understanding of how videocards work and their components interact.

So, a simple answer, no. It is possible that OGL / DX will be (or already are) rewritten to be wrappers around Vulkan, but it the fact is Vulkan is a tool for seasoned pro veterans. 95% applications out there don't need such level of control over the video card.

For my 2 cents, I don't see OGL going away before a long time, since it's heavily present everywhere and more into pro-software.
I see more Vulkan replacing DirectX, but anyway.
I'm in the same boat as SilverWarior considering Vulkan isn't a magical thing to resolve any problem/optimization. As usual we will see if it will live the hype.