Jump to content


Photo

Game Maker Suggestions


  • This topic is locked This topic is locked
1162 replies to this topic

#991 kikjezrous

kikjezrous

    Seer of Spaaace

  • GMC Member
  • 637 posts
  • Version:GM8.1

Posted 12 February 2012 - 06:35 PM

Give us screen_gamma() back!!!
  • 0

#992 GStick

GStick

    All Secrets Exposed

  • GMC Member
  • 1954 posts
  • Version:GM:Studio

Posted 12 February 2012 - 06:58 PM



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

#993 iam1me

iam1me

    GMC Member

  • GMC Member
  • 380 posts
  • Version:GM8

Posted 12 February 2012 - 08:10 PM




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

#994 GStick

GStick

    All Secrets Exposed

  • GMC Member
  • 1954 posts
  • Version:GM:Studio

Posted 12 February 2012 - 09:44 PM



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();

  • 0

#995 Big J

Big J

    GMC Member

  • GMC Member
  • 2852 posts
  • Version:GM8.1

Posted 12 February 2012 - 09:47 PM

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. :D

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.

  • 3

#996 kikjezrous

kikjezrous

    Seer of Spaaace

  • GMC Member
  • 637 posts
  • Version:GM8.1

Posted 12 February 2012 - 10:02 PM

+1
  • 0

#997 Gamer3D

Gamer3D

    Human* me = this;

  • GMC Member
  • 1819 posts
  • Version:GM:Studio

Posted 12 February 2012 - 11:17 PM

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

#998 iam1me

iam1me

    GMC Member

  • GMC Member
  • 380 posts
  • Version:GM8

Posted 12 February 2012 - 11:54 PM


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 :(
  • 0

#999 zekew11

zekew11

    GMC Member

  • GMC Member
  • 15 posts
  • Version:GM8

Posted 13 February 2012 - 02:04 AM

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)}
  • 0

#1000 Silver Scratch

Silver Scratch

    GMC Member

  • GMC Member
  • 166 posts
  • Version:GM8

Posted 13 February 2012 - 04:40 AM

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

#1001 GStick

GStick

    All Secrets Exposed

  • GMC Member
  • 1954 posts
  • Version:GM:Studio

Posted 13 February 2012 - 04:48 AM

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

#1002 iam1me

iam1me

    GMC Member

  • GMC Member
  • 380 posts
  • Version:GM8

Posted 13 February 2012 - 05:43 AM

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

#1003 paul23

paul23

    GMC Member

  • Global Moderators
  • 3985 posts
  • Version:GM:Studio

Posted 13 February 2012 - 07:15 AM



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

#1004 iam1me

iam1me

    GMC Member

  • GMC Member
  • 380 posts
  • Version:GM8

Posted 13 February 2012 - 07:39 AM

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.

  • 0

#1005 Big J

Big J

    GMC Member

  • GMC Member
  • 2852 posts
  • Version:GM8.1

Posted 13 February 2012 - 08:25 AM

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

#1006 kburkhart84

kburkhart84

    Firehammer Games

  • GMC Member
  • 1947 posts
  • Version:GM:Studio

Posted 26 February 2012 - 07:56 PM

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

#1007 Rexhunter99

Rexhunter99

    GMC Member

  • GMC Member
  • 924 posts
  • Version:GM:Studio

Posted 26 February 2012 - 10:40 PM

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.

  • 0

#1008 Big J

Big J

    GMC Member

  • GMC Member
  • 2852 posts
  • Version:GM8.1

Posted 26 February 2012 - 10:49 PM

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

#1009 iam1me

iam1me

    GMC Member

  • GMC Member
  • 380 posts
  • Version:GM8

Posted 27 February 2012 - 01:15 AM

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

#1010 Big J

Big J

    GMC Member

  • GMC Member
  • 2852 posts
  • Version:GM8.1

Posted 27 February 2012 - 01:31 AM

So the -> thing de-references things? No... for Game Maker, it should just be the dot. We don't want to de-reference anything, therefore we don't want ->. For example:
inst = instance_create(x, y, object);
dist = inst.point_distance(x, y, 32, 32);
We don't want to derefrence the variable that has the instance ID, therefore it would seem to me the dot is more appropriate. Instance.method() is pretty much a "normal reference". So yeah, there's no reason to complicate things with a dot vs ->. This is Game Maker, just keep it simple.
  • 0

#1011 iam1me

iam1me

    GMC Member

  • GMC Member
  • 380 posts
  • Version:GM8

