• 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.

 [suggestion] Array vector accesors and vector functions

GMWolf

aka fel666
[edit] is this the right subforum? probably not...

GM at the moment is quite a mess with all the vector and matrix functions either taking in multiple float values, or returning arrays.
I suggest we get more functions to deal with vectors directly.

but first, some nice accessors to make everyone happy:
Code:
v.x //would be the same as v[0] if v is an array
v.y //same as v[1] if v is array
v.z //same as v[2] if v is array
v.w //same as v[2] if v is array
v.b //same as v.x
v.g //same as b.y
v.r //same as b.z
v.a //same as b.w

//bonus, combine them to get things like
v.xy //same as [v.x, v.y]
v.xz //same as [v.x, v.z]
//etc
These should make working with vectors more pleasing to the eye :)

As for actual functions:
Code:
vector_direction(array a, array b) //same as point direction, uses two array vectors
vector_distance(array a, array b) //same as point_distance, but with array vectors
vector_distance_3d(array a, array b) //again same as point_distance_3d
vector_dot_product(array a, array b) //same as dot_product, but with array vectors
(include all dot product normalized and 3d...)
matrix_transform_vector(matrix, vector) //same as matrix_transform_vertex, but with arrays
With these new functions, we could more easily reason about our code, no need to use many lines to de-array and re-array our vector variables.

Yes, these methods could be written in GML, but by having them be core functions, we can hopefully loose less performance when it comes to array accesses. very useful in vector heavy processes like procedural noise generation.

It would also be nice to extend these to colours:
Code:
colour_get_vector(colour) //returns colour vector of color value, like color_get_rgb
colour_set_vector(vector) //get a colour value from the vector, like color_make_rgb
 

YellowAfterlife

ᴏɴʟɪɴᴇ ᴍᴜʟᴛɪᴘʟᴀʏᴇʀ
Forum Staff
Moderator
I feel like this is a dangerous idea - having seemingly normal code do something else on an occasion (with "some" variable names and an array instead of an instance ID on an accident) is never easy to debug.
 

GMWolf

aka fel666
I feel like this is a dangerous idea - having seemingly normal code do something else on an occasion (with "some" variable names and an array instead of an instance ID on an accident) is never easy to debug.
In that case, GML should just be refactored entirely. GNL is basically a bad idea ^^ I mean, arrays getting copied when you change a value.. What?
 

FrostyCat

Member
In that case, GML should just be refactored entirely. GNL is basically a bad idea ^^ I mean, arrays getting copied when you change a value.. What?
This is perfectly normal behaviour in many other languages, including some that you personally use --- C# comes to mind immediately.

So should C# just be refactored entirely because some people don't know better?
 

GMWolf

aka fel666
This is perfectly normal behaviour in many other languages, including some that you personally use --- C# comes to mind immediately.
what? c# doesn't work like that! C# passes arrays by reference. If you modify an element of the array, it does not create a copy of the array before modifying it, it modifies the array the variable is referencing.
with GML, unless you use the @ modifier, it will create a new array for just that variable!
 

GMWolf

aka fel666
It's called copy-on-write. Believe me or not, but this is also how strings work in basically any modern programming language.
yeah, The data is copy on write, but it does not create a new reference to a different object.

The thing is if you modify an array in a script (without accessors), it will not affect all other refferences to that object.
In every other language i know, if you modify an array A, all the references to A see the change.
in GML, if you modify the array A, (without accessors), no other reference will see the change.

for example:
Code:
script add_one: {
    ///this scripts add one to the first element of tthe given array
    argument0[0] += 1;
}


var array = [1,2,3];
add_one(array);
show_message(array[0]);
this will display 1, not 2.
what other language works that way?

Besides, that's not the point: YYG have already decided to use arrays as vectors. can all function not make use of those vectors instead of forcing us to wrap and unwrap our vectors all the time?

BTW, seems like GMLive doesnt model GML arrays correctl
y. wierd how GMLive uses a better version of GML, with JS objects, declaring scripts and events in text... why cant we have this in actual GM?
 
Last edited:

YellowAfterlife

ᴏɴʟɪɴᴇ ᴍᴜʟᴛɪᴘʟᴀʏᴇʀ
Forum Staff
Moderator
The thing is if you modify an array in a script (without accessors), it will not affect all other refferences to that object.
In every other language i know, if you modify an array A, all the references to A see the change.
in GML, if you modify the array A, (without accessors), no other reference will see the change.
Strings work that way in basically every language, as I have mentioned above - if you modify a string, that does not change all other references to it, it changes the local reference.

what other language works that way?
Java has it optional on some classes. Swift copies array references by default (var a = [...]; var b = a; (a == b) returns false). GM likely borrowed the feature from somewhere because until some point array references could not be copied at all.

BTW, seems like GMLive doesnt model GML arrays correctly. wierd how GMLive uses a better version of GML, with JS objects, declaring scripts and events in text... why cant we have this in actual GM?
Lack of need for backwards compatibility. I can mention that arrays are not copy-on-write in "Help" (I did), and blame anyone that doesn't read that. YYG can't just change this without breaking tons of existing games, hence the addition of [@] operator.
 

GMWolf

aka fel666
Strings work that way in basically every language, as I have mentioned above - if you modify a string, that does not change all other references to it, it changes the local reference.


Java has it optional on some classes. Swift copies array references by default (var a = [...]; var b = a; (a == b) returns false). GM likely borrowed the feature from somewhere because until some point array references could not be copied at all.


Lack of need for backwards compatibility. I can mention that arrays are not copy-on-write in "Help" (I did), and blame anyone that doesn't read that. YYG can't just change this without breaking tons of existing games, hence the addition of [@] operator.
fair enough. I still dont think its a particularly nice language feature.

But back to the original suggestion: what do you think of the extra functions.
and as for the extra accessors, many languages have different operators do differnent things on different data types. after all, the '.' is just an operator.
 
Top