Re: Horizons on winex - problem with addsmooth?

>> These happened when using texture shaders that contained
>> "addsmooth"
>
>I thought "addsmooth" was part of the standard fixed-function
>multitexture blend operation set, not part of texture
shaders. We don't
>support texture shaders yet, so I'm guessing perhaps that's
what you
>meant.
>
I am probably using the wrong terms, the addsmooth was in
*.sha files in the games texture directories that are used for
displaying certain effects.


>> Is addsmooth supported by winex? What open GL call does it
become?
>
>Very badly. WineX does not even tell games that it supports
it, because
>it's not known to work reliably yet. In unextended OpenGL, it
becomes
>GL_BLEND with caveats. With ARB_texture_env_combine, it becomes
>GL_INTERPOLATE_EXT. Both of these GL operations need the
texture factor
>to be "hijacked" (it's normally used for the d3d texture
constant) in
>order to work the way ADDSMOOTH is defined, and at this time, the
>validate_tex_stage code still won't validate that correctly.
>
>Techically ADDSMOOTH can also be done without the texture
factor with
>NV_texture_env_combine4, but the code does not give preferential
>treatment to NV_texture_env_combine4 at this time.

So changing the addsmooth to add within the game files is more
likely to be the best way of dealing with this? (since this
method does seem to work)



>> Either way why would parsing a file that uses it report a
>> memory access violation?
>
>I'm not quite sure what you mean.

Following the games debug logs it starts to "parse" its term a
given .sha file which contains the addsmooth, the game then
crashes and its crash log says the crash was caused by a
memory access violation. I dont know why it decides this is
the case as only the game devs have the tools to read the dumps.