Page 9 of 27
Re: The latest SVN bugs thread
Posted: Tue Jun 26, 2012 12:22 pm
by 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.
Re: The latest SVN bugs thread
Posted: Tue Jun 26, 2012 12:40 pm
by 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.
Re: The latest SVN bugs thread
Posted: Tue Jun 26, 2012 2:24 pm
by 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
Re: The latest SVN bugs thread
Posted: Tue Jun 26, 2012 2:28 pm
by 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.
Re: The latest SVN bugs thread
Posted: Tue Jun 26, 2012 3:02 pm
by greenya
hybrid wrote: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.
Re: The latest SVN bugs thread
Posted: Tue Jun 26, 2012 3:10 pm
by 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.
Re: The latest SVN bugs thread
Posted: Wed Jun 27, 2012 10:55 am
by 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.
Re: The latest SVN bugs thread
Posted: Thu Jun 28, 2012 11:55 pm
by 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?
Re: The latest SVN bugs thread
Posted: Fri Jun 29, 2012 8:03 am
by 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.
Re: The latest SVN bugs thread
Posted: Fri Jun 29, 2012 8:22 am
by 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.
Re: The latest SVN bugs thread
Posted: Fri Jun 29, 2012 12:14 pm
by 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.
Re: The latest SVN bugs thread
Posted: Fri Jun 29, 2012 12:17 pm
by hybrid
No, we can query the type of the shader attribute, and if it's a sampler id we can ignore it.
Re: The latest SVN bugs thread
Posted: Fri Jun 29, 2012 12:37 pm
by 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.
Re: The latest SVN bugs thread
Posted: Sun Jul 01, 2012 2:52 pm
by 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);
Re: The latest SVN bugs thread
Posted: Sun Jul 01, 2012 5:15 pm
by Nadro
Thanks for a report. Fixed in latest trunk