91–100 of 118 posts
This is for Fedora on the M1. It would be amazing to get this for macOS. What's involved in pulling something like that off?
One day, Apple will deprecate opengl 3.3 core, and I guess everybody might end up deprecating it. I've read that generally opengl is just easier to use than vulkan, I don't know if that's true, but if something is too complicated, it becomes just too hard for less experienced devs to exploit those GPU, and it becomes a barrier to entry, which might discourage some indie game developers. Although everyone uses unity a…
> I've read that generally opengl is just easier to use than vulkan [here's]( https://learnopengl.com/code_viewer_gh.php?code=src/1.gettin... ) an opengl triangle rendering example code (~200 LOC) [here's]( https://vulkan-tutorial.com/code/17_swap_chain_recreation.cp... ) a vulkan triangle rendering example code (~1000 LOC) ye it's fair to say opengl is a bit easier to use ijbol
Further, the OpenGL example is not following modern graphics best practices and relies on defaults from OpenGL which cuts down the lines of code but is not practical in real applications.
Getting Vulkan initialized is a bit of a chore, but once it's set up, it's not much more difficult than OpenGL. GPU programming is hard no matter which way you put it.
I'm not claiming Vulkan initialization is not verbose, it certainly is, but there are libraries to help you with that (f.ex. vkbootstrap, vma, etc). The init routine requires you to explicitly state which HW and SW features you need, reducing the "it works on my computer" problem that plagues OpenGL.
If you use a recent Vulkan version (1.2+), namely the dynamic rendering and dynamic state features, it's actually very close to OpenGL because you don't need to configure render passes, framebuffers etc. This greatly reduces the amount of code needed to draw stuff. All of this is available on all desktop platforms, even on quite old hardware (~10 year old gpus) if your drivers are up to date. The only major difference is the need for explicit pipeline barriers.
Just to give you a point of reference, drawing a triangle with Vulkan, with the reusable framework excluded, is 122 lines of Rust code including the GLSL shader sources.
Another data point from my past projects, a practical setup for OpenGL is about 1500 lines of code, where Vulkan is perhaps 3000-4000 LOC where ~1000 LOC is trivial setup code for enabled features (verbose, but not hard).
As a graphics programmer, going from OpenGL to Vulkan has been a massive quality of life improvement.
Earlier quoted context omitted.
How so? I'm daily driving it as my only machine since November.sure there are missing features but none that are really essential for most people.
You and I have very different work environments for you to be able to claim that microphones aren't essential for most people.
One day, Apple will deprecate opengl 3.3 core, and I guess everybody might end up deprecating it. I've read that generally opengl is just easier to use than vulkan, I don't know if that's true, but if something is too complicated, it becomes just too hard for less experienced devs to exploit those GPU, and it becomes a barrier to entry, which might discourage some indie game developers. Although everyone uses unity a…
OpenGL mostly only makes sense if you followed its progress from the late 90's and understand the reasons behind all the accumulated design warts, sediment layers and just plain weird design decisions. For newcomers, OpenGL is just one weirdness after another.
Unfortunately Vulkan seems to be on the same track, which makes me think that the underlying problem is organisational, not technical, e.g. both APIs are lead by Khronos, resulting in the same 'API design and maintenance philosophy' - and frankly, the approach to API design was OpenGL's main problem, not that it didn't map to modern GPU architectures (which could have been fixed with a different API design approach without throwing the baby out with the bath water).
But on Mac, what matters more is how OpenGL compares to Metal, and the answer is much simpler: Metal both has a cleaner design, and is easier to use than OpenGL.
One day, Apple will deprecate opengl 3.3 core, and I guess everybody might end up deprecating it. I've read that generally opengl is just easier to use than vulkan, I don't know if that's true, but if something is too complicated, it becomes just too hard for less experienced devs to exploit those GPU, and it becomes a barrier to entry, which might discourage some indie game developers. Although everyone uses unity a…
OpenGL is not deprecated, it is simpler and continues to be used where Vulkan is overkill. Using it for greenfields is a good choice if it covers all your needs (and if you don't mind the stateful render pipeline).
One day, Apple will deprecate opengl 3.3 core, and I guess everybody might end up deprecating it. I've read that generally opengl is just easier to use than vulkan, I don't know if that's true, but if something is too complicated, it becomes just too hard for less experienced devs to exploit those GPU, and it becomes a barrier to entry, which might discourage some indie game developers. Although everyone uses unity a…
OpenGL is already deprecated on macOS and iOS for a couple of years. It still works (nowadays running as layer on top of Metal), but when building GL code for macOS or iOS you're spammed with deprecation warnings (can be turned off with a define though).
Earlier quoted context omitted.
This is a bit misleading. Much of the extra code that you'd have to write in Vulkan to get to first-triangle is just that, a one-time cost. And you can use a third-party library, framework or engine to take care of it. Vulkan merely splits out the hardware-native low level from the library support layer, that were conflated in OpenGL, and lets the latter evolve freely via a third party ecosystem. That's just a sensib…
And often those LOC examples use GLFW or some other library to load OpenGL. Loading a Vulkan instance is a walk in the park compared to initializing an OpenGL context, especially on Windows. It's incredibly misleading. If you allowed utility libraries for Vulkan to compare LOC-to-triangle Vulkan would be much closer to OpenGL.
Kind of crazy to think that the only reason OpenGL was ever a thing for 3D gaming was because of John Carmack's obsession with using it for Quake II back in the 90s.
Earlier quoted context omitted.
I think both SGI and Quake were absolutely crucial. Without Quake, OpenGL would have remained an extremely niche thing for professional CAD and modeling software. And Microsoft would have completely owned the 3D gaming API space. Quake (and Quake 2, and Quake 3, and the many games that licensed those engines) really opened the floodgates in terms of mass market users demanding OpenGL capabilities (or at least a subse…
Microsoft never owned the 3D gaming API space, SEGA, Sony and Nintendo also have/had their own APIs.
Earlier quoted context omitted.
I never heard about SEGA, Sony or Nintendo 3D APIs being used on a PC. I guess somebody somewhere did it, but it's so insignificant.
I never heard about 3D gaming API space being something PC only, maybe in some fancy FOSS circles.
Everybody else is this discussion is talking about the PC 3D API space. The place where OpenGL lives. It's right there in the title of the linked article.