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

I learned Vulkan and wrote a small game engine with it

edw.is

Post reply on HN
Print view View original

111–120 of 268 posts

Re: I learned Vulkan and wrote a small game engine with it

#111

Post by eliasdaler »

proc0 wrote: post #94
spicyusername wrote: post #10

Lots of good advice in this article. One that stuck out to me: Don’t implement something unless you need it right now This is a constant battle I fight with more junior programmers, who maybe have a few years of experience, but who are still getting there. They are often obsessed with "best-practices" and whatever fancy new tool is trending, but they have trouble starting with the problem they need to solve and focus…

This is in context of a one person team. The next advice makes this evident: > Remember that you can always rewrite any part of your game/engine later. This isn't the case in medium to large organizations. Usually you will just move on and rarely have the time to revisit something. This is unfortunate of course, but it means you need to build things properly the first time around and make sure it won't have a chance…

I agree. I should probably clarify that in the article. It’s much easier to write “throwaway” code when you’re working alone and when you’re doing it just for fun. This advice was probably aimed at people who tend to overthink things in these kinds of situations and spend years implementing things in the “right” way, which tends to slow them down considerably instead.

Re: I learned Vulkan and wrote a small game engine with it

#112

Post by eliasdaler »

hjadal wrote: post #61
alexvitkov wrote: post #30

Earlier quoted context omitted.

Vulkan has advantages over OpenGL even if you don't care about visual fidelity. - No global state - You can select which GPU you want to use at runtime - OpenGL error handling is terrible - Validation layers!! - Cool official artwork - Fantastic documentation - You can upload data to the GPU asynchronously from a second thread in a sane way - Fancy GPU features - Mesh shaders, RTX

I will say that validation layers alone are worth it. Damn they are nice, so many bugs in my code has been found by them which saved a lot of time.

Agreed. I don’t even need all these fancy Vulkan features most of the time… Just validation layers and RenderDoc debugging make the whole experience of doing graphics programming so much more pleasant for me, compared to what I had to deal with in OpenGL.

Re: I learned Vulkan and wrote a small game engine with it

#113

Post by dc443 »

sigmoid10 wrote: post #54
OnionBlender wrote: post #50

Earlier quoted context omitted.

I've heard the same thing about DirectX 12 vs DirectX 11. One book basically said that you will probably have worse performance in DirectX 12 vs DirectX 11 if you don't know what you're doing.

DirectX 12 only gets interesting when you want hardware raytracing support to make use of the new Nvidia cards on windows. Tbf that is pretty cool, which is why I actually dabbled with it a little. But it's not necessary for the vast, vast majority of graphics applications.

I wonder how much less ergonomic is is for getting there via Vulkan. For the ray tracing shaders.

Re: I learned Vulkan and wrote a small game engine with it

#114

Post by edflsafoiewq »

tombert wrote: post #110
edflsafoiewq wrote: post #107

Earlier quoted context omitted.

Vulkan is for writing OpenGL-type libraries against. It's advantage is largely that much of the library-level code is moved out of opaque and buggy device drivers and into user-space libraries.

No, I don't think that that's good reasoning. They could, if nothing else, make first-party libraries that have a high-level DSL or something that makes it less horrible to use. As it stands it creates a bunch of crappy libraries on top instead of an officially supported API that could also be standardized across operating systems and platforms. The terrible terrible Vulkan API just kind of feels gatekeepey. They got…

It doesn't really make sense to have Khronos maintain nice high-level libraries. There's no evidence they'd be good at it and if you look at their GitHub, they're not particularly good at maintaining actual codebases in the first place. Their commitee/standard-based process works for specs, but I don't think it will work very well for the needs of day-to-day application programmers.

Why do you need Khronos to "bless" a particular library anyway?

Also they didn't get rid of OpenGL. You can still use it. It will probably be the most widely supported graphics API for a long time.

Re: I learned Vulkan and wrote a small game engine with it

#115

Post by eliasdaler »

Keyframe wrote: post #68
jokoon wrote: post #14

I think vulkan is great, but its only purpose is to take full advantage of advanced GPU features. It also leads to better performance when using advanced GPU features compared to OpenGL. Generally, I feel OpenGL is the recommended route if you don't really aim for advanced rendering techniques. There are plenty 2D /lowpoly/ps1-graphics games right now, and those don't need to use vulkan. Vulkan is an example of how t…

I think Vulkan was a mistake. Maybe I should say OpenGL Next should've been a (priority) thing and Vulkan could still happen on the side.. and not this, push towards everything Vulkan. It's not for everybody and not everybody needs it (nor deserves it).

