133 replies to this topic

[TheMagicNumber]

I think these should be removed:
- Mplay
- Pascal syntax
- "Treat uninitialized variables as 0"

I'm sure you're going to remove mplay, so don't use functions similar to 39DLL, improve on them. 39DLL is garbage.

By the way, stop getting off topic. This is what should be removed, not what you want. Stop asking for compiling, threading, and OpenGL.

[thatshelby]

Forgot about that. Remove 'Treat uninitialized variables as 0'. It causes more harm than good.

[FredFredrickson]

Another vote here for removing mplay. The idea behind the implementation of mplay was a decent one, but it just never played out the way it should have because its usefulness was stymied by its attempt at being simple.

So I'd definitely be in favor of trimming out mplay, especially if it meant replacing it with a built-in version of something a lot more robust; something along the lines of 39dll, for example.

[Nocturne]

Okay, my turn to list things...

• mplay. Been said in multiple posts why!
• Game information. Ugly and only really useful for examples... An integrated info screen/room is easy to program and looks much better.
• Horrible built in global variables like "health" and "score". Just as easy to make your own and less confusing to newer users...
• Triggers. I just don´t really see what they offer the user...
• Preload on sounds... modern pc´s really don´t need it. And while we are at it, the 3D sound functions are crap too and i don´t think anyone actually uses them (although I´m probably wrong!)
• Solid in the objects properties. I know this may not be liked by some people, but is it really that hard to program "x=xprevious" into a collision event? And it seems to cause more problems than it solves from my experience on the novice forums...
• Treat uninitialised variables as 0. The worst sin to ever have befallen mankind... Only good for maskin your own poor programming.

I think that´s about it for me...

Edited by Mark13673, 27 January 2011 - 04:48 PM.

[paul23]

hmm though one for me...

What I'd like is if all "standard" variables are gone from objects (and only enabled (in groups) when asked). But that's more of a feature (so we can actually make structures like linked lists without a huge performance hickup).


But on a more realistic note: mplay is always a troublesome thing, I personally haven't delved too deep in it. But given the simple fact people actually recommend NOT to use it should be a good indication it's a bad feature!


@mark:
For number 6, there's a good reason for using it though. You have the functions "move_outside" (or move_bounce).. However it would move an object outside all other objects.. Now to move outside a specific object, you simply set solid to true and then use "move_outside_solid". - So if it was to be removed, consider the functionality of this function!

Edited by paul23, 27 January 2011 - 04:43 PM.

[gnysek]

I'm using "then" in code... but begin and end can be removed, same as :=. GML is not a Pascal.

[Recreate]

I think these should be removed:
- Mplay
- Pascal syntax
- "Treat uninitialized variables as 0"

I'm inclined to agree with this.

[kburkhart84]

Forgot about that. Remove 'Treat uninitialized variables as 0'. It causes more harm than good.

This is my biggest thing that should be removed.

I would second the removal of Beginner/Advanced mode.

I have never used GM's mplay, but if it is as bad as it sounds, then it is also probably a waste of space.

Most of the other suggestions should not be removed. Just because you don't use them doesn't mean no one else does. Just like the first poll with external editors, most features don't get in the way if you don't use them. I myself love timelines. I haven't used triggers but I'm sure some people do.

[Nocturne]

@mark:
For number 6, there's a good reason for using it though. You have the functions "move_outside" (or move_bounce).. However it would move an object outside all other objects.. Now to move outside a specific object, you simply set solid to true and then use "move_outside_solid". - So if it was to be removed, consider the functionality of this function!

Could be replaced with "move_outside_object()"?

[GStick]

Definitely mplay and Game Information. Even for examples, Game Information can be replaced with rooms or the "Info" tab in Global Game Settings. I'm also not a friend of many of the built-in global variables like "score" and "health", although it's just as easy to ignore their existence and use your own, like "playerHealth" or whatever.

There's more things I would like changed than I would like removed, I think. I'm not sure I can come up with much else.

[GPro]

You should be choosing what to have in your GM, (from ur personal computer) so everyone can be thanked

[Dark Matter]

Variables like health, score.
Making objects solid.
Mplay should also be removed (though an alternative that works better would be good).

Edited by Dark Matter, 27 January 2011 - 05:14 PM.

[gnysek]

MCI_command and cd_xxx functions. Even Sony closed their biggest CD factory in USA.

Health and Score should left for begginners - remember, some people using Game Maker at school, so it can be first time that they programming - score and health works also without GML, by drag&drop actions.

Edited by gnysek, 27 January 2011 - 05:18 PM.

[NakedPaulToast]

Remove deprecated features
When a feature is deprecated, formalize its deprecating in the documentation, keep it in the next version for backwards compatibility, then actually remove in future versions.

