8000 Modifications to use application metadata for depth and stencil buffers by ggcrunchy · Pull Request #553 · coronalabs/corona · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Modifications to use application metadata for depth and stencil buffers #553

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 1 commit into from
Jun 27, 2023
Merged

Modifications to use application metadata for depth and stencil buffers #553

merged 1 commit into from
Jun 27, 2023

Conversation

ggcrunchy
Copy link
Contributor

A couple of my tests for the experimental build were working on the Android emulator (Pixel_3a_API_31_arm64-v8a, chosen arbitrarily) but not on an actual device (Neffos x9 or so, v7 architecture I believe).

The eglConfigChooser() call was not requesting depth (or stencil) bits, although it seems some drivers are generous.

These modifications let you ask for a depth buffer and it will modify that request accordingly.

At the moment this is a simple "I want it", in which case it gives you a 16-bit depth buffer. (If you request a stencil buffer, which will be 8 bits, it will also throw the 16-bit depth buffer in, since these always seem to go hand-in-hand.)

Perhaps some refinement could follow later, e.g. for 24-bit depth, although it would probably have to query for capabilities or pixel formats.

The options are "wantsDepthBuffer" and "wantsStencilBuffer", which you can provide in build.settings like so:

	android =
	{
		applicationChildElements = {
			[[<meta-data android:name="wantsDepthBuffer" android:value="true" />]]
		}
	}

This gave me appropriate on-device results with that setting and without it.

I haven't run into the same need on Windows, Mac, iOS, or tvOS in my tests (these last two in their respective emulators), but they'd call for something similar if it should arise.

TODO?

I wasn't sure if I could trip those code paths that pass false, false when constructing fView and fCoronaRuntime.

@ggcrunchy ggcrunchy requested a review from Shchvova as a code owner April 23, 2023 01:05
@Shchvova Shchvova merged commit c9206e2 into coronalabs:experimental Jun 27, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@Shchvova Shchvova Shchvova approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@ggcrunchy @Shchvova
0