Drawing with transparency and inconsistency of Instructions

[komame]

What I would like to discuss here is something I initially wanted to report in the bug tracker. However, after some thought, I realized that it's not a bug but rather a certain inconsistency that is difficult for me to accept because it contradicts the principles of good programming.

In most graphics drawing instructions, you can use transparency. The [color] parameter appears in almost all of these instructions (sometimes more than once, as the instruction operates with multiple colors), and you can define it in several ways:

- a HEX number in the format #AARRGGBB, where 'AA' represents the level of transparency. For example, PIXON_P(10,10,#80AABBCC) // alpha = 128 (HEX: 80);
- the RGB(R,G,B,A) instruction, where the parameter A indicates the level of transparency. For example, PIXON_P(10,10,RGB(255,0,0,128)) // alpha = 128;
- a list with color as the first element and the transparency level as the second element, such as {#FF0000, 128} or {RGB(255,0,0), 128}.

A transparency value set to 0 means complete opacity, while a value of 255 means full transparency.
The following instructions work in the manner described above:
- PIXON(_P)
- LINE(_P)
- RECT(_P)
- ARC(_P)

Since a color and transparency level can be specified as RGB(A,R,G,B) and alternately as a list {color, alpha}, why was the alpha parameter added as the second element of the list? This leads to inconsistency because if the color has its own alpha, and you specify alpha as the second element in the list, two different alphas can coexist. It's not entirely clear which of these alpha levels the program author wants to use.

Furthermore, there are two instructions where color is not used, but a separate alpha parameter is included. These instructions are:
TRIANGLE(_P)
BLIT(_P)

In these cases, there is also an inconsistency. In TRIANGLE(_P), a value of 0 for alpha means full opacity, and 255 means full transparency (as in the previous instructions). However, if you attempt to use BLIT(_P), these values are reversed, meaning 0 means full transparency, and 255 means full opacity.

Additionally, despite having a color parameter, the TEXTOUT(_P) instruction does not support transparency (it ignores the alpha value).

Furthermore, the FILLPOLY(_P) instruction, in addition to the [color] parameter (which can be a list), has a separate, independent [alpha] parameter. This creates three possible ways to assign alpha levels within a single instruction!
FILLPOLY_P({10, 10, 50, 10, 30, 50}, {RGB(255, 255, 255, alpha), alpha}, alpha);

Such inconsistencies in graphic instructions can be very frustrating, and I don't understand them at all. When creating new instructions, some standards should be maintained.

In my opinion, it would be better to get rid of the {color, alpha} list syntax and keep only the direct color parameter, which already allows transparency to be defined directly using HEX values (#AARRGGBB) or the RGB(R,G,B,A) instruction. Additionally, for BLIT(_P), the values should be reversed (0=>255, 255=>0) to make them consistent with the other instructions.

Of course, this can slightly affect existing PPL programs that used transparency in the form of a list (in the other cases, there will be no issue). However, it is known that such programs will be easy to fix, and I have the impression that these will mainly be games, and only a few of them.

Returning to the topic of reporting this in the bug tracker, I personally consider this an issue and would like to report it for improvement. However, I would first like to hear your opinion on this matter.

Is it worth unifying and doing it "properly," or should we leave it as it is?

Thanks.