• 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

Cerberus-X development procedure

Wingnut

Well-known member
3rd Party Module Dev
Tutorial Author
Joined
Jan 2, 2020
Messages
1,414
What API's and tools do you use for each platform to get the graphics working in Cerberus-X?
I'm curious about all the platforms, but especially Linux Desktop. With Linux Desktop you use GCC or G++ and some standard graphics API to compile the game binaries, correct? What are those API's / libraries?
 
I don't understand such question coming from you. You know that CX uses OpenGL and opengles. The source code is at your hands.
Android Studio for Android, Nothing for HTML5, Xcode for Macos and IOS, MingW 4.9.2 or MSVC 2017 CE for Windows. Linux used GCC.
 
And by the time you are around, you should definitely know the tool chain.
 
So no Linux-specific API? There were some dependencies I had to install to get it running.

I thought that also GLFW was used, together with cmake? I know OpenAl is used for sound instead of Jack.
 
So far I see nothing that stops me to compile for ARM and that's great news.
 
So no Linux-specific API? There were some dependencies I had to install to get it running.
Those would be the standard development libraries required.
I thought that also GLFW was used, together with cmake? I know OpenAl is used for sound instead of Jack.
GLFW is part of the target templates for Desktop applications. There's no need to install it and it doesn't need cmake to build it unless you intend to build GLFW yourself.

For sound, Desktops and Android use a version of OpenAL. Depending on the operating system, this would be:
Windows OpenAL the original/OpenAL-soft
Linux and Android OpenAL-soft.
Apple use their own implementation of OpenAL based off the original sources. At least for the time being.....

OpenAL is totally different to JACK. JACK is a sound server, OpenAL is not. Like pulse audio, Jack runs in the background managing communication between applications and the sound drivers. OpenAL will use whatever is installed as a 'back-end' be it ALSA, JACK or PULSE AUDIO if they are installed and OpenAL is set to use one of them.
 
Thanks. For sound, OpenAl uses JACK/JACK2 underneath of course most of the time. Which is good I suppose, and JACK2 seem even cross-platform now there's Linux, macOS and Windows at least. I'm looking into https://pipewire.org/ right now. I'm trying to tie things together and see how Oboe on Android or other Android low-latency audio API's could fit in.
 
Yes, we have been watching its progress and it looks pretty promising. The main issue with this (and many other render-layers) and mojo2 is, that gl-shaders have to be translated to metal shader language at runtime for full functionality.
 
I say mojo2 and mojo should be left like they are and build something new.
 
Okay. Can't you convert the few default shaders that mojo2 users using the GLSL converter in The author of open-source converters gave this advice.

And then let creators of custom shaders like me, do something similar. I have a few I need to migrate in that case and then I will learn to code what ever metal use directly.

I like what Mike says as well. I'm a little bit concerned about learning a new API as I've built everything in Mojo2 but still have confidence that it will be something good with all the features of Mojo2 and more. Will Mojo1 and Mojo2 stay at all in that case?
 
Some ideas I want to throw out there for inspiration if you need a working title for any new graphic API's

Caño (Meaning Vulcano and someone with metal-silvery hair)

Hephaestus (The god of vulcanos and metal-forging)

Meccaño (It's just cool)
 
Can't you convert the few default shaders that mojo2 users using the GLSL converter in
No, that's the problem. Mojo2 parses the shader to do some modifications and combines it with the mainshader and after that it puts it into the gl shader pipeline to make it executable. To make it functional you either have to translate the shader to metal at runtime or you have to rewrite the logic of mojo2 to fit for metal shader language.
 
Okay, that's a shame I just started to really like the simpler parts of GLSL and Mojo2.. It works very well.
 
I am sure somebody will come up with a solution for this. There is definitely a huge market for a layer that enables any openGL code to execute on a metal only platform. @MikeHart and me investigated a lot and tried to implement things like sokol to see where the issues are.
For now everything works on Metal platforms, but as soon as there is a deadline I am sure this problem will be solved without us having to do all the things by ourselves, so we put it off for a while.
 
I'm sure you know these but I'm curious what you think of them

3 ways to write cross-platform / agnostic shadercode:



SPIRV-Cross via
 
Back
Top Bottom