Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How I learned Vulkan and wrote a small game engine with it (2024)

edw.is

Post reply on HN
Print view View original

71–80 of 107 posts

Re: How I learned Vulkan and wrote a small game engine with it (2024)

#71

Post by Pulcinella »

gyomu wrote: post #11
tombert wrote: post #4

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 prog…

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.

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.

Re: How I learned Vulkan and wrote a small game engine with it (2024)

#72

Post by Pulcinella »

user____name wrote: post #60
tombert wrote: post #9

Earlier quoted context omitted.

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

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 m…

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

Re: How I learned Vulkan and wrote a small game engine with it (2024)

#73

Post by flohofwoe »

dontlaugh wrote: post #46
59nadir wrote: post #42

Earlier quoted context omitted.

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.

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

> 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 :/

Re: How I learned Vulkan and wrote a small game engine with it (2024)

#74

Post by shortrounddev2 »

ryandrake wrote: post #70
shortrounddev2 wrote: post #58

Earlier quoted context omitted.

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

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

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

Re: How I learned Vulkan and wrote a small game engine with it (2024)

#75

Post by keyringlight »

DeathArrow wrote: post #48
ryandrake wrote: post #13

Earlier quoted context omitted.

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 Graph…

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

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.

Re: How I learned Vulkan and wrote a small game engine with it (2024)

#76

Post by flohofwoe »

ryandrake wrote: post #16
anvuong wrote: post #12

Vulkan was one of the hardest thing I've ever tried to learn. It's so unintuitive and tedious that seemingly drains the joy out of programming. Tiny brain =(

You don't have a tiny brain. Vulkan is a low-level chip abstraction API, and is about as joyful to use as a low-level USB API. For a more fun experience with very small amounts of source code needed to get started, I'd recommend trying OpenGL (especially pre-2.0 when they introduced shaders and started down the GPU-programming path), but the industry is dead-set on killing OpenGL for some reason.

> I'd recommend trying OpenGL

Tbh, OpenGL sucks just as much as Vulkan, just in different ways. It's time to admit that Khronos is simply terrible at designing 3D APIs ;) (probably because there are too many cooks involved)

Re: How I learned Vulkan and wrote a small game engine with it (2024)

#77

Post by bashmelek »

tombert wrote: post #4

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 prog…

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

Re: How I learned Vulkan and wrote a small game engine with it (2024)

#78

Post by HexDecOctBin »

fulafel wrote: post #68
HexDecOctBin wrote: post #25

Earlier quoted context omitted.

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.

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.

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

Re: How I learned Vulkan and wrote a small game engine with it (2024)

#79

Post by maybewhenthesun »

tombert wrote: post #4

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 prog…

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.

Re: How I learned Vulkan and wrote a small game engine with it (2024)

#80

Post by hutao »

anvuong wrote: post #12

Vulkan was one of the hardest thing I've ever tried to learn. It's so unintuitive and tedious that seemingly drains the joy out of programming. Tiny brain =(

When I first tried to learn Vulkan, I felt the exact same way. As I was following the various Vulkan tutorials online, I felt that I was just copying the code, without understanding any of it and internalizing the concepts. So, I decided to learn WebGPU (via the Google Dawn implementation), which has a similar "modern" API to Vulkan, but much more simplified.

The commonalities to both are:

- Instances and devices

- Shaders and programs

- Pipelines

- Bind groups (in WebGPU) and descriptor sets (in Vulkan)

- GPU memory (textures, texture views, and buffers)

- Command buffers

Once I was comfortable with WebGPU, I eventually felt restrained by its limited feature set. The restrictions of WebGPU gave me the motivation to go back to Vulkan. Now, I'm learning Vulkan again, and this time, the high-level concepts are familiar to me from WebGPU.

Some limitations of WebGPU are its lack of push constants, and the "pipeline explosion" problem (which Vulkan tries to solve with the pipeline library, dynamic state, and shader object extensions). Meanwhile, Vulkan requires you to manage synchronization explicitly with fences and semaphores, which required an additional learning curve for me, coming from WebGPU. Vulkan also does not provide an allocator (most people use the VMA library).

SDL_GPU is another API at a similar abstraction level to WebGPU, and could also be another easier choice for learning than Vulkan, to get started. Therefore, if you're still interested in learning graphics programming, WebGPU or SDL_GPU could be good to check out.

Post reply on HN