I learned Vulkan and wrote a small game engine with it • Hacker News Board

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

#221

Post by account42 » Fri, Jun 07, 2024, 11:47 AM UTC

troad wrote: post #217

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

> 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!"

If you can write that OS in anything close to 600 lines then yes, it is easy.

The point is that more realistic OpenGL and Vulkan projects will have a much smaller relative size difference.

> Great. What about the other 99% of people?

They can use higher-level abstractions built on top of Vulkan. Or spend some time learning to use Vulkan directly.

> I'm not against Vulkan for those applications that truly do need it, but - frankly - most graphics programming does not need it.

Disagree.

> In giving up OpenGL we're giving up a sane, standard way to do graphics programming

Sane is not a word I would use to describe OpenGL. It has managed to collect many warts over the years and as I have already mentioned, what performs well is not at all intuitive.

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

"Oh no, so many options". A nice problem to have.

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

Wild and unfounded speculation. You can already use ANGLE, which is open source, as your middleware today if you like the OpenGL API so much.

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

#222

Post by MindSpunk » Fri, Jun 07, 2024, 11:49 AM UTC

torginus wrote: post #186

andrewmcwatters wrote: post #126

Earlier quoted context omitted.

Khronos keeps pushing this in their promotional materials for the standard, and it's not an advantage. Now instead of vendors writing this correctly once for everyone, everyone can do it poorly. Go read a few Vulkan initialization implementations across a few repositories. It's all the same code, and some people miss portions of it here and there. I don't know how this lie caught on so well, but it doesn't pass the s…

Honestly, this might be a bit of a conspiracy theory, but the practical use-case of Vulkan's low-level access isn't because of PCs and consoles - it's because of smartphone manufacturers that make absolutely abysmal mobile drivers.

This isn’t a conspiracy it’s the reality we live in. That was one of the primary benefits sold to hardware vendors. “Easier to write a driver”. Whether that panned out though is another question. The drivers still suck on mobile.

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

#223

Post by jcelerier » Fri, Jun 07, 2024, 11:50 AM UTC

andrewmcwatters wrote: post #139

edflsafoiewq wrote: post #134

Earlier quoted context omitted.

Pushing the code into a user-space library used by many programs means bugs can be fixed once in the library, instead of being at the mercy of every vendor fixing their driver blobs.

Yeah, somehow I think putting this one on multi-million dollar companies with budgets to work on graphics work for products they sell and make actual money off of is better than having some podunkian whose popular graphics library gets consumed by a bunch of people while they make $5 each from less than 1% of their users off Patreon and GitHub Sponsors.

You don't know how incredibly, incredibly broken drivers are, especially on embedded.

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

#224

Post by animal531 » Fri, Jun 07, 2024, 12:07 PM UTC

The screenshots reflect my experience 10-15 years ago creating my own SDL OpenGL engine+game where lighting is the first really hard thing to get looking good for a beginner to intermediate developer.

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

#225

Post by Ono-Sendai » Fri, Jun 07, 2024, 12:45 PM UTC

exDM69 wrote: post #216

Ono-Sendai wrote: post #159

Earlier quoted context omitted.

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.

Yeah you need to make sure the upload has completed before you try and use the texture, right?

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

#226

Post by exDM69 » Fri, Jun 07, 2024, 12:51 PM UTC

Ono-Sendai wrote: post #225

exDM69 wrote: post #216

Earlier quoted context omitted.

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.

Yeah you need to make sure the upload has completed before you try and use the texture, right?

Yes, and you need to make sure that the upload has completed before you reuse the pixel buffer too.

And the synchronization API isn't very awesome, it can only wait for all operations until a certain point have been completed. You can't easily track individual transfers.

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

#227

Post by Buttons840 » Fri, Jun 07, 2024, 12:58 PM UTC

ReleaseCandidat wrote: post #179

Animats wrote: post #93

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

> WGPU doesn't support multiple threads updating GPU memory without interference WGPU uses WebGPU and AFAIK no browser so far supports "threads". https://gpuweb.github.io/gpuweb/explainer/#multithreading https://github.com/gpuweb/gpuweb/issues/354 And OpenGL never supported "threads", so anything using OpenGL can't either.

WGPU is an implementation of WebGPU. This is more accurate than saying it uses WebGPU; WebGPU is not software, you can't use it.

WGPU goes beyond WebGPU in many ways already, and could also support threads.

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

#228

Post by HelloNurse » Fri, Jun 07, 2024, 1:08 PM UTC

troad wrote: post #217

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

> 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

I cannot avoid thinking that this sort of argument was made for countless technological innovations, from steam engines vs. draft animals to boats vs. swimming.

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

#229

Post by HelloNurse » Fri, Jun 07, 2024, 1:20 PM UTC

tombert wrote: post #110

edflsafoiewq wrote: post #107

Earlier quoted context omitted.

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…

The "first party library" is OpenGL, or if you have special needs OpenGL ES, WebGPU, Metal, DirectX variants, implemented on top of Vulkan.

The "NO REPLACEMENT" is sidelining ugly OpenGL drivers and adopting leaner and more modern Vulkan drivers.

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

#230

Post by HelloNurse » Fri, Jun 07, 2024, 1:27 PM UTC

eliasdaler wrote: post #111

proc0 wrote: post #94

Earlier quoted context omitted.

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. I should probably clarify that in the article. It’s much easier to write “throwaway” code when you’re working alone and when you’re doing it just for fun. This advice was probably aimed at people who tend to overthink things in these kinds of situations and spend years implementing things in the “right” way, which tends to slow them down considerably instead.

A large organization is likely to have both a separation between experiments and the "actual" game engine, containing the churn of throwaway code in order to build on good foundation, and significant experience and reuse from their previous game engine, constraining (possibly for the worse) the experiments and rewrites.