I can somewhat agree… I don’t dislike/fear Vulkan now, but I feel like there should have been something in-between OpenGL and Vulkan, because in most cases you don’t need the same level control over the GPU which AAA game require. Thankfully, libraries like VMA and vk-bootstrap + new extensions like dynamic rendering make Vulkan start to resemble what “OpenGL Next” could have been. It’s still not perfect, but I’m glad that things have moved into that direction.

Re: I learned Vulkan and wrote a small game engine with it

#116

Post by dc443 »

Animats wrote: post #93

This minimalism is very effective. I took the opposite approach, and it has cause great pain. I've been writing a metaverse client in Rust. Right now, it's running on another screen, showing an avatar riding a tram through a large steampunk city. I let that run for 12 hours before shipping a new pre-release. This uses Vulkan, but it has WGPU and Rend3 on top. Rend3 offers a very clean API - you create meshes, 2d text…

> WGPU doesn't support multiple threads updating GPU memory without interference, which Vulkan supports.

This is really helpful for me to learn about, this is a key thing I want to be able to get right for having a good experience. I really hope WGPU can find a way to add something for this as an extension.

Re: I learned Vulkan and wrote a small game engine with it

#117

Post by dc443 »

dc443 wrote: post #116
Animats wrote: post #93

This minimalism is very effective. I took the opposite approach, and it has cause great pain. I've been writing a metaverse client in Rust. Right now, it's running on another screen, showing an avatar riding a tram through a large steampunk city. I let that run for 12 hours before shipping a new pre-release. This uses Vulkan, but it has WGPU and Rend3 on top. Rend3 offers a very clean API - you create meshes, 2d text…

> WGPU doesn't support multiple threads updating GPU memory without interference, which Vulkan supports. This is really helpful for me to learn about, this is a key thing I want to be able to get right for having a good experience. I really hope WGPU can find a way to add something for this as an extension.

Do you know if these things I found offer any hope for being able to continue rendering a scene smoothly while we handle GPU memory management operations on worker threads?

https://gfx-rs.github.io/2023/11/24/arcanization.html

https://github.com/gfx-rs/wgpu/issues/5322

Re: I learned Vulkan and wrote a small game engine with it

#118

Post by eliasdaler »

wg0 wrote: post #84

Off topic kind of - Can an LLM generate such an article? Reading such in depth experiences and consolidating advice makes me think that web is made by humans and every other day,I spot something on the web that is clearly generated from some LLM. Great write up. Inspiring.

Thanks a lot, that’s a very touching comment.

I try to make my website to feel like “the old Internet” that we seem to be losing and it's great that it’s noticeable. :)

Re: I learned Vulkan and wrote a small game engine with it

#119

Post by tombert »

edflsafoiewq wrote: post #114
tombert wrote: post #110

Earlier quoted context omitted.

No, I don't think that that's good reasoning. They could, if nothing else, make first-party libraries that have a high-level DSL or something that makes it less horrible to use. As it stands it creates a bunch of crappy libraries on top instead of an officially supported API that could also be standardized across operating systems and platforms. The terrible terrible Vulkan API just kind of feels gatekeepey. They got…

It doesn't really make sense to have Khronos maintain nice high-level libraries. There's no evidence they'd be good at it and if you look at their GitHub, they're not particularly good at maintaining actual codebases in the first place. Their commitee/standard-based process works for specs, but I don't think it will work very well for the needs of day-to-day application programmers. Why do you need Khronos to "bless"…

> It doesn't really make sense to have Khronos maintain nice high-level libraries.

I guess we'll have to agree to disagree on that.

> There's no evidence they'd be good at it and if you look at their GitHub, they're not particularly good at maintaining actual codebases in the first place.

Well that's another complaint then, but it doesn't detract away from my initial complaints.

> Why do you need Khronos to "bless" a particular library anyway?

Because now we're going to have a million different wrapper libraries to do everything, or you're going to be stuck with the absurd Vulkan API. It was already annoying enough that you had to have different wrappers to abstract the GUI components, now people have to have another mediocre abstraction in addition to the GUI crap.

I suppose you could argue "that's fine", and you're free to have that opinion, but I think it's worse

> Also they didn't get rid of OpenGL. You can still use it. It will probably be the most widely supported graphics API for a long time.

They're not doing new versions of OpenGL. Yes, the drivers will support them for the foreseeable future but they will get increasingly out of date.

Re: I learned Vulkan and wrote a small game engine with it

#120

Post by eliasdaler »

archermarks wrote: post #3

Really nice article! I have some OpenGL familiarity and tried out Vulkan but bounced off of it due to all of the up-front complexity just getting something running. Might give it another shot now!

vkguide is a great way to get a feel of modern Vulkan. Maybe it’ll be still to complex for you - then it’s okay to say on OpenGL or learn some WebGPU.

I started learning Vulkan as an experiment and it seemed to work out well, so that’s why I wrote this article. :)

Post reply on HN