Sean (Jul 02 2026 at 20:57): Sean (Jul 02 2026 at 20:57):@starseeker I really don't like the color.h deprecation/changes at all... those helpers are primarily to make code easier to read, and that change will do the complete opposite.
pixel[RED] = 12; pixel[BLU] = 23; pixel[GRN] = 34;
vs
pixel[BU_COLOR_INDEX_RED] = 12; pixel[BU_COLOR_INDEX_BLU] = 23; pixel[BU_COLOR_INDEX_GRN] = 34;
code went from being a subtly self-documenting to the macros themselves utterly dominating the expressions. and sheer chore of dealing with them.
Sean (Jul 02 2026 at 20:59):it's not like they've not conflicted before. often it's other codes doing the exact same define. we just address the conflict as needed and move on. every so often we have to undef them before/after an include or something, but not really something dwelled on or worth expanding like that.
Sean (Jul 02 2026 at 21:02):our convenience is way more important than worrying about system headers. if there was some fundamental unavoidable conflict (which would be a first in 50 years), I'd try a char or drop them altogether before expanding out 18 chars to indicate a 0/1/2 value.
Sean (Jul 02 2026 at 21:09):the only reason we need them at all is because some pixel encodings are RGB, some are BGR, so the defines make it clear to anyone what we're doing without them having to take the time to find out.
Sean (Jul 02 2026 at 21:09):that and alpha channels make it complicated
starseeker (Jul 04 2026 at 11:23):Here's another idea (which I'll check with you first this time ;-) ) I think what prompted that was an undef complicating something in a unity build with headed include rework, so rather than renaming away from RED what if we encapsulate the necessary voodoo to make us locally independent of any system RED/GRN/BLU defines - something along the lines of:
_BU_RGB_DEFS_BEGIN
our code here...
_BU_RGB_DEFS_END
That way we would have a succinct way to guarantee what we need locally no matter what the system includes do, and we could avoid any unity build issues because we wouldn't have to worry about bu/colors.h being included somewhere else and our undef RED being out of order for avoiding the system conflict. That might even let us avoid the toplevel RED et. al. defines completely, but I don't really have a strong opinion about that. Thoughts?
Sean (Jul 08 2026 at 18:10):if it's system induced, we could just ifdef/undef in common.h
Sean (Jul 08 2026 at 18:16):maybe but still adds some overhead on our part to maintain. I guess I'd really want to see whatever new error that can't be resolved before adding some wrapper baggage everywhere we use the color defines.
they're in hundreds of files and have survived decades. seems like there's an easier solution to fix whatever issue pops up new given how rare there has been an issue. could be header order is wrong, could be common.h could undo some damage, could be a simple undef, etc..
starseeker (Jul 09 2026 at 00:26):All right - I think I got a localized minimal fix in the one place it was giving me trouble, so I'll leave it alone.
starseeker (Jul 09 2026 at 00:29):I think what was happening was something in the unity included color.h earlier, that set the guard for color.h being included, then the file in question did the undef, and when we would have been counting on color.h include to define it again via stand-alone file include we didn't get it because it had already been included earlier due to unity bundling. An ifndef check covers it for the one problem case.
Last updated: Jul 25 2026 at 01:46 UTC