Cerberus-X development procedure

Jimmy

Active member
3rd Party Module Dev
Tutorial Author
Joined
Jan 2, 2020
Messages
912
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?
 

MikeHart

Administrator
Joined
Jun 19, 2017
Messages
3,165
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.
 

Jimmy

Active member
3rd Party Module Dev
Tutorial Author
Joined
Jan 2, 2020
Messages
912
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.
 

Jimmy

Active member
3rd Party Module Dev
Tutorial Author
Joined
Jan 2, 2020
Messages
912
So far I see nothing that stops me to compile for ARM and that's great news.
 

dawlane

Well-known member
CX Code Contributor
Joined
Jun 21, 2017
Messages
852
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.
 

Jimmy

Active member
3rd Party Module Dev
Tutorial Author
Joined
Jan 2, 2020
Messages
912
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.
 

Jimmy

Active member
3rd Party Module Dev
Tutorial Author
Joined
Jan 2, 2020
Messages
912

Jimmy

Active member
3rd Party Module Dev
Tutorial Author
Joined
Jan 2, 2020
Messages
912

Phil7

Administrator
CX Code Contributor
3rd Party Tool Dev
Joined
Jun 26, 2017
Messages
643
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.
 

Jimmy

Active member
3rd Party Module Dev
Tutorial Author
Joined
Jan 2, 2020
Messages
912
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?
 

Jimmy

Active member
3rd Party Module Dev
Tutorial Author
Joined
Jan 2, 2020
Messages
912
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)
 

Phil7

Administrator
CX Code Contributor
3rd Party Tool Dev
Joined
Jun 26, 2017
Messages
643
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.
 

Jimmy

Active member
3rd Party Module Dev
Tutorial Author
Joined
Jan 2, 2020
Messages
912
Okay, that's a shame I just started to really like the simpler parts of GLSL and Mojo2.. It works very well.
 

Phil7

Administrator
CX Code Contributor
3rd Party Tool Dev
Joined
Jun 26, 2017
Messages
643
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.
 

Jimmy

Active member
3rd Party Module Dev
Tutorial Author
Joined
Jan 2, 2020
Messages
912
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
 
Top Bottom