ie. image_single

image_single was deprecated and replaced with image_speed/image_index years ago. V4 maybe V5. But it's still hanging around.

Action_* functions
I'm not saying to remove actions, but at least remove action_functions from being used directly and from within the function list and editors intellisense.

execute_string and execute_file
Horribly inefficient, can usually be avoided. The existence of these functions prevents or limits potential future GM features such as compiling or obfuscation.

cd_* functions
Do really need games to be playing CDs

max3, min3
deprecated years ago.

set_program_priority and priority related system
If a program performs poorly, the solution is to redesign and improve algorithms. Not to steal resources from my OS and other processes.

Edited by NakedPaulToast, 27 January 2011 - 05:39 PM.

[Dark Matter]

Remove deprecated features
When a feature is deprecated, formalize its deprecating in the documentation, keep it in the next version for backwards compatibility, then actually remove in future versions.

ie. image_single

image_single was deprecated and replaced with image_speed/image_index years ago. V4 maybe V5. But it's still hanging around.

Action_* functions
I'm not saying to remove actions, but at least remove action_functions from being used directly and from within the function list and editors intellisense.

execute_string and execute_file
Horribly inefficient, can usually be avoided. The existence of these functions prevents or limits potential future GM features such as compiling or obfuscation.

cd_* functions
Do really need games to be playing CDs

max3, min3
deprecated years ago.

set_program_priority and priority related system
If a program performs poorly, the solution is to redesign and improve algorithms. Not to steal resources from my OS and other processes.

Yeah, I agree with most of these, though there are circumstances where execute_string is useful...

[ragarnak]

I think these should be removed:
..
- Pascal syntax
..

If that is possible than I vote for removing any C(++/#/anything) syntax too. We're talking about GML here, not some derivative of some other language.

Triggers

I do not know if they have any real speed advantage, but for the rest they are doing something you can already do yourself. So: agreed.

And while we are at it, the 3D sound functions are crap too and i don´t think anyone actually uses them (although I´m probably wrong!)

Although they are not used often, 3D/directional sound can add quite a bid of atmosfere to 3D games (being able to determine from which direction your enemy tries to sneak up on you. No current 3D game could nowerdays do without it). So: Disagreed.

Solid in the objects properties. I know this may not be liked by some people, but is it really that hard to program "x=xprevious" into a collision event? And it seems to cause more problems than it solves from my experience on the novice forums...

Only if commands like "move_outside(...)" get enhanced to check for specific objects (like Mark13673 already mentioned). Alas, enhancing other functions was not part of the question. So: Disagreed.

[gnysek]

Yeah, I agree with most of these, though there are circumstances where execute_string is useful...

True. execute_string should left, it's like REMOVED) in other scripting languages. But execute_file gives you possibility to change everything in game in real time by injecting code - you can even create new objects, and gameplay in someone game! And export some data and resources without decompiling.

Edited by gnysek, 27 January 2011 - 05:59 PM.

[TheMagicNumber]

I think these should be removed:
..
- Pascal syntax
..

If that is possible than I vote for removing any C(++/#/anything) syntax too. We're talking about GML here, not some derivative of some other language.

Having two syntaxes that you can switch between at any time is silly. Just one is enough.

Of course, things like semicolons and (maybe) parenthesis-less statements would still be optional. Just make it impossible to mix begin/end and braces.

I'd also like to see the examples in the manual where all the code is in a block removed. You don't need all your code in a block.

[LSnK]

Having two syntaxes that you can switch between at any time is silly. Just one is enough.

Unless you use it. I don't feel like 'fixing' a hundred thousand lines of code to satisfy someone else's obsessive-compulsive urges for linguistic purity.

It's not the type of suggestion they're looking for anyway. There would be no performance or filesize gain, and it's a negligable amount of work to implement.

[ragarnak]

Having two syntaxes that you can switch between at any time is silly. Just one is enough.

Having a language which accepts a number of different ways to describe what you want just caters to people (teachers?) coming from other language than that C(whatever) language. You could even claim that it enables the teenagers using GML to choose which kind of notation they are most comfortable with. [/sarcasm].

Something just popped in my mind : those "||", "&&", "^^" should go too. We already have the way more intuitive "or", "and" and for anyone having done anything with booleans, "xor" for that.

But that again, some pople here swear by those "&&", "||" aand "^^" thingies. Who am I that I should decide they should be using my way of expressing such things ?

Of course, things like semicolons and (maybe) parenthesis-less statements would still be optional. Just make it impossible to mix begin/end and braces.

In other words: make it a strict syntax (maybe even switchable between certain preferences).

I would call that a big change to GM, and most likely not at all what Mark had in mind when he created it ...