[tombert]

My opinions of Vulkan have not changed significantly since this was posted a year ago https://news.ycombinator.com/item?id=40601605

I'm sure Vulkan is fun and wonderful for people who really want low level control of the graphic stack, but I found it completely miserable to use. I still haven't really found a graphics API that works at the level I want that I enjoyed using; I would like to get more into graphics programming since I do think it would be fun to build a game engine, but I will admit that even getting started with the low level Vulkan stuff is still scary to me.

I think what I want is something like how SDL does 2D graphics, but for 3D. My understanding is that for 3D in SDL you just drop into OpenGL or something, which isn't quite what I want.

Maybe WebGPU would be something I could have fun working on.

[thegrim33]

SDL 3.0 introduced their GPU API a year or so ago, which is an abstraction layer on top of vulkan/others, might want to check it out.

Although after writing an entire engine with it, I ended up wanting more control, more perf, and to not be limited by the lowest common denominator limits of the various backends, and just ended up switching back to a Vulkan-based engine.

However, I took a lot of learnings from the SDL GPU code, such as their approach to synchronization, which was a pattern that solved a lot of problems for me in my Vulkan engine, and made things a lot easier/nicer to work with.

[ryandrake]

I'm working with SDL GPU now, and while it's nice, it hasn't quite cracked the cross platform nut yet. You still need to maintain and load platform-specific shaders for each incompatible ecosystem, or you need a set of "source of truth" HLSL shaders that your build system processes into platform-specific shaders, through a set of disparate tools that you have to download from all over the place, that really should be one tool. I have high hopes for SDL_shadercross to one day become that tool.

[shortrounddev2]

I thought shaders just needed to be compiled to spir-v

[ryandrake]

My comment was specifically about cross-platform. Apple operating systems don't know what spir-v is.

[shortrounddev2]

Oh well sure if you're targeting apple as a platform you're gonna have to deal with their special snowflake graphics API

[tombert]

I wish Apple had made a point to support Vulkan. I know about MoltenVK and all that fun stuff, but for a time, there was a graphics API that worked on all of the major platforms: OpenGL.

Vulkan was meant to succeed OpenGL, and despite my annoyances with the API, I still think that it's nice to have an open standard for these things, but now there isn't any graphics API that works on everything.

[HexDecOctBin]

SDL GPU is extremely disappointing in that it follows the Vulkan 1.0 model of static pipelines and rigid workflows. Using Vulkan 1.3 with a few extensions is actually far more ergonomic beyond a basic "Hello, World" than using SDL GPU.

[fulafel]

That might exclude a lot of your user base. For example a big chunk of Android users, or Linux workstation users in enterprise settings who are on older LTS distributions.

[HexDecOctBin]

SDL GPU doesn't properly support Android anyways due to driver issues, and I doubt anyone's playing games on enterprise workstations.

[on_the_train]

But sdl is super high level. If you want to do more than pong, you'll hit a wall very quickly.

I just want OpenGL, it was the perfect level of abstraction. I still use it today, both at work and for personal projects.

[59nadir]

For what it's worth my experience with Metal was that it was the closest any of the more modern APIs got to OpenGL. It's just stuck on an irrelevant OS. If they made sure you could use it on Windows & Linux I think it'd fill a pretty cool niche.

[dontlaugh]

WebGPU is in many ways closer to Metal than to Vulkan. You can use the API outside of the browser too, especially in Rust.

[flohofwoe]

> WebGPU is in many ways closer to Metal than to Vulkan.

If only that were true for the resource binding model ;) WebGPU BindGroups are a 1:1 mapping to the Vulkan 1.0 binding model, and it's also WebGPU's biggest design wart. Even Vulkan is moving away from that overly rigid model, so we'll probably be stuck with a WebGPU that's more restrictive than required by any of its backend APIs :/

[59nadir]

I'll check out WebGPU at some point, I guess. I've written our rendering layer in all of the major APIs (OpenGL, DX12, Vulkan and Metal) and found it very instructive to have all of them to compare at the same time because it really underscored the differences; especially maintaining all of them at the same time. We eventually decided to focus only on DX12, but I think I'll revive this "everything all at once" thing for some side projects.

[reactordev]

As someone who has done this since DX7, what you’re looking for is WebGPU either Dawn (Google) or wgpu-native (Firefox). WebGPU works. It’s 99% there across platforms for use.

There’s another wrapper abstraction we all love and use called BGFX that is nice to work with. Slightly higher level than Vulkan or Metal but lower than OpenGL. Works on everything, consoles, fridges, phones, cars, desktops, digital signage.

My own engines have jumped back and forth between WebGPU and BGFX for the last few years.

