In the process of porting a game made with a legacy version of GameMaker (7.0, 8.1 and 8.1) over to GameMaker:Studio, it is normal get a few compiler errors when you first run the game. Some of these will be caused by Triggers and Extensions being missing, while others are caused by the use of obsolete functions.
This article aims to show which functions have been removed as well as explain a bit about why they were removed and how to fix the issues caused by them not being available for your game any more.
For information on how to import your game to GameMaker:Studio, as well as on how to fix issues with Triggers or Extensions, please see the following article:
You can also find a complete list of all the obsoleted functions here:
Before getting started, however, it is worth noting that porting games made with previous versions of GameMaker over to GameMaker:Studio will be more difficult the more complex the game you are porting. the differences between versions stack up the more complex your code base, so it may be that it is better to finish your game in the previous version and keep your GameMaker:Studio for new projects only.
In previous versions of GameMaker, you could read and write data to the Windows Registry. However this is considered a major security issue, and is also not compatible with other platforms (like Android or iOS), meaning that these functions have been removed from GameMaker:Studio.
There are a number of ways that you can get around the use of these functions, with the principal one being to use the ini file functions, but you can also use text files, binary files, or the (new in GameMaker:Studio) buffer functions.
In GameMaker:Studio, the message functions (like show_message()) have been deprecated and are now only available for debugging your game, and the splash_*() functions have been removed altogether. These functions effectively blocked the game loop and took over the runner, which is really only something that you can do on Windows, as on almost all other platforms, the OS will think that your game has crashed and try to close it.
Unfortunately, if your game uses the splash functions, the only work-around for you is to create your own "in-game" splash screen using a room and objects with sprites. However it is worth noting that GameMaker:Studio integrates the PlayHaven API for the Android target module, meaning that if you sign up with them for advertising, you can create certain custom content that will appear as an overlay (splash) on your game.
The get_* and show_* functions in previous GameMaker versions were an important tool to many users, permitting the rapid creation of dialogues to request information. Thankfully, GameMaker:Studio has not obsoleted them completely, but rather deprecated them in favour of new asynchronous versions that perform the same task as before but without actually stopping the game from running while waiting for a response from the user.
NOTE: The deprecated functions can still be used when testing your game in debug mode, but they will not show on most platforms when the game is compiled.
The async functions are triggered like previous get and show functions, but they are now associated with their own event - the Asynchronous Event - with the Dialogues Event category being triggered by most of them. For example, where you would previously have had:
num = get_integer("Choose a number", 0);
In GameMaker:Studio it would look more like this:
num = get_integer_async("Choose a number", 0);
It looks the same but now the variable "num" does not hold the return value of the question, but rather the "handle" or "id" of the async request. This id will then be used in the above mentioned Async Event to retrieve the value that the player entered, like this:
var i_d = ds_map_find_value(async_load, "id");
if i_d == num
if ds_map_find_value(async_load, "status")
global.Age = ds_map_find_value(async_load, "value");
The main difference with this approach and the previous one is that the game will keep running in the background while waiting for the user to respond to the message. This means you have to be careful where you call the function so as not to annoy the user, or you maybe want to pause the game until you receive the async callback.
For further information see:
Message_ And Highscore Functions
The message_* customisation functions have been removed completely from GameMaker:Studio, meaning that any async message dialogues that are shown to the user will all be the standard set by the OS of the target platform. The same goes for the highscore_* functions, with the exception of draw_highscore() which will still work to give you a limited highscore display using the font and colour that you set in code.
Since these functions cannot possibly work in a multi-platform environment, the only way to get around any issues they cause is to remove them completely from your game and code your own message and highscore displays using the draw functions and sprites/fonts.
You can still use particles in GameMaker:Studio, and you should even find that they are far more efficient than before. Part of this is because of the removal of a number of advanced particle functions, namely:
- particle attractors
- particle changers
- particle deflectors
- particle destroyers
That may seem a large part of the particle functions, but unfortunately they were not at all efficient due to the fact that the original particle is designed to be created and "forgotten" by the game, performing the predefined changes in scale, alpha etc... over its lifetime in an automatic way. Therefore to perform any further calculations or changes on any given particle required that the game keeps track of all of them! This made the functions far slower than they should be for a purely graphical effect and so all the code that could modify a particle after its creation has been removed from GameMaker:Studio.
The workaround for this would be to create "pseudo" particle instances, rather than "true" particle effects. These would be simple objects with a set of start values that are changed through an Alarm (or the Step Event) until a condition is met that will destroy, change, attract or deflect the instance (all of which can be done easily through code). You may need to limit the amount of these "pseudo" particles that you create, but with all the increases in speed of execution that you gain when porting to GameMaker:Studio, this may not be an issue since everything is much faster anyway.
Another part of GameMaker:Studio that has been over-hauled is the sound. previous GM versions were very limited in that department, and although GameMaker:Studio still has the legacy sound_* functions they have been deprecated in favour of the newer audio_* functions.
If your game only uses the basic sound functions, then you should not have to make any changes and it will just work (if not, then check the General Global Game Settings as there is an option there to use new audio which should be unticked for legacy projects). But if your game used any audio effects or 3D sound then you will need to make changes.
There are currently no GameMaker:Studio equivalent functions for these effects, so you will have to remove the functions from your game. This may mean that you will have to redo some of the sounds in an external editor to add the desired effect and then import it back into GameMaker:Studio.
3D sound is available to you in GameMaker:Studio, but not using the previous functions. The new audio engine has a number of advanced emitter and listener functions that permit you to control 3D audio like never before in the GameMaker series, but it also means that you must enable the new audio in the Global Game Settings and change all your current legacy sound codes.
For 3D sound using the new audio, you will need to indicate that the sound is to be used as such when you first load it into GameMaker:Studio as a sound asset. This will convert it automatically on each platform to the required format. You would then code your game to play the sounds through emitters which can then be moved and positioned through code. this may seem more complex, but it gives a far greater degree of control as well as a greater selection of tools, than the legacy audio could.
Other Sound Functions
The rest of the obsoleted sound functions deal with preloading sound to memory and discarding it (which is no longer necessary as all sound is loaded on startup unless streaming audio), unsupported file types (midi) and panning (which can be done easily with the new audio system).
Dynamic functions are those that changed integral parts of a game at runtime, like adding a new object, running code from a string or adding code to a timeline. This also includes the set of functions used to test for the existence of different scoped variable and arrays.
You can no longer create objects at run-time in GameMaker:Studio. This ability was removed due to changes in the underlying runner that GameMaker:Studio uses to generate the device specific packages, and removing it has also helped increase logic efficiency, giving your game better performance.
If you used these functions in your game, then your best bet to work around them is to first create a script library with all the code different code from the code-blocks that you were adding to your object. you would then create a new "chameleon" object with a controller variable in the create event and, in all further events that the object will need to use, have a switch() check of this variable to run the appropriate script. Now when you create this object, you simply set the initial values needed and the control variable to have it perform the associated scripts in the correct event.
The variable_*() functions have been completely obsoleted in GameMaker:Studio, with no replacements due to them being incredibly slow to execute and also often used as an excuse for sloppy/lazy programing.
How you work around this will depend largely on what you were using the functions for. The two most common uses and workarounds are outlined below:
Initialising a variable within an instance in the room creation code - It was common practice in GM7 and GM8/8.1 to initialize a variable from the instance creation code in the Room Editor and then do a variable_local_exists() check in the Create Event of the object to see if it existed or not then set it to a default value if it didn't. in this way you could give custom values to individual instances, however in GameMaker:Studio this process has been reversed. Now, all the instances run their Create Event first, and then any Room Editor instance creation code after, meaning that your create event can define the default value for the variable, and then you can override it in the creation code, setting it to a custom value, on a per-instance basis.
Checking for a variable in a script - Some people, when writing scripts, required a specific variable to exist as they want to set and manipulate it's value. So, rather than initialise it in the Create Event of an object, they would just initialise it in the script itself if it doesn't already exist. To fix this, remove the variable check from the scripts and simply initialise the variable in the Create Event of the object.
Other circumstance for using the variable functions will need to be fixed up on a case by case basis, but generally they can all be solved by simply initialising the variables/arrays in the Create Event of an object.
GameMaker:Studio now imposes a number of restrictions on the dynamic creation of game assets:
Adding sprites and backgrounds using the *.gmXXX format - This has been removed as the format is no longer supported.
Adding sprites, backgrounds and sounds from external files - This has been greatly changed, and you must now include all externally loaded resources with the game bundle as an Included File, or provide a valid URL to download the asset from. The functions will now return a "handle" or "id" for the asset being requested which must be checked in the new Asynchronous Event under the appropriate category. This event returns a ds_map with the id of the requested resource which can then be used as normal in your game.
NOTE: Adding multiple graphics assets to your game in this way will degrade performance due to each new image requiring it's own, unoptimised, texture page, and so increasing the texture swaps required each frame. This means you should use this function only when absolutely necessary.
Replacing or manipulating assets - You can no longer replace a sprite or background directly since it is stored on a texture page along with other images. Therefore you must first duplicate the image (creating a new texture page only for that image asset) and replace the duplicated asset. This is also true for setting the alpha of an image asset. For sounds, you can only use the replace function on added sounds and only then when running your game using the legacy audio system.
Creating new assets from the screen - The functions to create or add images to the sprites and backgrounds assets from the currently drawn screen have been removed. Their functionality was based on Windows only behaviour and could not work on any other platform correctly. To replace these functions, you will need to use a surface and the appropriate functions to create an asset from that.
The upshot of all these changes is that you really should try and include all your game assets within your final game as sprites, backgrounds or audio. GameMaker:Studio is optimised to give the best performance possible with all assets included within the game bundle, so using the above mentioned functions will, inevitably, incur a performance hit. This is negligible for small numbers of assets, but if you are wishing to import large amounts, or constantly change them at runtime, you should probably rethink the structure of your game.
Previous versions of GameMaker had the function execute_string(). This has been removed in GameMaker:Studio for a number of reasons:
- It was a potential security issue
- It required a GML parser in the runner
- It was incredibly slow performance-wise
- It was almost never really necessary to use
How you work around this will greatly depend on how you used the function and due to this it's impossible to give any further fixes. However, in the particular (and common) case where it was being used to parse a string to dynamically choose a game asset, in GameMaker:Studio you now have two dedicated functions which can be used to fullfill the same purpose:
Both these functions take a string as the "name" of the asset to be checked, and so can be used to dynamically select game assets from code.
There have been a number of display and window functions obsoleted in GameMaker:Studio. Most of these functions were for customising the game window or for setting the desktop resolution and display size, so obviously on most target platforms these are no longer applicable. There is no work around for these functions and they should simply be removed from the game code.
Note that among these functions you will find the screen_refresh() and screen_redraw() functions. The removal of these may cause problems for those of you that use surfaces in your game, since they were commonly used in older versions of Gamemaker to "capture" a screen to a surface for later manipulation or for pausing.
To get around this you will have to now assign a surface to a specific view using view_surface_id. This will assign all drawing that is being done in that view to draw to the surface canvas instead of the screen canvas. This surface can then be drawn and manipulated as normal.
These functions are obsolete in GameMaker:Studio as they are outdated and not compatible with any of the other target platforms. However GameMaker:Studio now has a far more flexible and easy to use system for networking using Web Sockets, so you may wish to re-write your code using them. For further information see the Networking page of the GameMaker:Studio Manual.
These functions have been removed from GameMaker:Studio due to the fact that they are not necessary anymore and they are not compatible with the cross-platform focus of the program. You should remove these functions from your game.
There are a number of other functions that had very specific tasks on Gm7.0/8.0/8.1 which have been made obsolete in GameMaker:Studio. Most are obsolete because they are no longer valid in a modern cross-platform environment and the exact work around you use will very much depend on the purpose of code that you used them.