Page 2 of 28
Posted: Wed Aug 26, 2009 10:12 am
by 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.
Posted: Mon Aug 31, 2009 10:43 am
by BlindSide
Mel wrote: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?
Posted: Mon Aug 31, 2009 9:42 pm
by 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.
Posted: Tue Sep 01, 2009 10:19 am
by BlindSide
Mel wrote: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.
Posted: Tue Sep 01, 2009 12:11 pm
by 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)
Posted: Mon Jan 25, 2010 4:10 pm
by kaos
I can to see the corners of one skybox( last svn )
Posted: Mon Jan 25, 2010 4:33 pm
by 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.
Posted: Thu Jul 15, 2010 5:55 pm
by 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
Posted: Thu Jul 15, 2010 11:20 pm
by 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.
Posted: Fri Jul 16, 2010 9:50 pm
by 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).
Posted: Sat Jul 17, 2010 2:35 pm
by hybrid
I think this only applies to DDS compression, not decompression.
Posted: Sat Jul 17, 2010 3:51 pm
by 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.
Posted: Sat Jul 17, 2010 6:24 pm
by anchor
DDS decompression? I'm very disappointed
A real DDS loader would be nice...
Posted: Sat Jul 17, 2010 6:38 pm
by 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.
Posted: Sun Jul 18, 2010 3:45 pm
by 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