[beeflet]

I like OpenGL ES but the support for compute shaders sucks. I hate transform feedbacks. I am in the process of trying out WebGPU now, but it doesn't have good native support everywhere like OpenGL ES 3 does.

[bitwize]

OpenGL is designed-by-committee state-machine crap.

You don't know it yet, but what you really want is DirectX 9/10/11.

[on_the_train]

Maybe, but Microsoft tech feels icky

[thegrim33]

SDL GPU, not SDL. The GPU project is a generic wrapper/abstraction on top of the modern GPU APIs, such as Vulkan. You do all the same stuff as you would in a modern GPU API, except in a generic / slightly more accessible way.

[trzy]

In practice SDL is used to abstract away the system-dependent parts required to set up OpenGL.

[simonask]

`wgpu` in Rust is an excellent middle ground, matching the abstraction level of WebGPU. More capable than OpenGL, but you don’t have to deal with things like resource barriers and layout transitions.

The reason you don’t is that it does an amount of bookkeeping for you at runtime, only supports using a single, general queue per device, and several other limitations that only matter when you want to max out the capabilities of the hardware.

Vulkan is miserable, but several things are improved by using a few extensions supported by almost all relevant vendors. The misery mostly pays off, but there are a couple of cases where the API asks you for a lot of detail which all major drivers then happily go ahead ignore completely.

[raincole]

How easy is it to integrate wgpu if the rest of your game is developed with a language that isn't rust? (e.g. C# or C++)

[merksoftworks]

Very! there are unified headers and a C library that the maintainers have written as a wrapper around the library.

https://github.com/gfx-rs/wgpu-native

https://github.com/eliemichel/WebGPU-Cpp

[ChadNauseam]

wgpu is the name of the Rust library, but it pretty closely follows the WebGPU spec, which you can easily use from C or C++ via Google's `dawn` library. It provides C bindings as well as a templatized C++ API.

[pdpi]

Webgpu.h is, AIUI, part of the webgpu spec. Both Dawn (Google’s C++ implementation used in Chrome) and wgpu (Mozilla’s implementation used in Firefox) can be used as concrete implementation of those headers.

[tombert]

I'll definitely give wgpu a look. I don't need to make something that competes with Unreal 5 or anything, but I do think it would be neat to have my own engine.

[foltik]

Could you say more about which extensions you’re referring to? I’ve often heard this take, but found details vague and practical comparisons hard to find.

[simonask]

Dynamic rendering, timeline semaphores, upcoming guaranteed optimality of general image layouts, just to name a few.

The last one has profound effects for concurrency, because it means you don’t have to serialize texture reads between SAMPLED and STORAGE.

[attheicearcade]

Not the same commenter, but I’d guess: enabling some features for bindless textures and also vk 1.3 dynamic rendering to skip renderpass and framebuffer juggling

[ryandrake]

As someone who did OpenGL programming for a very, very long time, I fully agree with you. Without OpenGL being maintained, we are missing a critical “middle” drawing API. We have the very high level game engines, and very low level things like Vulkan and Metal which are basically thin abstractions on top of GPU hardware. But we are missing that fun “draw a triangle” middle API that lets you pick up and learn 3D Graphics (as opposed to the very different “learn GPU programming” goal).

If I was a beginner looking to get a basic understanding of graphics and wanted to play around, I shouldn’t have to know or care what a “shader” is or what a vertex buffer and index buffer are and why you’d use them. These low level concepts are just unnecessary “learning cliffs” that are only useful to existing experts in the field.

Maybe unpopular opinion: only a relative handful of developers working on actually making game engines need the detailed control Vulkan gives you. They are willing to put up with the minutiae and boilerplate needed to work at that low level because they need it. Everyone else would be better off with OpenGL.

[delta_p_delta_x]

> Without OpenGL being maintained, we are missing a critical “middle” drawing API.

OpenGL still works. You can set up an old-school glBegin()-glEnd() pipeline in as few as 10 lines of code, set up a camera and vertex transform, link in GLUT for some windowing, and you have the basic triangle/strip of triangles.

OpenGL is a fantastic way to introduce people to basic graphics programming. The really annoying part is textures, which can be gently abstracted over. However, at some point the abstractions will start to be either insufficient in terms of descriptive power, or inefficient, or leaky, and that's when advanced courses can go into Vulkan, CPU and then GPU-accelerated ray tracing, and more.

[59nadir]

OpenGL still exists, runs and works fine on the two platforms that matter. I think its death has been overstated quite a bit.

