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

211–220 of 268 posts

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

#211

Post by eliasdaler »

Waterluvian wrote: post #89

Are there any examples of an academic attempt at putting as much of a game into the GPU as possible? Like, architecting a game in a way that pretty much everything, including game logic, could be implemented as a shader?

I know about two games which do very interesting stuff with modern GPU capabilities:

* Noita

* Teardown

They both do their physics on GPU which results in some impressive effects and the level of destruction/world interaction which wasn't seen anywhere before.

Here's an interesting Teardown engine overview by its devs: https://www.youtube.com/watch?v=tZP7vQKqrl8

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

#212

Post by eliasdaler »

mort96 wrote: post #58
eliasdaler wrote: post #4

Earlier quoted context omitted.

Thank you. The up-front complexity is still there and it might take quite a few days to see your first triangle. But I promise, everything will get much easier from that point. :)

The thing I'm most interested in doing when starting a new project is pretty much never to spend a few weeks and writing 10-20k LOC to get a triangle on the screen, I think I'll stick with OpenGL for the time being tbh

You'll need 1k LOC to draw a single triangle and not 10-20k.

Sticking with OpenGL is understandable, but I can recommend learning some Vulkan as a side project (with the help of vkguide) without too much commitment. That's how I started and it turned out to be not as bad as I imagined! Uour mileage may vary, of course.

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

#213

Post by eliasdaler »

bashmelek wrote: post #15
jsheard wrote: post #5

Earlier quoted context omitted.

It's not quite as bad as it used to be, various later additions to Vulkan like dynamic rendering have eliminated some of the complexity it originally had. Figuring out which subset you should be using is a challenge in itself though, especially since there's a lot of outdated introductory resources floating around which still promote the ultra-verbose Vulkan 1.0 way of doing things. If a tutorial tells you to use ren…

Do you have any recommendations for sources? I’ve used Vulkan Tutorial, which is a bit stale but I suppose still good for exposure. I’ve also used Vulkan Guide, before its latest overhaul. That one was educational. Not sure if I’ll be able to do their new guide, my laptop can’t run some of the more recent versions of Vulkan

> Not sure if I’ll be able to do their new guide, my laptop can’t run some of the more recent versions of Vulkan

If your laptop got still GPU driver updates in 2022 or later, it should probably support Vulkan 1.3. You can install Vulkan SDK (or just extract the archive) and check your Vulkan version by running the supplied "vulkaninfo" program.

For example, my 5 year old Thinkpad T490 fully supports Vulkan 1.3 and it only has an iGPU! :)

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

#214

Post by troupo »

flohofwoe wrote: post #177
troupo wrote: post #130

Earlier quoted context omitted.

webgpu is a modern graphics API for modern GPUs to replace/complement these two APIs in the browser: WebGL (a very limited outdated subset of OpenGL) and Canvas (basically WinAPI drawing from 2000s) It's heavily influenced by Metal (based on original work by Apple and Mozilla). People are talking about it because it's on the web and it's finally something modern to work with.

> webgpu is a modern graphics API TBF, WebGPU is at least a decade behind too. For instance it implements a Vulkan-style rigid render pipeline model which even Vulkan is moving away from because it turned out too rigid. So once WebGPU becomes mainstream it may very well be the most "awkward" 3D API.

Don't worry, browsers will then come up with a fourth graphics API to solve all the issues of the previous three :)

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

#215

Post by Const-me »

_kidlike wrote: post #173
mort96 wrote: post #52

Earlier quoted context omitted.

Eh that's really only an option if you want to only ever target Microsoft platforms. Which is fine for some people, sure, but in a lot of situations, closing the door on Linux (Steam Deck), macOS, iOS, Android and the non-xbox consoles is a tough sell.

Valve's efforts on playing Microsoft only games started ~10 years ago with Proton (which is more like an umbrella project for ~15 software components like Wine and DXVK). Today, proton is surprisingly good. Their bet paid off, and allowed them to make SteamDeck. Most if not all new games play fine out of the box, with 0 tinkering. Older games sometimes have issues.

