• Hello [name]! Thanks for joining the GMC. Before making any posts in the Tech Support forum, can we suggest you read the forum rules? These are simple guidelines that we ask you to follow so that you can get the best help possible for your issue.

Legacy GM Particles Wrong Color

This is the code I'm using, note the c_yellow built-in color for the particles

Code:
 ///Shoot it Down
 //Shoot it down
 if position_meeting(mouse_x, mouse_y, id)and mouse_check_button_pressed (mb_left){
 instance_destroy(self);
 score += 1;
 Control.Duck_1 = false;
 effect_create_above(ef_explosion, x, y, 1, c_yellow);
 }
but when I'm getting is blue



Same with a lot of the colors rendering as random shades of blue instead of what they're supposed to be. To make it even more bizarre black renders as black just fine when I try c_black.
 
If I remember correctly, in one of the last versions of GMS 1.4, the colour order was switched (I believe inadvertantly, as in its a bug). So instead of colours being RGB, they were GRB for example. There are other posts on this forum you can search for that mention this.

So to build c_yellow, you would need to use one of the make_colour functions, but swap the appropriate channels around.

Here's one of the posts that mentioned it:
https://forum.yoyogames.com/index.p...99-released-feedback.52292/page-3#post-325874
 
If I remember correctly, in one of the last versions of GMS 1.4, the colour order was switched (I believe inadvertantly, as in its a bug). So instead of colours being RGB, they were GRB for example. There are other posts on this forum you can search for that mention this.

So to build c_yellow, you would need to use one of the make_colour functions, but swap the appropriate channels around.

Here's one of the posts that mentioned it:
https://forum.yoyogames.com/index.p...99-released-feedback.52292/page-3#post-325874
That kind of sucks and it seems like fixing that monumental screw-up would count as one of the vital bug-fixes they promised they'd keep doing for GMS1.

Has anyone made a third-party fix/patch to repair the color system?
 

TsukaYuriko

☄️
Forum Staff
Moderator
The code in question has less to do with the particle system than with binary arithmetic.

It swaps the red and blue channels of an input color so that it's reordered from RGB to BGR depending on the target platform, as this issue only seems present for some of them.

Or, to be more specific:
It extracts the bytes of the input (for example, 112233 -> 11, 22 and 33).
They are then padded to become stand-alone three-byte values that are in RGB order but only contain the value of one of the color channels (example: 000011, 002200, 330000).
Finally, they are ORed together bitwise in reverse order so the three separate channels add up to a single value that contains them all again (example: 330000 | 002200 | 000011 -> 332211, because n | 0 = n).
 
Here's an example of what it's doing, but using Game Makers built-in colour functions (and not as concise, and without the os type check):

Code:
/// get_fixed_colour(original_colour)
/// returns fixed colour

var _original_colour = argument0

// Extract separate colour components
var _red = colour_get_red(_original_colour);
var _green = colour_get_green(_original_colour);
var _blue = colour_get_blue(_original_colour);

// Make a new colour - but with red and blue swapped - normally we would pass in the args as (red, green, blue), to swap
// we pass them in as (blue, green, red)
var _fixed_colour  = make_colour_rgb(_blue, _green, _red);

return _fixed_colour;
 
Here's an example of what it's doing, but using Game Makers built-in colour functions (and not as concise, and without the os type check):

Code:
/// get_fixed_colour(original_colour)
/// returns fixed colour

var _original_colour = argument0

// Extract separate colour components
var _red = colour_get_red(_original_colour);
var _green = colour_get_green(_original_colour);
var _blue = colour_get_blue(_original_colour);

// Make a new colour - but with red and blue swapped - normally we would pass in the args as (red, green, blue), to swap
// we pass them in as (blue, green, red)
var _fixed_colour  = make_colour_rgb(_blue, _green, _red);

return _fixed_colour;
Good lord

Does just using custom colors with hex codes work around it or is that screwed up and requires the long-from fix clogging up the code as well?

Side note: why do you put underscores at the start of your variable names? That's something I've seen in GML before.
 

TsukaYuriko

☄️
Forum Staff
Moderator
No, there is no technical difference between decimal and hexadecimal representation of colors, but make_color_* functions should return the correct format.

FrostyCat's script is anything but clogging up the code, it's a one-liner that replaces the broken function call.


I'm not the one the question was addressed at, but my reasoning seems to be identical: I prefix local variables with underscores to tell them apart from instance variables more easily.
 
