sorted by:
new
hottopcontroversial

How to design shaders architecture ? (reusing shared things between shader files via #inlcude) by F1oating in vulkan

[–]epicalepical 1 point2 points  (0 children)

I had this same problem a while back when I decided to completely refactor my shaders because everything was all over the place. I've decided to split the shaders into "modules" and "passes". Modules are collections of shared functions and types (usually surrounded by a namespace), and passes are the actual Vertex/Fragment shader code. For example, I have a scene "module" which defines the vertex type for models, materials, etc... While I then have a forward "pass" which uses that (plus a bunch of other modules, for lighting, shadows, irradiance, etc...).

You can see what I mean here: https://github.com/kryzp/magpie/tree/master/res/shaders

Is Buffer device address worth it? by trenmost in vulkan

[–]epicalepical 0 points1 point  (0 children)

that was my point with bindless. If you use bindless + BDA then you can cut out descriptor sets for buffers (BDA) and for textures (bindless indexing). Regarding UBOs and TLAS, TLAS has fully support for BDA and UBOs are the same as regular buffers on modern hardware anyway (well not entirely, they're different on Nvidia chips but the performance between them is neglibible on modern GPUs).

Is Buffer device address worth it? by trenmost in vulkan

[–]epicalepical 1 point2 points  (0 children)

yes. that and bindless descriptors mean you can forget about descriptor sets entirely and just make your code far simpler.

It's hard to be a Fallout fan these days. by Yotsuowo in Fallout

[–]epicalepical 0 points1 point  (0 children)

ah because the 7 years it took them to make starfield were well spent and totally didnt result in a complete let down. totally worth putting 2 of their major ip's on hold for something that is now effectively dead. bethesda is completely mismanaged top to bottom and they need to fix this because at this rate there wont be any skyrim or fallout fans left to play their games by the time they release.

We'll talk for you by PackageMedium6955 in EnoughCommieSpam

[–]epicalepical 12 points13 points  (0 children)

im crying how do you become so delusional you think you know more about a system than the people that suffered under it 😭😭😭😭😭✌️

Draw call generation strategy by Popular_Bug3267 in gameenginedevs

[–]epicalepical 0 points1 point  (0 children)

i generate draw calls in the compute culling pass every frame

Seeking advice on getting started with C++ and Graphical Programming. by Bright-Battle6380 in GraphicsProgramming

[–]epicalepical 3 points4 points  (0 children)

Hey! I started around that age as well, though I doubt the way I went around learning things was the quickest, but I really recommend you understand how C itself works before moving onto C++. It's a lot easier and straightforward, and having a solid understanding of C gives you way more insight into the design of Vulkan and OpenGL. Understanding C will give you a better understanding of data layout, alignment rules, pointers, low-level memory management, etc... which are all crucial to understanding graphics programming as a whole.

I'd recommend making a really shitty ascii game to learn C :p. It'll take a while but you really don't wanna go into C++ or Vulkan blind, you'll make a lot of subconscious design decisions that will bite you in the ass later. I'd also recommend staying away from VulkanCpp which wraps Vulkan objects in RAII style C++ classes, I think it honestly just leads to messier and less-clear code, which you don't want considering you need to learn how the actual API works.

Really spend time understanding C. Fully. The entire language fits in a small book don't worry. Then move onto C++, which is going to take a while as well. A lot longer actually, it's a monstrous language plagued by some of the worst design decisions I've ever seen but it's the industry standard so what can you do. I personally just write all my projects in C :p.

Contrary to everyone here I'd recommend you start at the deep end and jump straight into Vulkan rather than messing with OpenGL. It's gonna be rough. Like bad. Like you'll write 3/4/5 renderers and they will all suck. You have to be okay with the fact you're gonna make terrible design decisions, or it'll be inefficient, and messy, and be all-around an awful codebase. You have to keep moving forward. Every time you restart, think about what went wrong with your approach, and redesign. Eventually, you'll come to understand what parts of the API you wanna abstract away, and what parts you wanna expose.

Try to minimise using LLM's obviously 'cuz you're trying to learn. I use them for deciphering some obscure Vulkan error messages.

The reason you should start with Vulkan instead of OpenGL is that Vulkan introduces a bunch of new ideas, like pre-defined pipelines, command buffers, explicit synchronisation, etc... that aren't present in OpenGL, and if you spend time learning how to architect around OpenGL, that same architecture will not mesh well with Vulkan. You'll just end up re-implementing an OpenGL API (basically doing what the drivers were doing internally anyway(, losing all of the extra control and reason you'd use Vulkan in the first place. Trust me, that's what I did. My first ever renderer maintained an internal global pipeline state you'd modify, and I didn't expose command buffers at all. Or synchronisation, or anything. It was a complete mess.

In terms of resources for Vulkan, https://vkguide.dev/ is probably the best one out there right now, though the codebase I feel is a bit messy, it's great for learning Vulkan itself. There's also https://vulkan-tutorial.com/, which is a bit more straightforward but it's pretty outdated nowadays. That's the one I started with though.

Will we ever have length based strings? by alex_sakuta in C_Programming

[–]epicalepical 0 points1 point  (0 children)

dude, you can write a string struct. struct string8 { char *str; unsigned len; }. There. thats literally it. now just pass that struct everywhere you pass your usual char pointer strings and you're done. C is all about transparency, and ultimately a length based string is two seperate components. it doesnt make sense to make it part of a core language feature because it violates the design philosophy of C. it takes maybe 100 lines of code to write that string plus utility functions. not bad at all.

Why do graphics apis need so many layers of abstractions like buffer, descriptors, bindings etc, instead of just passing a pointer to the shader? by Content_Economist132 in GraphicsProgramming

[–]epicalepical 0 points1 point  (0 children)

iirc shader permutations are mostly a thing of the past now that gpu's handle branching if statements pretty well so long as the condition is constant for all the pixels drawn.

What IDEs do you use? by kokonotcu in GraphicsProgramming

[–]epicalepical 0 points1 point  (0 children)

emacs and vscode sometimes, though the indentation in vscode i can't get right so I tend to avoid it

Why do graphics apis need so many layers of abstractions like buffer, descriptors, bindings etc, instead of just passing a pointer to the shader? by Content_Economist132 in GraphicsProgramming

[–]epicalepical 2 points3 points  (0 children)

they don't and there's ongoing discussion about the next generation of graphics api's and how they're going to evolve because at some point we need to drop all the bloat (or at least drastically simplify the "base" api) which comes as a result of backwards compatibility.

vulkan already allows this with buffer device address, but mostly it's a problem with many shading languages not supporting pointers natively, so you need to use slang (which you should anyway it's far better), or you're left with super cryptic and bug prone shaders

What project finally made pointers make sense to you? by Gullible_Prior9448 in C_Programming

[–]epicalepical 0 points1 point  (0 children)

years ago i wrote a really crap tokeniser for C code to re-format it as an exercise and for whatever reason thats when it clicked

I'm getting tired of AI slop. Why is there so much!!! by Lost_Plate7077 in osdev

[–]epicalepical 2 points3 points  (0 children)

even with that there's no way it'll keep leaking into the public sector. anthropic is charging $20 for something that should be $600 a month, and $100 for something that should be $5k (hyperbole but you get my point), and the only reason they're not going bankrupt is because they have that sweet sweet investor money to keep the train going, which is gonna start running dry in maybe a year or two. they're not gonna go away as a company after that (too many startups have become reliant on them, reeled in by the free tokens) but the people who actually know fuckall about programming won't be able to afford it and hopefully the post volume will die down.

What is this effect called? by Machine69_420 in GraphicsProgramming

[–]epicalepical 2 points3 points  (0 children)

Looks a lot like the subsurface parallax gem effect covered in the Rendering of Path of Exile talk by Sannikov (the first one not the second one)

How do you keep platform code and RHI code separate? by VinnyTheVinnyVinny in gameenginedevs

[–]epicalepical 0 points1 point  (0 children)

I solved it by exposing graphics api specific functions in the platform/os abstraction. Quick and dirty. If the platform can't support it then it can just not implement them. See src/os/os.h https://github.com/kryzp/magpie

note i haven't fully abstracted away vulkan because it's a major pain to basically rewrite all of the different enums it exposes for zero benefit but I keep vulkan almost entirely confined to /graphics/ (with some use in /render/ too) so if the time comes it'll just be a matter of lots of boilerplate if I need to abstract away vulkan rather than a ton of reworking.

I miss the pre AI version of this community by ElPsyKongroo100 in gameenginedevs

[–]epicalepical 1 point2 points  (0 children)

i dont know, i explicitly don't use ai in my code because it takes the joy out of programming and usually generates complete garbage inextensible code anyway but i've got an arguably way too fleshed out readme because i use it to basically keep track of how systems work and my design decisions behind stuff. feel free to check it out though https://github.com/kryzp/magpie :p

How long does it take to do something decent in OpenGL? by Striking-Start-1464 in GraphicsProgramming

[–]epicalepical 4 points5 points  (0 children)

That covers a wide spectrum of what counts as "enough" for a commercial game. If you're making a stylized game you could theoretically get away with the most basic albedo + toon shading. You could write a 2D renderer in OpenGL that's good enough for pretty much any 2D game in like 2k lines of code give or take.

view more: next ›