The latest SVN bugs thread

[hybrid]

Argh, I just started to fix this to the common init scheme... So I will overwrite this commit then later on. I also have a dx8 enabled system at home, but only use this seldomly. So I encounter those problems only from time to time.
Regarding the matrix warnings: Where do you get them? My compiles are always without any warning.

[hybrid]

Ok, blind fix without knowing whether any typos have occured. I may have some time tonight to test it, otherwise please just report if anything still fails. Have been several changes now.

[greenya]

When i run 10.Shaders example, pick D3D9 renderer, choose "yes" to use high level shaders, i get console flooded with the message

Error setting int array for HLSL variable

But all rendered seems correct.

P.S.: with OpenGL there is no such problem. I see rev. 4130 change, there was removed test

Code: Select all

if(driver->getDriverType() == video::EDT_OPENGL)

I don't know what is correct, the only i believe that error message flood shouldn't be in SDK example

[hybrid]

Guess we need to wait for Nadro on this one. I thought that the shader interface for texture setting was unified across all hl shaders now.

[greenya]

Regarding the matrix warnings: Where do you get them? My compiles are always without any warning.

Well, you don't see them since you don't use them in code -- the code which uses them should be compiled (not skipped).
If you search entire solution (Irrlicht and examples) for using of setRotationAxisRadiansLH() or setRotationAxisRadiansRH() you will get only interface and implementation in matrix4.h (2 lines). Nothing calls them. I believe that is why compiler skips implementation, so no warning until actual code which calls them has been met. When i compile my wrapper, which wraps (and actually uses in code) these methods, all warnings pops up.

For test case, you can just enter next code after "main(){" in 01.HelloWorld example:

Code: Select all

        f32 f(0.5f);
        vector3df v(1, 2, 3);
 
        matrix4 m;
        m.setRotationAxisRadiansLH(f, v); // this line gives 9 warnings
        m.setRotationAxisRadiansRH(f, v); // this line gives 9 more warnings

P.S.: i think, maybe it would be good practice when if any new method added, it should be used (explicitly called from some test code, and this test should be compiled to see all warnings). The code may even not work, i mean we can pass null pointer to some method, just for compiler to compile it, we don't need to run this code.

[hybrid]

We usually have a lot of such test methods in our test suite. But not yet all are covered. So I just wanted to make sure that you're not dealing with some double calculations around those methods.

[Nadro]

@greenya
Thanks for a report. I'll check today what is wrong.

I thought that the shader interface for texture setting was unified across all hl shaders now.

Yes, thats true.

[Nadro]

@greenya
I fixed this issue. Binding textures in OGL works different than in D3D9. In OGL we should bind a textures by setUniform method called from in C++ code, but in D3D9 we should use register(sX) where X correspond to a texture index from a SetTexture method called in C++ code. When we have only one texture registers isn't needed.

BTW. Maybe we should add overload of method setVertexShaderConstant for ITexture params? This function will be empty for D3D9, but I think that it will be more intuitive than current int interface and the same application code will work for both D3D9 and OGL. What do You think about it?

[CuteAlien]

Hm, I'm still not really into shaders, but having all shader-functions so far in a single interface was rather nice for a start. It allows seeing with one look what is possible. I don't thinking moving just one function into another class will make things easier to find.

[hybrid]

No, the idea is to have another overload. Right now we have setVertexShaderConstant for float arrays and integer arrays. As e.g. used in the example

Code: Select all

services->setPixelShaderConstant("myTexture", &TextureLayerID, 1);

Since OpenGL requires the texture numbers to be set (to the proper texture names, which we don't know, at least not the order to use) with a call as shown before. This one sets texture layer given by the variable to the shader sampler myTexture. For D3D, this setting happens automatically, as the textures are assigned consecutively to the shader variables.
The suggestion is to have a third overload, taking a texture pointer instead of an integer. With the call above, we cannot know if the number is used for a texture sampler, or just some parameter for render options. With a texture pointer, nothing else could be done, so we can provide the implementations as required.
But I guess we can simply check for the object type of the parameter, and ignore setting the texture sampler numbers. We could even check if the user keeps the correct order here, and warn if samplers would be used in a different way.

[Nadro]

Hmmm, so for a D3D9 we have to ignore this combination:
IntInterface + ValuesCount=1
but it may be also something else than a texture bind call. Maybe last BOOL parameter with default value set to TRUE will be good solution?

Code: Select all

bool setVertexShaderConstant(const c8* name, const s32* ints, int count, bool isTexture = true)
{
        if(isTexture)
        {
                // set a texture or skip call in D3D9
        }
        else
        {
                // old behaviour
        }
}

If we don't want a BOOL parameter we can also read setVertexShaderConstant call as a texture bind call when "count" param will be equal to 0. Personally I think that a second solution is nicer.

[hybrid]

No, we can query the type of the shader attribute, and if it's a sampler id we can ignore it.

[Nadro]

Fact, Your solution is better

BTW. We have to add a cache for uniform locations (something similar for attributes cache from shader-pipeline branch), because calls like extGlGetUniformLocation are expensive.

[hendu]

In COpenGLExtensionHandler.h:2326, shouldn't the AMD branch be "else if"? Otherwise irr sets the same thing twice

Also applies to 1.7, if this is correct.

Code: Select all

--- a/source/Irrlicht/COpenGLExtensionHandler.h
+++ b/source/Irrlicht/COpenGLExtensionHandler.h
@@ -1786,7 +1786,7 @@ inline void COpenGLExtensionHandler::extGlBlendFuncIndexed(GLuint buf, GLenum
 #ifdef _IRR_OPENGL_USE_EXTPOINTER_
        if (FeatureAvailable[IRR_ARB_draw_buffers_blend] && pGlBlendFunciARB)
                pGlBlendFunciARB(buf, src, dst);
-       if (FeatureAvailable[IRR_AMD_draw_buffers_blend] && pGlBlendFuncIndexedAMD)
+       else if (FeatureAvailable[IRR_AMD_draw_buffers_blend] && pGlBlendFuncIndexedAMD)
                pGlBlendFuncIndexedAMD(buf, src, dst);
 #elif defined(GL_ARB_draw_buffers_blend)
        glBlendFunciARB(buf, src, dst);
 

[Nadro]

Thanks for a report. Fixed in latest trunk