What about 16-bit textures and different subpixelformats?

[ShiftZ]

Hi Eddie,
Currenly Im working on PVR texture image codec module and there is a little problem.
PVR may contain 16bit and 32bit textures with different sub-pixel formats: 5551 4444 565 and others.
However, render modules can "eat" only RGBA8888 \ RGB888 pixel formats, there is simply no apropritate argument in OpenGLTexture::loadFromMemory for sub-pixel format. Cross-render-API unification??
Possible solution is to do conversion from "any sub-pixel format" to RBGA8888 in place. But it's not the best way, since there also will be compressed texture formats which must stay compressed (GPU supported), and as im going to write my own OpenGL ES render module, i want my OpenGLES_Texture::loadFromMemory to know if a pointed block of memory is actually compressed texture or not. (And simply i dont know how to do that conversion that could be a amount of work)
What im trying to say, maybe if you could make texture loading more flexible somehow. What i need is sub-pixel format definition and more about pixel-format (compression format).
Donot know about DX9\10 but OpenGL can make textures with all kinds of sub-pixel formats.
PS How DX fans is feeling without their DXTC? =)

[CrazyEddie]

I acknowledge this as a current limitation in the system. I also acknowledge that you are probably not alone in thinking this as an issue (though I don't recall it coming up previously).

For the main CEGUI::Renderer and CEGUI::Texture interfaces, the functions do need to remain totally independent as far as the underlying APIs go, however there is no reason that API specific overloads or what have you could not be provided. You could also pre-create the underlying texture and 'wrap' that existing texture in a CEGUI::Texture afterwards (that might be a 0.7.0 only thing, can't remember).

I'm not certain of the implications of any of this since I've never given it any thought.

CE.

[ShiftZ]

You could also pre-create the underlying texture and 'wrap' that existing texture in a CEGUI::Texture afterwards (that might be a 0.7.0 only thing, can't remember).

What you meant by that? i didn't get it exactly.
You mean avoid somehow loadFromMemory()?

PS in perfect, it would be nice to see pvr support in CEGUILayoutEditor.

[CrazyEddie]

Yes, the current trunk (to be 0.7.0) code allows you to pre-create the texture and wrap it with a CEGUI::Texture afterwards, avoiding the loadFromMemory function. Obviously this is not entirely flexible, and perhaps there are improvements we can make in that area in the future. Again, I've not looked into the implications of actually doing this, so I'm not sure of the issues that will no doubt arise

CE.

[ShiftZ]

Another problem - how can i make two codecs working together? I want pvr to be suppported as well as other common image formats.

[CrazyEddie]

You can't use more than one ImageCodec at the same time. You'd need to provide an ImageCodec implementation that supports the formats you need.

CE.

[Jamarr]

could you make a custom ImageCodec that filters based on the image type, and then delegate the loading to an ImageCodec actually designed for that format?

[ShiftZ]

could you make a custom ImageCodec that filters based on the image type, and then delegate the loading to an ImageCodec actually designed for that format?

That is what im thinking too. Looks not too difficult.

Also, here is another problem, pvr container has different pixel store sequence format, When i load pvr image it looks flipped.
Now i wonder how would i manage all these image loading limitation. =\ I was hoping that i could manage that without scalpel and scissors.
Maybe it's possible to pass some addittional renderer-independed information. As OpenGL has its glPixelStore, DX and others should have same ability i suppose. No?

[ShiftZ]

Just founded that i was mistaken about pixel store sequence format. Forgot to uncheck corresponding option in PVR texture converter.