49 replies to this topic

[sabriath]

If you want a fright, look up the SIMD instruction set, now there's a set of scary command names

Those aren't so scary....
pack
unpack
signed saturation
unsigned saturation
byte
word
double word
low
high
packed...
..add
..multilply
..subtract
..multiply then add
etc.

odds are it was part of a GOTO joke

Why does everyone hate 'goto' so much? How else do you break out of a second/third/Nth tier nested switch/for/otherloop block efficiently?



As for arguments in scripts...I just thought of something, what if you had:

execute_string("somevar = argument12;");

Obviously GM wouldn't know that "argument12" is being used...this severely breaks a vital piece of GM's coding ability, and what makes it versatile. Although I do agree that a boundary should be made, it should be left up to the programmer instead of automatic (Erik gives another example of such a failure in GM if used automatically).

[kburkhart84]

If you want a fright, look up the SIMD instruction set, now there's a set of scary command names

Those aren't so scary....
pack
unpack
signed saturation
unsigned saturation
byte
word
double word
low
high
packed...
..add
..multilply
..subtract
..multiply then add
etc.

odds are it was part of a GOTO joke

Why does everyone hate 'goto' so much? How else do you break out of a second/third/Nth tier nested switch/for/otherloop block efficiently?



As for arguments in scripts...I just thought of something, what if you had:

execute_string("somevar = argument12;");

Obviously GM wouldn't know that "argument12" is being used...this severely breaks a vital piece of GM's coding ability, and what makes it versatile. Although I do agree that a boundary should be made, it should be left up to the programmer instead of automatic (Erik gives another example of such a failure in GM if used automatically).

About GOTO, as far as I know, its like a singleton. It is supposedly not recommended, but yet it is known to be useful and simply works. And I'm guessing because of how known that story is, it got turned into joke material, similar to Chuck Norris.

About execute_string, that would suck to lose that function. I'd rather risk GM not being able to detect arguments being used in strings than to lose that function. But that's just me. Sadly enough, execute_string somewhat falls into the same category I mentioned above about GOTO and the singleton.

[Dangerous_Dave]

Is there anything wrong with teaching the newbies that numbering in programming usually starts at 0?

While we're here, are we making character positions in strings start at 0? If we are teaching them numbering starts at 0, let's keep it consistent.

[Desert Dog]

After some thought, I give the array error thing a check.

I'm a bit more tentative about the fixed script argument thing, it reduces flexibility a touch, but the speed increase is worth it for me, so check that, too.

I am wondering about backwards compatability, though.

[Dangerous_Dave]

The fixed script arguments aren't reduced in flexibility, as anything you could do before can still be done but you will need to use the argument array (argument[x]) instead of the argument variables (argument0, argument1...).

As far as backwards compatibility goes, there are very few reasons why people should be having an unknown number of arguments, so almost no one should be doing anything that will now cause errors. Those that are can simply change argument0 to argument[0] and all is fixed.

[TheMagicNumber]

var realOrStr;
dim(array, 10, 0);

Why not be consistent and have:

var realOrStr;
var array[10];
variable_array_clear("array", 0);

You could always have the var statement accept initial values, and assume the initial value for an array is for all elements.

GM is already C and Pascal style, don't add on crap from BASIC now.

Edited by TheMagicNumber, 10 April 2011 - 05:18 AM.

[Manuel777]

GM is already C and Pascal style, don't add on crap from BASIC now.

Sometimes we can aaall agree with you TMN, sometimes

going back to the arguments stuff, i really liked the argc and dim() implementations.. but letme get this straight; calling a script:

MyScriptName(value,x,y,"Hello");

will have four arguments, so the argc will be four, and thats it.. you dont need to go trough all the 15 arguments to initialize them as zero.. i really never saw the point on that since no other languaje does it and it may turn buggy (as mike stated)
So, an error when you try to access argument[5] in the function above would be a nice idea, something like "Uninitialized argument [5] on function MyScriptName [blah blah]"
An here is where dim() comes in, in case you want to define initialized arguments as zero? Am-i-rite?? (if so i like it a lot)

[broadsword]

My only concern with the argument change is that I currently use it to overload scripts in GM. For example consider this function/script:

show_dialog(x,y,string,width,height,txt_speed,skip_key);

by adding the following to that script:

var width, height; //,etc...
width = 200;
height = 100;

if (argument3) width = argument3;
if (argument4) height = argument4;
//etc...

I can call show_dialog like this to use default values:

show_dialog(x,y,string);

Will this new error handling remove this functionality and if so, will there be any other way to overload a script in GM?

[kburkhart84]

My only concern with the argument change is that I currently use it to overload scripts in GM. For example consider this function/script:

show_dialog(x,y,string,width,height,txt_speed,skip_key);

by adding the following to that script:

var width, height; //,etc...
width = 200;
height = 100;

if (argument3) width = argument3;
if (argument4) height = argument4;
//etc...

I can call show_dialog like this to use default values:

show_dialog(x,y,string);

Will this new error handling remove this functionality and if so, will there be any other way to overload a script in GM?

It has already been stated that using the array method to access arguments(like argument[5]) would keep the old functionality.