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.

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.

It is extremely rare for me to comment, but all programmers that want to learn how to write professional code and everyone that wants a professional, easy-to-use, flexible, and FAST gui/hud/inventory/etc. system should support this project's development. I have been employed as a programmer (C++/CLI, C#, VisualBasic.NET, JavaScript, etc.) and know what companies look for and use, and I want to let people here know that they are using gui frameworks similar to what iam1me is providing here (if only gml were more object-oriented). For those that don't understand the current and massive potential benefits, I will try to help explain...

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.

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.

It is extremely rare for me to comment, but all programmers that want to learn how to write professional code and everyone that wants a professional, easy-to-use, flexible, and FAST gui/hud/inventory/etc. system should support this project's development. I have been employed as a programmer (C++/CLI, C#, VisualBasic.NET, JavaScript, etc.) and know what companies look for and use, and I want to let people here know that they are using gui frameworks similar to what iam1me is providing here (if only gml were more object-oriented). For those that don't understand the current and massive potential benefits, I will try to help explain...

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

My KBInput system is now on the marketplace here. It wraps up nice and tight GMStudio's input system into a few function calls making a user configurable input system that works the same regardless of what inputs the player has chosen including keyboard, mouse buttons, and gamepad/joysticks using DInput/XInput. The support forum topic for it is here.

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.

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.

It is extremely rare for me to comment, but all programmers that want to learn how to write professional code and everyone that wants a professional, easy-to-use, flexible, and FAST gui/hud/inventory/etc. system should support this project's development. I have been employed as a programmer (C++/CLI, C#, VisualBasic.NET, JavaScript, etc.) and know what companies look for and use, and I want to let people here know that they are using gui frameworks similar to what iam1me is providing here (if only gml were more object-oriented). For those that don't understand the current and massive potential benefits, I will try to help explain...

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

Read this before contacting me with a mentor request. This text file is subject to amendments at any time, without notice.

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.

It is extremely rare for me to comment, but all programmers that want to learn how to write professional code and everyone that wants a professional, easy-to-use, flexible, and FAST gui/hud/inventory/etc. system should support this project's development. I have been employed as a programmer (C++/CLI, C#, VisualBasic.NET, JavaScript, etc.) and know what companies look for and use, and I want to let people here know that they are using gui frameworks similar to what iam1me is providing here (if only gml were more object-oriented). For those that don't understand the current and massive potential benefits, I will try to help explain...

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

My KBInput system is now on the marketplace here. It wraps up nice and tight GMStudio's input system into a few function calls making a user configurable input system that works the same regardless of what inputs the player has chosen including keyboard, mouse buttons, and gamepad/joysticks using DInput/XInput. The support forum topic for it is here.

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.

It is extremely rare for me to comment, but all programmers that want to learn how to write professional code and everyone that wants a professional, easy-to-use, flexible, and FAST gui/hud/inventory/etc. system should support this project's development. I have been employed as a programmer (C++/CLI, C#, VisualBasic.NET, JavaScript, etc.) and know what companies look for and use, and I want to let people here know that they are using gui frameworks similar to what iam1me is providing here (if only gml were more object-oriented). For those that don't understand the current and massive potential benefits, I will try to help explain...

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

My KBInput system is now on the marketplace here. It wraps up nice and tight GMStudio's input system into a few function calls making a user configurable input system that works the same regardless of what inputs the player has chosen including keyboard, mouse buttons, and gamepad/joysticks using DInput/XInput. The support forum topic for it is here.

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

My KBInput system is now on the marketplace here. It wraps up nice and tight GMStudio's input system into a few function calls making a user configurable input system that works the same regardless of what inputs the player has chosen including keyboard, mouse buttons, and gamepad/joysticks using DInput/XInput. The support forum topic for it is here.

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

