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

51–60 of 107 posts

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

#51

Post by dontlaugh »

zffr wrote: post #33
ryandrake wrote: post #16

Earlier quoted context omitted.

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.

Does anyone know why the industry is killing OpenGL?

OpenGL cannot achieve the control over modern hardware necessary to get competitive performance. Even in terms of CPU overhead it’s very limiting.

Direct3D (and Mantle) had been offering lower level access for years, Vulkan was absolutely necessary.

It’s like assembly. Most of us don’t have to bother.

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

#53

Post by [deleted] »

59nadir wrote: post #42
on_the_train wrote: post #37

Earlier quoted context omitted.

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.

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.

[deleted]

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

#54

Post by reactordev »

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

Earlier quoted context omitted.

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

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…

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.

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

#55

Post by simonask »

foltik wrote: post #20
simonask wrote: post #7

Earlier quoted context omitted.

`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 capabi…

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.

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.

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

#56

Post by 59nadir »

reactordev wrote: post #54
59nadir wrote: post #49

Earlier quoted context omitted.

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…

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…

Personally I'm not interested in the web as a platform. The APIs themselves I'm interested in, but as a target I think the web needs to die for everything that isn't a document.

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

#57

Post by Nab443 »

raincole wrote: post #30
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 =(

I think anyone who ever looked at typical Vulcan code examples would reach the same conclusion: it's not for application/game developers. I really hope SDL3 or wgpu could be the abstraction layer that settles all these down. I personally bet on SDL3 just because they have support from Valve, a company that has reasons to care about cross platform gaming. But I would look into wgpu too (...if I were better at rust, si…

For wgpu, someone else mentionned in another comment that there are bindings for other languages, maybe your favorite too!

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

#58

Post by shortrounddev2 »

ryandrake wrote: post #14
thegrim33 wrote: post #8

Earlier quoted context omitted.

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…

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…

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

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

#59

Post by delta_p_delta_x »

ryandrake wrote: post #13
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…

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…

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

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

#60

Post by user____name »

tombert wrote: post #9
user____name wrote: post #5

Earlier quoted context omitted.

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

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

Post reply on HN