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

91–100 of 268 posts

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

#91

Post by SR2Z »

pxtail wrote: post #79
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…

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

Yeah, I am no longer a junior engineer.

When I WAS the bane of my existence was senior and staff engineers hoarding all the fun, new work for themselves and forcing me into "bitch work" where I'm just cleaning up old, broken code and handling bugs. I finally got promoted because I explicitly ignored my manager to deploy changes that were needed for my company, and that was what finally got me promoted. Of course, at that point, I had been looking for a new job and just left instead of taking the shitty, bottom-of-band promo increase.

It's awful for promotion chances, and it forced me to quit.

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

#92

Post by cristoperb »

eliasdaler wrote: post #77
PhilipRoman wrote: post #33

Earlier quoted context omitted.

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!).

Your site looks nice and is quite readable! The thing I most dislike about sites that just use raw HTML is the lack of `max-width` on the text containers (which makes using reader mode necessary), so thanks for including that

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

#93

Post by Animats »

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 textures, etc., and "objects", which reference the meshes and textures. Creating an object puts it on screen. Rust reference counting interlocks everything. It's very straightforward to use.

All those layers create problems. WGPU tries to support web browsers, Vulkan, Metal, DX11 (recently dropped), DX12, Android, and OpenGL. So it needs a big dev team and changes are hard. WGPU's own API is mostly like Vulkan - you still have to do your own GPU memory allocation and synchronization.

WGPU has lowest-common-denominator problems. Some of those platforms can't support some functions. WGPU doesn't support multiple threads updating GPU memory without interference, which Vulkan supports. That's how you get content into the GPU without killing the frame rate. Big-world games and clients need that. Also, having to deal with platforms with different concurrency restrictions results in lock conflicts that can kill performance.

Rend3 is supposed to be a modest level of glue code to handle synchronization and allocation. Those are hard to do in a general way. Especially synchronization. Rend3 also does frustum culling (which is a big performance win; you're not rendering what's behind you) and tried to do occlusion culling (which was a performance lose because the compute to do that slowed things down). It also does translucency, which means a depth sort. (Translucent objects are a huge pain. I really need them; I work on worlds with lots of windows, which you can see out of and see in.)

The Rust 3D stack people are annoyed with me because I've been pounding on them to fix their stack for three years now. That's all volunteer. Vulkan has money behind it and enough users to keep it maintained. Rend3 was recently abandoned by its creator, so now I have to go inside that and fix it. Few people do anything elaborate on WGPU - mostly it's 2D games you could have done in Flash, or simple static 3D scenes. Commercial projects continue to use Unity or UE5.

If I went directly to Vulkan, I'd still have to write synchronization, allocation, frustrum culling, and translucency. So that's a big switch.

Incidentally, Vulkano, the wrapper over Vulkan and Metal, has lowest-common-denominator problems too. It doesn't allow concurrent updating of assets in the GPU. Both Vulkan and Metal support that. But, of course, Apple does it differently.

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

#94

Post by proc0 »

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 to create bugs or side effects. I have worked in too many codebases were people feel the need to rush new features, and then it creates a minefield of a codebase where you have to manually check every feature and have the entire application in context when changing something small.

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

#95

Post by andrewmcwatters »

wudangmonk wrote: post #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 o…

Yes. It's too much to ask. Even the "official" examples by documentation do not do it. Reading the Vulkan specifications is an exercise in practicing technical bullshit.

When you're corroborating some random person's third-party instructions on initializing Vulkan and comparing those notes to what's done in Khronos Group repositories and reading the Vulkan 1.3 spec and realizing you have to read the specification out-of-order to get anything done, it's clear that they failed.

They failed. It's bad work by any other standard. But you'll do the work once and forget about it for the most part, so professionals don't complain too much.

Read my other comment in this thread for a portion of source code annotated with the specification chapters and sections.

It's a generic implementation that can be used with SDL and others.

Edit: As of the time of writing, the standard approach is to use VMA and Volk, both of which are included with the official Vulkan SDK. That should tell you enough about the state of the art.

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

#96

Post by andrewmcwatters »

eliasdaler wrote: post #80
andrewmcwatters wrote: post #56

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.

For sure. They just move the roughly 300 lines of code elsewhere so you don't have to do it, though.

I'd like to see them move nearly all 900-ish lines of SLOC back down into the near 90-ish you'd need to initialize OpenGL.

There's so much overlap in basically everyone's graphic usage of Vulkan that you realize after doing it yourself they should have done some simple optimization for the 99% use case, and allowed other people to write the full 900+ lines for GPU compute or other use cases.

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

#97

Post by _nist »

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 with this. In a large organization, if you have risen to a level where you are being relied upon at a regular intervals, it is imperative that you have a well architected solution that you can readily change and this is where you separate your program from spaghetti code to something useful. Sure, its nice to write unmaintainable junk when toying around, but I to have seen too many codebases where people were just throwing features in without thought and it causes the program to become way too constrained to only a specific problem domain and it becomes inflexible for solving new problems (to the point you have to re-write nearly everything from scratch).

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

#98

Post by izacus »

wudangmonk wrote: post #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 o…

Vulkan was always designed to be extremely low level API and with an idea in mind, that libraries would be required to get it up to level of OpenGL/DX11 and others. So in this respect, extensively using libraries on top of it is very normal, just like you don't write your software against syscalls these days.

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

#100

Post by outworlder »

xedrac wrote: post #67
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…

Yes, over engineering solutions is a constant thorn in my side. The end result is you get a lot of additional complexity for basically no benefit. In my experience, if new requirements do come down the pipeline at some later time, the generic solution you previously built will be completely inadequate and will need to be redone anyway. Solve the problem in front of you, not some unknown future problem.

The only thing I'll add is: do the simplest thing that can possibly work, but no simpler.

Don't back yourself into a corner. If a solution will block you from doing the right thing later, maybe some additional engineering may be needed after all to ensure you can continue to iterate. In large companies, inertia is enormous. Once a solution is in place and gets replicated, backtracking may become a herculean task.

Post reply on HN