[Feature] Lighting #51
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Just ran some tests on my 3ds vs emulation, I'm seeing some colour banding, though I'm not sure if that's an issue or a side effect of something else? Emulation (Lime3ds): My 3ds: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This adds support for the lighting API.
It's a bit rough, I don't currently have a 3ds to test it on but the pre-rebase version is used as part of our bevy 3ds port so I'm pretty confident it works alright.
It does have an example which should render a rotating purple cube with specular lighting, again I can only test this in emulation right now.
The implementation is... complex. The citro3d internals here are a minefield of backpointers, the wrapper makes liberal use of
Pinto try and avoid allocating where possible (the user is of course free to putLightEnvon the heap if they don't want to deal with the mess) as well as faithfully portraying the semantics of the C API.The way to actually use it is a bit convoluted, basically you should use
light_env_mutonInstance, technically you should be able tomem::swapon that and it'll bind a differentLightEnv, I'm not sure how or if this should be a part of the documented API.Note this currently does NOT include spotlight support, it only supports point lights.