Does just using custom colors with hex codes work around it or is that screwed up and requires the long-from fix clogging up the code as well?
You can manually write the hex codes into your game if you wish, just swap the red and blue values. I feel its not as convenient as using a function to do it though. In GMS 1.4.9999 case, it won't be being updated, so perhaps won't apply. But if a future update were to fix it, you'd have to manually go through and change every line where you hard-coded the colour.

Side note: why do you put underscores at the start of your variable names? That's something I've seen in GML before.
@TsukaYuriko is right. It's a coding convention to make it easier to see which variables are temporary to the script.
 
No, there is no technical difference between decimal and hexadecimal representation of colors, but make_color_* functions should return the correct format.

FrostyCat's script is anything but clogging up the code, it's a one-liner that replaces the broken function call.


I'm not the one the question was addressed at, but my reasoning seems to be identical: I prefix local variables with underscores to tell them apart from instance variables more easily.
It's not that much all it's own since it's plug in the c_color to get the correct color assigned to variable to plug into the effect code but when you have to call that before use of a particle effect it can get cumbersome

One more thing though, what does calling the argument at the beginning do? Or is the c_color supposed to be places there so the use of original_color below calls that color code?
 

TsukaYuriko

☄️
Forum Staff
Moderator
It's not that much all it's own since it's plug in the c_color to get the correct color assigned to variable to plug into the effect code but when you have to call that before use of a particle effect it can get cumbersome
I was talking about FrostyCat's script, which you call instead of the function you'd normally use to create a particle effect. Not the script that was posted in this topic.

One more thing though, what does calling the argument at the beginning do? Or is the c_color supposed to be places there so the use of original_color below calls that color code?
I'm unsure what you mean by "calling the argument". Do you mean this line?
Code:
var _original_colour = argument0
If so, it stores the value of the first argument in _original_colour so that said variable can then be used in the script. The alternative to this would be to use argument0 in its place throughout the script, which, when you have more than one argument, especially if they're of unrelated types, can get rather messy very quickly. A variable with a descriptive name eliminates this risk of confusion.
 
I was talking about FrostyCat's script, which you call instead of the function you'd normally use to create a particle effect. Not the script that was posted in this topic.



I'm unsure what you mean by "calling the argument". Do you mean this line?
Code:
var _original_colour = argument0
If so, it stores the value of the first argument in _original_colour so that said variable can then be used in the script. The alternative to this would be to use argument0 in its place throughout the script, which, when you have more than one argument, especially if they're of unrelated types, can get rather messy very quickly. A variable with a descriptive name eliminates this risk of confusion.
So wait, what function are we even storing to Argument 0 to be called? I don't see where where it's being defined as anything?

Am I missing a step where Arguement 0 is being defined as the color code/argument of a particle function?
 
Last edited:

TsukaYuriko

☄️
Forum Staff
Moderator
Arguments have nothing to do with arrays - the closest thing to that is the argument array, which is an array containing all arguments of a script.

The function of the argument in @IndianaBones' code is to let the user pass a color value into the script.
 
Here's a usage example:

Code:
 effect_create_above(ef_explosion, x, y, 1, get_fixed_colour(c_yellow));
You first would create a script resource called get_fixed_colour and put my code in it.

Then you would be able to call the script in the example in this post.

argument0 in my script would contain the value of c_yellow in this case. It would then do the red/blue swapping, and return the correct value, which would then be used by the effect_create_above() function.

Edit: Just to repeat what @TsukaYuriko said above, I assign argument0 to the script variable _original_colour to make the code in the script easier to read.
 
Here's a usage example:

Code:
 effect_create_above(ef_explosion, x, y, 1, get_fixed_colour(c_yellow));
You first would create a script resource called get_fixed_colour and put my code in it.

Then you would be able to call the script in the example in this post.

argument0 in my script would contain the value of c_yellow in this case. It would then do the red/blue swapping, and return the correct value, which would then be used by the effect_create_above() function.

Edit: Just to repeat what @TsukaYuriko said above, I assign argument0 to the script variable _original_colour to make the code in the script easier to read.
That makes more sense seeing it in context. When you plug the script it automatically assigns the color code your targeting as the argument in the script call to that variable so it's all automatic. Would this script still have to be used with hex codes for them to return the proper color?
 
Would this script still have to be used with hex codes for them to return the proper color?
I'm not sure. You may need to test it and see what results you get. According to the manual, when defining colours with hex codes, the order is Blue / Green / Red. i.e. $BBGGRR. So try the built-in effect_create_above() function with a hex code. If it gives the wrong colour, then you need to use the fixing function(or @FrostyCat 's script). The get_fixed_colour() *should* also work the same with hex codes, but, I haven't tested it.

You can let us know if it's still giving problems.
 
Top