1176 replies to this topic

[IceMetalPunk]

Recursion happens. There's no way to overload the operator and still somehow call the original definition of that operator,

*sighs*

int operator+(int left, int right) {
  return super(left,right);
}

I've never seen that, and looking for it online just gives me references that say it's Java-specific and simply calls the function from the parent class's scope. If that's the case, it's not the same thing here, since that doesn't need to be in a class (and wouldn't be, equivalently even, in GM).

-IMP

[Rusky]

It would be a possible syntax if function overriding were made an explicitly documented part of GML. I think I would prefer some minimal namespace support or something instead though, at least in the short term.

[sabriath]

I've never seen that, and looking for it online just gives me references that say it's Java-specific and simply calls the function from the parent class's scope. If that's the case, it's not the same thing here, since that doesn't need to be in a class (and wouldn't be, equivalently even, in GM).

Sorry, I sometimes get languages mixed up....I think I got lua mixed up with it.

Anyway, just did some research and found that recursion does not occur in C/C++ when a global operator is used inside a global operator overloading function. At least, that's the information that I found:

http://www.cs.washington.edu/education/courses/cse303/10wi/ticpp-excerpt/ticpp-ch12.html

Is it reliable? I don't care...if not, 'asm' can be used. The main point is that almost anything is possible with other languages, GM is limited even though it's interpreted, which makes no sense since it should be even MORE versatile.

[Rusky]

Lua is even farther removed from "super" than GML.

C++ doesn't even allow you to define operators on native types like int.

A language's worth is not based solely on how many concepts and "features" are stuffed into it.

[IceMetalPunk]

I've never seen that, and looking for it online just gives me references that say it's Java-specific and simply calls the function from the parent class's scope. If that's the case, it's not the same thing here, since that doesn't need to be in a class (and wouldn't be, equivalently even, in GM).

Sorry, I sometimes get languages mixed up....I think I got lua mixed up with it.

Anyway, just did some research and found that recursion does not occur in C/C++ when a global operator is used inside a global operator overloading function. At least, that's the information that I found:

http://www.cs.washington.edu/education/courses/cse303/10wi/ticpp-excerpt/ticpp-ch12.html

No, it does occur. Something like this (only writing the relevant parts):

class Integer {
  private:
    int i;
  public:
    int operator+(int val) {
      return (i+val);
    }
};

Is not calling the same function. It's overloading + for (Integer_type_variable)+(int_variable) and calling (int_variable)+(int_variable). In C++, because the parameters are different types, it's a different function. Now, if you tried this:

class Integer {
  private:
    int i;
  public:
    int operator+(Integer val) {
      return (*this + val);
    }
};

That would indeed cause recursion problems.

In GM--where typing is not only very loose to begin with, but scripts don't have prototypes or any way to define the types of their arguments--that means GM has no way of knowing if you're using a different "+", so to speak, and would be forced to assume recursion.

Of course, like I said before, "because other languages can't do it" is a very poor reason not to add it to GM. It just opens up a host of other issues that need to be considered, such as recursion. The easiest way to fix that would be as has been suggested: create a call_default("script_name", arguments,...) function which is the only function that cannot be overloaded.

-IMP

*EDIT* Slight correction of the operator overloading syntax. Oh, and I tested that kind of operator recursion in a short command-line C++ program. The result is just a complete program crash .

Edited by IceMetalPunk, 02 September 2011 - 04:38 PM.

[GStick]

Of course, like I said before, "because other languages can't do it" is a very poor reason not to add it to GM. It just opens up a host of other issues that need to be considered, such as recursion. The easiest way to fix that would be as has been suggested: create a call_default("script_name", arguments,...) function which is the only function that cannot be overloaded.

Adding to this, just because it sounds pretty interesting to me right now, but perhaps it could just be a property of functions and scripts. So maybe you could declare a script as some form of constant to prevent you or anyone else that uses your code from doing anything to it. Just seems like it would be better than to just make an exception for one new function. Could also just use the same default keyword from switch statements to declare that you wish to use the default function or script.

default script_name(argument0);

Not a function so that it wouldn't matter if this was const or not, and not something like "default.script_name" to avoid clashing with object syntax.

Just popped into my head, not sure what anyone else would really think of it. Seems good to me.

Edited by GStick, 02 September 2011 - 04:31 AM.

[thatshelby]

The shape drawing functions (draw_line, draw_circle, etc) and I assume the text drawing functions when the font is not set to a sprite, don't scale with a view port.


I'd like this to be fixed, I have to hack together some stuff to check the view port and it's annoying.

Edited by Theophilus, 09 September 2011 - 01:52 AM.

[Yal]

I've been going to suggest this for a while, but I've gotten so wrapped up in bad GInD topics so I've forgotten about it all the time. Today there was no new topics at all, giving me some extra time, so now I'll finally get this off my chest.

======================================================================================
Suggestion: Object Layers for the Room Editor
======================================================================================
Description:

The object layer tool would graphically look like the tile layer system; you can make layers of different depths, and instances placed in the room would be part of the layer you select. Operations like "Delete all" and "Shift" would only affect the current layer, giving you some neat housekeeping options, such as to place background decorations in one layer and hero/items in another one. If you want to remove for instance all the background decorations from the level, you can easily do that by selecting that layer and then click "Delete All", then choose Yes from the "Delete all instances in the current layer?" dialog.

Object layers are sorted by depth; the default depth layer is 0. When instances are created, their normal default depth will have its layer depth added to it: if you put a depth 100 obj_chimera in instance layer 5000, when the game runs it will be created with a depth of 5100. This also gives you an easy mechanism to depth sort instances, and should in particular be useful for new users.

Delete Underlying would also only delete underlying things in the same instance layer. Instances with different depth could still be part of the same depth layer, even if their total depth (default + layer) equals the depth of another layer.
======================================================================================

So instance layers comes with the following advantages:
- You can easily group/sort stuff you place in the room in different categories such as enemies, decorations, items and only operate on a certain group; Locking instances isn't that useful for that.
- It's an easy way to depth sort your instances, and e.g. use the same background tree in multiple layers to make a forest with trees at multiple depths
- It might be easier to grasp the layer system for a new user and then go on to the local variable depth
- Would be very useful in a 3D-mode game to make a multi-storey building layer for layer in the room editor (you could call with(all){depth = object_get_depth(object_index)} to restore the depth of all instances to default if you want to use just the layer functionality but not have your stuff depth sorted)

[Conan87]

It would be cool for the new GM8.1 if the background that says Game-Maker could be changed to a desired image with various options like, left/right/middle/etc. placing of the image, looping, stretching, etc. just as something for those wanting to put a little flavor to their GM while making games.

[Dark Matter]

It would be cool for the new GM8.1 if the background that says Game-Maker could be changed to a desired image with various options like, left/right/middle/etc. placing of the image, looping, stretching, etc. just as something for those wanting to put a little flavor to their GM while making games.

That's a pretty useless feature really, isn't it?
It doesn't affect the overall game at all and hardly anyone would use it.

[Erik Leppen]

When instances are created, their normal default depth will have its layer depth added to it: if you put a depth 100 obj_chimera in instance layer 5000, when the game runs it will be created with a depth of 5100.

Better yet: the Object form gets an additional check box called Relative for the depth. If Depth Relative is on, then a 100 depth object instance added to layer 5000 gets depth 5100 as you suggest. However if Depth Relative is off, the depth will be absolute, so it will simply be 100 no matter what the layer will be.

Relative is off by default to keep backwards compatibility and easier understanding for novices.

[paul23]

When instances are created, their normal default depth will have its layer depth added to it: if you put a depth 100 obj_chimera in instance layer 5000, when the game runs it will be created with a depth of 5100.

Better yet: the Object form gets an additional check box called Relative for the depth. If Depth Relative is on, then a 100 depth object instance added to layer 5000 gets depth 5100 as you suggest. However if Depth Relative is off, the depth will be absolute, so it will simply be 100 no matter what the layer will be.

Relative is off by default to keep backwards compatibility and easier understanding for novices.

Hmm I would order it differently then:

First order by layer. And only if 2 objects overlap with the same LAYER they are ordered by depth. Especially if objects can't change from layer during their lifetime it will give an amazing possibility for optimizations.

[Dark Matter]

Hmm I would order it differently then:

First order by layer. And only if 2 objects overlap with the same LAYER they are ordered by depth. Especially if objects can't change from layer during their lifetime it will give an amazing possibility for optimizations.

Yeah, this is a good method/idea. It would allow for a great amount of flexibility, while still being easy to use.

[THE_GAME_EDITOR]

I guess everyone knows about the font size option in control panel on windows 7.
Well, try setting it bigger. This has effect on all the text drawed in gamemaker which is not good.
When however saved as an executable, then it's fine.

This is an problem that should be solved.

Edited by THE_GAME_EDITOR, 07 November 2011 - 12:43 PM.

[magnetox]

There is a nice suggestion that i always wanted to show, what if there was an option in the "Object Properties" window that makes the full "action section" fully gml-coded?
WHY?
-Because advanced users feel that code is much more quicker, cleaner and (in general) better than draggin and droppin boxes (that is actually very good for new ones)
-Because it is easier and faster to check and edit your code directly from each object than entering each piece of code
-There would be more space by removing the "Action" section merged with the tabs of D&D actions

The events would act as "Tabs" switching from one piece of code to another, one for each different event.

What happen to the past D&D system? Well, when the option is activated (Maybe just a checkbox somewhere) all D&D stuff is hidden and when it's disabled, it goes back to it's previous state. This way anyone will get angry because it will just an Activate-It-If-You-Want option, only for those who want.

Please give me your opinion about this, can make life easyier to a really lot of people

Saludos 8)

[Dark Matter]

@magnetox - This idea has been given so many times now. Yes, we all know it's a nice idea. Perhaps for GM9.

[Rani_sputnik]

This must have been suggested already, but I vote for manipulation of all built in object properties on a per instance basis in the room editor.

At the moment you can reposition objects but as soon as you want to rotate them you have to use creation code -> which in turn means you have to run the game in order to see the result.
Perhaps you also have a tree object that has a sprite containing a number of variations of that tree and you want to control which tree type is where in the room... again only possible with creation code.

I imagine this was already planned for implementation at some point, but I am impatient.
Please and thank you Mike and Russell :D

[icuurd12b42]

This must have been suggested already, but I vote for manipulation of all built in object properties on a per instance basis in the room editor.

At the moment you can reposition objects but as soon as you want to rotate them you have to use creation code -> which in turn means you have to run the game in order to see the result.
Perhaps you also have a tree object that has a sprite containing a number of variations of that tree and you want to control which tree type is where in the room... again only possible with creation code.

I imagine this was already planned for implementation at some point, but I am impatient.
Please and thank you Mike and Russell

It's in gm:html5

[Robert3DG+]

It's in gm:html5

*Goes to see*

Spoiler

Why did I not hear of this? That's awesome!

Bring on GM9

[Dark Matter]

I didn't know about that either...
It'd be much easier if it was real-time though...