Kept you waiting, huh?

/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
Graphics Debugger: 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.

Previous: >>105853772

First for DirectX 11

remember what they took from us

>>105896166

>>105896181
Stencil shadows are crisp but performance shits the bed with higher poly count. And it doesn't work on alpha textures.

The mirror is literally just rendering the model twice. And the trick only works on a flat plane. Some games still use it. But it's not really suitable for high poly since it would multiply everything visible by the amount of planes. It's why games just put them in tiny bathroom mirrors.

Basically you can still use these techniques in your own low-poly games. Just don't expect any AAA to ever use them again. Ray tracing is the future (unless something better pops up of course)

Anyone got any OpenGL2.x-specific resources?
NOTE: 2.x. Not 3.x. Not 1.x.
2.x.

>>105812748
Previously: subscription manager maintains "neighbors" for players, npcs, monsters, and projectiles
Progress: manager now also provides tile and object updates for "chunked" regions within a given radius of current chunk you're in
Here is what it all looks like
1. Client connects to server, during this we front load the map download or only the latest map changes from database since last login (TODO: adjust so you only need a few "chunks" instead of full map)
2. Before player spawns in the realm the server sends any changes in memory for player vicinity that might not be in database, or occurred while client syncs were taking place
3. When the player crosses to a different chunk, the server checks the surrounding chunk versions, and can ship updates to the client. These are not rendered for the client since they are not in the player view distance yet, this is updating the map data the client has knowledge of

>>105897765
https://www.khronos.org/opengl/wiki/History_of_OpenGL#OpenGL_2.1_(2006)
you need more?

Is it still worth using OpenGL or should I move to something that isn't archaic like Vulkan or DX12?

>>105898643
I've been using WebGPU and it's a bit annoying that some stuff is undocumented because the devs are playing catchup with the specs.

anyone got a guide to 3d physics for a car game? I have been trying and failing to make a simple cube move and steer when using verlet integration there doesn't seem to be any online resource for this topic.

>>105899878
bing 3d car controller

newfags can't triforce

>>105898643
>isn't archaic
>Vulkan
Vulkan is archaic in the worst way possible. Pretty much everyone agrees that descriptors are the worst part of learning Vulkan by a country mile, and they are a woefully outdated concept from around 2016 (which is almost 10 years ago now). So you suffer through that shit only to learn outdated practices. For this reason I learned OpenGL instead, I'm learning something "outdated" anyway, why learn the much harder and more annoying one?

Metal is the one major API that doesn't use descriptors but unless you're fine with Apple-only somehow, it's off the table. Say what you will about Apple but at least they know their shit on the low level.

>>105898643
>>105900388
Whatever your opinion on Vulkan or OpenGL is, it's worth to learn OpenGL first either way. Compared to Vulkan, OpenGL has no boilerplate, you start learning actual rendering almost right away, knowledge that generalizes to all graphics APIs.
Meanwhile with Vulkan you'll be writing 1500 lines of gibberish you don't understand before you even get to draw a triangle on screen. Then you'll be spending a year understanding and generalizing those 1500 lines of gibberish before you can do anything else than a triangle, the risk of being filtered at this point is extremely high.
Get some OpenGL experience first. Always. OpenGL isn't going away anyway and will always be the lowest common denominator API, it'll always have a use.

>>105896410
wow.. am indian and i think this very good very nice 3d graphics ramhajam balalam

Can i fuck code? No? Then fuck you.

>>105900388
people love whining instead of actually learning.
https://github.com/KhronosGroup/Vulkan-Samples/tree/main/samples/extensions/descriptor_buffer_basic
https://github.com/KhronosGroup/Vulkan-Samples/tree/main/samples/extensions/buffer_device_address

>>105898643
OpenGL is the best API for indies because it's easier and has good documentation
If you're more serious use DX12
There's no case for Vulkan

>>105901117
can i have buffer binding slots like in opengl, please? it's the simplest, best system. just bind the buffer at some index and acces it by index in any shader.

>>105901190
yes?

>>105901190
you can just bind the frame data buffers to some predermined slots... and that's the whole frame setup.

>>105901117
>stop whining and learn this outdated clunky system instead of wanting us to do things properly
Nah, fuck you Khronos group.

>>105901373
extensions are specifically about fixing 1.0 mishaps
VK_EXT_DESCRIPTOR_BUFFER is a good example.
as well as dynamic rendering

>>105901387
>extensions to change the architecture because the original design is outdated
might aswell use OpenGL at that point

>>105901401
>updates for opengl: good
>updates for vulkan: bad
?

>>105901410
The pitch for Vulkan was it provides a clean modern architecture unlike OpenGL which has 3 different architectures built ontop of each other

>>105901387
And that's the problem, getting stuck on old legacy shit instead of ripping it out and doing it properly. Bloated APIs with 50 shit ways to do something instead of 1 good way are trash.

Again, I dislike Apple but they do it right in a lot of things. Especially for a tool, you don't want choice, you want efficiency.

>>105901413
vulkan was specifically about being less of a black box for dynamic state that could yield better performance, it succeeded in that approach, but not without mistakes.
>>105901427
no one is forcing you to use 1.0 APIs, nor are you paying for things you aren't using. lol

>>105901387
descriptor isn't the better solution, that's just how the directx 12 works, it added for better dxvk interop.

manual descriptor buffer management is even more convoluted than descriptor pools.

>>105901450
>descriptor buffer

Broke: reading normal programming books in your native language
Woke: reading programming books in a language you'd like to learn as immersion input
https://www.exa-corp.co.jp/technews/download/OpenGL-text-091.pdf
日本語でOpenGL勉強します!

>>105901450
>manual descriptor buffer management is even more convoluted than descriptor pools.
i implore you to read.
https://github.com/KhronosGroup/Vulkan-Samples/tree/main/samples/extensions/buffer_device_address

>>105901213
you can implement something similar with bindless descriptor indexing. but in opengl you can rebind the buffer between drawcall, in vulkan you can't just ovewrite descriptors in use.

>>105901483
vulkan has dynamic rendering