True, and it’s not just games: https://github.com/Const-me/Whisper/issues/42

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

#216

Post by exDM69 »

Ono-Sendai wrote: post #159
Animats wrote: post #148

Earlier quoted context omitted.

> The solution is multiple queues. Modern GPUs have a dedicated transfer/copy queue separate from the main general purpose queue. Yes. This is the big performance advantage of Vulkan over OpenGL. You can get the bulk copying of textures and meshes out of the render thread. So asset loading can be done concurrently with rendering. None of this matters until you're rendering something really big. Then it dominates the…

I believe you can do loading texture data onto the GPU from another thread with OpenGL with pixel buffer objects: https://www.khronos.org/opengl/wiki/Pixel_Buffer_Object I haven't tried it yet, but will try soon for my open-source metaverse Substrata: https://substrata.info/ .

It is possible but managing asynchronous transfers in OpenGL is quite tricky.

You either need to use OpenGL sync objects very carefully or accept the risk of unintended GPU stalls.

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

#217

Post by troad »

account42 wrote: post #193
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…

> e.g. doing a spinning cube takes several hundred lines of code This really doesn't mean much. The second cube (or another shape) isn't going to double the line count. > 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. The problem is that OpenGL no longer matches current hardware so the naive way to use it is very much suboptimal for p…

> 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 cases, where there wasn't before. That's a loss.

> The problem is that OpenGL no longer matches current hardware so the naive way to use it is very much suboptimal for performance. Once you move to zero driver overhead techniques for OpenGL then Vulkan is not that much harder.

Again, mad standard. "Writing Vulkan shouldn't be a problem for people who write complex zero driver overhead code for OpenGL." Great. What about the other 99% of people?

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, and exchanging it for a choice between (i) making everyone write mad Vulkan boilerplate for control they don't need, or (ii) choosing between a bewildering array of engines and frameworks and libraries, none of which work at all similarly, many of which are still very immature.

And it's obvious which one will win - whichever proprietary, SaaS monolith emerges to clean up the mess. Losing OpenGL is a huge set back for open standards, honestly. The principal beneficiaries of depreciating OpenGL will be the shareholders of Unity, in the end.

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

#218

Post by Ono-Sendai »

Animats wrote: post #164
Ono-Sendai wrote: post #160

Earlier quoted context omitted.

What I do currently is just limit the amount of data uploaded per frame. Not ideal but works.

That works better in game dev where you have control over the content. Metaverse dev is like writing a web browser - some people are going to create excessively bulky assets, and you have to do something reasonable with them.

It works with large assets too. Just split the upload into chunks.

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

#219

Post by account42 »

foldr wrote: post #208
account42 wrote: post #193

Earlier quoted context omitted.

> e.g. doing a spinning cube takes several hundred lines of code This really doesn't mean much. The second cube (or another shape) isn't going to double the line count. > 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. The problem is that OpenGL no longer matches current hardware so the naive way to use it is very much suboptimal for p…

>This really doesn't mean much. The second cube (or another shape) isn't going to double the line count. It's like the difference between "Hello World" in Python and "Hello World" in Java. Doesn't matter in the context of a serious software engineering project, but it's a significant barrier for beginners.

I agree with your analogy. It just so happens that Java is commonly taught as a first programming language and most people manage just fine with the class boilerplate even if they don't really understand it yet.

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

#220

Post by jcelerier »

0x1ceb00da wrote: post #161
dc443 wrote: post #116

Earlier quoted context omitted.

> WGPU doesn't support multiple threads updating GPU memory without interference, which Vulkan supports. This is really helpful for me to learn about, this is a key thing I want to be able to get right for having a good experience. I really hope WGPU can find a way to add something for this as an extension.

Do you have any references? I thought all wgpu objects are wrapped with an Arc >.

That sounds wild to me. In c++ I remember a time where I increased the frame rate of a particle renderer from 20fps to 60fps+ simply by going from passing shared_ptr (Arc equivalent) to passing references.
Post reply on HN