Hacker News Reader

Hacker News

Comment by bullen | Hacker News Reader

Full thread

bullen

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.

View on HN

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.)

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

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.

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.

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.

That middleware is a different beast though, they are different engines providing different solutions for different problems - you can't have any single one of them be the solution to all problem and most of them are very complicated to be defined as a standard that is supposed to live for decades.

OpenGL, Vulkan and Direct3D are at a level where they enable you to write your own engine, but not at the level where they provide your the engine themselves. Microsoft tried it with Direct3D RM and it didn't work and Sun also tried it with Java3D as the official way to do 3D in Java but also didn't catch on (it caught on more than D3DRM but that is mainly because there was no other official way - however its popularity paled in comparison to OpenGL bindings that appeared soon after and nowadays it has been reimplemented and lives on top of these bindings).

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).

There is another translation layer called 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), 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 if you're interested in contributing or following.

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/gl...

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.

Reply on news.ycombinator.com