csanyk
Member
I am developing a script, and inside that script I am calling draw_sprite_ext(), which has a 9-arguments long parameter list. I need to pass these args into my script when I call it, and I also need to pass in some additional arguments as well. So I am going to need to be able to pass in >16 arguments; a total of 17 arguments, in fact.
Based on the manual, in GMS1.x it appears that we're limited to 16 arguments, whether we use the older argument0..argument15 variables, or the newer argument[0..15] array. Unless I'm missing something, or they overlooked updating the manual?
But in GMS2.x, they've removed the cap on the argument[] array, allowing us to provide as many args as we need. Which is great, and makes it very easy to do what I need.
I was hoping that I could keep my script compatible with both GMS1.x and 2.x for now, as I'm using it in a Marketplace asset, and I would like to continue to support both versions as long as both are officially supported by YYG.
My question is, what's the best way to go about it?
One way would be to write a GMS1 version of the function, working around the 16-argument limitation, and a GMS2 version of the function, which uses the more straightforward argument[0...z] approach.
But if I did that, then if a project is imported the user would need to convert from the GMS1 version of the function call to the GMS2 version, and I'm not even sure if the GMS2 version would compile in a GMS1 project, meaning I'd need to build a second package...
I would like to avoid inconsistency, and avoid surprising the user, so my ideal solution would be a single script that works the same way in GMS1 and 2.
Yes, I know large parameter lists are a code smell, but I don't think it can be helped in this case, at least not without doing something like passing a data structure or array as an argument. So I could maybe do something like this:
my_script(argument[0], argument[1], argument[2]...) and have argument[0] be itself an array containing the arguments to be fed into the draw_sprite_ext() function. So, something like this:
And so my_script's code would need to look something like this?
Or potentially, rather than passing an array variable as my_script's argument[0], I could pass a ds_map or a ds_list. But then my users would need to be familiar with ds_ structures and know to clean up their ds to avoid memory leaks, etc.
So what's your opinion? What's the best way to implement this? As a user of an extension that provides this function, what would be the most intuitive, elegant way for you to want to call my_script()?
Based on the manual, in GMS1.x it appears that we're limited to 16 arguments, whether we use the older argument0..argument15 variables, or the newer argument[0..15] array. Unless I'm missing something, or they overlooked updating the manual?
But in GMS2.x, they've removed the cap on the argument[] array, allowing us to provide as many args as we need. Which is great, and makes it very easy to do what I need.
I was hoping that I could keep my script compatible with both GMS1.x and 2.x for now, as I'm using it in a Marketplace asset, and I would like to continue to support both versions as long as both are officially supported by YYG.
My question is, what's the best way to go about it?
One way would be to write a GMS1 version of the function, working around the 16-argument limitation, and a GMS2 version of the function, which uses the more straightforward argument[0...z] approach.
But if I did that, then if a project is imported the user would need to convert from the GMS1 version of the function call to the GMS2 version, and I'm not even sure if the GMS2 version would compile in a GMS1 project, meaning I'd need to build a second package...
I would like to avoid inconsistency, and avoid surprising the user, so my ideal solution would be a single script that works the same way in GMS1 and 2.
Yes, I know large parameter lists are a code smell, but I don't think it can be helped in this case, at least not without doing something like passing a data structure or array as an argument. So I could maybe do something like this:
my_script(argument[0], argument[1], argument[2]...) and have argument[0] be itself an array containing the arguments to be fed into the draw_sprite_ext() function. So, something like this:
Code:
//setting up the array that will be used as the first argument passed into my_script
draw_sprite_ext_args[0] = sprite;
draw_sprite_ext_args[1] = subimg;
draw_sprite_ext_args[2] = x;
draw_sprite_ext_args[3] = y;
//etc.
//...
//calling my_script, passing the array of draw_sprite_ext() args into argument[0] and my other arguments into argument[1] through argument[whatever]
my_script(draw_sprite_ext_args, my_script_arg1, my_script_arg2, my_script_arg2, my_script_arg3, ...)
Code:
#define my_script
///my_script(draw_sprite_ext_args[], arg1, arg2, arg3, etc)
//declarations block
dse_args = argument[0];
my_sprite = dse_args[0];
my_subimg = dse_args[1];
my_x = dse_args[2];
my_y = dse_args[3];
my_xscale = dse_args[4];
my_yscale = dse_args[5];
my_rot = dse_args[6];
my_colour = dse_args[7];
my_alpha = dse_args[8];
myscript_arg1 = argument[1];
myscript_arg2 = argument[2];
myscript_arg3 = argument[3];
myscript_arg4 = argument[4];
//etc.
//actually do the stuff that my_script does...
So what's your opinion? What's the best way to implement this? As a user of an extension that provides this function, what would be the most intuitive, elegant way for you to want to call my_script()?