3 ms·

I'm sticking with OpenGL (ES) 3 that brought VAO for life. The returns will diminish to the point that porting or developing on new APIs does not pay for itsel

by bullen 7y ago

I'm sticking with OpenGL (ES) 3 that brought VAO for life. The returns will diminish to the point that porting or developing on new APIs does not pay for itself. I know both Jonathan Blow and Godot are clear signs that I'm wrong, but I guess we'll just have to wait and see. Until then I have my engine running on Win/x86 and the Pi 4 at good performance with minimal effort. Which is good; simple software will live forever.

pingyong 7y ago
Hmm. I've only really played around with both (OpenGL 4.x and Vulkan), but while Vulkan had an insane amount of boilerplate initially, it was really intuitive to me. The situation of "what do I even have to google here?" never came up, while that happened a lot with OpenGL. If you already have a working code base obviously that doesn't really matter, but if I was writing a new engine today, I'd probably use Vulkan just because the API seems so much more intuitive to me. (Well, Vulkan or D3D11.)
skocznymroczny 7y ago
I'm considering switching away from OpenGL just to get rid of the global state. It's too tiring to track the OpenGL state just to realize you forgot to unset some texture in a completely different part of code. My favourite of the newest APIs is Metal, because it's very easy to jump from OpenGL (triangle in Metal is about 30 lines of code). Perhaps WebGPU is an alternative once desktop translation layer is created (Google is working on one called Dawn).
- grovesNL 7y ago
  There is another translation layer called wgpu (https://github.com/gfx-rs/wgpu https://github.com/gfx-rs/wgpu) being developed as well. It's written in Rust and has bindings for C, Rust (https://github.com/gfx-rs/wgpu-rs https://github.com/gfx-rs/wgpu-rs), and some initial support for other languages (Python, Julia, Scopes, etc.). Dawn and wgpu have also been collaborating to create a common set of WebGPU headers. The WIP headers are located at https://github.com/webgpu-native/webgpu-headers https://github.com/webgpu-native/webgpu-headers if you're interested in contributing or following.
- earenndil 7y ago
  TBH, opengl has been improving in that respect. See, e.g., glTextureSubImage2D[1], which takes a pointer to the referred texture, unlike glTexSubImage2D. 1: https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glTexSubImage2D.xhtml https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/gl...
  - skocznymroczny 7y ago
    Yes, I am aware of the direct state access extensions. It was a good step forward, but a bit too late. And it still applies only to GL objects like buffers, samplers, textures. For things like setting scissor test, blending, depth test/write, color masks, binding textures, you're back to the global state.
badsectoracula 7y ago
Similar here, except i'm sticking with OpenGL 1.x (or 2.x for when i want shaders... or 3.x/4.x for when i want MORE shaders :-P), exactly because of the sheer simplicity of the API. I have written a bit of Vulkan code (i wrote this[0] the day the spec came out, after banging on it for several hours - and i found the spec quite readable, at least from the side of someone who wants to use it... someone i know who worked on the implementation side has told me that it wasn't that great), but i find the API way too ugly and verbose for my taste. I have considered writing a small OpenGL-like wrapper on top of it since i am concerned that OpenGL quality will deteriorate in the future (though that would break a TON of games, including the ultrapopular Minecraft), but for now things work fine. [0] https://i.imgur.com/rd8Xk84.gif https://i.imgur.com/rd8Xk84.gif
- pjmlp 7y ago
  Somehow ARB, and now Khronos keep forgetting that having something like MetalKit or DirectXTK as part of the specification really matters to onboard newbies. OpenInventor could have been it, but SGI had other plans for it, and no one at either ARB or Khronos actually cared about it.
  - badsectoracula 7y ago
    It isn't just newbies, i write OpenGL code for almost 2 decades, i see no reason to do use the harder parts of the API when i can simply use the easy parts :-P. Though i disagree with OpenInventor, it is too complex and takes too much upon itself, which few wanted - see Direct3D Retained Mode which despite being a much simpler API (both compared to D3DIM and OpenInventor) didn't see much use and in an uncharacteristic move by Microsoft (especially at the time) it was removed from Direct3D. A better solution would have been something like GLUT, but with a few more utilities thrown in (like vector math stuff - OpenGL implementations already have the code anyway, why not expose it?). And GLUT was more popular than OpenInventor ever hoped to be despite not offering more than a few basic things.
    - pjmlp 7y ago
      I think that widespread adoption of middleware engines has proven that retained mode was the way to go. The ones that don't use one, end up reimplementing their own scene graph anyway. As for the rest, full with you.

