Lock() Texture bug due to video card limitation to 256*256 ?

[3dsolar]

Hello,
Lock a texture in memory can be a nice feature but we found a limitation, many video card limit the lock() function to 256*256 texture size, do you know a turnaround to this problem as we need to lock a 512*512 (320*240) texture size!
Thanks

[vitek]

What graphics card? What driver version?

Travis

[3dsolar]

Works on ATI radeon 9000 and Geforce 6600 GT but fail on : GForce 4 7600, ATI radeon X2300, ATI Mobility Radeon x2300
So the only turn around so far we found its to lock two textures of 256*256 and merge them togehter.

Patrick

[hybrid]

With OpenGL or D3D? And still missing: The driver versions.
However, I doubt that any of those cards has such limited texture support. You might be doing something wrong.

[3dsolar]

we are in D3D Directx9

[3dsolar]

prm.DriverType = E_DRIVER_TYPE(4); (DirectX)

ITexture* g_tex = 0; // DL3D: Webcam frame

// Then

// Remove camera frame texture
_irDriver->removeTexture( g_tex );

// Then

// Create webcam frame texture if it doesn't already exists
if( g_tex == 0 )
g_tex = _irDriver->addTexture( dimension2d<s32>( 320, 240 ), "T1", ECF_R5G6B5 ); // ECF_A8R8G8B8 ECF_R5G6B5 ECF_R8G8B8

ITexture* tex = g_tex;

// Source data
u8 *psrc = (u8*)pSrc->pData;

// Lock and get texture data
u8 *pdest = (u8*)tex->lock();

// Update texture data
for( u32 y=0; y<240; y++ )
{
for( u32 x=0; x<320; x++ )
{
int i = y * 320 + x;

// BGR -> RGB conversion
pdest[ i * 4 + 0 ] = psrc[ i * 3 + 0 ]; // B
pdest[ i * 4 + 1 ] = psrc[ i * 3 + 1 ]; // G
pdest[ i * 4 + 2 ] = psrc[ i * 3 + 2 ]; // R
pdest[ i * 4 + 3 ] = 1.0; // A
}
}
// Release texture data
tex->unlock();


Thats it and we init

[hybrid]

Try to create a power-of-two texture (i.e. create the 512x512 texture) and lock it. And note that you have to make the proper byte conversions for the chosen format. R5G6B5 is a two byte format, while your code does 4 byte steps per pixel. There are several color format conversion methods available in CColorConverter.cpp from which you can choose (they are not exposed to the user under win32 systems, though).

[3dsolar]

Thanks we will try your way even if we found a turn around by locking 2 textures of 256*256, do you know if the lock() function is also available in Irrlicht with OpenGL ?

[hybrid]

The only thing that you cannot lock ATM is OpenGL RTT (because the contents does not get copied back into the CPU memory). But ordinary textures are lockable.

[3dsolar]

When we use a 512*512 textutre then no errors but no result texture stay empty maybe we dont update well pixels, any idea ?

[Dorth]

Soon Irrlicht should have the dropping of images from ram. When that come, a function to re-import them from gpu would be nice. And if that's there, then the rtt limitation will no longer be there ^^

[hybrid]

Besides that this statement does not help at all in this context, the two things you mentioned (dropping the image held and locking RTT) are not related at all. You can lock the RTT without a permanently stored image and you could lock the RTT into the stored image. However, it's simply not implemented (and you have to take care to make it efficient).

[BlindSide]

For performance reasons, a function to request just one pixel from the image would be great. Sometimes you only need to read a pixel or two from an RTT and you end up having to download the whole thing.

[hybrid]

Yes, that's true. But then you'd somehow know if onyl one or two pixels are requested, or if someone tries to read the whole image pixel by pixel. I'll try to add some more methods from IImage to ITexture, as long as it gives an efficient implementation for it... Later

[3dsolar]

any idea why our texture if 512*512 stay empty ?