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

81–90 of 107 posts

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

#81

Post by 59nadir »

reactordev wrote: post #61
59nadir wrote: post #56

Earlier quoted context omitted.

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.

I never mentioned the web as a target, rather devices. You don’t need a browser, you need a window or a surface to draw on and use C/C++/Rust/C# to write your code. WebGPU is a standard, not necessarily for the web alone. At no point does a browser ever enter the picture. https://eliemichel.github.io/LearnWebGPU/index.html

You mentioned "Google" and Firefox, one of which is a browser. I clarified that I'm not interested in the web as a target, not to dismiss your entire suggestion but rather to clarify that that particular part doesn't interest me.

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

#82

Post by 59nadir »

lostmsu wrote: post #65
59nadir wrote: post #45

Earlier quoted context omitted.

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…

What do you think makes DX12 better API than Vulkan?

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.

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

#83

Post by tombert »

DeathArrow wrote: post #47
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…

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

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…

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

#84

Post by user____name »

Pulcinella wrote: post #72
user____name wrote: post #60

Earlier quoted context omitted.

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

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

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

#85

Post by whstl »

keyringlight wrote: post #75
DeathArrow wrote: post #48

Earlier quoted context omitted.

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

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.

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

#86

Post by m-schuetz »

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 =(

Exactly the reason why I haven't switched from OpenGL to Vulkan. Vulkan is just ridiculously overengineered. Cuda shows that allocation of GPU memory and copy from host to device can be one-liners, yet in Vulkan it's an incredible amount of boilerplate to go through. Modern Vulkan fixes a lot of issues, like getting rid of pipelines, render passes, bindings, etc., but there is still much more to fix before it's usable.

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

#87

Post by bitwize »

on_the_train wrote: post #37
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…

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.

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

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

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

#88

Post by mpenick »

jezze wrote: post #52

I just want to be a bit picky and say that bike shedding means focusing on trivial matters while ignoring or being oblivious to the complicated parts. What he described sounded more like a combination of feature creep/over-engineering.

You’re risking bike shedding “bike shedding”.

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

#89

Post by dragonelite »

RamtinJ95 wrote: post #40
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?

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

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.

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

#90

Post by trzy »

on_the_train wrote: post #37
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…

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.

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