by bullen 7y ago

pingyong 7y ago

Hmm. I've only really played around with both (OpenGL 4.x and Vulkan), but while Vulkan had an insane amount of boilerplate initially, it was really intuitive to me. The situation of "what do I even have to google here?" never came up, while that happened a lot with OpenGL. If you already have a working code base obviously that doesn't really matter, but if I was writing a new engine today, I'd probably use Vulkan just because the API seems so much more intuitive to me. (Well, Vulkan or D3D11.)

skocznymroczny 7y ago

I'm considering switching away from OpenGL just to get rid of the global state. It's too tiring to track the OpenGL state just to realize you forgot to unset some texture in a completely different part of code. My favourite of the newest APIs is Metal, because it's very easy to jump from OpenGL (triangle in Metal is about 30 lines of code). Perhaps WebGPU is an alternative once desktop translation layer is created (Google is working on one called Dawn).

grovesNL 7y ago
There is another translation layer called wgpu (https://github.com/gfx-rs/wgpu https://github.com/gfx-rs/wgpu) being developed as well. It's written in Rust and has bindings for C, Rust (https://github.com/gfx-rs/wgpu-rs https://github.com/gfx-rs/wgpu-rs), and some initial support for other languages (Python, Julia, Scopes, etc.). Dawn and wgpu have also been collaborating to create a common set of WebGPU headers. The WIP headers are located at https://github.com/webgpu-native/webgpu-headers https://github.com/webgpu-native/webgpu-headers if you're interested in contributing or following.
earenndil 7y ago
TBH, opengl has been improving in that respect. See, e.g., glTextureSubImage2D[1], which takes a pointer to the referred texture, unlike glTexSubImage2D. 1: https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glTexSubImage2D.xhtml https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/gl...
- skocznymroczny 7y ago
  Yes, I am aware of the direct state access extensions. It was a good step forward, but a bit too late. And it still applies only to GL objects like buffers, samplers, textures. For things like setting scissor test, blending, depth test/write, color masks, binding textures, you're back to the global state.

badsectoracula 7y ago

Similar here, except i'm sticking with OpenGL 1.x (or 2.x for when i want shaders... or 3.x/4.x for when i want MORE shaders :-P), exactly because of the sheer simplicity of the API. I have written a bit of Vulkan code (i wrote this[0] the day the spec came out, after banging on it for several hours - and i found the spec quite readable, at least from the side of someone who wants to use it... someone i know who worked on the implementation side has told me that it wasn't that great), but i find the API way too ugly and verbose for my taste. I have considered writing a small OpenGL-like wrapper on top of it since i am concerned that OpenGL quality will deteriorate in the future (though that would break a TON of games, including the ultrapopular Minecraft), but for now things work fine. [0] https://i.imgur.com/rd8Xk84.gif https://i.imgur.com/rd8Xk84.gif

pjmlp 7y ago
Somehow ARB, and now Khronos keep forgetting that having something like MetalKit or DirectXTK as part of the specification really matters to onboard newbies. OpenInventor could have been it, but SGI had other plans for it, and no one at either ARB or Khronos actually cared about it.
- badsectoracula 7y ago
  It isn't just newbies, i write OpenGL code for almost 2 decades, i see no reason to do use the harder parts of the API when i can simply use the easy parts :-P. Though i disagree with OpenInventor, it is too complex and takes too much upon itself, which few wanted - see Direct3D Retained Mode which despite being a much simpler API (both compared to D3DIM and OpenInventor) didn't see much use and in an uncharacteristic move by Microsoft (especially at the time) it was removed from Direct3D. A better solution would have been something like GLUT, but with a few more utilities thrown in (like vector math stuff - OpenGL implementations already have the code anyway, why not expose it?). And GLUT was more popular than OpenInventor ever hoped to be despite not offering more than a few basic things.
  - pjmlp 7y ago
    I think that widespread adoption of middleware engines has proven that retained mode was the way to go. The ones that don't use one, end up reimplementing their own scene graph anyway. As for the rest, full with you.