1176 replies to this topic

[iam1me]

This would be an incredible improvement to the language for those of us who know how to program outside of GML.

Alternatively, just add an additional argument to any scripts that require taking in local variables...

I've thought of this of course, and that is how GML does things for lots of its built in functions. But when scripts are written which are meant to be run entirely in the scope of a particular instance, it would be preferable to have a '->' operator. It seems much more natural, personally. This would also prevent the unnecessary problem of having to pass along the instance id as a parameter when the scope is already set correctly.

[Anzkji]

Give us screen_gamma() back!!!

[GStick]

This would be an incredible improvement to the language for those of us who know how to program outside of GML.

Alternatively, just add an additional argument to any scripts that require taking in local variables...

I've thought of this of course, and that is how GML does things for lots of its built in functions. But when scripts are written which are meant to be run entirely in the scope of a particular instance, it would be preferable to have a '->' operator. It seems much more natural, personally. This would also prevent the unnecessary problem of having to pass along the instance id as a parameter when the scope is already set correctly.

I would just rather scripts be treated like methods.

[iam1me]

This would be an incredible improvement to the language for those of us who know how to program outside of GML.

Alternatively, just add an additional argument to any scripts that require taking in local variables...

I've thought of this of course, and that is how GML does things for lots of its built in functions. But when scripts are written which are meant to be run entirely in the scope of a particular instance, it would be preferable to have a '->' operator. It seems much more natural, personally. This would also prevent the unnecessary problem of having to pass along the instance id as a parameter when the scope is already set correctly.

I would just rather scripts be treated like methods.

Indeed! My "->" operator idea would essentially do this.

[GStick]

I've thought of this of course, and that is how GML does things for lots of its built in functions. But when scripts are written which are meant to be run entirely in the scope of a particular instance, it would be preferable to have a '->' operator. It seems much more natural, personally. This would also prevent the unnecessary problem of having to pass along the instance id as a parameter when the scope is already set correctly.

I would just rather scripts be treated like methods.

Indeed! My "->" operator idea would essentially do this.

Sort of. From what I gather from your idea, it would essentially just allow you to know the exact scope of your script, being local to the object... but that script is actually still a global entity because you can apply it to any object...

obj_player->do_kung_fu();
obj_wall->do_kung_fu();

// both of these would applicable?

Similar idea, but also... what if that script wasn't meant to be used locally, and you weren't thinking straight?

obj_wall->not_local_script();

I would just prefer to have scripts that are only local to the object and can be inherited, or not. Public/private would be nice but that's a bit different.

// do_kung_fu() can only be used by obj_player
obj_player.do_kung_fu();

// this will result in a compilation error / "code-time" error in the editor...
obj_wall.do_kung_fu();

[Big J]

This is how you do it in Game Maker:

with (instance)
{
    script();
}

That's because GM's language loves doing things differently than other languages, even if it completely sucks.

I'd like this:

instance.script();

I also want ++ and -- for incrementing and decrementing, and % for modulo division like in "real" languages.

Edited by Big J, 12 February 2012 - 09:48 PM.

[Anzkji]

+1

[Gamer3D]

I'd like this:

instance.script();

I prefer this to -> for localizing scripts. C++ reserves -> for combined dereference and element access. "a->" is more or less equivalent to "(*a)."; I'd suggest reserving it too, so the language doesn't need to change if pointers/references are added at some point.
Anyway, I think the whole a.script() is a good idea. It'll get people working with this, so when GM adds scripts as elements of objects, it'll be an even smoother transition.

I also want ++ and -- for incrementing and decrementing, and % for modulo division like in "real" languages.

Seconded. It's occasionally annoying to type % and remember that I need to use mod, but ALWAYS annoying to have no increment or decrement operator.

[iam1me]

I'd like this:

instance.script();

I prefer this to -> for localizing scripts. C++ reserves -> for combined dereference and element access. "a->" is more or less equivalent to "(*a)."; I'd suggest reserving it too, so the language doesn't need to change if pointers/references are added at some point.
Anyway, I think the whole a.script() is a good idea. It'll get people working with this, so when GM adds scripts as elements of objects, it'll be an even smoother transition.

