DBG(Colour(0xffffffff).getARGB());
currently writes ☐ into the console.
only writing 0xffffffff into dbg writes -1 for some reason.
seems like a bug to me, because that usually has put out the colour’s argb-value as uint32
It’s not getARGB() that is causing, it’s type is uint32, the problem, it is DBG. . numeric constants (0xffffffff) are signed, unless cast to unsigned, thus you see the -1. But, you would have to dig into DBG to see what it is not displaying a uint32 correctly. Make it easy on yourself and do DBG(String(Colour(0xffffffff).getARGB()));
no, it’s not because of DBG. you see a friend told me that he tried to use jlimit to keep a value between 0 and the maximum colour and then jlimit asserted that the maximum was below minimum. i told my friend that it can’t be but then tried it myself and it’s true. so the problem really has to come from that function getARGB.
edit: or maybe uint32 is just broken atm for some reason. idk.
Can you post the code, when you got that assert? We cannot dissect hearsay…
If you feed an already overflowed value to jlimit, it cannot work.
If you want to limit a uint32 to the values of uint32, it is already too late, the overflow already happened.
If you type your numbers, they default to int. To get unsigned numbers, you need to suffix the number with u. See cpp-reference: integer_literal
your jlimit with 0xffffffff will be signed, to get an unsigned you need 0xffffffffu.
But note, if you limit after your calculation to the allowed range of thevariables type, it is pointless: the information of the overflow was truncated already.
you can easily recreate the problem by writing something like this:
auto a = jlimit(0, int(0xffffffff), 34545);
0xffffffff is unsigned int by default so making that an int is supposed to make it a valid argument of jlimit, but then it suddenly claims it’d below the limit (0). how is that possible for a value that was just casted from a uint? also it makes no sense, because 0xffffffff is supposed to be the max value of uint32
Your problem is that you cast the 0xffffffff to int. and in int all bits set is -1.
What you actually wanted to write is
auto a = jlimit(0u, 0xffffffff, 34545u);
ok that works. but to be honest. it’s 0:28am in here and i think my brain doesn’t work at 100% anymore atm so maybe i’m talking shit now… but i could swear this was different just recently! i mean i worked a lot with colours and i needed to get maxValue so often. i always just used getARGB and it let me debug normally. something must have changed there that makes this so complicated now… or i’m stupid now. idk. but i understand your argument why it would work like that, so i guess it’s an improvement of some sort. it just confused me
wait a minute guys! this still makes no sense. why would i use jlimit if i wanted everything to cast to uint? i mean think of it. if my lower limit is 0 then i obviously do that because the value i want to be limited can get below 0. if i cast to uint then it would glitch out on that value before even going into jlimit. we need 0xffffffff to be int, just like it was before
That’s what I wrote two posts up, probably phrased it a bit complicated.
Maybe explain, what you want to achieve with jlimit? Where is the number coming from? What type is it?
my friend just tries to compare 2 colours with each other by subtracting one value from the other. ofc that could create negaive values and he just wants to keep it between 0 and max. and i’m really sure that even though i’m a bit wasted atm it always worked by getting int(Colour(0xffffffff).getARGB()). i know we were talking about that in the discord lately but i forgot which method just easily returns the size of some value type, or else i’d just tell him that, but my method also worked… until now, and i don’t understand why
compare with subtraction? what’s wrong with ==?
when i say compare i mean subtract them with each other. i just mean we want 2 colours to interact.
i mean really… how does it even remotely make sense that something that was casted from uint can result in -1? i can’t understand it. and i don’t see what the solution is supposed to be. we can’t always work with uint when we get the argb values from some colour. that’s annoying for a lot of calculations. something really weird happened here.
Ok, were getting closer.
If you subtract the numbers, you should do that per component. The overflow will go into the next component.
If you want to use low level numerics, you can do so with shift and bool operators. But you can also use the getRed(), getGreen() and getBlue() methods (strongly recommend).
And the difference between two colours is not necessarily a colour. You have seen, that the difference can produce negative numbers. You have to specify, what the result should be.
I guess, what you want is:
auto d = Colour (a.getRed() > b.getRed ? a.getRed() - b.getRed() : 0,
a.getGreen() > b.getGreen ? a.getGreen() - b.getGreen() : 0,
a.getBlue() > b.getBlue ? a.getBlue() - b.getBlue() : 0
if you cast a unsigned value into a signed value, and if it is beyond the max of the signed value, it becomes negative, because of how sign values work, ie. they use the most significant bit to indicate they are negative. just some basic computer science. 
1 Like
but isn’t the normal int a lot bigger than uint32? also why did it work before and now it doesn’t? was it wrong a week ago and it’s fixed now and i just learned it wrong or what?
i don’t understand your code. i know this ? creates something like an if-statement but i haven’t looked into that yet
and i use rgb split into 3 values a lot for my calculations, yes. but sometimes i just want the whole colour to be in only one number and i am just sure that it worked like that all the time
roughly… but actually -1 is the bool negate of 0, hence 0xffffffff. That is so incrementing can continue using the same bool operations. (0xffffffffff + 1 = 0x0).
The signed int takes the same number of its like the unsigned int. Therefore it can hold half the amount of distinct values positive, and the other half negative.
The code checks, which one’s bigger, before it subtracts. Because once the subtraction happened, you don’t know any more, if your calculation was legit, because the overflow already happened.
It was executing without complaining and the errors were not noticeable. But logic tells, that the overflow in one component will spill into other values. It was maybe good enough, but it was not correct.
i see. so your solution would be to make this check like that instead of casting anything to a signed type and using jlimit then. looks terrible and complicated tbh, but i guess this is the solution now. i think i’ll go to bed now. btw i’m very grateful about your help but i think there is no one who can help me about my anger now which comes from the fact that i try to fix getting a number from a colour for hours while i actually wanted to work on stuff. this really messed me up. you can’t imagine how i feel now 
holy shit. no. this day needs to end. good night