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

101–110 of 268 posts

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

#101

Post by cubefox »

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.

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 somewhere in the middle.

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

#102

Post by harrison_clarke »

sigmoid10 wrote: post #51
harrison_clarke wrote: post #46

Earlier quoted context omitted.

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

Vulkan is super appealing if you're in the industry and have the time and resources necessary to profit from its advantages. But if you're a single dev who wants to learn game engine design, you're going to have a bad time. Most people also don't get that game engine design is very far removed from actual game design. You can have a ton of fun learning math, physics and computer science when building an engine, but b…

vulkan doesn't have global state, and the error handling is better

but it's not batteries-included, and that's often to be a deciding factor at small scales

i think if you're going to dabble in engine dev, you pick which one you want depending on which part of the engine you find interesting. if you want to make a game, you pick up unity or godot or something

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

#103

Post by tombert »

I tried learning Vulkan a little more than a year ago and I have no desire to ever touch it again. It really bothers me that we're deprecating OpenGL and replacing it with something that's ridiculously hard to do anything simple (e.g. doing a spinning cube takes several hundred lines of code).

OpenGL was never "easy" but it was at least something a regular person could learn the basics of in a fairly short amount of time. You could go to any big book store, buy some intro to graphics programming book, and get some basic stuff rendering in an afternoon or two. I'm sure Vulkan is better in some regards but is simply not feasible to expect someone to learn it quickly.

Like, imagine the newest Intel/ARM/AMD chips came along and instead of being able to write C or C++, you're being told "We are dropping support for higher level languages so you can only write assembly on this now and it'll be faster because you have more control!" It would be correctly labeled as ridiculous.

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

#104

Post by cubefox »

alexvitkov wrote: post #70
solardev wrote: post #65

Earlier quoted context omitted.

Even more confused now, lol. (edit: thanks for editing your post. the revised version clears it up!)

Vulkan, Direct3D, Metal and OpenGL are graphics APIs - the implementation comes with your GPU driver, and they're as close as you can reasonably get to writing code "directly for the GPU". When you call a Vulkan function you're directly calling driver code. wgpu is a regular library that uses the native APIs above and abstracts them from you. I don't like calling it a graphics API because it implies it's the same as…

But clearly libraries like wgpu implement WebGPU while not requiring a browser. So WebGPU is not browser-exclusive.

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

#105

Post by tombert »

izacus wrote: post #98
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.

That's what bothers me though; why not have an official higher level API that's less awful to use? Instead you get a bunch of third party libraries bolted on top of everything.

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

#106

Post by sigseg1v »

cubefox wrote: post #101
xedrac wrote: post #67

Earlier quoted context omitted.

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.

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…

Totally agree, it needs a careful balance. But is it possible to know when to use what?

Anecdote: A couple years ago I migrated a 1M+ LOC application from one database to another, cutting the cloud hosting costs practically in half. This was absolutely massive for the company. It took a bit less than a year, but was possible because the people who designed the application didn't write any hardcoded queries, and everything went through an ORM or a query builder. Everything was built to an interface, even though they all only had one implementation. This turned out to be absolutely critical when we had to add the second implementation (and because we needed to maintain compatibility for the original implementation at the same time due to some one-off contracts) and the migration would not have been worth it cost-wise if the proper architecture wasn't in place from the start.

Now take the same application. It has tons of complicated architecture stuff implemented in house. Parts of it are definitely overengineered. It's been apparent when doing other upgrades and finding out "oh... this doesn't work because it's using a custom JSON serializer" that the choice to do that was poor.

In the end, I think the right choice for that application was the complex design that allowed those big migrations. For others, they might never do that and only get hit with downsides.

What it needs is likely a good vision and someone smart to know what to abstract and what to not abstract such that it will have been a good choice 15 years down the road.

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

#107

Post by edflsafoiewq »

tombert wrote: post #103

I tried learning Vulkan a little more than a year ago and I have no desire to ever touch it again. It really bothers me that we're deprecating OpenGL and replacing it with something that's ridiculously hard to do anything simple (e.g. doing a spinning cube takes several hundred lines of code). OpenGL was never "easy" but it was at least something a regular person could learn the basics of in a fairly short amount of…

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.

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

#108

Post by lpapez »

SR2Z wrote: post #91
pxtail wrote: post #79

Earlier quoted context omitted.

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

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

Oh how I relate to this...

That's why these days I go out of my way to "save" interesting work for my junior colleagues and have them grow through it.

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

#110

Post by tombert »

edflsafoiewq wrote: post #107
tombert wrote: post #103

I tried learning Vulkan a little more than a year ago and I have no desire to ever touch it again. It really bothers me that we're deprecating OpenGL and replacing it with something that's ridiculously hard to do anything simple (e.g. doing a spinning cube takes several hundred lines of code). OpenGL was never "easy" but it was at least something a regular person could learn the basics of in a fairly short amount of…

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 rid of the only open easy-to-use graphics standard, made NO REPLACEMENT, and then said "oh you should just use this impossible API or let the outside world come up with a fix around it".

Post reply on HN