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

91–100 of 107 posts

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

#91

Post by throwaway6977 »

fulafel wrote: post #69
mycall wrote: post #66

Earlier quoted context omitted.

It sounds like the standard did itself a disfavor by its name, more interesting in how you describe it.

The WebGPU spec identifies squarely as a web standard: "WebGPU is an API that exposes the capabilities of GPU hardware for the Web." There are also no mentions of non-web applications. The It's true that you can use Dawn and wgpu from native code but that's all outside the spec.

There is mention of desktop applications in their getting-started docs; it seems well within the intention of the maintainers to me.

https://eliemichel.github.io/LearnWebGPU/introduction.html

> Yeah, why in the world would I use a web API to develop a desktop application?

> Glad you asked, the short answer is:

    Reasonable level of abstraction

    Good performance

    Cross-platform

    Standard enough

    Future-proof

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

#92

Post by jesse__ »

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?

https://raytracing.github.io/books/RayTracingInOneWeekend.ht...

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

#93

Post by ChadNauseam »

raincole wrote: post #32
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…

How easy is it to integrate wgpu if the rest of your game is developed with a language that isn't rust? (e.g. C# or C++)

wgpu is the name of the Rust library, but it pretty closely follows the WebGPU spec, which you can easily use from C or C++ via Google's `dawn` library. It provides C bindings as well as a templatized C++ API.

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

#94

Post by tombert »

shortrounddev2 wrote: post #74
ryandrake wrote: post #70

Earlier quoted context omitted.

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

I wish Apple had made a point to support Vulkan. I know about MoltenVK and all that fun stuff, but for a time, there was a graphics API that worked on all of the major platforms: OpenGL.

Vulkan was meant to succeed OpenGL, and despite my annoyances with the API, I still think that it's nice to have an open standard for these things, but now there isn't any graphics API that works on everything.

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

#95

Post by AHTERIX5000 »

bsder wrote: post #18
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--programming Vulkan/DX12 sucks. The question you need to ask is: "Do I need my graphics to be multithreaded?" If the answer is "No"--don't use Vulkan/DX12! You wind up with all the complexity and absolutely zero of the benefits. If performance isn't a problem, using anything else--OpenGL, DirectX 11, game engines, etc. Once performance becomes the problem, then you can think about Vulkan/D…

What about new features? There are many small features that can't be used via older APIs and bigger ones like accelerated ray tracing.

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

#96

Post by elabajaba »

phendrenad2 wrote: post #15
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…

OpenGL is still being maintained, it just isn't being updated. Since OpenGL 4.0 or something we've had vertex and pixel shaders. As a non-AAA developer, I can't imagine anything else I'd really need. BTW: If anyone says OpenGL is "deprecated", laugh in their face.

Apple officially deprecated GL/GLES on both MacOS and iOS 7 years ago, and only ever supported up to GL 4.1 (which came out in 2010), meaning it doesn't support essential "modern" features like compute shaders (DX11 had them in 2009), or bindless textures (supported since 2012 on AMD+Nvidia, and 2015 for Intel iGPUs, massive performance win, needed for GPU driven rendering and ray tracing).

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

#97

Post by kimixa »

elabajaba wrote: post #96
phendrenad2 wrote: post #15

Earlier quoted context omitted.

OpenGL is still being maintained, it just isn't being updated. Since OpenGL 4.0 or something we've had vertex and pixel shaders. As a non-AAA developer, I can't imagine anything else I'd really need. BTW: If anyone says OpenGL is "deprecated", laugh in their face.

Apple officially deprecated GL/GLES on both MacOS and iOS 7 years ago, and only ever supported up to GL 4.1 (which came out in 2010), meaning it doesn't support essential "modern" features like compute shaders (DX11 had them in 2009), or bindless textures (supported since 2012 on AMD+Nvidia, and 2015 for Intel iGPUs, massive performance win, needed for GPU driven rendering and ray tracing).

Apple did that to push people towards their own walled garden of APIs rather than some deficiency of the OpenGL API.

There is no "technical" solution to this, no Even better API that would make them support it, as it's a business decision as much as anything else.

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

#98

Post by gustavopezzi »

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…

Hi there. Gustavo Pezzi here! Thanks for the mention. I always add new stuff to the lectures and I'm happy to inform that about a year ago I have added a bonus lecture on fixed-point rasterization at the end of that course. Nothing too crazy, but enough to cover the main points. Also, the PlayStation programming course is pretty much 100% fixed-point if anyone feels like diving into that too.

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

#99

Post by reactordev »

fulafel wrote: post #69
mycall wrote: post #66

Earlier quoted context omitted.

It sounds like the standard did itself a disfavor by its name, more interesting in how you describe it.

The WebGPU spec identifies squarely as a web standard: "WebGPU is an API that exposes the capabilities of GPU hardware for the Web." There are also no mentions of non-web applications. The It's true that you can use Dawn and wgpu from native code but that's all outside the spec.

And yet Electron exists…

The intent and the application are never squarely joined. Yes it’s made for the web. However, it’s an API for graphics. If you need graphics, and you want to run anywhere that a web page could run, it’s a great choice.

If you want to roll your own abstraction over Vulkan, Metal, DX12, Legacy OpenGL, Legacy DX11, Mesa - be my guest.

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

#100

Post by bsder »

AHTERIX5000 wrote: post #95
bsder wrote: post #18

Earlier quoted context omitted.

You don't have a tiny brain--programming Vulkan/DX12 sucks. The question you need to ask is: "Do I need my graphics to be multithreaded?" If the answer is "No"--don't use Vulkan/DX12! You wind up with all the complexity and absolutely zero of the benefits. If performance isn't a problem, using anything else--OpenGL, DirectX 11, game engines, etc. Once performance becomes the problem, then you can think about Vulkan/D…

What about new features? There are many small features that can't be used via older APIs and bigger ones like accelerated ray tracing.

Sure, but then you've already thrown away the possibility of using "simpler" APIs that everybody is whining that DX12/Vulkan is more complicated than.

Programmers should absolutely not be using DX12/Vulkan unless they understand exactly why they should be using it.

Post reply on HN