The reason i suggested "->" versus just "." is because everything in GM IS essentially a pointer. You don't work with instances, but instance "ids" - which tell GM where that instance is in memory. And any variable holding an instance id can be set to another instance id, just like a pointer!

I also want ++ and -- for incrementing and decrementing, and % for modulo division like in "real" languages.

Seconded. It's occasionally annoying to type % and remember that I need to use mod, but ALWAYS annoying to have no increment or decrement operator.

Thirded! I especially miss the ++ and -- operators

[zekew11]

Two Suggestions:

1: If a mathematical function is not possible (ex: division by zero), then, instead of an error, GM returns "null"
2: Object tagging; in an object's menu, a user can add tags to that object. These tags can be used to reference any object with that tag. for example, If I had 3 monster objects, and a bullet that should fly at the nearest one, I could tag all my monsters as "foe_tag". I could then write, in the create event of my bullet: {direction=point_direction(x,y,foe_tag.x,foe_tag.y)}

[Silver Scratch]

These four ideas might be stupid, but here we go.
1.)Add encypting and decrypting functions. I know xot made them in GMLScripts but it would be nice having it in Game Maker itself to protect our data some how.
2.) I was thinking that in "Debug", There should be options that shows arrayed variables. Like "Global Arrays" and "Local Arrays" so we can see what is going on cause we can't see if our arrays are getting the right information.
3.) Make the dialog box appear in the directory you want. get_openfilename(startdir,i 4got what it said here,and here) and if you want to start at "my documents" let there be a way to do so! This will help alot since the creators of some games put the game in "Program Files" and it would be nice to appear in another directory.
4.) Make more drawing shapes. This would be nice for effects like shooting starts. draw_star(x1,y1,x2,y2,outline), this would reduce some sprite usage. Star, diamond, trapezoid. Maybe some that others might request. Oh! and make it there be a "width" for the drawn shapes. Like draw_line_width but in the shapes. draw_rectangle_width(x1,y1,x2,y2,outline,line width) this would be more usefull when drawing stuff like a menu that clearly shows its boundary.
Just some suggestions since i have no good reasons
Edit:
I agree on making a better way to put tiles! Like a shape for the section you want. Maybe we might be "copying" from another maker but it is really useful.

[GStick]

2: Object tagging; in an object's menu, a user can add tags to that object. These tags can be used to reference any object with that tag. for example, If I had 3 monster objects, and a bullet that should fly at the nearest one, I could tag all my monsters as "foe_tag". I could then write, in the create event of my bullet: {direction=point_direction(x,y,foe_tag.x,foe_tag.y)}

Creating a parent object solves this issue already. Create an object foe and make that the topmost parent for enemies.

[iam1me]

OH!!! There needs to be an object_set_name() function so that GML defined objects can have names associated with them. Its not nice seeing all your instance variables in the debugger having the name "_newobject7" or something like that.

[paul23]

I'd like this:

instance.script();

I prefer this to -> for localizing scripts. C++ reserves -> for combined dereference and element access. "a->" is more or less equivalent to "(*a)."; I'd suggest reserving it too, so the language doesn't need to change if pointers/references are added at some point.
Anyway, I think the whole a.script() is a good idea. It'll get people working with this, so when GM adds scripts as elements of objects, it'll be an even smoother transition.

The reason i suggested "->" versus just "." is because everything in GM IS essentially a pointer. You don't work with instances, but instance "ids" - which tell GM where that instance is in memory. And any variable holding an instance id can be set to another instance id, just like a pointer!

That's actually bad reasoning: first of all in gm everything is a HANDLE, not a raw pointer. And actually it is more similar to a reference than to a pointer. Secondly - why should a "->" be used? You know that language like JAVA also always use references for their objects? And they use a "." sign.

[iam1me]

That's actually bad reasoning: first of all in gm everything is a HANDLE, not a raw pointer.

All a pointer is is a number that corresponds to a place in memory. Hence why in C and C++ you can use the arithmetical operators on them (like ++). True, a "Handle" is probably a more correct term when referring to things like the the ids that are passed back when you create a GML data structure, but this is not so for a numerical variable pointing to an instance of a custom object - you don't have to pass the pointer to gml functions in order to manipulate the instances.

