Android make_color_hsv all shades of blue

Erayd

Member
Pretty much in the title. For whatever reason, that method only returns different values of blue no matter what I put in, no matter how I blend, no matter how I draw. However if I use just their value like c_red, then it draws and blends perfectly in to that color. I'm using values between 255 and 0 and I get them from colorpicker. As well, if I make the color instead using hex code in the format $c40600 then what I get back should be red, however I get blue again. But when I put the hex code in for green, 007f0e, I get a light green color as intended. So thats being wonky as well.

Code:
part_Draw_Color = make_color_hsv(359, 98, 79);
The above should net me red, but it doesnt. I get a weird blue, but if I change it to c_red, its red... I'm confused.

This is my draw code, it is currently just overlaying a rectangle however before this I was using draw_sprite_ext and using the color option to blend the new color on top of a purely white sprite. I was having the exact same issue
Code:
draw_set_color(color);
draw_rectangle(x, y, x + sprite_width, y + sprite_height, false);
Also as a note, the reason why the variable used to store the color is different is because I'm passing it from the sprite that is dying to the particle being generated. The goal is to create particles with custom coloring depending on what blows up.
 
Last edited:
I'm assuming by the name of the variable you are storing it in that you're trying to colorize a particle. Is the sprite for that particle white? If it's not, then the color will end up being a combination of the sprite's color and the one you try to blend it with. The reason why you are seeing results with red is just likely coincidence, as red seems to be an easy color to blend to accurately regardless of the original color. Apologies if I'm way off in my assumptions!
 

Erayd

Member
I just updated the original post with a bit more info. It is a perfectly white sprite of size 1 pixel, so blending really shouldn't be a problem. I even tried changing the blend mode to additive and that did nothing.
 

TheouAegis

Member
359 isn't a valid value. All values must be between 0 and 255. The reason you're getting a blue is because 359 & 255 = 103. Draw 2 rectangles side by side using your code, but replace 359 with 103 in the other one. You'll see you're getting the same values.
 

Erayd

Member
Ok that's simple, can't believe I didn't see it. But that doesn't explain why I'm not getting the correct output from a hex code. The color picker shows me green but game maker shows me blue.

I can't believe I lost two hours on such a simple mistake...
 

TheouAegis

Member
Show me a screenshot of the color picker. GM's color picker or another program's color picker? I read somewhere that HSV has different results depending on the program.
 

Erayd

Member
I actually changed to just a simple make_color_rgb because it's just easier than converting to a 255 sized value which my main drawing programs do not use, they use a percentage. This would be the website I use for the colorpicker, if you input this into game maker and get red then great, I messed something up in my travels and I will move on knowing that their color making code is still sound.
upload_2016-9-8_20-29-4.png
 

TheouAegis

Member
Okay, so it's based on a color circle/cone/sphere/whatever on that site. So Hue is {0...359} based on the degrees in the circle. Saturation and whatever brightness are both percentages {0...100}.

Now, HSB and HSV and HSL are all slightly different, so there will be SOME discrepancies. Anyway, it's pretty simple to convert to GM's values.

h = 255 * H/359
s = 255 * S/100
v = 255 * B/100

And since you can't use decimal values in either one, ColorPicker.com gives you 3,672,360 colors to choose from, but GM gives you 16,777,216 colors. So GM clearly has the better scheme between the two, you just have to learn to work with it.

Also i noticed GM is a bit brighter than ColorPicker.
 

Erayd

Member
Thank you tons for your color knowledge, I think I'll stick to RGB values, those tend to be easier to set up and get consistency from, plus its not a super graphically intensive game so it's not big deal.
 
Top