Re: [PATCH 1/1] wined3d: Introduce a helper function for printing floats in GLSL shaders.

[Stefan Dösinger]

Am 11.06.2013 um 09:27 schrieb Henri Verbeet:
> We always want to use '.' as decimal separator in GLSL, instead of the locale
> specific one. Reported on IRC.

I think this should be added as a code comment above shader_glsl_ftoa, I don't think the reason why we need our own conversion function is obvious.

The ARB shader backend will need this as well, but I can take care of this. What external software triggers this behavior?
>                     case WINED3D_DATA_FLOAT:
> -
>                        sprintf(register_name, "%.8e", *(const float *)reg->immconst_data);
> -
>                        shader_glsl_ftoa(*(const float *)reg->immconst_data, register_name);
>                       break;

shader_glsl_ftoa doesn't handle inf or nan. I assume that's intentional because they would only trigger a parser error.

[PATCH 1/1] wined3d: Introduce a helper function for printing floats in GLSL shaders.

[Henri Verbeet]

On 11 June 2013 09:52, Stefan Dösinger  wrote:
> I think this should be added as a code comment above shader_glsl_ftoa, I
> don't think the reason why we need our own conversion function is obvious.

I originally considered adding a comment, but figured it was obvious
enough from being in the context of GLSL shader generation. I don't
feel particularly strongly about it though, so I can add it again if
it helps.
> The ARB shader backend will need this as well, but I can take care of this.
> What external software triggers this behavior?

I'm not sure, this was reported on IRC. But you can easily reproduce
it by e.g. adding setlocale(LC_ALL, ""); to wined3d_dll_init() and
running the tests with an appropriate locale set.
> shader_glsl_ftoa doesn't handle inf or nan. I assume that's intentional
> because they would only trigger a parser error.

Yeah, inf and nan aren't really meaningful here. If we really wanted
to it would only be a couple of extra lines though.