

HOW TO GET GAME MAKER STUDIO 1.4 LICENSE CODE
However if you are using code to generate or manipulate tiles, then these will be converted into compatibility Scripts. Tile layers in GameMaker can only be grid snapped, and since legacy GameMaker permitted tiles to be placed off the grid, the only way to do that now is to use this new asset layer. Instead, they will be rendered to the new asset layer of the room editor. What does that mean for your legacy 1.4 projects? If your games have the tiles added through the room editor, then GameMaker will import them and should render them correctly, but they won't be tiles. This might sound similar to GMS 1.4, but behind the scenes the rendering of the tiles has been completely changed so that they are faster and more efficient, with the final goal being that they will be blindingly fast to render and easier to use for fast bounding box collisions. Now tiles, like backgrounds, are created from sprite resources and are added as layers from within the room editor. GameMaker has also overhauled how the tile layers are dealt with. This means that anything in your project that references backgrounds through code will be set to use compatibility scripts as all the background functions have been removed from the IDE.

Instead, all images are stored in GameMaker as sprites and then these are used for your background, tileset and graphics asset layers. GameMaker no longer has a background resource. That said, let's quickly look at what exactly you can expect to have changed. In this way you can quickly see what new functions are required to get the same output as well as any workarounds for those functions that have no direct counterpart in GameMaker. The compatibility report will be saved in the Notes resource of the resource tree, and we recommend that you check it and open and revise all the scripts that have been created when importing a 1.4 project.
HOW TO GET GAME MAKER STUDIO 1.4 LICENSE MANUAL
The Macros script exists because macros are no longer defined in a separate editor, but instead can be defined inline in the script editor (see the Manual for more details), and the global variables scripts are required for some of the compatibility scripts to function correctly. The scripts created will be held in a folder marked "compatibility", and there may be other scripts outside of this folder for Macros and Global Variables.

This reports the object events that have been changed as well as the compatibility scripts and macros that have been added to enable the project to keep working in GameMaker. When you import a 1.4 project (from the File > Import menu) into GameMaker, you will be presented with a compatibility report, much like the one shown below:

This meant that we had to find a compromise solution so that projects made with the previous version of GameMaker (GameMaker Studio 1.4) could still be imported and "just work". With GameMaker we wanted to improve certain areas of the render pipeline, the resource tree, and also and the way that the GameMaker Language (GML Code) is structured, but at the same time we didn't want to completely break backwards compatibility. If you are wanting to import a project from an older version of GameMaker, then you will first have to import it into GameMaker: Studio 1.4, fix any issues, and then export that to be used in GameMaker. Note however that GameMaker will do its best to import 1.4 projects and create compatibility Scripts for those functions that are no longer relevant, and you should find that projects from 1.4 will still run in GameMaker. Any project created with the 1.4 version of GM:S can be imported into GameMaker, but it may need some fixing since there have been a number of things that have been completely removed from the IDE and the GameMaker Language (GML Code). GameMaker has introduced some major changes to how things are done with relation to rendering and the creation of rooms, and this means that it is not backwards compatible with legacy GameMaker versions except GameMaker: Studio 1.4.
