Make three GLES 3 paths reachable - #825
Open
Pitchoune wants to merge 3 commits into
Open
Conversation
Four glsm wrappers are guarded by HAVE_OPENGLES_3, which nothing defines. Makefile.common passes -DHAVE_OPENGLES3, without the underscore, and that is what the other 79 sites in the tree test. On a GLES build the four bodies were therefore compiled out and the wrappers returned without doing anything: glClearBufferfv, glClearBufferfi, glGetStringi and glRenderbufferStorageMultisample were silently dead. The parentheses only make the existing precedence explicit: && already bound tighter than ||, so the four conditions are unchanged apart from the macro name. The colour clear is the one that shows: GLideN64 clears frame buffers through rglClearBufferfv, so buffers kept whatever was in them. Rayman 2 drew its logo over the previous frame instead of black, and South Park left the old image behind on a resolution change. All four are core in GLES 3.0, so testing HAVE_OPENGLES3 is enough. HAVE_OPENGLES_3_1 and HAVE_OPENGLES_3_2 are left alone deliberately - they guard entry points a plain GLES 3.0 context need not provide, and they are equally undefined here, so those wrappers stay inert on purpose rather than by accident.
The option is read on every build but declared only on desktop GL, so on GLES it never appears in the core options and the value read is always the default. What N64 depth compare needs is shader image load/store, which is core in GLES 3.1. The guard also covered EnableShadersStorage; keep it around that one alone. Only reachability changes - the default stays False.
Config.h numbers the modes dcDisable = 0, dcFast = 1, dcCompatible = 2. update_variables() assigned 1 for both "Compatible" and "True", so the two settings did the same thing and the compatible path could not be selected from the core options at all.
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Three small fixes for code that a GLES build compiles but never reaches.
Six lines changed in total. Found on a Raspberry Pi 5 (GLES 3.1).
1. glsm's GLES 3.0 wrappers are gated on a macro nothing defines
Four wrappers test
HAVE_OPENGLES_3.Makefile.commonpasses-DHAVE_OPENGLES3, without the underscore, and that is what the other 79sites in the tree test.
glClearBufferfv,glClearBufferfi,glGetStringiand
glRenderbufferStorageMultisamplewere therefore silently dead on GLES.The colour clear is the one that shows: GLideN64 clears frame buffers through
rglClearBufferfv, so buffers kept whatever was in them. Rayman 2 drew itslogo over the previous frame instead of black, and South Park left the old
image behind on a resolution change.
All four are core in GLES 3.0.
HAVE_OPENGLES_3_1andHAVE_OPENGLES_3_2are deliberately left alone: they guard entry points a plain GLES 3.0 context
need not provide.
2. N64 depth compare is read on GLES but not declared
The read lost its guard already; the declaration kept it, so the option never
appears in the core options on GLES and the value read is always the default.
What it needs is shader image load/store, core in GLES 3.1.
3. "Compatible" selected Fast
Config.hnumbers the modesdcDisable = 0,dcFast = 1,dcCompatible = 2.update_variables()assigned 1 for both "Compatible" and"True", so the compatible path could not be selected at all.
Defaults are unchanged throughout; only reachability and one value differ.