With that said we decided to focus on DX12 eventually because it just made sense. I've written our platform layers targetting OpenGL, DX12, Vulkan and Metal and once you've just internalized all of these I really don't think the horribleness of the lower level APIs is as bad as people make them out to be. They're very debuggable, very clear and well supported.

[phendrenad2]

OpenGL is still being maintained, it just isn't being updated. Since OpenGL 4.0 or something we've had vertex and pixel shaders. As a non-AAA developer, I can't imagine anything else I'd really need.

BTW: If anyone says OpenGL is "deprecated", laugh in their face.

[elabajaba]

Apple officially deprecated GL/GLES on both MacOS and iOS 7 years ago, and only ever supported up to GL 4.1 (which came out in 2010), meaning it doesn't support essential "modern" features like compute shaders (DX11 had them in 2009), or bindless textures (supported since 2012 on AMD+Nvidia, and 2015 for Intel iGPUs, massive performance win, needed for GPU driven rendering and ray tracing).

[phendrenad2]

Right, and the damage Apple has done to themselves with this policy is several orders of magnitude higher than OpenGL users have suffered from not being able to use OpenGL on Mac or iOS. Apple gets: No indie games that aren't sluggish Unity or Unreal asset flips. OpenGL devs get: Now you need to pay a specialist a few $x,xxx to port your game to iOS if you ever get popular enough that you want your game on the Apple ecosystem.

[kimixa]

Apple did that to push people towards their own walled garden of APIs rather than some deficiency of the OpenGL API.

There is no "technical" solution to this, no Even better API that would make them support it, as it's a business decision as much as anything else.

[ryandrake]

OK, maybe OpenGL is not "unmaintained" but the major OS and hardware vendors have certainly handed him his hat.

[engeljohnb]

If I were starting a new project, would it be unwise to just use OpenGL? It's what I'm used to, but people seem to talk about it as if it's deprecated or something.

I know it is on Apple, but let's just assume I don't care about Apple specifically.

[59nadir]

OpenGL is fine, it has the same issues now it had before but none of it really comes from "old age" or being deprecated in any way. It's not as debuggable and much harder to get good performance out of than the lower level APIs but beyond that it's still great.

Honestly, starting out with OpenGL and moving to DX12 (which gets translated to Vulkan on Linux very reliably) is not a bad plan overall; DX12 is IMO a nicer and better API than Vulkan while still retaining the qualities that makes it an appropriate one once you actually want control.

Edit:

I would like to say that I really think one ought to use DSA (Direct State Access) and generally as modern of a OpenGL usage as one can, though. It's easy to get bamboozled into using older APIs because a lot of tutorials will do so, but you need to translate those things into modern modern OpenGL instead; trust me, it's worth it.

Actual modern OpenGL is not as overtly about global state as the older API so at the very least you're removing large clusters of bugs by using DSA.

[lostmsu]

What do you think makes DX12 better API than Vulkan?

[59nadir]

I've found it has less idiosyncrasies, is slightly less tedious in general and provides a lot of the same control, so I don't really see much of an upside to using Vulkan. I don't love the stupid OO-ness of DX12 but I haven't found it to have much of an adverse effect on performance so I've just accepted it.

On top of that you can just use a much better shading language (HLSL) with DX12 by default without jumping through hoops. I did set up HLSL usage in Vulkan as well but I'm not in love with the idea of having to add decorators everywhere and using a 2nd class citizen (sort of) language to do things. The mapping from HLSL to Vulkan was also good enough but still just a mapping; it didn't always feel super straight forward.

(Edit: To spell it out properly, I initially used GLSL because I'm used to it from OpenGL and had previously written some Vulkan shaders, but the reason I didn't end up using GLSL is because it's just very, very bad in comparison to HLSL. I would maybe use some other language if everything else didn't seem so overwrought.)

I don't hate Vulkan, mind you, I just wouldn't recommend it over DX12 and I certainly just prefer using DX12. In the interest of having less translation going on for future applications/games I might switch to Vulkan, though, but still just write for Win32.

[rabf]

OpenGL is still be the best for compatibility in my opinion. I have been able to get my software using OpenGL to run on Linux, Windows, old/new phones, Intel integrated graphics and Nvidia. Unless you have very specific requirements it does everything you need and with a little care, plenty fast.

[DeathArrow]

>Maybe unpopular opinion: only a relative handful of developers working on actually making game engines need the detailed control Vulkan gives you.

If you make a game instead of a game engine, you can use one of the existing engines.

[keyringlight]

For a while I've been wondering if the push to DX12 or vulkan as the "better" APIs has been a factor in the big engines becoming a near monoculture with games development. Games are very varied in what they require, some push the limits but many releases are more modest yet lots of them are gravitating around full featured leading edge Unreal/Unity. Having a lower barrier to entry for graphics programming that lets them make something that's a closer fit to their requirements.