It is extremely rare for me to comment, but all programmers that want to learn how to write professional code and everyone that wants a professional, easy-to-use, flexible, and FAST gui/hud/inventory/etc. system should support this project's development. I have been employed as a programmer (C++/CLI, C#, VisualBasic.NET, JavaScript, etc.) and know what companies look for and use, and I want to let people here know that they are using gui frameworks similar to what iam1me is providing here (if only gml were more object-oriented). For those that don't understand the current and massive potential benefits, I will try to help explain...

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

My KBInput system is now on the marketplace here. It wraps up nice and tight GMStudio's input system into a few function calls making a user configurable input system that works the same regardless of what inputs the player has chosen including keyboard, mouse buttons, and gamepad/joysticks using DInput/XInput. The support forum topic for it is here.

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.

An index is an integer, for example 0, 1, 2, so how is that a pointer.

That's all a pointer is - an integer.

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.

Again, array = pointer.

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

Yes you can - all they are is integers that are offsets into memory.

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.

Both are simple - but "->" is more accurate and would be handy for real programmers, especially those working on dlls and thus switching between C/C++ and GML, such that they wouldn't have to keep switching syntax.

It is extremely rare for me to comment, but all programmers that want to learn how to write professional code and everyone that wants a professional, easy-to-use, flexible, and FAST gui/hud/inventory/etc. system should support this project's development. I have been employed as a programmer (C++/CLI, C#, VisualBasic.NET, JavaScript, etc.) and know what companies look for and use, and I want to let people here know that they are using gui frameworks similar to what iam1me is providing here (if only gml were more object-oriented). For those that don't understand the current and massive potential benefits, I will try to help explain...

Yes, under the hood, an index could be casted to a pointer, but then it would be completely wild, and useless. Whereas the actual name of the array is a valid pointer. I'm not disagreeing with that part. But remember, the way an index is used is not as a pointer, rather as an offset from a valid pointer(the array), therefore, the index itself is not a pointer, though you could attempt to cast it to a pointer, and get something invalid. You could also add an integer to a pointer a likely get a valid pointer, assuming you have allocated that amount of memory to the array, or it would then be another wild pointer. But the integer index itself, though "technically" castable to a pointer, is not a valid pointer, unless used in the context of the offset of an array.

By your logic, the integer '1' when put into a variable is instantly a pointer, just because it would technically point to the second unit into the array of RAM? Technically, yes, but that doesn't make it useful, hence why I'm saying that an index(integer) is not the same as an actual usable pointer, like the array name is.

And about -> vs. '.', we can agree to disagree here. Each side has valid points, and is will be up to Yoyo if they want to even implement such a thing, and if so to decide which one.

0

My KBInput system is now on the marketplace here. It wraps up nice and tight GMStudio's input system into a few function calls making a user configurable input system that works the same regardless of what inputs the player has chosen including keyboard, mouse buttons, and gamepad/joysticks using DInput/XInput. The support forum topic for it is here.

Yes, under the hood, an index could be casted to a pointer, but then it would be completely wild, and useless. Whereas the actual name of the array is a valid pointer. I'm not disagreeing with that part. But remember, the way an index is used is not as a pointer, rather as an offset from a valid pointer(the array), therefore, the index itself is not a pointer, though you could attempt to cast it to a pointer, and get something invalid. You could also add an integer to a pointer a likely get a valid pointer, assuming you have allocated that amount of memory to the array, or it would then be another wild pointer. But the integer index itself, though "technically" castable to a pointer, is not a valid pointer, unless used in the context of the offset of an array.

An index is an offset from the start pointer, and thus points to a very specific place in memory - it is a pointer, but a relative vs absolute pointer.

By your logic, the integer '1' when put into a variable is instantly a pointer, just because it would technically point to the second unit into the array of RAM? Technically, yes, but that doesn't make it useful, hence why I'm saying that an index(integer) is not the same as an actual usable pointer, like the array name is.

No - any integer value would not be a pointer, it explicitly must be used to point to a specific location in memory to be a pointer, which is what an index does.

