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. 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). 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.
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.
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. 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". Enter compatibility scripts.
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 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. 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.
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 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. 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.
That said, let's quickly look at what exactly you can expect to have changed...
GameMaker no longer has a background resource. Instead, all images are stored in GameMaker as sprites and then these are used for your background, tileset and graphics asset layers. 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.
GameMaker has also overhauled how the tile layers are dealt with. Now tiles, like backgrounds, are created from sprite resources and are added as layers from within the room editor. 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.
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. Instead, they will be rendered to the new asset layer of the room editor. 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.
However if you are using code to generate or manipulate tiles, then these will be converted into compatibility Scripts. The tile system has changed dramatically as it was a major bottleneck in the processing and rendering of a room in legacy GameMaker, meaning that all those functions have been removed and replaced by a more robust method using layers and tilemaps.
D3D / Drawing / Textures
In GameMaker you should be using the vertex buffers to properly create 3D models or any type of primitive, especially since the old iteration of 3D in GML gave rather poor performance and these are much faster and more versatile. To that end, a number of functions have been removed from the language and you will have to look at creating your own vertex formats and buffers to re-create their functionality. The same can be said of the old D3D camera functions, which have instead been moved over to use a new set of matrix functions, permitting you a far greater control over the view camera for 3D scenes.
Apart from those functions, a great number of the draw_set_* and texture_* functions have been renamed to make them more context specific and consistent and they can now be found under the GPU function list (check the manual). For example, texture_set_interpolation has now become gpu_set_texfilter. These things will be changed for you when you import a GMS 1.4 project and will appear in the compatibility scripts.
Cameras And Views
The old views have been removed from GameMaker and instead have been replaced by cameras and view ports. You still have 8 different view ports into the game room, but now instead of assigning views you can assign a camera instead. Cameras can be created and destroyed like any other dynamic resource, and you do not have to assign a camera when it is created, but can instead store the ID value for it in a variable and assign it to a view port at any time. So, you can have (for example) three different cameras defined and then apply them to a view port at different times to create a cutscene.
GameMaker has NO deprecated functions. Previous versions of GMS had deprecated a number of APIs (like the "sound" api in favour of the audio API) and functions, but to make a clean break and keep everything new and fresh, these deprecated features have been completely removed from GameMaker. This means that any project that still used these deprecated functions will just not work and you will either need to continue working in GMS 1.4 or remove them and use an alternative.
The removed API's and Functions include:
Date and time functions - most of the date and time functions are still relevant, but there have been some that are removed and no longer in the IDE
Sound functions - all sound functions have been removed and you should switch over to use the audio functions
Particles - All the deprecated particle functions related to changers, destroyers, attractors, etc... have been removed from the IDE
Actions - The old action_ functions that were internally used for D&D have been removed. D&D now creates native GML so these will no longer work.
GM8 Legacy functions - These were rendered inoperative some time back, but were still present in the IDE and have now been removed. This includes the CD, registry, message, screen window and display functions. This shouldn't be an issue as you shouldn't have been using them anyway.
These are the main things that you may notice that have gone, but there are more. To find out if a function you require is obsolete, go to the Search option in the manual (not the Index) and type in the function name you are looking for, and if it is obsolete then the link will take you to the obsolete functions page.
So that's more or less what you can expect when you import a legacy game into GameMaker. We hope that your games will "just work" in GameMaker and we have worked hard to maximise compatibility and keep the migration as painless as possible, but there may be some edge cases where compatibility scripts either fail or aren't created. If that is the case then please file a bug (see here for details on how to do that).
You can find more information on the obsolete functions here: GameMaker Obsolete Functions List
You can find more details on the new functions here: GameMaker New Functions