Horde3D

If I remember rightly, horde uses BGR instead of RGB for its texture formats right? I seem to recall that from reading the code. Please correct me if I'm wrong here. I'm trying to remember where I changed some shader code to a different format so figuring out the trail of RGB/BGR conversions.

I'd look at the repo logs, but I changed to mercurial after the move to RGB, now my models come up blueish

Ah, its coming back to me. Is it libjpg or libpng that was messed with a bit to return BGR textures? I ask because I think I'm using a different version and thats why I'm getting some strange colours.

The conversion to BGR(A) is done within utImage.cpp where all loaders (JPEG, PNG, ...) convert STBI's RGB(A) data to BGR(A).
Of course you could do the swizzle later.
Don't know if it applies to you: but at some point we added another library (SFML windowing, graphics, input toolkit similar to GLFW, but allowing for several windows) - and this comes with its own STBI implementation. At runtime (as we used shared objects), horde's utImage picked up the wrong symbol, e.g. stbi_load_image from the unmodified SFML library and all our textures were messed up as well, because the unmodified STBI utImage.cpp does not convert textures to BGRA.

Yeah, same issue. Thanks for the heads up. I'll take a look and merge the diffs.

Slightly off topic, but any idea why Horde does the swizzle itself, rather than letting OpenGL do it?

_________________
Tristam MacDonald - [swiftcoding]

Good question.

Interestingly enough, I just added another format TextureFormats::RGBA8 and fed it through to egTexture and it failed to work properly in RendererBase uploadTextureData (which I modified to read the format and keep both internal and input formats as RGBA8.

Everything was black. Weird.

I'd like to come up with a better way of fixing this though. The problem is that I have another version of stbi as was mentioned before (I'm using SFML also, which uses STBI via SOIL). So rather than knobbling stbi with a swizzle, I'd prefer to do it in the OpenGL end. Otherwise SFML loaded textures will come out strange (because they dont expect the swizzle in stbi).

Any thoughts?

Actually Alex, how did you guys fix this? I might as well do the same thing.

I sort of got around it by hacking utImage.cpp in the ES test branch, it is safe to copy & replace the mainline if you want to do RGBA.

_________________
-Alex
Website

Well, we got around the problem using link re-ordering as far as I remember.
As we do not want to use SFML texture loading code anyway, this works for us. But it will fail if we plan to load textures through both Horde and SFML as one or the other will mix textures up.
I think Horde changed some parts of the stbi, so I think I'd stay with that.
To me, I think it is SFML's fault to expose the internal stbi symbols, that should be kept inside.
But changing SFML might be tedious (there is already a nasty static GLcontext creation going on on MODULE linker loading time when static symbols get initialized), so the easiest fix is certainly:
Put the stbi symbols from horde inside a namespace, so they cannot be mixed up with symbols outside the library. I think I'll give this a try tomorrow, as linking order is always a bit nasty too.

BTW: I heard people might have problems with interoperability of SFML and Horde, e.g. overlays or sprites in SFML not working. It is a good idea to save/restore GL render state before calling h3dInit and h3dRender.

Hmm, I'd rather not have two versions of the STBI stuff linked in. Seems a bit silly to do that. I would have thought the best bet would be to add RGBA8 and allow the loader to load that format and then do the format swizzling in the GL driver.

Marciano: what was the reason for doing the colour swizzle on load from STBI anyway?

I'll have a play with this tommorow. Been ill for a few days so dont feel too keen right now

I agree, having almost duplicate code is not so fancy, but using 3rd party libs this will often be the case, without even knowing, as symbols are hidden/not exported.
For us it was not worth combining SFML and Horde, as the minimal namespace fix did quite well.
I guess the reason for BGRA8 was simply speed, as texture uploads are/used to be faster that way, but may be negligible.

BGRA is the native memory layout on PC for 8 bit textures (mainly because of Windows), everything else will force some swizzling and overhead in the driver. Using the native format is essential for dynamic texture upload performance. Originally we used BGRA only for dynamic uploads (when using mapResourceStream) and RGBA for loading from stbi but that was changed for consistency (and that small performance advantage which is not essential at load-time though).

Regarding symbol visibility. Horde exports only the public API functions but if some other lib does not hide internal symbols, you can get problems of course. To avoid this, I guess it makes sense that we wrap everything into a namespace.

Yeah, I see that makes sense. I guess the best bet is to wrap the horde STBI in a namespace then.