• 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

Graphics

Wingnut

Well-known member
3rd Party Module Dev
Tutorial Author
Joined
Jan 2, 2020
Messages
1,414
What actually happens when you program in OpenGL ES 2.0 on Cerberus X?
I know that it's pure GLES 2.0 on Android and iOS and that it becomes WebGL for Web target but what does it use on Desktop targets?

My intuition says it must be Open GL 3.x or 4.x but how to the system know what exist on a system? Does it use whatever exists or some kind of layer that converts GLES into regular OpenGL?

I know that with Windows you always have the option of ANGLE that converts GLES to Direct X or Vulkan, but what if you don't use that option or if you use Linux / macOS?
 
Last edited:
Maybe I don't get your point, but I'll try anyways: afaik OpenGL ES 2.0 is a subset of OpenGL 3.0. Plus: OpenGL should be backwards compatible - if you write a game using OpenGL ES 2.0 it will run on any system with an Open GL version of 3 or higher. There should be no need to convert anything.
 
Sorry I should have explained in my thoughts about this was that in my mind Open GL ES is only for non-desktop platforms.

So, when I program in that and I put the target to desktop, and still see that it actually somehow works, and I get confused how it does it because it's not a slow software simulation.
 
I did not know that Open GL ES 2.x was compatible with Open GLE 3.x.

I think ANGLE's project description made me confused.
I thought it was more like If you don't use ANGLE you would get OpenGL ES in Windows and if you do use it you get Open GL ES simulation that gets converted into OpenGL by ANGLE.

I dunno, it's a mess..
 
Our Angle target is OOOLLLDDD. Imho there is no real reason to use it, unless you want to create a version that runs on DirectX. I THINK that our Angle Target does directx calls. It is definitely slower. The fastest performance you get with the normal Desktop target with MSVC.
 
ANGLE is the only way to get smooth graphics on Windows. I promise you that. GLFW never been smooth on any device any platform anywhere.
 
The only exception is macOS and the reason of that is because there's a magical fairy that makes it work.
Apple probably have a ANGLE-like mechanism inbuilt to make OpenGL to Metal just as they convert WebGL to metal internally.
 
I remember strongly how the whole range of Microsoft Surface products needed ANGLE to produce smooth graphics. When you used that option instead of plain GLFW as a target, then Cerberus-X became wonderful and extremely powerful.

I'll see if I will take the time to learn OpenGL or skip right to Metal and Vulkan. I'm very confused about the whole Open GL series If I'm to be honest.
 
Regardless of how the in-betwen layers works, everything seems built
to work nicely as long as you follow the guidelines of Open GL ES 2.
This seems to be how most people have solved it.

So I've decided to use OpenGL ES 2 to implement everything. I'll convert all routines later into Vulkan and Metal and that will become a separate thing.

This is my complete list of graphic features I will implement in Cerberus-X
-------------------------------------------------------------------------------------

* Adding more blend modes to Cerberus-X (DONE)

* Collision using shaders and atomic counters (have lots of fresh ideas to talk about here)

* More efficient virtual resolution (for personal mainly use as my device is slow and need an improved solution)

* More efficient reading pixels (for special types of collisions, no writing ever needed)

* A general shader with intput output to make physics calculations (more suitable for Vulkan really but I have a few good ideas)
 
ANGLE is the only way to get smooth graphics on Windows. I promise you that. GLFW never been smooth on any device any platform anywhere.
Lol, you know that Angle uses GLFW on that target?
 
Regardless of how the in-betwen layers works, everything seems built
to work nicely as long as you follow the guidelines of Open GL ES 2.
This seems to be how most people have solved it.

So I've decided to use OpenGL ES 2 to implement everything. I'll convert all routines later into Vulkan and Metal and that will become a separate thing.

This is my complete list of graphic features I will implement in Cerberus-X
-------------------------------------------------------------------------------------

* Adding more blend modes to Cerberus-X (DONE)

* Collision using shaders and atomic counters (have lots of fresh ideas to talk about here)

* More efficient virtual resolution (for personal mainly use as my device is slow and need an improved solution)

* More efficient reading pixels (for special types of collisions, no writing ever needed)

* A general shader with intput output to make physics calculations (more suitable for Vulkan really but I have a few good ideas)

Sounds great on paper. Good luck with your efforts. So we should stop our efforts and wait for your stuff?
 
Last edited:
What being snarky?

you don't want help? I have holes of knowledge yes . But that's no reason to behave like that.