And actually it is more similar to a reference than to a pointer.

You have somewhat of a case for a handle, but not for a reference. References are like 'permanent pointers' - you CANNOT have a reference variable that points to one spot in memory and then switch what it points to. You CAN however do that with a pointer or with a numerical variable in GML.

Secondly - why should a "->" be used? You know that language like JAVA also always use references for their objects? And they use a "." sign.

That's just it - they use references, not pointers.

Edited by iam1me, 13 February 2012 - 07:44 AM.

[Big J]

It's easier to type a dot. Besides, that's how Java does it.

[kburkhart84]

I've mentioned particles in this topic before, but I have another suggestion that would be really nice.

I know some people are downing the particle editor itself as part of the GUI. I myself would like to see that, but not only that.

I would like to see particles(either code or editor based) be much more capable. Instead of either 1/2/3 color and alpha settings, would it not be better to have an actual gradient, with many more "stops" defining colors/alphas. Even with defining 3 colors, since we can only define the color, not the "gradient position" we can't say that the first 10% is the first color, then the other two colors, rather it is only beginning/middle/end.

How about using a "sprite" emitter. If 3d engines can emit from 3d models, why couldn't we emit particles from sprites, specifically the non-transparent sections. This would be great to create random shapes of flames, etc... among many other uses.

With Box2D coming into GMStudio, than the GM9 version of GMStudio could provide the full physics simulation for particles as well, which could then turn into the fluid simulator of sorts, though maybe not on that last step. This would also make the deflectors more useful, because particles could actually "bounce" around instead of just changing direction.

Of course, this type of thing is probably easier to create/modify with an in GUI editor instead of code. The reason code has worked fine so far for particles is the limits they have.

***

And about the '->' versus '.' bit, I think the dot is plenty. The '->' in C++ can be confusing to beginners as too why that instead of the dot(for pointer to objects/class instances for example) but for GM, that will be confusing. The simple '.' is all we need to simply execute a script "from the object", but that is what the "with" construct is for. The dot would be a welcome addition, but is not really adding functionality in this case.

[Rexhunter99]

It's easier to type a dot. Besides, that's how Java does it.

So by your reasoning, because Java does it so should all other languages? Because Java forces users to put super(); in their constructors of objects, Game Maker should force users to put super(); in their create events? I don't think so, C/C++ set a programming language standard that C# and Java follow, the topic regarding '->' is about making things more fluid for experienced users who are constantly getting mixed up after going back and forth between languages, which I am sure that YYG are quite familiar with, having worked on a C++ runner and the Delphi Runner and obviously testing these things out in GML after updating the engine.

I am incredibly familiar with the issue being discussed and while it does not break anything in regards to development of a game withing Game Maker, it is incredibly frustrating, especially for DLL developers using C++ like myself. Working on an OpenGL wrapper for Game Maker (for educational purposes mainly) I am constantly making the mistake of using % instead of mod, ++ instead of += and -- instead of -= among other things, I have even caught myself using pointers, haha, it's the same for functions but it is typically easier to catch out several sinf()'s than dozens of the aforementioned things.

Edited by James_ogden, 26 February 2012 - 10:46 PM.

[Big J]

My bad, I should have said that Java and C++ both use the dot, because they do. The point is, typing a dot is easier and makes more sense.

[iam1me]

My bad, I should have said that Java and C++ both use the dot, because they do. The point is, typing a dot is easier and makes more sense.

There is a fundamental functional difference between a dot and "->" - the dot is used for normal variables/references, and the "->" is the combination of dereferencing and the dot (ex: (*myptr).function(). The reason Java doesn't use "->" is because pointers aren't part of the Java language.

Furthermore, "->" is more appropriate for GM since everything in GM, apart from the variables used to hold numerical data in of itself and those variables which serve as handles to data structures, is essentially a pointer. Any variable that holds an instance id IS functionally a pointer - not a reference variable. "->" is plenty easy to understand for programmers and makes more sense to them.

Finally, as has been pointed out, the use of "->" would be an addition for advanced users - beginners can stick with their D&D.