Levi Bard
aevaopengl is for people who want to finish projects and vulkan is for people who are just looking for something to help their ecs framework stand out a little more
Joshua Barretto@aeva *screams, clutches chest, falls over and dies*
Evie 🏳️⚧️@aeva tho I would say once you spent enough effort into vulkan it has less "it doesn't work, idk why and can't find out"
halcy 
@aeva to be entirely fair, after finishing (1 week to release! basically done!) a project with opengles3.0 just now, I can see why people would want to use vulkan instead, but likely that's just because I have not used vulkan enough
wait actually. more like i can see why people would want to use webgpu instead. where does webgpu fall in this spectrum
@aeva wait, it's.... usable from C++ or really wherever, isn't it. i thought it was, at least. the main reason I'm curious about it at all is that SDL3 added support for creating contexts for it and that's very not rust unless something changed while I wasn't looking
radgeRayden@radgeRayden well, I am mostly interested in running shit in the browser via emscripten -> sdl3 for context -> render a bunch of stuff
in which case I think something like dawn, is not needed?
@halcy yeah if you want web it should be easier. Though the support situation is not good yet - for example I don't think any of the browsers shipped linux support.
@radgeRayden oof
yeah I guess the initial decision for opengl over webgpu was motivated a lot by familiarity with the API, but also by "wouldn't it be nice if people could actually run this", and I haven't really checked whether this has changed
@halcy I'm the guy in the picture (I'm writing vulkan code) and I think if I actually ship something it might be necessary to write an opengl fallback, yeah. In my case the choice of the less backwards compatible API is wanting to use some cool new things.
@radgeRayden @halcy i don't think I've seen webgpu work yet in Firefox at all. webgpu is a total joke
@radgeRayden @halcy the rust frog boiling shader language and lack of required support for spirv is a bridge too far for me. i will not use it ever until that changes.
@radgeRayden @halcy the standard could have been good but it's still born
redstrate@aeva @radgeRayden @halcy the only true opinion about webgpu. when i last looked there was some SPIRV->WLSL (or whatever they call it) bridge but it was super annoying to integrate. that's when i reach for something more sane
@redstrate @radgeRayden @halcy I suppose compiling from a high level language to an IR back to a high level language only for the runtime to presumably compile it back into an IR before passing it off to the driver to compile to the final binary is better than nothing, even if it's completely ridiculous.
@aeva @redstrate @radgeRayden i have no well formed opinion on this but I think „spirv“ sounds funny so clearly it’s good. It’s like the tinny sound an old car on its last legs makes. Spirvspirvspirvspirv
Lynne@aeva I dislike OpenGL so strongly I wrote a Vulkan renderer which scraps all aspects of rasterization, instead using mesh shaders -> BVH gen -> ray query inside compute shaders. I raised every Vulkan dev's eyebrow.
@aeva Wasn't really a game. I wrote https://github.com/cyanreg/versp since I got into Bonzomatic and wanted to do livecoding listening to music. But I got bored with it.
I'm building a simulator which uses this mechanism for physics. The idea is to construct small meshlets via mesh shaders, then determine collisions with ray queries. Mainly for materials like sand or really viscous fluids.
tbh its now that I hate OpenGL, its just that I'm simply too stubborn to understand how writing to a global scalar variable inside a vertex shader causes stuff to happen in a fragment shader. How is this a nice API?
I'm building a simulator which uses this mechanism for physics. The idea is to construct small meshlets via mesh shaders, then determine collisions with ray queries. Mainly for materials like sand or really viscous fluids.
tbh its now that I hate OpenGL, its just that I'm simply too stubborn to understand how writing to a global scalar variable inside a vertex shader causes stuff to happen in a fragment shader. How is this a nice API?
LR@aeva i just use SDL_gpu and Slang now. couldn't be happier.
well i could but not in a control flow based environment
@lritter SLD3 GPU fills an important niche and i respect it. the main reasons i am not myself using it for either of my current projects is because it's not backwards compatible with enough hardware, and i can't make browser games with it. ES2 provides a very simple API and also me to support the widest variety of hardware. being a dead API like win32 also means if i write code against it, it'll work forever.
@aeva good points. maybe we'll get that ES2 support into SDL3 eventually.
what is the reason for this conservative approach? the widest support?
@lritter you know that thing where you can't really buy a new gpu, ram, or ssd these days without paying out the nose
@aeva i see. i'm very long term oriented and i try to code for the world i want. because if the present is any indicator for the foreseeable future, then my existence makes no sense - for this eventuality, i don't need to prepare much.
@lritter the other reason ES2 appeals to me at this time is its simplicity keeps me focused on the goal. if i can't think of a way to do an effect with the simple capabilities it provides, that effect gets cut.
@aeva it's why i fell in love with GL in the first place. but my pipelines got pretty complex since then (streaming a voxel world is chonk). and any lingering state or a lack of control over scheduling only drives me up the walls anymore.
this is definitely more work. which is why i write compilers. they allow me to amp up the complexity without going mad over writing pipeline boilerplate. eventually.
@lritter i mean that's kind of my point right, these things take time, and that's a lot for one person to do. if you had taken the desire to abandon conventional tools due to the growing complexity of the project as a sign to dramatically cut scope it's possible that you would have shipped several games by now. of course, quantity is often not a virtue.
Josh Simmons@aeva i remember the "make many claypots" speech well. but gamedev projects, they are almost all artist driven projects. of course they think this way. but i see it as an engineering project. i make the thing that makes the game. hell i can't even say if the outcome will actually be fun. i just want to make a rite of passage game that allows players to get at least twice as much out of the rest of their life. no... that's not it. it allows young men to learn from mistakes.
@aeva to learn from a mistake they have to own all choices that led up to it. they must experience, delivered by an impartial system, the logical consequences of a harmful action and its greater implication for society, so they know any excuse is impossible, and then never do it in real life.
artists try to do this with storytelling. the fail state is: "what do artists know? it's just an opinion. it's just a story. i will stick to math. if it can be done it will be done."
@aeva i was bad at math also until i dropped out and took acid and this made me so curious... i wanted to know *everything*. so when i continued school i decided i'd be into math now. chew through it. there's always more math. fuck is there a lot of math. stick to a use! WHY do you need this... to blow them all away of course. long live the demoscene, sole designer of my curriculum.
@aeva and for some things, it is maybe ok to think so. when it is about our all survival, for example. but almost always it is important to consider the human in this.
we keep showing humans as they are in art, but then we activate sexual perception also. so we must disguise the human as alien to be able to see their inside.
but what have games done for modeling the psyche of humans? very little. creatures. milo. end of list.
mcc@aeva @lritter Incidentally, I'd argue that WebGPU is a better "long term oriented" target than Vulkan, because it's the common subset of Vulkan/Metal/DX12— unless someone specifically wants to support Android, they're unincentivized to bother making sure they can support the entire Vulkan feature set, but there is strong market logic for supporting at least the entirety of WebGPU, and strong disincentive for Apple or anyone like them to allow WebGPU to break in future.
ValorZard