Posted 27 February 2012 - 01:49 AM

So the -> thing de-references things? No... for Game Maker, it should just be the dot. We don't want to de-reference anything, therefore we don't want ->. For example:

inst = instance_create(x, y, object);
dist = inst.point_distance(x, y, 32, 32);
We don't want to derefrence the variable that has the instance ID, therefore it would seem to me the dot is more appropriate. Instance.method() is pretty much a "normal reference". So yeah, there's no reason to complicate things with a dot vs ->. This is Game Maker, just keep it simple.


Actually - you ARE dereferencing inst. What value does inst contain? It contains a # which represents the new instances position in memory. It is thus functioning as a pointer. A further testament to this is the fact that you can change the value contained in inst and thus point to different instances in memory.
  • 0

#1012 kburkhart84

kburkhart84

    Firehammer Games

  • GMC Member
  • 1947 posts
  • Version:GM:Studio

Posted 27 February 2012 - 02:58 AM


So the -> thing de-references things? No... for Game Maker, it should just be the dot. We don't want to de-reference anything, therefore we don't want ->. For example:

inst = instance_create(x, y, object);
dist = inst.point_distance(x, y, 32, 32);
We don't want to derefrence the variable that has the instance ID, therefore it would seem to me the dot is more appropriate. Instance.method() is pretty much a "normal reference". So yeah, there's no reason to complicate things with a dot vs ->. This is Game Maker, just keep it simple.


Actually - you ARE dereferencing inst. What value does inst contain? It contains a # which represents the new instances position in memory. It is thus functioning as a pointer. A further testament to this is the fact that you can change the value contained in inst and thus point to different instances in memory.


I see where you try to compare an object id to a C pointer, but that is the breaking point. If you change the number, and then try to use it as an object, unless by luck it happens to be the id of another object instance, you are breaking things, because GM won't be able to find said object in its array.

On the other hand, trying to de-reference a "bad" pointer in C also leads to crashes, so in this they are similar, but different, see what I mean. The "bad" pointer does indeed point to a memory location, even if said memory is not belonging to the program in question, whereas the "bad" GM instance ID does not point to anything, rather it is like a simple bad index to an array/data structure.

And lastly, some people could argue that a computer's RAM is of sorts a massive array of spaces for values to be stored, therefore making instance IDs and C pointers that much more similar, but regardless of all of this, I'd still say for GM, just use a dot.
  • 1

#1013 iam1me

iam1me

    GMC Member

  • GMC Member
  • 380 posts
  • Version:GM8

Posted 27 February 2012 - 05:11 AM

I see where you try to compare an object id to a C pointer, but that is the breaking point. If you change the number, and then try to use it as an object, unless by luck it happens to be the id of another object instance, you are breaking things, because GM won't be able to find said object in its array.


It would break in C/C++ as well - changing a pointers location to some random place in memory is a dangerous practice. These are known as wild pointers, and are a side affect of BAD programming. While the C/C++ program might not crash, you can expect strange results, memory leaks, and even damage to files (though I believe the OS will limit the range of damage a wild pointer can inflict). That GM automatically crashes when you try to use a wild pointer is simply a handy run-time error checking feature.

On the other hand, trying to de-reference a "bad" pointer in C also leads to crashes, so in this they are similar, but different, see what I mean. The "bad" pointer does indeed point to a memory location, even if said memory is not belonging to the program in question, whereas the "bad" GM instance ID does not point to anything, rather it is like a simple bad index to an array/data structure.


An array IS a pointer, when you get down to it. Hence in C/C++ you can take any pointer and use it as if it were an array. Likewise, you can take any array and use it like a pointer.

And lastly, some people could argue that a computer's RAM is of sorts a massive array of spaces for values to be stored, therefore making instance IDs and C pointers that much more similar, but regardless of all of this, I'd still say for GM, just use a dot.


Again, an array is simply a pointer.
  • 0

#1014 kburkhart84

kburkhart84

    Firehammer Games

  • GMC Member
  • 1947 posts
  • Version:GM:Studio

Posted 27 February 2012 - 04:48 PM

Yes, an array is a pointer in C/C++, but any given index of the array is similar to an iterator, and is not a pointer. So GM's object IDs, since they are more like indices to the array(I believe they are actually more like the keys to a map/dictionary data structure), and so aren't all that similar to pointers in that sense. Though in C/C++, the array itself is a pointer, which points to the first index in said array.