And about -> vs. '.', we can agree to disagree here. Each side has valid points, and is will be up to Yoyo if they want to even implement such a thing, and if so to decide which one.

It is extremely rare for me to comment, but all programmers that want to learn how to write professional code and everyone that wants a professional, easy-to-use, flexible, and FAST gui/hud/inventory/etc. system should support this project's development. I have been employed as a programmer (C++/CLI, C#, VisualBasic.NET, JavaScript, etc.) and know what companies look for and use, and I want to let people here know that they are using gui frameworks similar to what iam1me is providing here (if only gml were more object-oriented). For those that don't understand the current and massive potential benefits, I will try to help explain...

It is extremely rare for me to comment, but all programmers that want to learn how to write professional code and everyone that wants a professional, easy-to-use, flexible, and FAST gui/hud/inventory/etc. system should support this project's development. I have been employed as a programmer (C++/CLI, C#, VisualBasic.NET, JavaScript, etc.) and know what companies look for and use, and I want to let people here know that they are using gui frameworks similar to what iam1me is providing here (if only gml were more object-oriented). For those that don't understand the current and massive potential benefits, I will try to help explain...

An index is an offset from the start pointer, and thus points to a very specific place in memory - it is a pointer, but a relative vs absolute pointer.

In that sense, you could call an index a pointer, but my point is that is doesn't work along as such, rather in relation a "real" pointer, like the array name.

***

And yes, Yoyo could use both of these pieces of syntax if they wanted to. At the moment, both single and double '=' are working as valid equality comparisons. I think you can still use some delphi constructs, but I seem to remember that this kind of thing was going to end up being removed by Yoyo. Maybe I'm wrong though.

0

My KBInput system is now on the marketplace here. It wraps up nice and tight GMStudio's input system into a few function calls making a user configurable input system that works the same regardless of what inputs the player has chosen including keyboard, mouse buttons, and gamepad/joysticks using DInput/XInput. The support forum topic for it is here.

And yes, Yoyo could use both of these pieces of syntax if they wanted to. At the moment, both single and double '=' are working as valid equality comparisons. I think you can still use some delphi constructs, but I seem to remember that this kind of thing was going to end up being removed by Yoyo. Maybe I'm wrong though.

Hopefully they fix it and make people use "==" for comparisons only. It's horrible programming practice to use a single "="

It is extremely rare for me to comment, but all programmers that want to learn how to write professional code and everyone that wants a professional, easy-to-use, flexible, and FAST gui/hud/inventory/etc. system should support this project's development. I have been employed as a programmer (C++/CLI, C#, VisualBasic.NET, JavaScript, etc.) and know what companies look for and use, and I want to let people here know that they are using gui frameworks similar to what iam1me is providing here (if only gml were more object-oriented). For those that don't understand the current and massive potential benefits, I will try to help explain...

Hopefully they fix it and make people use "==" for comparisons only. It's horrible programming practice to use a single "="

Hardly horrible programming practice. Lazy at worst.

Yeah. GML's made to be easy to use, so people don't have to bother with == vs =, or use semi-colons, or whatnot. It makes things easier for new coders. If you want a stricter syntax, use a different language.

1. Array functions. Been using PHP for a bit, and am sorely missing its lovely array functions in GM, especially foreach() http://php.net/manual/en/ref.array.php2. Named arguments in functions. Instead of:

show_message(argument0+argument2+argument1);

have

show_message(question+divider+answer);

3. Ternary operators. Instead of:

str="Hello ";
if (world)
str+="World";
else
str+="City";
str+="!";

Just have:

str="Hello "+(world ? "World" : "City")+"!";

It makes writing and maintaining code a lot easier. Obviously, these are only simplistic examples and not a real-world scenario.

