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

251–260 of 268 posts

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

#251

Post by 3836293648 »

ReleaseCandidat wrote: post #247
3836293648 wrote: post #245

Earlier quoted context omitted.

And what do you call when you call that API? wgpu in Firefox and Dawn in Chrome. wgpu is an implementation of webgpu with the raw rust bindings rather than the C-API it also provides called by Firefox. Unless you want to dig into the implementation details of the various subcrates.

> wgpu in Firefox Ah, sorry, I didn't know that, thanks. On Chrome it uses either WebGL2 or WebGPU. When running in a web browser (by compilation to WebAssembly) without the "webgl" feature enabled, wgpu relies on the browser's own WebGPU implementation. https://github.com/gfx-rs/wgpu?tab=readme-ov-file#tracking-t...

The wgpu crate in rust can do two things. The first is that it is an implementation of the webgpu spec built upon OpenGL/Vulkan/DirectX/WebGL/Metal. This is what firefox uses. The other is that it can just generate calls to the webgpu api. This is what it does when targetting wasm.

So if you're writing rust with wgpu and you target wasm and run it in firefox you will have a wasm program that calls the browser's implementation of webgpu which is the same wgpu crate you used just built in the other way.

If you run it in Chrome instead it will use Dawn.

And in native land wgpu and dawn are incompatible and have different C-apis. One uses uint32_t everywhere and the other size_t. So they're the same on 32bit platforms like WASM but not on modern native platforms

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

#252

Post by ngcc_hk »

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…

My reading is slightly different. It is not about a 1p team, but about a 1p team just starting and learning. Once finish learning you still have to go back and refactor for future maintenance. He has to reuse these codes as part of an engine, just like a larger team.

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

#253

Post by ngcc_hk »

eliasdaler wrote: post #111
proc0 wrote: post #94

Earlier quoted context omitted.

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.

I guess what you said is right - the starting code and the later refactored code for reuse is and should be different. You experiment a lot …

Anyway after reading I still struggle. All these discussion is about game. I am more on simulation like Game Of life but in 3d (2d done using sdl and except iOS-mixer, one code base can run on most platform I care about). And possibly VR. May be back to unity and … learn so much using c/c++ using sdl especially just pass grenderer and gwindow around and just use function pointer. I guess 3d is out of reach based on reading your article. Very enjoyable reading nevertheless.

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

#254

Post by jms55 »

nextaccountic wrote: post #243
jms55 wrote: post #131

Earlier quoted context omitted.

Exactly this. Vulkan, especially Vulkan 1.0, was never really meant directly for graphics developers. It was meant specifically for engine developers that didn't want to have to deal with buggy and inconsistent drivers, e.g. Nvidia vs AMD vs crappy Android phones. The solution Vulkan came up with was "make everything as explicit and user-controlled as possible", and leave "implementing a more user friendly driver" up…

What happened was wgpu, which runs on top of Vulkan and can also run on the web as web gpu Many Rust programs are written against wgpu rather than Vulkan

I develop a lot of the more advanced features for Bevy, so I'm fully aware :)

The unfortunate reality is that wgpu does not have enough funding. Extremely valuable features like bindless, multi queue, and mesh shaders/raytracing are missing. CPU-overhead is fairly high. Things like debugging support are not great. Having to abstract over all of Vulkan/DX12/Metal brings difficulties.

I love wgpu, and don't begrudge the volunteer devs (they've done a lot of amazing work already), but I'm also frequently frustrated by its limitations.

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

#255

Post by nextaccountic »

jms55 wrote: post #254
nextaccountic wrote: post #243

Earlier quoted context omitted.

What happened was wgpu, which runs on top of Vulkan and can also run on the web as web gpu Many Rust programs are written against wgpu rather than Vulkan

I develop a lot of the more advanced features for Bevy, so I'm fully aware :) The unfortunate reality is that wgpu does not have enough funding. Extremely valuable features like bindless, multi queue, and mesh shaders/raytracing are missing. CPU-overhead is fairly high. Things like debugging support are not great. Having to abstract over all of Vulkan/DX12/Metal brings difficulties. I love wgpu, and don't begrudge th…

Oh nice!

