← Home ← Back to /g/

Thread 107155727

23 posts 18 images /g/
Anonymous No.107155727 [Report] >>107159811
/gedg/ - Game and Engine Development General
DirectX 11 Edition

/gedg/ Wiki: https://igwiki.lyci.de/wiki//gedg/_-_Game_and_Engine_Dev_General
IRC: irc.rizon.net #/g/gedg
Progress Day: https://rentry.org/gedg-jams
/gedg/ Compendium: https://rentry.org/gedg
/agdg/: >>>/vg/agdg
Render bugs: https://renderdoc.org/

Requesting Help
-Problem Description: Clearly explain your issue, providing context and relevant background information.
-Relevant Code or Content: If applicable, include relevant code, configuration, or content related to your question. Use code tags.
Anonymous No.107155894 [Report]
Implemented collision detection with SAT
Anonymous No.107155972 [Report]
I implemented some point lights. no shadows yet though.
Anonymous No.107156256 [Report] >>107156433 >>107158853 >>107160020
>AI is a thing now
>all of a sudden enginekeks are posting decent progress
Very suspicious. What happened to building it yourself?
Anonymous No.107156433 [Report]
>>107156256
i still enjoy programming without llms, so my lights are done without llm assistance.
i guess someone could vibe it and it would take them way less time, but I don't care.
Anonymous No.107156835 [Report] >>107156910 >>107157068
What is the best 3d collision library in C? I heard bullet is C++ and I cannot find any other.
Except if bullet has bindings for C
Anonymous No.107156882 [Report] >>107156886
How can I do these retro looking lights in OpenGL, like the ones from original Majoras Mask?
Anonymous No.107156886 [Report] >>107157363
>>107156882
This one is better visible.
Anonymous No.107156910 [Report] >>107156928
>>107156835
Haven't used it myself, but I heard good things about Jolt. It's written in C++ has interfaces bindings for C.
https://github.com/jrouwe/JoltPhysics?tab=readme-ov-file#bindings-for-other-languages
It's quite the big package, but physics libraries usually need to cover lots of things
Anonymous No.107156928 [Report]
>>107156910
Isn't Jolt very new and doesn't support a lot of things?
Anonymous No.107157068 [Report]
>>107156835
Write your own. https://gamephysicsweekend.github.io
Anonymous No.107157309 [Report] >>107157372 >>107157448
Why do all tutorials for Vulkan STILL treat the normal OpenGL/Vulkan1.0 way of doing things as the standard? It's not easier, it's not more intuitive, most features in Vulkan since 1.0 have been moving it towards being more of a normal programming language instead of some esoteric autistic cult thing like graphics APIs used to be, but every fucking tutorial still assumes you're some retard entrenched in 20 years of OpenGL work who can't think in more sane patterns (which must be rare considering they must then be unable to do "normal", non-graphics programming).

At the very least using buffers (and buffer addresses) for as much as possible should be standard. Honestly, bindless should be as well.
Anonymous No.107157363 [Report] >>107158068
>>107156886
Vertex colors. Northern Journey did it and it looks pretty good.
Anonymous No.107157372 [Report] >>107157560
>>107157309
If you know better than the tutorials why are you even following them you idiot?
Anonymous No.107157448 [Report] >>107157560
>>107157309
i agree. not having to worry about e.g. descriptors and bindings simplifies so many things and makes vulkan more approachable as a newbie.
opengl was in a similar situtation with many resources being available introducing opengl 1 and 2 as the way of doing things. Those were the tutorials people found first, so that's what most people learned. Way fewer tutorials were written for opengl 3 (until learnopengl.com changed that at least), and even fewer exist with opengl 4 in mind.
vulkan still carries some historical baggage because of how the hardware got to where it is today. And when new tutorials are written for newer versions, I think people often still want to point out the evolution of the hardware and api's. Sometimes knowing about that can explain why certain things are the way they are today, but often it's just unnecessary detail .
Anonymous No.107157512 [Report]
Managed to take 30% off RTree querying time, though for 2 dimensions version only. With this spatial index autism can come to an end.
Anonymous No.107157560 [Report]
>>107157372
Who said I'm following them? I did follow one initially but bailed after I got the basics.
>>107157448
Understandable but hopefully tutorials will update to more modern Vulkan methods instead of teaching people outdated and arcane ways.
Anonymous No.107158068 [Report] >>107158071
>>107157363
does that mean that I will have to split large flat surfaces into multiple quads to work?
Anonymous No.107158071 [Report]
>>107158068
yes
Anonymous No.107158853 [Report]
>>107156256
I built my engine before LLMs
Anonymous No.107159537 [Report]
Update from >>106889917
they uploaded the 25.3.0-rc4 release oh github and it supports GL_EXT_mesh_shader on zink and I does work (at least the feature appears, I have not run any code, just checking if the extension exists)
I wonder what the differences it has compareed to GL_NV_mesh_shaders, or what type of performance it has.
And this could be used to give mesh shaders for opengl on AMD and intel GPU's (but vulkan has had cross vendor mesh shaders for 3 years).
Anonymous No.107159811 [Report]
>>107155727 (OP)
The
>previous thread
>>107136078
had mention of Kuwahara filters. I was messing about in Blender and noticed a Kuwahara compositor node.
>Actually I wanted to see what 'temporal distortion' would look like applied to a video but there seems to be no reasonable way to do this in Blender... so this is just noise in screen space rather than in time...
Anonymous No.107160020 [Report]
>>107156256
It just took a while to build the foundations