I would also like to add some suggestions:
- support for .fli files (which can be used as animated backgrounds)
- animated loading screens
- update the build-in multiplayer functions. Game Maker should add support for client-server networking (rather than the peer-to-peer features mplay uses), so one can make games that
correctly can be played over the internet, lobbying servers, and Directplay Voice. As the current build-in mplay functions use the peer-to-peer technology, one can make multiplayer games for
20 players max. Whith the client-server approuch, this can be extended to infite or more.

I would also like to add some suggestions:- support for .fli files (which can be used as animated backgrounds)- animated loading screens- update the build-in multiplayer functions. Game Maker should add support for client-server networking (rather than the peer-to-peer features mplay uses), so one can make games that correctly can be played over the internet, lobbying servers, and Directplay Voice. As the current build-in mplay functions use the peer-to-peer technology, one can make multiplayer games for20 players max. Whith the client-server approuch, this can be extended to infite or more.

- Use a standard .avi format. That is a Quicktime (.mov-family) format, and Apple tends to not want to share. I'd say about half of PCs don't have Quicktime on them. In website development, I like to call it the 95% rule. If you know >95% of your users are able to view it, use it. Otherwise, find something else. If you want a good codec for animation compression, you can look into the H.263/4, Cinepack, or DV compressions. Cinepack is the most "global" but it doesn't give you all too good a quality. DV compression only works on 720x480 frames, and although it's a great format some computers may not always have the H.263/4 codecs.- There already are...- 39dll

I would also like to add some suggestions:- support for .fli files (which can be used as animated backgrounds)- animated loading screens- update the build-in multiplayer functions. Game Maker should add support for client-server networking (rather than the peer-to-peer features mplay uses), so one can make games that correctly can be played over the internet, lobbying servers, and Directplay Voice. As the current build-in mplay functions use the peer-to-peer technology, one can make multiplayer games for20 players max. Whith the client-server approuch, this can be extended to infite or more.

- Use a standard .avi format. That is a Quicktime (.mov-family) format, and Apple tends to not want to share. I'd say about half of PCs don't have Quicktime on them. In website development, I like to call it the 95% rule. If you know >95% of your users are able to view it, use it. Otherwise, find something else. If you want a good codec for animation compression, you can look into the H.263/4, Cinepack, or DV compressions. Cinepack is the most "global" but it doesn't give you all too good a quality. DV compression only works on 720x480 frames, and although it's a great format some computers may not always have the H.263/4 codecs.- There already are...- 39dll

-At the moment, you can't use a .avi file as a background. That's why I suggested .fli files, as they have the same effect, but in a different format.-You can't use animated loading screens as the Game Maker game loads.-I recently heard that Game Maker uses DirectX 7 for the build-in mplay functions, while the minimum system requirement is DirectX 8. So this have to be updated anyway. Butright now, one cannot make multiplayer games with the build-in functions that can be played over the internet. That's why I suggested to update the build-in functions,because I prefer not to use a DLL.

- 3D Model loading (I mean that there would be a subfolder like "Sprites" and "Objects") and a model editor.