Maybe someone else will appreciate that I try to collaborate. But you now what, It feels more like one on one..

I've seen it so many times that plain GLFW on Windows (both Mojo1 and Mojo2) gets a terrible tearing right in the middle when going fullscren. This implies to me that there's a timer which tries to emulate vertical blanking and it fails at trigging at the correct time. But if you ignore the tearing part and just look at performance you'll see that at least Mojo 2 behaves great, so that's all well.

I never use plain GLWF on Windows after that because it only works on specific machines, and that's not my goal.
For most devices it has always prooved to make both Mojo 1 and Mojo 2 suboptimal.

When you pick "GLFW + Angel" in Windows, Mojo2 becomes the most beutiful thing you ever saw.
While Mojo 1 becomes a strange beast. It becomes much faster, actually it always(!) becomes x4-x5 times faster than Mojo 2, for reasons that I don't know.

But I gather that Mojo 1 is faster simply because how it works using a more list-and-batch-like behaviour by default,
while Mojo2 behaves in a more in an immediate way.

But despite all this power that Mojo 1 has, it still starts to jitter on most systems, when you start building something big.
Even if you keep thigns way below what you know it can handle well. It's not about power.

If you think about all the time that passes between your graphic commands.
Interruptions will come from many sources beside the simple ones like garbage collection.. Many of
these sources happens at much lower levels than Cerberus-X have contorl over. Directly at least.

But Mojo2 handles this in-between time so much better, while Mojo1 is exceptionally bad at it (probably because it does not need it as mucuh, and that's why it looks so good before you start buidling something big).

What I've learned is that yes Mojo 1 is always x5 more powerful but jitter will be impossible to avoid at some point when the code grows. While when using Mojo 2 you'll still have more than enough power to make anything that you wish, while
being capable of keepign jitters out of the way completely, and especially if you're tricky and careful.

Maybe you can be tricky with Mojo 1 too, especially if you use Open GL like that Cube example. I like that example. But is it Mojo 1?


Anyways I started this day being happy and wanted to code, thanks for dragging me down.
 
Sounds great on paper. Good luck with your efforts. So we should stop our efforts and wait for your stuff?
What being snarky?
you don't want help? I have holes of knowledge yes . But that's no reason to behave like that.
Well, it's not my discussion here, but I can relate to some things that have been said and I want to try a different perspective...

@Jimmy First you can read @MikeHart s comment much more literally than it might sound in the first place: "Sounds great on paper. Good luck" Your list of features is pretty ambicious and is targeting low level stuff that I have near to none knowledge about. So you will definitely be on your own with this stuff even if we give our best to share information.
"... we should stop our efforts and wait...?" As you know we are trying to implement an alternative way to render stuff under the hood to support Metal on the apple side, but it might also have an influence on how things work on other targets. So finetuning the current graphics system on a low level makes only sense before we change the renderer or even better afterwards.

I guess we can all see your engagement for CX, the willingness to contribute, your efforts to get deep into that matter and also some holes of knowledge ;)
Nevertheless there are some critics and/or emotional aspects to consider that have not been talked about as far as I know:

Performance Critics
You are presenting pretty generalized critics about the performance of CX. Critics can be quite unpleasant, if you can't do anything about the issues. If you are running into something on your machines this might be a completely different story on someone elses. To make a long story short: Just cope with it like it was a bug. Give a workin code example so we can easily reproduce the issue and see on what kind of hardware it occurs. I know @MikeHart for some time and I am sure he is the first one to give it a test run on his device to see for himself.
But you might have some patience with us in those regards. Our time is limited and there is a lot of work to get done here.

Advance in Knowledge regarding CX
Don't overestimate our knowledge of CX. None of the team members was involved in the creation of the main parts of CX nor in the conceptual structure of it. All the knowledge, which is not as much as you might think, stems mainly from tinkering with the source code, reading through all the different files for hours while scratching our heads due to the lack of comments or some other aspects of the code. Well, it has never been written with the goal in mind of beeing readable for someone else or even be released as open source.

Time, Focus
We, the team, as you might have noticed are always willing to help wherever it is possible. But we have our fulltime job, family and even pets, so our time is pretty limited. To get to grips with the big things we want to accomplish, we have to focus on them and even our beloved forum can be a distraction at times.


And just to make things clear. This is just my opinion on these aspects and I cannot speak for the whole team.

Bye
Phil
 
Back
Top Bottom