Live data from Hacker News

I learned Vulkan and wrote a small game engine with it

edw.is

71–80 of 268 posts

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

#71
post #37

This might come off as a surprise to some people but getting good performance with Vulkan (compared to say OpenGL) isn't trivial because: the Vulkan driver is missing that ~20k loc of code that OpenGL driver does for you to set up the rendering pipelines, render targets etc. This is all code that already exists in the OpenGL driver and has been optimized for +20 years by the best people in the industry. So when you s…

the biggest part for me is the shader compiler. opengl has one built in, vulkan requires me to pull in yet another dependency i've heard that vulkan allows bindless textures now, so the descriptor nonsense is a bit less awful that it used to be vulkan is appealing, but there's a high initial cost that i don't want to pay

Also in the case of glslang there are enough references to GPL to (probably erroneously) strike fear into legal departments

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

#73

I've been trying to learn Vulkan on and off for years (I used to know OpenGL ES 2&3 pretty well). One thing I found difficult is understanding how to use things in a real engine rather than a sample. A lot of samples will allocate exactly what they need or allocate hundreds of something so that they're unlikely to run out. When I was trying to learn DirectX, I found Microsoft's MiniEngine helpful because it wasn't ov…

Take a look at a real engine, something like vkquake is a good reference [1].

[1]: https://github.com/Novum/vkQuake

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

#74
Its great to have more Vulkan resources but unfortunately this one too suffers from the same problem as every other resource I've found on getting something on the screen with Vulkan.

They all introduce another layer of abstraction on top of Vulkan even before giving you the simple case without it. Its always use vk-bootstrap, volk, vma or someother library.

Is there a single resource anywhere that gives an example of doing the memory management manually because I havent found one, it seems like its either use vma or go figure out the spec are the only choices you are given. Is it too much to ask to just get the most basic example without having to add any libraries other than the Vulkan sdk itself?.

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

#75
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 don't think it's a mistake, I think it's targeted and leveraged poorly.

Vulkan is a great idea for a general game engine or backing something like OpenGL. It's a low-level abstraction that should allow you to do something like use OpenGL 8.0 on a GPU that has long lost support for from its manufacturer.

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

#76

Its great to have more Vulkan resources but unfortunately this one too suffers from the same problem as every other resource I've found on getting something on the screen with Vulkan. They all introduce another layer of abstraction on top of Vulkan even before giving you the simple case without it. Its always use vk-bootstrap, volk, vma or someother library. Is there a single resource anywhere that gives an example o…

there's a common gamedev practice of allocating a big chunk of memory up front, and then using a bump allocator inside of it

in most games, there are about 3 "lifetimes": - permanent/startup - per-level - per-frame

and they're nested. so, you can use a single stack allocator for all of them. at the end of the frame/level, pop back to where it started

there are more complicated patterns, but this one will get you pretty far. you can use it on the CPU and the GPU

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

#77

hey just curious, any reason why some of these articles I see from time to time don't apply some simply CSS? I don't mind the raw html, I'm mostly wondering if there's some benefit to it that I might not be aware of.

The site definitely has CSS, just not a lot of it.

Indeed. I used as little CSS as I could because I love minimalist websites. And the lack of syntax highlighting was inspired by Go blog, for example. :)

Raw HTML definitely looks much uglier, sadly (“Reader mode” in most browsers makes websites without CSS easily readable, though!).

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

#78

I've been trying to learn Vulkan on and off for years (I used to know OpenGL ES 2&3 pretty well). One thing I found difficult is understanding how to use things in a real engine rather than a sample. A lot of samples will allocate exactly what they need or allocate hundreds of something so that they're unlikely to run out. When I was trying to learn DirectX, I found Microsoft's MiniEngine helpful because it wasn't ov…

Vulkan is quite similar DirectX 12. Done concepts transfer directly. For memory allocation, you can use a library called vma to assst you. It takes care of a few stupid edge cases that the Standard accunulated over the years and is quite powerful.

For descriptor set allocation, there is only one pattern that nakes sense to me: expect the pools to be rather short lived and expect to have many of them. Allocate a new one once allocation from the current one fails - don't keep your own counters for alocated descriptors. The standard allows for all kinds of pool behaviors that deviate from strict counting. Discard old pools after the the last command buffer referencing that pool is finished.

Pipeline barriers and image layouts are a big pain in the butt. It makes sense to abstract them away in a layer that tracks last usage and lat Format for everything and adds barriers as required. It can get complex, but ot's worthbitnonce you have optional passen or passes that can get reordered or other more complex things going on.

About neshes, materials, rendering order: this goes beyond what I can summarize in a single HN post. This depends a lot on the choice of rendering algorithms and I do not consider a very generalized solution to be worth the (enormous) effortto get this right.

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

#79

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…

>starting with the problem they need to solve and focusing on the minimum needed to just solve that problem

To be fair if held strictly to these principles their work would revolve mostly around gluing together various Apis, services and sometimes adjusting already written software to company's needs. So I'm not surprised they are using every possible opportunity to write something here and there, this menial digital plumber's work takes its toll and one needs to try to squeeze in something a bit more enjoyable from time to time just to keep sanity in place a bit longer

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

#80

For the casual reader who is curious what it takes to write a "Hello, Triangle!" in Vulkan 1.3: https://github.com/Planimeter/game-engine-3d/blob/main/src/g...

Indeed. vk-bootstrap is a bit better with 600 lines of code, though: https://github.com/charles-lunarg/vk-bootstrap/blob/main/exa...

Vulkan initialization and basic swapchain management is very verbose, but things get much better after you do it for the first time and make some handy abstractions around pipeline creation/management later.

Post reply on HN