The latest SVN bugs thread

[Mel]

To test floating point textures, i started messing with the render to texture example, and i came across a bug.

Setting in Example 13 the render to texture to something like this

rt = driver->addRenderTargetTexture(core::dimension2d<u32>(256,256), "RTT1",video::ECF_R32F);

Using OPEN GL, the mouse doesn't update the camera, in DX9C the mouse works well. Or at least, no in an unexpected way.

This is the output, and the resulting render.





I had the SVN updated in August 25th.

[BlindSide]

To test floating point textures, i started messing with the render to texture example, and i came across a bug.

Thanks for your bug report Mel. I tested the example in OpenGL and I could not reproduce this bug. The RTT correctly showed a red fairy against a black background (Red because the RTT format you chose only writes to the red channel). The D3D9 example shows a white fairy against a cyan background because D3D9 seems to clear unwritten channels to white where as OpenGL clears them to black.

Perhaps it works for me because my console displays:

Using renderer: OpenGL 3.1.0

Where as yours:

Using renderer: OpenGL 2.1.2

Can you double check that you have the latest drivers from NVidia?

[Mel]

Uops! i also forgot to mention that i recompiled the engine to have 8 textures per material. When i compiled it, also, it gave me some warnings in the DX driver which had to do with the texture stages above the 3rd which weren't treated or the like. Maybe that is something to check also.

Edit: I updated the drivers, and now the example run in OpenGL 3.1.0 and runs perfect, though i think that the failure of a texture shouldn't mess the cameras too.

[BlindSide]

though i think that the failure of a texture shouldn't mess the cameras too.

I couldn't reproduce the camera issue. I'm also running Windows XP so its probably not an OS issue.

[Mel]

Hmm, is probably an unhandled pointer in the example (perhaps) so who knows? but an unhandled pointer shouldn't affect the camera. IMO, Don't know. I compiled it straight. (stripping symbols to reduce the final DLL, and stuff... but still)

[kaos]

I can to see the corners of one skybox( last svn )

[hybrid]

Since you didn't say in which example I assume it happens when your skybox is loaded from a .irr file. This happens due to the lack of texture creation flag serialization. You can manually change the textureLOD of the skybox to avoid this later on.

[randomMesh]

Latest trunk doesn't compile on my machine (Ubuntu 10.4 64 bit, g++ 4.4.3).

Code: Select all

g++ -Wall -pipe -fno-exceptions -fno-rtti -fstrict-aliasing -fexpensive-optimizations -O3 -I../../include -Izlib -Ijpeglib -Ilibpng -I/usr/X11R6/include -DIRRLICHT_EXPORTS=1  -c -o CImageLoaderDDS.o CImageLoaderDDS.cpp
CImageLoaderDDS.cpp: In function ‘irr::s32 irr::video::DDSGetInfo(irr::video::ddsBuffer*, irr::s32*, irr::s32*, irr::video::eDDSPixelFormat*)’:
CImageLoaderDDS.cpp:77: warning: dereferencing type-punned pointer will break strict-aliasing rules
CImageLoaderDDS.cpp: In function ‘void irr::video::DDSDecodeAlpha3BitLinear(irr::u32*, irr::video::ddsAlphaBlock3BitLinear*, irr::s32, irr::u32)’:
CImageLoaderDDS.cpp:335: warning: dereferencing type-punned pointer will break strict-aliasing rules
CImageLoaderDDS.cpp:354: warning: dereferencing type-punned pointer will break strict-aliasing rules
CImageLoaderDDS.cpp: In function ‘irr::s32 irr::video::DDSDecompressDXT1(irr::video::ddsBuffer*, irr::s32, irr::s32, irr::u8*)’:
CImageLoaderDDS.cpp:421: error: cast from ‘irr::u8*’ to ‘irr::u32’ loses precision
CImageLoaderDDS.cpp: In function ‘irr::s32 irr::video::DDSDecompressDXT3(irr::video::ddsBuffer*, irr::s32, irr::s32, irr::u8*)’:
CImageLoaderDDS.cpp:467: error: cast from ‘irr::u8*’ to ‘irr::u32’ loses precision
CImageLoaderDDS.cpp: In function ‘irr::s32 irr::video::DDSDecompressDXT5(irr::video::ddsBuffer*, irr::s32, irr::s32, irr::u8*)’:
CImageLoaderDDS.cpp:522: error: cast from ‘irr::u8*’ to ‘irr::u32’ loses precision
make: *** [CImageLoaderDDS.o] Fehler 1

[CuteAlien]

Hm, probably a problem with 64-bit. I think casting to u32 (or int) is wrong there for pointer-arithmetic. Should probably be casted to unsigned long.

I just wanted to test it, but found while doing so another problem - the file-open dialog no longer works (at least on Linux) as it's no longer possible to change the path (and so I couldn't open the dds now quick for a test). Guess I will look on that problem first. But too late today already as I have to work tomorow, so will have to wait until weekend.

[CuteAlien]

I couldn't figure out how to fix the DDS-loader, so I disabled it by default now. Probably better not enabling it by default anyway, because I think users have to be rather careful about patent-violations when they use that loader in the USA (that's the reason all those open-source app's don't support DDS).

[hybrid]

I think this only applies to DDS compression, not decompression.

[CuteAlien]

Doesn't seem so to me, although I'm not able to completely understand the language in which patents are written. It's sad how bad the US-patent system is when it comes to software, but well, if users want to ignore it, it's now just a single define to enable. And I think it's better to warn them. It rather sucks to find out after you finished a project that you broke a well-known patent accidentally.

[anchor]

DDS decompression? I'm very disappointed
A real DDS loader would be nice...

[CuteAlien]

It is a real DDS loader, so you should be happy. It just contains DDS decompression which could be a problem. There had been another patch-proposal for a DDS-loader in the past (which needed a few more changes to the texture-interface, but worked quite well). But I no longer remember if that allowed the usage of compressed texture in the hardware drivers - which would for most people probably the most useful thing (and would to my knowledge not be a patent-problem as the card-vendors would be responsible in that case). Anyway - it's another feature/problem. For this thread I mostly cared that svn should compile without errors. If anyone further improves DDS that's probably fine with everyone.

[anchor]

Thank You! Very good!
I'm using Nardo's DDS patch with Irr 1.7.1. without any errors.

http://irrlicht.sourceforge.net/phpBB2/ ... hp?t=33552