Most of the stuff I see on this list is predictable and reasonable. I'm a bit surprised and disappointed to see some particle functions go, it will rather limit what you can do with them. I hope alternatives are going to be provided for.
I'll also really miss the pop-up menu and the file dialogs. They're not interesting from the perspective of a game, but I do use them when building a level editor and I need a quick selection box or a simple way to load and save external files. I hope they're at least going to push them into extensions, so we can keep on using them.
One other thing:
set_automatic_draw
This isn't a display-specific function, it's a engine-level control function. It was very useful to be able to decide ourselves whether to draw or skip drawing a certain step, so that the game could be throttled somewhat if a game step couldn't be made. Again, I hope some alternative throttling method is going to be provided.
In one of the older blog posts from mike he already hinted at this - and I asked for more information about it. - But this has to do with their decision to go to opengl, I don't remember the specifics, but in opengl they liked to use a mode where drawing happens at regular intervals -ONLY-. This forced drawing to happen always and only during the draw-event. And that in turn would make manual drawing obsolete.
As long as the file_find_* functions are still there however, it can be replicated with scripts.
However it is impossible to replicate NATIVE pop-up menus with scripts. And now that I read a bit more about application development I learned that this is one of the main important things in applications. (And something like a map-editor is useful for a game yet should behave like an application).
variable_local_exists and variable_local_set are also completely useless, at no point should you have undeclared variables, that's a terrible and silly practice.
I've already said it - but I guess it needs saying again. In programming passing a VARIABLE to a function is often much better than passing a value. There are many paradigms that depend on this: ie a function might have a failure condition, in which case one would return whether the function succeeds, and the actual value gets set in one of the passed variables. Sometimes it is semantically more correct to change a variable (ie think about the function "+=" - it add the right hand side to the left hand side semantically, that's semantically different from making a copy first). And many other times one wishes to have a "output variable" (speed considerations). There are several ways language use this:
- Older languages often used pointers. Simply pointing to memory where a variable is located & then changing that memory
- Newer languages like the pass-by-reference idiom (used in VB, C#, JAVA). Here you actually tell the compiler directly "that argument IS a variable, not a copy"
- If these are not possible sometimes arrays are used instead (only language I can think of are older version of fortran)
In C & basic family the programmer has total control over this by language keywords. - In java pass-by-reference was always applied, except for build in types in which pass-by-value was used. (Leading to types such as "Double"). In gamemaker a similar behaviour to JAVA is used - simple types (real, string) are passed by value; while when you pass an instance index/list it acts as a pass by reference.
The problem however is that there is no easy encapsulation of simple types possible in GM. You can't feasibly create a list with 1 value and then use that. That's just way too ugly, error prone, to even think about: GM lacks the OO capabilities for this. Previously one could pass the variable as (literal) string, and use variable_get_* functions to get the actual contents. But now I really don't see any way to pass-by-reference.
The other option - to pass arrays to functions - is even not possible at all in gm.
This certainly is my biggest objection to the new versions of GM & something I honestly don't know how/if I will work around yet.