Lots of people say that wgpu is lacking in comparison to vulkan (specially because it has gpu features from circa 2015), but how do you compare it to opengl?

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

#256

Post by troad »

HelloNurse wrote: post #228
troad wrote: post #217

Earlier quoted context omitted.

> This really doesn't mean much. The second cube (or another shape) isn't going to double the line count. That's an absurd standard. "Writing an OS is easy, because once you've written enough code to get Doom to run, firing up a second copy of Doom is relatively straight-forward!" It's those first 600 lines that are the problem. There's now a steep learning curve and lots of boilerplate required for even trivial use…

> I'm not against Vulkan for those applications that truly do need it, but - frankly - most graphics programming does not need it. In giving up OpenGL we're giving up a sane, standard way to do graphics programming I cannot avoid thinking that this sort of argument was made for countless technological innovations, from steam engines vs. draft animals to boats vs. swimming.

Haha, that's an interesting thought. Not to play devil's advocate, but can you honestly tell me the average American's weekly car need couldn't be met by a horse? (Mostly kidding.)

I think the distinguishing thing here is that those technological innovations were all adopted voluntarily by people setting aside the previous technologies, for the advantages of the new technology were obvious. Here, people are clinging to the old tech despite being threatened with its constant depreciation (already done on Apple systems), for the simple reason that using the new tech is more work for no more gain. For the average use case, Vulkan feels more like a technological regression than an advance.

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

#257

Post by jms55 »

nextaccountic wrote: post #255
jms55 wrote: post #254

Earlier quoted context omitted.

I develop a lot of the more advanced features for Bevy, so I'm fully aware :) The unfortunate reality is that wgpu does not have enough funding. Extremely valuable features like bindless, multi queue, and mesh shaders/raytracing are missing. CPU-overhead is fairly high. Things like debugging support are not great. Having to abstract over all of Vulkan/DX12/Metal brings difficulties. I love wgpu, and don't begrudge th…

Oh nice! Lots of people say that wgpu is lacking in comparison to vulkan (specially because it has gpu features from circa 2015), but how do you compare it to opengl?

It's better than OpenGL 3 in my opinion. It has a much saner API, is a lot more predictable, and API calls can be made from multiple CPU threads.

OpenGL 4 has some more advanced features like bindless that WebGPU lacks (and Vulkan has), but I wouldn't use OpenGL because of that.

My recommendation is start with WebGPU if you're new to graphics programming. Once you're at the end point where you have a bunch of working features and have optimized your engine as much as you can, and are starting to push against WebGPU limits, then I would think about switching to Vulkan 1.3 / DirectX 12.

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

#258

Post by amandasystems »

I really appreciate a “here’s how I did this” that also includes hints on how to avoid bikeshedding and essentially getting scared out of doing the thing.

In my experience being daunted ans not knowing where to start is a large part of the difficulty in doing difficult things.

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

#259

Post by nmfisher »

Narishma wrote: post #234
nox101 wrote: post #178

Earlier quoted context omitted.

If you want OpenGL use ANGLE https://github.com/google/angle several phones now ship ANGLE as their only OpenGL support on top of their Vulkan drivers. If you want a modern-ish API that's relatively easy and portable use WebGPU via wgpu (rust) or dawn (c++).

ANGLE is such a pain to build, I've never managed to do it.

Really? I did it recently (integrating an OpenGL texture render target into a D3D application) and it was pretty straightforward (on Windows, at least).

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

#260

Post by cubefox »

wtetzner wrote: post #250
cubefox wrote: post #101

Earlier quoted context omitted.

On the other hand, often a "quick and dirty" solution unexpectedly becomes the foundation of a lot of other stuff, which can be a persistent pain in the future, while the cost of rewriting the whole thing increases the more other stuff depends on it. There are two poles: On the one side is making everything an unmaintainable pile of quick hacks, on the other side is over engineering everything. You want to be somewhe…

> There are two poles I'm not sure I agree. I think you can write a simple-but-not-hacky implementation that does only what is necessary, and is also easy to maintain and extend later. Of course, you never really achieve that ideal, but you can keep getting closer to it as you gain more experience.

"Easy to extend" arguably means including more abstraction and making things more general than they need to be merely for solving the current problem. There is a trade-off here.
Post reply on HN