gdxhyrd

Considering UE4 and Unity both support OpenGL, yes, a lot if not the majority of games.

WebGL and OpenGL ES are pretty much OpenGL. Formally they are different standards, but they are based all in OpenGL: if you know one, you know the others pretty well, which is what is important for developers as you agree in the second paragraph.

Thanks!

AMD has always lacked tools and has never produced much on the software side.

That is not news, and that has nothing to do with the state of OpenGL.

Please, stop spreading misinformation about OpenGL.

OpenGL does not stop being cross-platform just because it does not work natively in 1 platform.

In any case, abstraction layers for macOS already exist.

And, going by your definition, if Apple only allows Metal, then no API will be cross-platform ever anyway.

That profiler is meant for low-level debugging as its own description says. That is why it does not support DX11 either.

You are conflating language/build issues with VCS issues.

Everything you discuss also applies to multirepo, but worse, because there no one enforces consistency across all the project and you will end up with a broken interdependency.

A lot of games and apps are being released using OpenGL today.

Then there is WebGL and OpenGL ES, widely used everywhere too.

So, no, it is not going anywhere. In fact, Khronos themselves have said so.

Apple is not Khronos.

They haven't supported OpenGL for years anyway, so the fact they deprecate it now is irrelevant.

In almost no situations you want to have software, pixel-based access.

Are we really going back 30 years?

Where is this all being discussed and developed?

POSIX, SDL and the usual suspects are pretty much cross-platform and run everywhere.

Eh, no. Vendors everywhere will package things for your architecture and give you binaries.

That is how it has always been done and is still done.

Yes, you can do it differently with an IL, but that isn't new either (Java, .NET, etc.).

No, OpenGL is not "on the way out". Please back up your claims.

You are right, I was thinking of CVS.

In any case, with SVN you usually do not want to give write perms to everyone in all the tree, so you end up with effectively partitioned spaces, or you make several repos instead, or you put another layer on top. With Git, anyone can easily develop global commits.

> Plus, one have to draw a line somewhere on what to include (a Python interpreter? A Go version? awk and grep?), and third party vs in-house is a fairly robust one imo.

If your code/project/company uses the dependency in any way in production and it is not a part of the base system (which should be reproducibly installed), you include it; either in source or binary form.

Why is the size a problem? Developers should only be checking out once. If your repo hits the many-GiB mark, then you can apply more complex solutions (LFS, sparse, etc.) if it is a burden.