Author Topic: Who has a Mac? I'd like to debug #431: Magic Pink not Transparent  (Read 200 times)

0 Members and 1 Guest are viewing this topic.

Online Simon

  • Administrator
  • Posts: 3488
    • View Profile
    • Lix
Hi,

In 2022, naymapl and cameo69 reported:
github #431: Magic pink won't become transparent on macOS (both Intel and ARM64)
I'd like to debug this, but I don't have a Mac. Thus:

Who has a Mac? Would you like to compile and run Lix on it, and are you up for some testing?

I'll walk you through everything. I'll answer all of your questions. No need to hurry: It's okay if you can spare a few hours here and there. It's okay if you take several days off before you can test a new theory that I'll get.

Let's see if the bug still manifests in 2023. Since naymapl's and cameo69's reportings, has been at least one new release of Allegro 5, Lix's graphics library, and it's possible that the bug is already gone. And if the bug reproduces on your Mac, I'll create some minimal example programs for you to try, to see if the bug is in Lix or in Allegro 5.

-- Simon

Offline Dullstar

  • Posts: 2046
    • View Profile
    • Leafwing Studios Website (EXTREMELY OUTDATED)
Re: Who has a Mac? I'd like to debug #431: Magic Pink not Transparent
« Reply #1 on: January 23, 2023, 10:44:39 AM »
If you can't find anyone who has one and is willing to test, I *do* have an old one, but there's a reasonably high chance that it's much too old, especially considering Apple's record regarding backwards compatibility (for reference, I believe it's on Snow Leopard). Feel free to reach out if you want me to try anyway, but definitely wait at least a week for other people to respond. Because it's so old that compatibility for the relevant software could very feasibly be a major issue, I will not try to set it up unless you explicitly ask me specifically to try it.



That said, my hunch is that it's probably an Allegro bug, though I am aware of at least one way to make an Allegro application that runs properly in Linux but not Windows (but still compiles on both), so it's not infeasible that there could be another mac-related issue. I once made something on my Linux machine while my Windows one was broken (hardware issue), and once I got the parts to get the Windows one working again, it turned out the Windows version didn't work because there was a missing addon init function call (I think it was al_init_primitives_addon). On Linux it didn't matter, at least not for what I was doing, but on Windows it turned out to be important. I doubt it's what's happening here, but I can produce a minimal example of it if you want (and/or possibly look for other combinations with similar effects). In any case, while I highly doubt one of them could have been missing this long without getting noticed, it could be worth double checking, since the library doesn't seem to define what should happen if you try to use things without calling those initialization functions first.

Online Simon

  • Administrator
  • Posts: 3488
    • View Profile
    • Lix
Re: Who has a Mac? I'd like to debug #431: Magic Pink not Transparent
« Reply #2 on: January 24, 2023, 09:56:56 PM »
Thanks for the offer! Right, let's see if others have a more recent Mac.

I've looked at the source, and it looks like I call the al_init_* before creating color constants and before creating the A5 display. The calls are in src/basics/init.d: al_init_image_addon(); al_init_font_addon(); al_init_ttf_addon(); al_init_primitives_addon();

The bug report suggests wrong colorings after al_convert_mask_to_alpha that also gets called after the al_init_*; it looks like that function failed to recognize the magic pink in the images. I have further recoloring with handwritten pixel-by-pixel code with al_get_pixel, al_put_pixel, e.g., to replace the greyscale GUI icons with the GUI hues based on user's options. Those handwritten recolorings (in src/graphic/recol.d, here be dragons) also appear to fail. The screenshots on github have grey icons on the GUI buttons, not pale blue icons.

I'm not 100 % sure with the ordering of the various calls other than that the al_init_* are called early. Reducing Lix or having minimal A5 examples still looks helpful.

-- Simon
« Last Edit: January 24, 2023, 10:02:25 PM by Simon »

Online Simon

  • Administrator
  • Posts: 3488
    • View Profile
    • Lix
Re: Who has a Mac? I'd like to debug #431: Magic Pink not Transparent
« Reply #3 on: January 24, 2023, 10:17:32 PM »
Digging around the cutting edge A5 source of al_convert_mask_to_alpha: This function is OS-independent, and it is, like my handwritten Lix recoloring, a high-level pixel-by-pixel loop.


One possible method of attack: Investigate how C memcmp can fail to recognize two pixel structs as identical even though both are pink. A5 color structs contain 4 floats without padding:

typedef struct ALLEGRO_COLOR ALLEGRO_COLOR;
struct ALLEGRO_COLOR
{
   float r, g, b, a;
};


Now, for IEEE floats, the C language considers +0 == −0 when we compare them with ==, but memcmp(+0, −0) will not consider them equal. (Perhaps even +1 won't memcmp-equal some other representation of +1, but I doubt it.) Then memcmp will fail. I'll ask on A5 what they think about memcmp here. Comparing floats with equality is a can of worms in general, I have no good immediate fix to offer.



I don't want to scare away other Mac users with technicialities. Who has a Mac? :lix-grin:

-- Simon
« Last Edit: January 24, 2023, 10:44:51 PM by Simon »

Offline Dullstar

  • Posts: 2046
    • View Profile
    • Leafwing Studios Website (EXTREMELY OUTDATED)
Re: Who has a Mac? I'd like to debug #431: Magic Pink not Transparent
« Reply #4 on: January 25, 2023, 02:19:42 AM »
Does the C standard say anything about padding, i.e. is the compiler allowed to insert whatever padding it wants? If so it could explain a system dependent memcmp result discrepency.

Online Simon

  • Administrator
  • Posts: 3488
    • View Profile
    • Lix
Re: Who has a Mac? I'd like to debug #431: Magic Pink not Transparent
« Reply #5 on: January 25, 2023, 09:56:55 PM »
Padding in a struct of only floats: When I read the C11 standard on structs, it looks like it allows padding between any two members, and at the end, but not at the beginning. Nonetheless, in practice, the floats will be packed without any padding, like an array of 4 floats.

Yesterday, I've written a custom version of al_convert_mask_to_alpha and asked the Mac users in the github issue to try that. I'll see if anything comes up.

In Allgero's IRC channel, nobody can tell for sure if −0 is a valid color component within 0 and 1. I'd like to see what comes back from the Mac testing before I possibly open a pull request to change the memcmp to four ==.

-- Simon
« Last Edit: January 25, 2023, 10:02:39 PM by Simon »