Introduce IMGUI_USE_BGRA_PACKED_COLOR in imconfig.h.

[thedmd]

PR was recreated due to lost references after changing fork origin. That was not my intention, sorry.
For comments please look at previous PR.

PR adds ability to tell ImGui to generate packed color in BGRA format instead of RGBA.
This change simplify backend implementation by removing need to convert colors in vertex buffer before uploading to engine. For ImGui packing colors differently make no difference and backend can use memcpy().

To change color packing uncomment #define IMGUI_USE_BGRA_PACKED_COLOR in imconfig.h

What changes. Hardcoded bit shifts were replaced by constants like IM_COL32_R_SHIFT. Depending of IMGUI_USE_BGRA_PACKED_COLOR being defined constants have different values.

[ocornut]

Merged, thanks. Sorry for the late reaction.

I'm particularly eager to tidy up the inconsistent handling of colors (ImVec4 or U32) and a little cautious around those areas.

[Flix01]

Not sure if this is appropriate (I still have to understand if old code is backward-compatible with this PR). However the question is:
Should we need to change "old" lines like:

if ((col >> 24) == 0) {...}

or not ?
They are quite common in imgui_draw.cpp AFAIR.

[ocornut]

Yes we should..

[thedmd]

Old code will work since in both cases alpha occupy same bits.
Test for transparency can be moved to function/macro to remove dependency from color format. I can do that if you don't have time.

[ocornut]

Ah you are right, alpha hasn't moved. So it's not urgent/important.
I am thinking adding IM_COL32_A_MASK so the end-user code stays obvious.

Just #define IM_COL32_A_MASK 0xFF000000 in the blocks to make it trivial.
Correct-er would be say (ImU32)((1LL << (IM_COL32_A_SHIFT+8))-1)
But it might be leading to some subtle compiler annoyance with integer sizes, I don't mind just having 0xFF000000 as a literal.

I can do it, it's easy.

[ocornut]

Done.

[ocornut]

@thedmd I am curious: if you are using this, are you able to also use functions such as ColorEdit4() ? How do you encode your user/app-side colors that may need authoring using imgui tools? Are they encoded the same way as your renderer packed color values?

[thedmd]

@ocornut I'm using this mode in our engine, since I'm stuck with a variant of fixed pipeline compatibility layer where I can pick what vertex buffer is build from but do not have precise control over format. Using BGRA allows me to just memcpy vertex data to our vertex buffer.

User code never touches render code directly. Instead it operate on high level primitives like Image or Text where color is set using our version of ImColor structure.

ImGui works as usual. Including ColorEdit4() where our color can be used directly. When dealing with draw lists colors are converted using ImColor() or stated explicitly using IM_COL32() macro. Raw values are never used.

Does that answer to your question?

[ocornut]

Hmm I guess my question didn't entirely make sense, since currently ColorEdit4 cannot take a U32 value.
Do you store your CPU-side colors as U32 or Float4 ?

What I am wondering is, if people store U32 colors in their game objects and they want to edit them, would they necessarily be in the same format as the U32 colors for rendering?

[thedmd]

I'm using floats. They are lingua franca in color world.

If game object choose packed format over floats edit code can unpack it prior to calling ColorEdit4() and repack if changed.
Handling packing by ColorEdit4() would be covinient, but not necessary since there are many ways to define packed format (RGB545, RGBA4444, etc) and no enum will cover them all.

I think if game object store color in packed format and it is very same ImGui use it is a convinient coincidence rather than desired behavior.