Skip to content

Conversation

@Bigfoot71
Copy link
Contributor

I reviewed the depth formats and removed the 8-bit one. It could have been marginally useful for orthographic projection, but without heavier adjustments it would never really be practical.

I also added a 32-bit floating-point depth format, which avoids conversions, though after testing it turned out to be slightly slower than 16-bit with conversion. So 16-bit remains the default.

I also added saturation when writing depth values, since in some cases, when the camera was very close to a clipped triangle, the depth value could exceed the limit and cause an overflow.

This might require reviewing some details in the clipping, I find it strange at first glance...

This issue seems to mention the related UB problem: #5309

I compiled in debug mode with UBSan and ran several examples, didn't notice any issues on my side with this update.

The 24-bit format has also been quickly reviewed and tested, everything seems perfect!

@Bigfoot71
Copy link
Contributor Author

After some more testing, the results are mixed about 32-bit format.

I found it strange that the 32-bit format was slower, but it seems to vary depending on the example, sometimes it's very slightly slower or basically identical, but in the first_person_maze example it actually gains just under 10 FPS.

Well, it would probably need more specific profiling.

@raysan5 raysan5 merged commit bca5404 into raysan5:master Oct 30, 2025
16 checks passed
@raysan5
Copy link
Owner

raysan5 commented Oct 30, 2025

@Bigfoot71 thanks for the review! Definitely the 8-bit depth buffer use is very limited.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants