• Dear Cerberus X User!

    As we prepare to transition the forum ownership from Mike to Phil (TripleHead GmbH), we need your explicit consent to transfer your user data in accordance with our amended Terms and Rules in order to be compliant with data protection laws.

    Important: If you accept the amended Terms and Rules, you agree to the transfer of your user data to the future forum owner!

    Please read the new Terms and Rules below, check the box to agree, and click "Accept" to continue enjoying your Cerberus X Forum experience. The deadline for consent is April 5, 2024.

    Do not accept the amended Terms and Rules if you do not wish your personal data to be transferred to the future forum owner!

    Accepting ensures:

    - Continued access to your account with a short break for the actual transfer.

    - Retention of your data under the same terms.

    Without consent:

    - You don't have further access to your forum user account.

    - Your account and personal data will be deleted after April 5, 2024.

    - Public posts remain, but usernames indicating real identity will be anonymized. If you disagree with a fictitious name you have the option to contact us so we can find a name that is acceptable to you.

    We hope to keep you in our community and see you on the forum soon!

    All the best

    Your Cerberus X Team

The future?

Wingnut

Well-known member
3rd Party Module Dev
Tutorial Author
Joined
Jan 2, 2020
Messages
1,414
@Ferdi already started to make a bgfx target. There were some issues how to fit it into mojo and mojo2 to get a decent performance. Overall bgfx seems to be quite a big bag of software to put on top of cerberus.
 
I had contacted @Ferdi recently and his remarks were that he stopped working on it, as the performance will never be there. It has largely to do how he has to work around the limitations regarding missing data types in CX and how you have can interface with a 3rd party solution like that.
Plus he said he has no time to maintain it.

Any new GFX backend should be easy to maintain and performant. Basically I have to be able to maintain it.

There several paths we could follow.
  1. Stay in OpenGL ES and hope/wait till ANGLE finishes its support for Vulkan/Metal.
  2. Create our own native backend for at least Metal
  3. Go with a 3rd party solution
#1 might be the easiest solution but I think it won't be the most performant.
#2 Sokol's implementation gave me some hints on how to go about that.
#3 There I hit several times the wall where I could throw my comp into the same. Linker problem here, compiler error there. Of course, I am not a C++ guy so it is expected.

Using a 3rd party solutions should be easy to implement. Best would be to have a DLL or static lib you can link against. So far I looked at...

SOKOL

It is coded in C and uses initializers, that is not compatible with MingW. So no easy path here. His whole build and tool chain called Fips is so nonestandard, it is mind blowing. Adding to that, the author doesn't communicate. Plus point is that it is supporting Metal, OpenGL 3.3 and OpenGL ES. Web is supported through Emscripten. Android runs with NDK I think. But in general it is only a backend.

BFGX

Ferdi tried it and there is no easy way I guess to implement it. When you ask a question that he could easily answer, its author always refers to a support place that I never heard before. I has ALOT of push requests on GH which to me indicates that it has quite a lot of problems.

RAYLIB

To me the most appealing but then why the heck did its author names some of its structure the same like some windows structure. That made it incompatible with CX. At least when you want to compile it from source. There is no support for IOS and no METAL support in general.

There are a lot of other engines, which I am sure I will run into a lot of problems trying to integrate them.

If I can figure out how to use SOKOL with our tool chain, then this might be the way to go.

Any hints/help/comments are appreciated.
 
@MikeHart

Have you ever considered Heaps?
It is a free and open-source, cross-platform graphics engine for the Haxe programming language which is again free and open-source and similar to Cerberus, it is translate down to the target programming language, C++, JS, Java..etc but it is also have a framework called HashLink which is essentially works similar to JVM, .NET, Mono, Xamarin and have a bunch of libraries available to use.

Don't know if it feasible to target Haxe/Heaps from Cerberus, but Heaps looks pretty sweet and shared under the MIT license.
 
It is not about Haxe but Heaps really I'm guessing to target Heaps you need to target Haxe but I have no idea really.
What I have in mind is that Cerberus more simple to code, also you don't have to learn a new language if it was possible.
I did try Haxe and did not really like it so I did not get in to Heaps, but if I were able to target Heaps from Cerberus that would be interesting that's all I'm saying. But I have no idea if it feasible.

It was just an idea running through my head.
 
I believe the Haxe cross-compiler and VM is also open-source and free to use in open-source projects. So, maybe Cerberus 2 could be based on Haxe but keep the current basic syntax and use Heaps for rendering? Just an other random thought since I remember did see a discussion somewhere about what direction Cerberus 2 should go :D
 
Last edited:
Maybe the best way would be to realise a graphical API for all platforms ((Windows, macOS, iOS, Android and Web) by implementing a simplified Mojo3 based on only Metal and Vulkan that has what we've learned from Mojo1 and Mojo2.
We'll keep no more than 10% of all their commands to make it manageable in the future, a small API makes you think and become more productive.

We could implement it either directly or using library such as Moltenvik.
 
You keep mention the 10%. I always thought that the api is quite small. Please list whixh commands that 10% should be.
 
I would actually love that. I will do it till next weekend that's a promise.
 
I won't put too much energy into it
I guess what @MikeHart means, is that it would be interesting to know what sort of commands you prefer and which are the ones you don't use. This is definitely valuable input. At least this is what I am curious about. --- End Mindreading ;)
But for a useful api you have to find a good balance between beginner friendliness and performance/optimisation slots while keeping an eye on the workload for the maintainance of the code.
 
What i ment was that ok course i am curious. But don't expect changes. Your suggestion might be taken in or not. If that would be a problem then don't bother. I saw it happen before. Just my 2 cts.
 
Back
Top Bottom