fix: ysgl uniform type/value mismatches (sampler unit, fogEnabled, textureSampleCoeff) - #12
Open
tomingtoming wants to merge 1 commit into
Open
Conversation
…xtureSampleCoeff) Three glUniform calls disagree with the shader-side declarations. On a conforming GL they raise an error and the assignment is dropped (or lands on an arbitrary target), so they only work because the intended value happens to coincide with what the uniform ends up holding: - ysglslbitmaprenderer.c RenderTexture2D: the sampler uniform was set to the texture object id (samplerIdent) instead of the texture-unit index. Depending on the id's value the call is either rejected (GL_INVALID_VALUE, uniform keeps its initial value 0 -- the unit all callers actually bind) or accepted and points the sampler at whatever unit shares that number. On WebGL this rendered every text bitmap (in-flight messages, console lines) as a solid black box. - ysglsl3ddrawing.c YsGLSL3DRendererInitializeUniform: fogEnabled is a float in every shader but was initialized with glUniform1i (GL_INVALID_OPERATION, dropped; the runtime setter YsGLSLSet3DRendererUniformFogEnabled already uses glUniform1f). - ysglsl3ddrawing.c YsGLSL3DRendererInitializeUniform: textureSampleCoeff is a vec3 but was initialized with glUniform1f (GL_INVALID_OPERATION, dropped; the runtime setter in YsGLSLSet3DRendererTextureType already uses glUniform3fv). No intended behavior change on desktop GL -- the fixes assign the same values the uniforms already held -- but the phantom GL errors disappear and stricter implementations (WebGL) render correctly. Measured on a desktop Linux gl2.0 build of YSFLIGHT (boot -> free flight): 16 GL errors from these call sites before, 0 after; in-flight message text renders identically. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WuRxGPB4xoPDLzUBGdw5Fe
tomingtoming
force-pushed
the
upstream-fix/ysgl-uniform-types
branch
from
August 13, 2026 09:17
4bbe9e7 to
6881656
Compare
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
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
glUniformcalls in ysgl disagree with the shader-side declarations. On a conforming GL each one raises an error and the assignment is dropped (or lands on an arbitrary target), so they only work because the intended value happens to coincide with what the uniform ends up holding:ysglslbitmaprenderer.cRenderTexture2D— the sampler uniform was set to the texture object id (samplerIdent) instead of the texture-unit index. Depending on the id's value the call is either rejected (GL_INVALID_VALUE, uniform keeps its initial value 0 — the unit all callers actually bind) or accepted and points the sampler at whatever unit shares that number. On WebGL this rendered every text bitmap (in-flight messages, console lines) as a solid black box. YSFLIGHT's own callers already treat the parameter as unit 0 —ysscenerygl2.0.cpppasses0with the comment// 0 for GL_TEXTURE0 apparently.ysglsl3ddrawing.cYsGLSL3DRendererInitializeUniform—fogEnabledis afloatin every shader but was initialized withglUniform1i(GL_INVALID_OPERATION, dropped). The runtime setterYsGLSLSet3DRendererUniformFogEnabledalready usesglUniform1f; this makes the init site match it.ysglsl3ddrawing.cYsGLSL3DRendererInitializeUniform—textureSampleCoeffis avec3but was initialized withglUniform1f(GL_INVALID_OPERATION, dropped). The runtime path inYsGLSLSet3DRendererTextureTypealready usesglUniform3fv.No intended behavior change on desktop GL — the fixes assign the same values the uniforms already held by accident — but the phantom GL errors disappear, and stricter implementations (WebGL) render correctly.
Verification (desktop Linux, gl2.0 build of YSFLIGHT)
Interposed
glUniform1i/glUniform1fwith anLD_PRELOADshim that callsglGetError()after each real call, then ran the same scenario (boot →-freeflight→ in-flight message) on binaries built from currentmastervs.master+ this commit:glUniform1ion the floatfogEnabledinits, 5×glUniform1fon the vec3textureSampleCoeffinits, allGL_INVALID_OPERATION)In-flight message text (the bitmap-renderer path of fix 1) renders identically before and after.
Found while porting YSFLIGHT to WebAssembly (ysflight-web), where fix 1 was the difference between readable messages and black boxes. Related YSFLIGHT-side fixes: captainys/YSFLIGHT#7, captainys/YSFLIGHT#8. As with those, no hurry at all!