Supermodel Forum

No joy. I get the same errors and behavior as with texture2DLod but now the error just says textureLod instead.

So I went ahead and also try with texture2D instead and now it works!
Not sure if the change is right tough or if the function is really equivalent because graphs quality looks better with the legacy 3D engine which is bit surprising (either that or just that the Intel GPU is under-powered althoughI didn’t observed any slowdowns while testing).

Also I found this while researching. Could it be connected somehow?

https://github.com/godotengine/godot/is ... -456917312
https://www.reddit.com/r/Amd/comments/h ... &context=3

“It uses const at places for non constant values, uses texture2DLod in a glsl 120 fragment shader (which is not allowed without requesting a glsl 130 profile, as the 120 spec does restrict that function to vertex shaders).”

I mean that some extensions or profiles need to be enabled for some platforms/drivers like mesa on Linux?

First link is opengl es which has nothing to do with desktop gl
The issue is mesa gl on Linux. Windows drivers don't have this issue.

Lastly using simply the texture function will give you the wrong result.

Ian wrote:First link is opengl es which has nothing to do with desktop gl
The issue is mesa gl on Linux. Windows drivers don't have this issue.

Lastly using simply the texture function will give you the wrong result.

Thanks for clarifying clearly this is all new to me.

I will try to learn more and in the meantime keep using the legacy engine.

Thanks

After doing some more research I found a workaround to this issue without any code changes.

Setting the environment variable force_glsl_extensions_warn=true when launching Supermodel makes texture2DLod errors go away and the game renders just fine using the new 3D engine. No slowdowns or anything. Just a warning: ATTENTION: default value of option force_glsl_extensions_warn overridden by environment.

Code: Select all

Supermodel: A Sega Model 3 Arcade Emulator (Version 0.3a-WIP)
Copyright 2003-2022 by The Supermodel Team
ATTENTION: default value of option force_glsl_extensions_warn overridden by environment.
    Title:          Daytona USA 2 - Battle on the Edge (Japan, Revision A)
    ROM Set:        daytona2
    Developer:      Sega
    Year:           1998
    Stepping:       2.1
    Extra Hardware: Digital Sound Board (Type DSB2), Drive Board, Net Board, Security Board


According to what I found in the Internet, force_glsl_extensions_warn: let the program use extensions without asking, but warn on use.

In case anyone find this in the future the command line to start Supermodel should look like this:

Code: Select all

force_glsl_extensions_warn=true <path_to_supermodel_binary> <path_to_rom> <additional_options>


Having said that, I may be wrong because this is all new to me but it seems that on mesa/Linux OpenGL extensions needs to be enable explicitly from the code in order to use texture2DLod function and if not requested by the code they will not be enabled, causing the errors and rendering issues.

This comment I found in an ancient mesa bug report may be interesting and more meaningful for you guys than what I can try to explain with my lack of knownledge on this matter: https://bugs.freedesktop.org/show_bug.cgi?id=43477#c6

1. Specifying #version 130 (it doesn't, so it gets 110, which is mandatory spec behavior)

So I went ahead and replaced #version 120 with #version 130 in line 6 of Src/Graphics/New3D/R3DShaderTriangles.h and recompiled supermodel.
With this change in place now the texture2DLod errors are gone but the issue is not completely solved as I'm getting a new error:

Code: Select all

error: fragment shader lacks main


And no 3D graphs rendered. In this scenario, using the workaround mentioned above, also makes everything works fine.

I will keep looking into this and sorry for the long post but I thought this information may be useful for you and other users finding this issue.

Thanks.

Finally solved it!

I missed another occurrence of #version 120 on line 64 of Graphics/New3D/R3DShaderTriangles.h.
Replaced it with #version 130 as well and recompiled.
Now all errors are gone and 3D graphs are rendered correctly!
I only tested Daytona 2 for a few minutes but everything seems to be fine so far.

Not sure if other shader files for the new 3D engine needs to be changed as well. For example effects used by other games that Daytona doesn't utilize.
I guess I will get errors in supermodel output and at least I now know how to approach the troubleshooting.

Any chance you can consider changing this in the code if only when compiling for mesa/Linux?

Thanks.

Someone should file a bug report with MESA or whoever is responsible for opengl drivers on linux. They probably don't even know this bug exists and they are missing this function.

Ian wrote:Someone should file a bug report with MESA or whoever is responsible for opengl drivers on linux. They probably don't even know this bug exists and they are missing this function.

I wouldn't mind to do that to be honest, but I will need more specific technical details to do so (I'm not familiar at all with OpenGL standards, etc.) and probably won't be able to sustain a discussion about it because of the lack of knowledge.

So for me to better understand, the function should be available in version 120 (GL 2.1) and requesting version 130 (GL3.0) shouldn't be necessary, right?
The function is there, because either requesting version 130 or allowing extensions with version 120 works fine.

I guess in the meantime the environment variable can be used without changing any code.

https://registry.khronos.org/OpenGL/spe ... c.1.20.pdf
page 64 in the spec

All these should be supported

vec4 texture2D (sampler2D sampler, vec2 coord [, float bias] )
vec4 texture2DProj (sampler2D sampler, vec3 coord [, float bias] )
vec4 texture2DProj (sampler2D sampler, vec4 coord [, float bias] )
vec4 texture2DLod (sampler2D sampler, vec2 coord, float lod)
vec4 texture2DProjLod (sampler2D sampler, vec3 coord, float lod)
vec4 texture2DProjLod (sampler2D sampler, vec4 coord, float lod)

texture2DLod is the one we are missing

Ian wrote:https://registry.khronos.org/OpenGL/specs/gl/GLSLangSpec.1.20.pdf
page 64 in the spec

All these should be supported

vec4 texture2D (sampler2D sampler, vec2 coord [, float bias] )
vec4 texture2DProj (sampler2D sampler, vec3 coord [, float bias] )
vec4 texture2DProj (sampler2D sampler, vec4 coord [, float bias] )
vec4 texture2DLod (sampler2D sampler, vec2 coord, float lod)
vec4 texture2DProjLod (sampler2D sampler, vec3 coord, float lod)
vec4 texture2DProjLod (sampler2D sampler, vec4 coord, float lod)

texture2DLod is the one we are missing

Thanks for pointing me to this document Ian.
I was going through it and found something confusing that I would like to confirm with you since I as already mentioned this is all new to me.

The triangles shader is a fragment or vertex shader? From the errors I saw while troubleshooting this I believe is a fragment shader.
Can you confirm?

I'm asking because on page 63 right before the table of functions the document states the following:

The built-ins suffixed with “Lod” are allowed only in a vertex shader

So according to the specs texture2DLod is not allowed on a fragment shader and maybe this is the reason why mesa is not allowing it unless explicitly using the environment variable to allow extensions usage but warn about it.

What do you think?

Thanks!

Man, that might actually be correct. I don't know why they would impose that limitation. Almost no one uses texture lookup in the vertex shader anyway.

Even apple allows the lod functions in the fragment shader.

Hm.