The other big push would be Epic cutting royalties until you're earning a significant amount, which would encourage studios not to hire or allocating as much resources to in-house.

[whstl]

I don't really think it is related. Graphics aren't really the most difficult part of a modern engine, and there are high quality open-source 3rd party solutions for rendering anyway.

In fact the "engine" part itself is quite small compared to the editor, and the hardest things can be done with third-party solutions, a lot open source: physics, rendering, audio, ECS, controls, asset loading, shader conversion.

The reason people gravitate towards Unity/Unreal is because of the low barrier to entry. This caused the monoculture among hobbyists.

The reason studios are gravitating to those engines is because of there is plenty of cheap labour available.

[user____name]

If you don't need 4K PBR rendering, a software renderer is a lot of fun to write.

[tombert]

Interesting. I wouldn't actually mind learning how to do that; any tips on how/where to get started?

[RamtinJ95]

Pikuma.com writes a software renderer pretty much from scratch with all the necessary math and explanations in a very pedagogical way. Highly recommend it

[dragonelite]

I can highly recommend this course, i finished it. It's one of those code katas to learn a new language with a bit like Raytracing in one weekend.

[junon]

Getting a triangle on the screen is the hello world of 3D applications. Many such guides for your backend of choice. From there it becomes learning how the shaders work, internalizing projection matrices (if you're doing 3D) which takes a bit of thinking, then slowly as you build up enough abstractions turns back into a more "normal" data structures problem surrounding whatever it is you're actually building. But it's broad, be prepared for that.

Definitely recommend starting with a more "batteries included" framework, then trying your hand at opengl, then Vulkan will at least make a bit more sense. SDL is a decent place to start.

A lot of the friction is due to the tooling and debugging, so learning how to do that earlier rather than later will be quite beneficial.

[rabf]

Tsoding has been live streaming the development of a software renderer as of late: https://www.youtube.com/watch?v=maSIQg8IFRI

[jesse__]

https://raytracing.github.io/books/RayTracingInOneWeekend.ht...

[dmpk2k]

Pikuma.com has a good one.

[user____name]

If you want to render 2d vs 3d there are different tradeofs, a 3d renderer has to do interpolation of attributes over triangles, a 2d renderer doesn't and as a result can render ngons without having to triangulate them.

I'm just going to dump some links really quick, which should get anyone started.

Getting a framebuffer on screen: https://github.com/zserge/fenster

I would recommend something like SDL if you want a more complete platform abstraction, it even supports software rendering as a context mode.

Filling solid rectangles is the obvious first step.

Loading images and copying pixels onto parts of the screen is another. I recommend just not drawing things that intersect the screen boundaries to get started. Clipping complicates things a bunch but is essential.

Next up: ghetto text blitting https://github.com/dhepper/font8x8 I dislike how basically every rendering tutorial just skips over drawing text on screen, which is super useful for debugging.

For drawing single pixel lines, this page has everything on Bresenham:

http://members.chello.at/easyfilter/bresenham.html

For 2d rasterization, here's an example of 3 common approaches: https://www.mathematik.uni-marburg.de/~thormae/lectures/grap...

Scanline rasterization tought me a lot about traversing polygons, I recommend trying it even if you end up preferi g a different method. Sean Barrett has a good overview: https://nothings.org/gamedev/rasterize/

Side note: analytical antialising is fast, but you should be carefull with treating alpha as coverage, the analytic approaches tell you how much of a pixel is covered, not which parts are.

For 3d rasterization Scratchapixel is good: https://www.scratchapixel.com/lessons/3d-basic-rendering/ras...

Someone mentioned the Pikuma course which is also great, though it skips over some of the finer details such as fixed point rasterizing.

For good measure here's some classic demoscene effects for fun: https://seancode.com/demofx/

Anyway, this is just scratching the surface, being progressively able to draw more and more types of primitives is a lot of fun.

[gustavopezzi]

Hi there. Gustavo Pezzi here! Thanks for the mention. I always add new stuff to the lectures and I'm happy to inform that about a year ago I have added a bonus lecture on fixed-point rasterization at the end of that course. Nothing too crazy, but enough to cover the main points. Also, the PlayStation programming course is pretty much 100% fixed-point if anyone feels like diving into that too.

[Pulcinella]

Awesome! Do you have any resources on, uhhh, "hardware accelerating" a software renderer. i.e. using SIMD (or math hardware like the vector hardware you can access with the Accelerate[0] framework on Apple devices).

[0] https://developer.apple.com/documentation/accelerate

[user____name]

There's the work on Larrabee by Mike Abrash and co: https://www.gamedeveloper.com/programming/sponsored-feature-...

[throwaway2046]

This is a gold mine, thank you.

[maybewhenthesun]

The problem with 'something like SDL, but 3D' very quickly turns into a full blown engine. There's just such a combinatorial explosion of different ways to do things in 3D compared to 2D that 3D 'game engine' is either limiting or complicated.

OpenGL was designed as a way to more or less do that and it turned complicated fast.

[gyomu]

To this day, the best 3D API I’ve used (and I’ve tried quite a few over the years) is Apple’s SceneKit. Just the right levels of abstraction needed to get things on the screen in a productive, performant manner for most common use cases, from data visualization to games, with no cruft.

Sadly 1) Apple only, 2) soft deprecated.