- More ready sprites/backgrounds/sounds and examples. I would suggest you to put Mario and Pacman sprites/backgrounds/sounds and examples, because most people create clones of them. (And other famous games of course). Also, you could put ready 3D Models (okay I don't mean that you should create very good models, just basic)

- 2D/3D Room/Object selection. When you create a room, you could choose if you want it to be 2D or 3D. 2D rooms could put 2D objects (the ones with sprites) and 3D room could put 3D objects (the ones with 3D sprites/models). Also 3D rooms could have an 3D editor.

That's it. If I have more suggestions I'll tell you.

NOTE: I don't demand you to do these, I'm just giving you suggestions. Also, I don't know if anyone else here have posted the same things, because there are a lot of posts and I can't read them all.

-I recently heard that Game Maker uses DirectX 7 for the build-in mplay functions, while the minimum system requirement is DirectX 8. So this have to be updated anyway. Butright now, one cannot make multiplayer games with the build-in functions that can be played over the internet. That's why I suggested to update the build-in functions,because I prefer not to use a DLL.

No, it doesn't mean that at all.

GameMaker's DirectPlay 7 mplay can still be used to create applications that can be played over the Internet. However all participants need to port-forward their NAT devices. DirectPlay 8 does have much improved NAT traversal mechanisms, but that means a complete rewrite of GM's mplay API. That would be absolutely silly given mplay is Microsoft only, deprecated and slow.

YYGs has tweeted/blogged about replacing mplay with their own cross-platform API. It's likely to be socket based. Given 39DLL is also socket based, there should be enough similarity so that working with 39DLL should be portable to the YYGs Network API.

- More ready sprites/backgrounds/sounds and examples. I would suggest you to put Mario and Pacman sprites/backgrounds/sounds and examples, because most people create clones of them. (And other famous games of course). Also, you could put ready 3D Models (okay I don't mean that you should create very good models, just basic)

So you're encouraging copyright infringement? Fangames are technically illegal and YYG would potentially be in some kind of trouble for distributing copyrighted images of copyrighted characters like Mario or Pac-man. That is probably why Game Maker no longer has a "Pac-man" example. It's now disguised as a treasure hunt game. It plays like Pac-man though.

0

Read this before contacting me with a mentor request. This text file is subject to amendments at any time, without notice.

- More ready sprites/backgrounds/sounds and examples. I would suggest you to put Mario and Pacman sprites/backgrounds/sounds and examples, because most people create clones of them. (And other famous games of course). Also, you could put ready 3D Models (okay I don't mean that you should create very good models, just basic)

So you're encouraging copyright infringement? Fangames are technically illegal and YYG would potentially be in some kind of trouble for distributing copyrighted images of copyrighted characters like Mario or Pac-man. That is probably why Game Maker no longer has a "Pac-man" example. It's now disguised as a treasure hunt game. It plays like Pac-man though.

You're right. I respect copyright as well. I suggested this because it's easier to users to create Mario and other games' clones. I didn't know that was illegal, because YoYo is allowing this. Sanbox is full with clones. I don't know much about copyright stuff. I am new to Game-Making world. And if YoYo doesn't want to follow my suggestion it's ok. I am not demanding anything. It's their product so their decision

I don't want to be rude with anyone, I am friendly,D4RknEZz (known also as Manolis Greece)

Copyrighted sprites...Not going to happen. They could create more sprites to work with, including platformer sprites. But I don't think they really need to. There are plenty of free sprites available to get you started, and many of them are listed on this very forum in the graphics section, and the same applies to sound/music.

3d models....Seriously Doubt It Even though GM has a little 3d, it is meant for 2D game creation. I'm not against adding 3d, though they would be better off creating a separate project, and they have there hands full of competition in that arena too, between Unity and Shiva. On the 2d side, the competition is much less fierce, especially with the mobile platforms, which are more suited to 2d games anyway. And for indie developers, 2d is better for game creation for the most part anyway(though that is another argument for another topic) so I can't really disagree with Yoyo's decision to go for multi-platform 2D games creation.

Networking API...Could Happen. Here's the catch(NPT you already know this). Whatever yoyo adds to Game Maker is most likely going to be cross-platform, not only between windows and Mac, but Android and iOS, and likely HTML5 as well, and any number of other platforms that yoyo could want to do. This seriously limits API choices. Yoyo may/could choose to include things that aren't quite as cross-platform, specifying that things only work on certain platforms. GM's goals with Studio appear to be a "2D Unity" in that they want one code base to export to all available platforms with minimal changes. Box2D for physics is a good example, but it is open-source, and can be ported to all the platforms up to this point, including even the HTML5. Most anything Yoyo adds is going to be like that from here on out.

0

My KBInput system is now on the marketplace here. It wraps up nice and tight GMStudio's input system into a few function calls making a user configurable input system that works the same regardless of what inputs the player has chosen including keyboard, mouse buttons, and gamepad/joysticks using DInput/XInput. The support forum topic for it is here.