And yes, you quoted the first part I said, and then quoted the second part that I said, but you were trying to "correct" me about wild pointers, when the second part of what I said stated exactly that. Lovely....
  • 1

#1015 Dark Matter

Dark Matter

    RPG Expert

  • GMC Member
  • 3196 posts
  • Version:GM:Studio

Posted 27 February 2012 - 05:34 PM

Is there really any point in arguing about this? The dot syntax wouldn't work for GM because it's not OOP. If you made it OO, they'd be a whole lot more you'd have to change than just that...
  • 0

#1016 Big J

Big J

    GMC Member

  • GMC Member
  • 2852 posts
  • Version:GM8.1

Posted 27 February 2012 - 05:41 PM

It would work just fine because YoYo would program to work. There's no point in claiming that it "won't work" when it could be made to work. How preposterous.
  • 0

#1017 kburkhart84

kburkhart84

    Firehammer Games

  • GMC Member
  • 1947 posts
  • Version:GM:Studio

Posted 27 February 2012 - 06:27 PM

Yes it could work. We already have the "with" construct, which is essentially what the dot would do. Now, you are right that GM isn't really OOP, but that doesn't prohibit them from using the dot if they want to.
  • 0

#1018 iam1me

iam1me

    GMC Member

  • GMC Member
  • 380 posts
  • Version:GM8

Posted 27 February 2012 - 09:43 PM

Yes, an array is a pointer in C/C++, but any given index of the array is similar to an iterator, and is not a pointer. So GM's object IDs, since they are more like indices to the array(I believe they are actually more like the keys to a map/dictionary data structure), and so aren't all that similar to pointers in that sense. Though in C/C++, the array itself is a pointer, which points to the first index in said array.

And yes, you quoted the first part I said, and then quoted the second part that I said, but you were trying to "correct" me about wild pointers, when the second part of what I said stated exactly that. Lovely....


An index is merely an offset into memory. By incrementing the index, you can indeed iterate through an array - but each index is itself essentially a pointer. The same doesn't hold true for other data structures where they explicitly require you to use a special iterator instance. They are thus exactly like pointers, because they are pointers.

As for responding to different parts of your message - I should have probably responded to it all together vs responding to each part, but I had already written my response to the first part before reading the second, and figured it would be a waste to delete it :P
  • 0

#1019 kburkhart84

kburkhart84

    Firehammer Games

  • GMC Member
  • 1947 posts
  • Version:GM:Studio

Posted 27 February 2012 - 10:02 PM

An index is an integer, for example 0, 1, 2, so how is that a pointer. You can't use it by itself as such, whereas the array name itself you can use on its own for various things. The object ids that GM creates/uses are similar to both indices and pointers, for example with the "with" construct you can operate script directly on said object instance, and using the current '.' operator you can modify variables of said instance. And considering GM stores all the object instances in a massive array/data structure, the object IDs also have similarity to indices.

Regardless of all of this, you can't say that indices are the same as pointers in C/C++.

And lastly, I still say the '.' operator would be a nice alternative to the 'with' construct in GM, instead of '->' but that isn't even based on whether the things are more similar to pointers or variables or whatever you want, rather it is quite simpe(which GM is supposed to be) and that it flows with how the dot can already be used to change variables on specific object instances.
  • 0

#1020 fawful

fawful

    dear leader

  • GMC Member
  • 1321 posts
  • Version:GM8

Posted 27 February 2012 - 10:12 PM

I think gamemaker as a program would greatly benefit from increased developmental capabilities without basic errors causing difficulties in the simplist of tasks.

The best way to work around this as a developer is to build his or her own development engine over a core programming language such as C++, a personal 'gamemaker' if you will. Unfortunately, many of users of GameMaker are too incompetent to carry this out, and I think it's an issue that is vastly ignored.

The solution?

It's very simple, all that needs to be done is to add a single function to Gamemaker to assist in the development of another game making system.

generate_program_gamemaker(3d,GTF,col,GM)

Using procedural generation and voxels this would have gamemaker generate a specially designed version of gamemaker except it would be personalized using four variables.

-3d would determin exactly how 3d this version of gamemaker is.

-GTF stands for "glitch to function" ratio, which is used to set how annoyed you will be by it.

-col is the colour it would be. e.g c_red.

-GM decides if this version of Gamemaker can use the function 'generate_program_gamemaker(3d,GTF,col,GM)' in case an additional version of Gamemaker is needed.
  • 0




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users