[Pulcinella]

SceneKit is actually just straight up deprecated now: https://developer.apple.com/documentation/scenekit/

I imagine it will still be around for a long time because Apple and a lot of large third party apps use it for simple 3D experiences. (E.g. the badges in the Apple Fitness app).

Apple wants devs to move to RealityKit, which does support non-AR 3D, but it is still pretty far from feature parity with SceneKit. Also RealityKit still has too many APIs that are either visionOS only or are available on every platform but visionOS.

Microrant: I absolutely loathe when I am told "move to new thing. Old thing is deprecated/unsupported" and the new thing is incredibly far from feature parity and usually never reaches parity, let alone exceeds it. This is not just an Apple problem.

[AndriyKunitsyn]

Not my experience, unfortunately. I worked on a SceneKit project, it was bad.

In general, it suffered from the problem of even Apple not knowing what it was made for, and what it even is. For a 3D API, it has less features than OpenGL 2. For a game engine, it… also has way less features than the competition, which shouldn’t surprise anyone - game engines are hard, and the market leaders have been developed for _decades_. But that’s what it looks like the most - a game engine. (It even has physics.)

Customizing the rendering pipeline in SceneKit is absolutely horrible. The user is given a choice between two equally bad options: either adding SCNTechniques which are configurable through .plists and provide no feedback on what goes wrong with their configuration (as like 3D rendering isn’t hard enough already), or using “shader modifiers” - placing chunks of Metal code into one of 4 places of the SceneKit’s default shader which the end users _don’t even have the source code of_ without hacking into the debug build! Or pulling it from Github from people who already did that [_].

If you just need something that can display 3d data, SceneKit is still fine, but once there’s a requirement to make that look good, it’s better to throw everything away and hook up Unity instead.

[_] https://gist.github.com/warrenm/794e459e429daa8c75b5f17c0006...

[fingerlocks]

Trying to write a ground up game engine in Metal is a very serious exercise in self-discipline. Literally everything you need is right at your finger tips with RealityKit / old SceneKit. It’s so tempting to cheat or take a few short cuts. There’s even a fully featured physics engine in there.

[rudedogg]

RealityKit is pretty cool and the replacement it seems. Still Apple only though, and I find the feedback loop slow/frustrating due to Swift

I find SDL3 more fun and interesting, but it’s a ton of work to to get going.

[bashmelek]

I followed tutorials for Vulkan. I liked vk-guide, until it updated to the latest version. People said the newer SDL is so much better, but I honestly had more fun and got things done back with Renderpasses.

I personally have just been building off of tutorials. But notwithstanding all of the boilerplate code, the enjoyability of a code base can be vastly different.

The most fun I’ve ever had coding, and still do at times, is with WebGL. I just based it off of the Mozilla tutorial and went from there. WebGLFundamentals has good articles…but to be honest I do not love their code

[diath]

If you want something like SDL but for 3D, check out Raylib.

[DeathArrow]

There was XNA but it was abandoned a long time ago.

[tombert]

I think there are maintained community forks/reimplementations. FNA is probably something I would enjoy; that’s basically the level I want to program at.

I wonder if I can get it working with F# in Linux…

[cuckmaxxed]

Unironically I think I can help.

Frank Luna’s D3D11 bible is probably the closest thing we’ll get to a repetition spaced learning curriculum for 3D graphics at a level where you can do an assload with the knowledge.

No, it won’t teach you to derive things. Take Calculus I and II.

No, it won’t teach you about how light works. Take an advanced electrical engineering course on electromagnetism.

But it will teach you the nuts and bolts in an approachable way using what is by far an excellent graphics API, Direct3D 11. Even John Carmack approves.

From there on all the Vulkan, D3D12 shit is just memory fences buffers and queue management. Absolute trash that you shouldn’t use unless you have to.