11 ms·
How I learned Vulkan and wrote a small game engine with it (2024)
- jakogut 10mo agoNote that I have retained the original title of the post, but I am not the author.
- gnabgib 10mo ago(2024) At the time (625 points, 260 comments) https://news.ycombinator.com/item?id=40595741 https://news.ycombinator.com/item?id=40595741
- tombert 10mo agoMy opinions of Vulkan have not changed significantly since this was posted a year ago https://news.ycombinator.com/item?id=40601605 https://news.ycombinator.com/item?id=40601605 I'm sure Vulkan is fun and wonderful for people who really want low level control of the graphic stack, but I found it completely miserable to use. I still haven't really found a graphics API that works at the level I want that I enjoyed using; I would like to get more into graphics programming since I do think it would be fun to build a game engine, but I will admit that even getting started with the low level Vulkan stuff is still scary to me. I think what I want is something like how SDL does 2D graphics, but for 3D. My understanding is that for 3D in SDL you just drop into OpenGL or something, which isn't quite what I want. Maybe WebGPU would be something I could have fun working on.
- user____name 10mo agoIf you don't need 4K PBR rendering, a software renderer is a lot of fun to write.
- tombert 10mo agoInteresting. I wouldn't actually mind learning how to do that; any tips on how/where to get started?
- junon 10mo agoGetting a triangle on the screen is the hello world of 3D applications. Many such guides for your backend of choice. From there it becomes learning how the shaders work, internalizing projection matrices (if you're doing 3D) which takes a bit of thinking, then slowly as you build up enough abstractions turns back into a more "normal" data structures problem surrounding whatever it is you're actually building. But it's broad, be prepared for that. Definitely recommend starting with a more "batteries included" framework, then trying your hand at opengl, then Vulkan will at least make a bit more sense. SDL is a decent place to start. A lot of the friction is due to the tooling and debugging, so learning how to do that earlier rather than later will be quite beneficial.
- rabf 10mo agoTsoding has been live streaming the development of a software renderer as of late: https://www.youtube.com/watch?v=maSIQg8IFRI https://www.youtube.com/watch?v=maSIQg8IFRI
- dmpk2k 10mo agoPikuma.com has a good one.
- RamtinJ95 10mo agoPikuma.com writes a software renderer pretty much from scratch with all the necessary math and explanations in a very pedagogical way. Highly recommend it
- dragonelite 10mo agoI can highly recommend this course, i finished it. It's one of those code katas to learn a new language with a bit like Raytracing in one weekend.
- user____name 10mo agoIf you want to render 2d vs 3d there are different tradeofs, a 3d renderer has to do interpolation of attributes over triangles, a 2d renderer doesn't and as a result can render ngons without having to triangulate them. I'm just going to dump some links really quick, which should get anyone started. Getting a framebuffer on screen: https://github.com/zserge/fenster https://github.com/zserge/fenster I would recommend something like SDL if you want a more complete platform abstraction, it even supports software rendering as a context mode. Filling solid rectangles is the obvious first step. Loading images and copying pixels onto parts of the screen is another. I recommend just not drawing things that intersect the screen boundaries to get started. Clipping complicates things a bunch but is essential. Next up: ghetto text blitting https://github.com/dhepper/font8x8 https://github.com/dhepper/font8x8 I dislike how basically every rendering tutorial just skips over drawing text on screen, which is super useful for debugging. For drawing single pixel lines, this page has everything on Bresenham: http://members.chello.at/easyfilter/bresenham.html http://members.chello.at/easyfilter/bresenham.html For 2d rasterization, here's an example of 3 common approaches: https://www.mathematik.uni-marburg.de/~thormae/lectures/graphics1/code_v2/RasterPoly/index.html https://www.mathematik.uni-marburg.de/~thormae/lectures/grap... Scanline rasterization tought me a lot about traversing polygons, I recommend trying it even if you end up preferi g a different method. Sean Barrett has a good overview: https://nothings.org/gamedev/rasterize/ https://nothings.org/gamedev/rasterize/ Side note: analytical antialising is fast, but you should be carefull with treating alpha as coverage, the analytic approaches tell you how much of a pixel is covered, not which parts are. For 3d rasterization Scratchapixel is good: https://www.scratchapixel.com/lessons/3d-basic-rendering/rasterization-practical-implementation/overview-rasterization-algorithm.html https://www.scratchapixel.com/lessons/3d-basic-rendering/ras... Someone mentioned the Pikuma course which is also great, though it skips over some of the finer details such as fixed point rasterizing. For good measure here's some classic demoscene effects for fun: https://seancode.com/demofx/ https://seancode.com/demofx/ Anyway, this is just scratching the surface, being progressively able to draw more and more types of primitives is a lot of fun.
- cuckmaxxed 10mo agoUnironically I think I can help. Frank Luna’s D3D11 bible is probably the closest thing we’ll get to a repetition spaced learning curriculum for 3D graphics at a level where you can do an assload with the knowledge. No, it won’t teach you to derive things. Take Calculus I and II. No, it won’t teach you about how light works. Take an advanced electrical engineering course on electromagnetism. But it will teach you the nuts and bolts in an approachable way using what is by far an excellent graphics API, Direct3D 11. Even John Carmack approves. From there on all the Vulkan, D3D12 shit is just memory fences buffers and queue management. Absolute trash that you shouldn’t use unless you have to.
- simonask 10mo ago`wgpu` in Rust is an excellent middle ground, matching the abstraction level of WebGPU. More capable than OpenGL, but you don’t have to deal with things like resource barriers and layout transitions. The reason you don’t is that it does an amount of bookkeeping for you at runtime, only supports using a single, general queue per device, and several other limitations that only matter when you want to max out the capabilities of the hardware. Vulkan is miserable, but several things are improved by using a few extensions supported by almost all relevant vendors. The misery mostly pays off, but there are a couple of cases where the API asks you for a lot of detail which all major drivers then happily go ahead ignore completely.
- tombert 10mo agoI'll definitely give wgpu a look. I don't need to make something that competes with Unreal 5 or anything, but I do think it would be neat to have my own engine.
- foltik 10mo agoCould you say more about which extensions you’re referring to? I’ve often heard this take, but found details vague and practical comparisons hard to find.
- attheicearcade 10mo agoNot the same commenter, but I’d guess: enabling some features for bindless textures and also vk 1.3 dynamic rendering to skip renderpass and framebuffer juggling
- simonask 10mo agoDynamic rendering, timeline semaphores, upcoming guaranteed optimality of general image layouts, just to name a few. The last one has profound effects for concurrency, because it means you don’t have to serialize texture reads between SAMPLED and STORAGE.
- raincole 10mo agoHow easy is it to integrate wgpu if the rest of your game is developed with a language that isn't rust? (e.g. C# or C++)
- thegrim33 10mo agoSDL 3.0 introduced their GPU API a year or so ago, which is an abstraction layer on top of vulkan/others, might want to check it out. Although after writing an entire engine with it, I ended up wanting more control, more perf, and to not be limited by the lowest common denominator limits of the various backends, and just ended up switching back to a Vulkan-based engine. However, I took a lot of learnings from the SDL GPU code, such as their approach to synchronization, which was a pattern that solved a lot of problems for me in my Vulkan engine, and made things a lot easier/nicer to work with.
- ryandrake 10mo agoI'm working with SDL GPU now, and while it's nice, it hasn't quite cracked the cross platform nut yet. You still need to maintain and load platform-specific shaders for each incompatible ecosystem, or you need a set of "source of truth" HLSL shaders that your build system processes into platform-specific shaders, through a set of disparate tools that you have to download from all over the place, that really should be one tool. I have high hopes for SDL_shadercross to one day become that tool.
- shortrounddev2 10mo agoI thought shaders just needed to be compiled to spir-v
- ryandrake 10mo agoMy comment was specifically about cross-platform. Apple operating systems don't know what spir-v is.
- shortrounddev2 10mo agoOh well sure if you're targeting apple as a platform you're gonna have to deal with their special snowflake graphics API
- 10mo ago
- gyomu 10mo agoTo this day, the best 3D API I’ve used (and I’ve tried quite a few over the years) is Apple’s SceneKit. Just the right levels of abstraction needed to get things on the screen in a productive, performant manner for most common use cases, from data visualization to games, with no cruft. Sadly 1) Apple only, 2) soft deprecated.
- rudedogg 10mo agoRealityKit is pretty cool and the replacement it seems. Still Apple only though, and I find the feedback loop slow/frustrating due to Swift I find SDL3 more fun and interesting, but it’s a ton of work to to get going.
- fingerlocks 10mo agoTrying to write a ground up game engine in Metal is a very serious exercise in self-discipline. Literally everything you need is right at your finger tips with RealityKit / old SceneKit. It’s so tempting to cheat or take a few short cuts. There’s even a fully featured physics engine in there.
- Pulcinella 10mo agoSceneKit is actually just straight up deprecated now: https://developer.apple.com/documentation/scenekit/ https://developer.apple.com/documentation/scenekit/ I imagine it will still be around for a long time because Apple and a lot of large third party apps use it for simple 3D experiences. (E.g. the badges in the Apple Fitness app). Apple wants devs to move to RealityKit, which does support non-AR 3D, but it is still pretty far from feature parity with SceneKit. Also RealityKit still has too many APIs that are either visionOS only or are available on every platform but visionOS. Microrant: I absolutely loathe when I am told "move to new thing. Old thing is deprecated/unsupported" and the new thing is incredibly far from feature parity and usually never reaches parity, let alone exceeds it. This is not just an Apple problem.
- AndriyKunitsyn 10mo agoNot my experience, unfortunately. I worked on a SceneKit project, it was bad. In general, it suffered from the problem of even Apple not knowing what it was made for, and what it even is. For a 3D API, it has less features than OpenGL 2. For a game engine, it… also has way less features than the competition, which shouldn’t surprise anyone - game engines are hard, and the market leaders have been developed for _decades_. But that’s what it looks like the most - a game engine. (It even has physics.) Customizing the rendering pipeline in SceneKit is absolutely horrible. The user is given a choice between two equally bad options: either adding SCNTechniques which are configurable through .plists and provide no feedback on what goes wrong with their configuration (as like 3D rendering isn’t hard enough already), or using “shader modifiers” - placing chunks of Metal code into one of 4 places of the SceneKit’s default shader which the end users _don’t even have the source code of_ without hacking into the debug build! Or pulling it from Github from people who already did that [_]. If you just need something that can display 3d data, SceneKit is still fine, but once there’s a requirement to make that look good, it’s better to throw everything away and hook up Unity instead. [_] https://gist.github.com/warrenm/794e459e429daa8c75b5f17c000600cf https://gist.github.com/warrenm/794e459e429daa8c75b5f17c0006...
- ryandrake 10mo agoAs someone who did OpenGL programming for a very, very long time, I fully agree with you. Without OpenGL being maintained, we are missing a critical “middle” drawing API. We have the very high level game engines, and very low level things like Vulkan and Metal which are basically thin abstractions on top of GPU hardware. But we are missing that fun “draw a triangle” middle API that lets you pick up and learn 3D Graphics (as opposed to the very different “learn GPU programming” goal). If I was a beginner looking to get a basic understanding of graphics and wanted to play around, I shouldn’t have to know or care what a “shader” is or what a vertex buffer and index buffer are and why you’d use them. These low level concepts are just unnecessary “learning cliffs” that are only useful to existing experts in the field. Maybe unpopular opinion: only a relative handful of developers working on actually making game engines need the detailed control Vulkan gives you. They are willing to put up with the minutiae and boilerplate needed to work at that low level because they need it. Everyone else would be better off with OpenGL.
- phendrenad2 10mo agoOpenGL is still being maintained, it just isn't being updated. Since OpenGL 4.0 or something we've had vertex and pixel shaders. As a non-AAA developer, I can't imagine anything else I'd really need. BTW: If anyone says OpenGL is "deprecated", laugh in their face.
- ryandrake 10mo agoOK, maybe OpenGL is not "unmaintained" but the major OS and hardware vendors have certainly handed him his hat.
- elabajaba 10mo agoApple officially deprecated GL/GLES on both MacOS and iOS 7 years ago, and only ever supported up to GL 4.1 (which came out in 2010), meaning it doesn't support essential "modern" features like compute shaders (DX11 had them in 2009), or bindless textures (supported since 2012 on AMD+Nvidia, and 2015 for Intel iGPUs, massive performance win, needed for GPU driven rendering and ray tracing).
- diath 10mo agoIf you want something like SDL but for 3D, check out Raylib.
- DeathArrow 10mo agoThere was XNA but it was abandoned a long time ago.
- tombert 10mo agoI think there are maintained community forks/reimplementations. FNA is probably something I would enjoy; that’s basically the level I want to program at. I wonder if I can get it working with F# in Linux…
- deleted 10mo ago[deleted]
- bashmelek 10mo agoI followed tutorials for Vulkan. I liked vk-guide, until it updated to the latest version. People said the newer SDL is so much better, but I honestly had more fun and got things done back with Renderpasses. I personally have just been building off of tutorials. But notwithstanding all of the boilerplate code, the enjoyability of a code base can be vastly different. The most fun I’ve ever had coding, and still do at times, is with WebGL. I just based it off of the Mozilla tutorial and went from there. WebGLFundamentals has good articles…but to be honest I do not love their code
- maybewhenthesun 10mo agoThe problem with 'something like SDL, but 3D' very quickly turns into a full blown engine. There's just such a combinatorial explosion of different ways to do things in 3D compared to 2D that 3D 'game engine' is either limiting or complicated. OpenGL was designed as a way to more or less do that and it turned complicated fast.
- anvuong 10mo agoVulkan was one of the hardest thing I've ever tried to learn. It's so unintuitive and tedious that seemingly drains the joy out of programming. Tiny brain =(
- ryandrake 10mo agoYou don't have a tiny brain. Vulkan is a low-level chip abstraction API, and is about as joyful to use as a low-level USB API. For a more fun experience with very small amounts of source code needed to get started, I'd recommend trying OpenGL (especially pre-2.0 when they introduced shaders and started down the GPU-programming path), but the industry is dead-set on killing OpenGL for some reason.
- zffr 10mo agoDoes anyone know why the industry is killing OpenGL?
- whstl 10mo agoPeople wanted more direct control over the GPU and memory, instead of having the drivers do that hard work. To fix this AMD developed Mantle in 2013. This inspired others: Apple released Metal in 2014, Microsoft released DX12 in 2015, and Khronos released Vulkan in 2016 based on Mantle. They're all kind of similar (some APIs better than others IMO). OpenGL did get some extensions to improve it too but in the end all the big engines just use the other 3.
- dontlaugh 10mo agoOpenGL cannot achieve the control over modern hardware necessary to get competitive performance. Even in terms of CPU overhead it’s very limiting. Direct3D (and Mantle) had been offering lower level access for years, Vulkan was absolutely necessary. It’s like assembly. Most of us don’t have to bother.
- jbb67 10mo agoVulkan is definitely a major pain and very difficult to learn... But once you've created an init function, a create buffer function, a create material function etc which you do once you can largely then just ignore it and write at a higher level. I don't like Vulkan. I keep thinking did nobody look at this and think 'there must be a better way' but it's what we've got and mostly it's just learn it and write the code once
- nodesocket 10mo agoI am fascinated with 3D/Gaming programming and watch a few YouTubers stream while they build games[1]. Honestly, it feels insanely more complicated than my wheelhouse of webapps and DevOps. As soon as you dive in, pixel shaders, compute shaders, geometry, linear algebra, partial differential equations (PDE). Brain meld. [1] https://www.youtube.com/@tokyospliff https://www.youtube.com/@tokyospliff
- jesse__ 10mo ago> Starting your engine development by doing a Minecraft clone with multiplayer support is probably not a good idea. Plenty of people make minecraft-like games as their first engine. As far as voxel engines go, a minecraft clone is "hello, world."
- jesse__ 10mo agoI love that it's becoming kind of cool to do hobby game engines. I've been working on a hobby engine for 10 years and it's been a very rewarding experience.
- DeathArrow 10mo ago>If you haven’t done any graphics programming before, you should start with OpenGL I remember reading NeHe OpenGL tutorials about 23 years ago. I still believe it was one of the best tutorial series about anything in the way they were structured and how each tutorial built over knowledge acquired in previous ones.
- jezze 10mo agoI just want to be a bit picky and say that bike shedding means focusing on trivial matters while ignoring or being oblivious to the complicated parts. What he described sounded more like a combination of feature creep/over-engineering.
- mpenick 10mo agoYou’re risking bike shedding “bike shedding”.
- MomsAVoxell 10mo agoThe author could also have used the phrase "hobby horsing", which is similar to bike shedding in that the individual is focusing on things that don't really push the project forward, but which rather give them personal pleasure, instead. Bike shedding usually is explained as "working out what color to paint the bike shed before the rest of the house is done".
- groovy2shoes 10mo agocf. yak shaving :)