[Suggestion] ITexture::lock() and data size

[Mloren]

When you call ITexture::lock() it returns a void* to the pixel data, but it doesn't give any indication of the size of that data. Now while you can probably use getColorFormat() and getSize() to work this out, it still feels a little unsafe to me.

If I use these functions to calculate data size, I feel like I'm making an assumption about the internal workings and a dangerous one.

I assume this is the correct approach but it would probably be better if lock() output a data size through an int* parameter or something so you could be sure of the size.

[hybrid]

Why would you know the size if an int* is returned? While the number of pixels is easily calculated, returning an int* would fail in many situations (e.g. 16bit textures).
A safer way would be to return an IImage*, which would require another lock inturn, though, which would return the void* again. But it would allow to pass more information along.
A much better way would be access via some SColor* type, which transparently handles the access. This is more or less already possible, via setPixel. But it's not really efficient. Moreover, all these changes would require heavy rework of the internals of images and textures, so it won't happen before Irrlicht 2.0 probably.

[slavik262]

I think he's asking if you could pass a parameter in which the function would set to the number of bytes, i.e.

Code: Select all

virtual void* lock (bool readOnly, u32 mipmapLevel, u32* numBytesOut)


However, Mloren: getPitch() * getSize().Height will get you the total number of bytes, and is perfectly safe. The pitch is the number of bytes per row, so multiplying it by the height of the texture will get the exact number of bytes in that texture.

[hybrid]

Oh yeah, sorry, I skipped over one of the 'size's in the last sentence.

[Mloren]

ok thanks