From 716ce36734ab6c0e87b3933906c299de05745923 Mon Sep 17 00:00:00 2001 From: YYBartT Date: Thu, 19 Dec 2024 23:02:34 +0100 Subject: [PATCH 01/14] docs(general):delta_time() example should not use hardcoded microseconds value YoYoGames/GameMaker-Bugs#8700 * Changed the code example to use game_get_speed(gamespeed_microseconds) and clarified that the base speed should also be expressed in pixels per step * Small changes to game_get_speed() page --- .../General_Game_Control/game_get_speed.htm | 23 +++++++++---------- .../Date_And_Time/delta_time.htm | 15 ++++++------ 2 files changed, 18 insertions(+), 20 deletions(-) diff --git a/Manual/contents/GameMaker_Language/GML_Reference/General_Game_Control/game_get_speed.htm b/Manual/contents/GameMaker_Language/GML_Reference/General_Game_Control/game_get_speed.htm index 2b6382e95..5a18f5419 100644 --- a/Manual/contents/GameMaker_Language/GML_Reference/General_Game_Control/game_get_speed.htm +++ b/Manual/contents/GameMaker_Language/GML_Reference/General_Game_Control/game_get_speed.htm @@ -4,7 +4,7 @@ game_get_speed - + @@ -15,8 +15,8 @@ -

game_get_speed

-

This function can be used to get the game speed as either the number of game frames to run per second or as the number of micro seconds per game frame. Note that this is not the actual running speed FPS value (for that use the fps_real variable) but rather the number of game frames (FPS) that the game will attempt to maintain each second, or the length of each game frame in microseconds that the game will try to maintain (MPF). When you use this function you need to give one of the following constants which will determine the type of the return value:

+

game_get_speed

+

This function can be used to get the game speed as either the number of game frames to run per second or as the number of microseconds per game frame. Note that this is not the actual running speed FPS value (for that use the fps_real variable) but rather the number of game frames (FPS) that the game will attempt to maintain each second, or the length of each game frame in microseconds that the game will try to maintain (MPF). When you use this function you need to give one of the following constants which will determine the type of the return value:

@@ -24,7 +24,7 @@

game_get_speed

- + @@ -43,7 +43,7 @@

game_get_speed

So, for example, if the game speed is set at 30 in the Game Options and you use the FPS type, then the function will return 30, but if you use the MPF then the function will return 33333.

 

Syntax:

-

game_get_speed(type);

+

game_get_speed(type);

Game Speed ConstantGame Speed Constant
Constant
@@ -53,32 +53,31 @@

Syntax:

- +
typeGame Speed ConstantGame Speed Constant The type of method used to get the game speed (see the constants above).

 

Returns:

-

Real

+

Real

 

Example:

-

if (game_get_speed(gamespeed_fps) != 60)
+

if (game_get_speed(gamespeed_fps) != 60)
{
    game_set_speed(60, gamespeed_fps);
}

The above code checks to see if the game is running with a game speed of 60 FPS and if not it is set to 60 FPS.

 

 

-

 

-

delta_time

+

delta_time

This variable returns the frame delta time, which is the time difference between the previous frame and the current frame. This value is in microseconds, where 1 microsecond is 1,000,000th of a second.

-

The purpose of delta timing is to eliminate the effects of the lag or slowness of computers that try to handle complex graphics or a lot of code. It is a value that can be multiplied with the speed of objects so that they will eventually move at the same speed, regardless of lag. This is achieved in GameMaker by using the delta_time variable every step as it measures the time that has passed between one step and the next in microseconds. Therefore the variable delta_time can be used to calculate how much faster (for example) a game character has to move to make up for a lag spike in the game.

+

The purpose of delta timing is to eliminate the effects of the lag or slowness of computers that try to handle complex graphics or a lot of code. It is a value that can be multiplied with the speed of objects so that they will eventually move at the same speed, regardless of lag. This is achieved in GameMaker by using the delta_time variable every step as it measures the time that has passed between one step and the next in microseconds. Therefore the variable delta_time can be used to calculate how much faster (for example) a game character has to move to make up for a lag spike in the game.

 

Syntax:

-

delta_time

+

delta_time

 

Returns:

Real (integer)

 

Example:

-

var _dt = delta_time / 1000000;
+

var _dt = delta_time / game_get_speed(gamespeed_microseconds);
speed = spd * _dt;

-

The above code will set the speed of the instance using delta-time to correct for lag. The variable "_dt" would be used to hold the previously calculated delta time value so that the ratio can be used to multiply the base speed value (held in the variable "spd") and to get a consistent speed for the instance.

-

 

+

The above code will set the speed of the instance taking delta time into account to correct for lag. The variable _dt would be used to hold the previously calculated delta time value so that the ratio can be used to multiply the base speed value (held in the variable spd and expressed in the same units as speed, i.e. pixels per step) and to get a consistent speed for the instance.

 

 

-
© Copyright YoYo Games Ltd. 2021 All Rights Reserved
+
© Copyright YoYo Games Ltd. 2024 All Rights Reserved

environment_get_variable

This function returns the value (a string) of the environment variable with the given name (also a string).

-

You can get the available environment variables on macOS and Ubuntu (Linux) by typing "env" into the terminal app, and for information on Windows environment variables, if you are using the command prompt then type "echo %PATH%", and using PowerShell it's "ls env". Note that on both macOS and Ubuntu (Linux) the "HOME" environment variable will return the "~/" path which maps to "/Users/<username>" on macOS and "/home/<username>" on Ubuntu (Linux).

+

You can get the available environment variables on macOS and Ubuntu (Linux) by typing "env" into the terminal app, and for information on Windows environment variables, if you are using the command prompt then type "set", and using PowerShell it's "ls env:". Note that on both macOS and Ubuntu (Linux) the "HOME" environment variable will return the "~/" path which maps to "/Users/<username>" on macOS and "/home/<username>" on Ubuntu (Linux).

 This function is for Windows, macOS and Ubuntu (Linux) only.

 

Syntax:

@@ -31,14 +31,14 @@

Syntax:

name - String + String The name (a string) of the environment variable to check.

 

Returns:

-

String

+

String

 

Example:

e_str = environment_get_variable("APPDATA");

@@ -52,7 +52,7 @@

Example:

Next: scheduler_resolution_get
-
© Copyright YoYo Games Ltd. 2023 All Rights Reserved
+
© Copyright YoYo Games Ltd. 2024 All Rights Reserved

tilemap_set_mask

This function sets the Tile Map Bit Mask for a single tile map.

-

You give the tile map element ID (which you get when you create a tile map element using layer_tilemap_create or when you use the function layer_tilemap_get_id), and then the mask value. If you have, for example, a pretty small tile set of 16 x 16 tiles then you have a total of 256 different tiles in your tile set. You only need 8 bits of the  to index these tiles (from an available 19 bits of data). These bits can be "masked" and then the rest of the tile data can be used to store additional values. See Calculating the Mask Bits.

+

You give the tile map element ID (which you get when you create a tile map element using layer_tilemap_create or when you use the function layer_tilemap_get_id), and then the mask value. If you have, for example, a pretty small tile set of 16 x 16 tiles then you have a total of 256 different tiles in your tile set. You only need 8 bits of the  to index these tiles (from an available 19 bits of data). These bits can be "masked" and then the rest of the tile data can be used to store additional values. See Calculating the Mask Bits.

Tile map bit masking is an advanced feature and allows you to use bits of the tile data "blob" for your own use. For example, you could reserve a bit to mean "solid" in the tile data that can then be checked for fast collisions. Basically, the bit mask is "and"-ed against the tile data when the tile map is drawn (so it doesn't affect any of the other functionality), meaning that bits which aren't in the mask are ignored, but can still be read and written to by the user for their own purposes.

 

Syntax:

From 09c4310ef1b3e44c765e4f7c1adc813e8b164a84 Mon Sep 17 00:00:00 2001 From: YYBartT Date: Mon, 13 Jan 2025 13:37:54 +0100 Subject: [PATCH 06/14] docs(general): Profiler docs refer to the time column unit as microseconds when it should be milliseconds YoYoGames/GameMaker-Bugs#8959 * Changed two mentions of "microseconds" to "milliseconds" * Updated a few names in the text to match IDE descriptions, along with a few other things --- .../IDE_Tools/The_Debugger/The_Profiler.htm | 40 ++++++++----------- 1 file changed, 16 insertions(+), 24 deletions(-) diff --git a/Manual/contents/IDE_Tools/The_Debugger/The_Profiler.htm b/Manual/contents/IDE_Tools/The_Debugger/The_Profiler.htm index 802389ebc..95e66b74b 100644 --- a/Manual/contents/IDE_Tools/The_Debugger/The_Profiler.htm +++ b/Manual/contents/IDE_Tools/The_Debugger/The_Profiler.htm @@ -4,7 +4,7 @@ The Profiler - + @@ -14,58 +14,50 @@ -

The Profiler

+

The Profiler

The Debugger permits you to step through your code and find any issues with the code base, but sometimes you need to check for subtler details in order to properly optimise your games. The Profile option helps to do just that by giving you a performance overview, showing the time it takes to call functions, scripts, and even how long it took a specific event to complete.

Debug Profile WindowApart from the main window showing all the different events, scripts and functions being called, you also have the following options for using the Profiler:

Enable / Disable

-

This is the button to enable or disable the Profiler. When enabled, the profiler will start and you will start to see events, scripts and functions be listed in the main window along with different data values for each of them. How this data is displayed - will depend on the Time Display and the View Mode (both explained in more depth below).

-


+

This is the button to enable or disable the Profiler. When enabled, the profiler will start and you will start to see events, scripts and functions be listed in the main window along with different data values for each of them. How this data is displayed will depend on the Time Display and the View Mode (both explained in more depth below).

+

 

Time Display

-

This checkbox permits you to switch between the average time and the absolute time for the profiler. When it is not checked, the values shown in the main window will be the total number of calls made to the - function, script or event and the total time taken (times are in microseconds) over the course of the profile. However if you enable this then these columns show the average time taken per step for each function, - script or event, and the average number of times that it was called.

-


+

This checkbox permits you to switch between the average time and the absolute time for the profiler. When it is not checked, the values shown in the main window will be the total number of calls made to the function, script or event and the total time taken (times are in milliseconds) over the course of the profile. However, if you enable this then these columns show the average time taken per step for each function, script or event, and the average number of times that it was called.

+

 

View Mode

This menu lets you choose the view mode, which can be either Top Down or Bottom Up.

-

Selecting the Top Down view mode will show the profile from the top down (more or less the same as the callstack hierarchy) so it will show the event, then the script and then any functions used. Note that you can double click LMB Icon on any of the entries to have it open in the Source debug window if you - have one. If you see a Expand Debug Icon icon beside a name then there are further script or function calls within that - section, and clicking the Expand Debug Icon will expand the tree to show them.

-

Selecting the Bottom Up view mode will show things from the bottom up so you can see all the functions and script calls individually. When using this view mode, clicking on the Expand Debug Icon will expand the function or script to show what actually called it.

-


+

Selecting the Top Down view mode will show the profile from the top down (more or less the same as the callstack hierarchy) so it will show the event, then the script and then any functions used. Note that you can double click LMB Icon on any of the entries to have it open in the Source debug window if you have one. If you see a Expand Debug Icon icon beside a name then there are further script or function calls within that section, and clicking the Expand Debug Icon will expand the tree to show them.

+

Selecting the Bottom Up view mode will show things from the bottom up so you can see all the functions and script calls individually. When using this view mode, clicking on the Expand Debug Icon will expand the function or script to show what actually called it.

+

 

View Target

-

The View Target permits you to choose between viewing the project GML (event and code data), the background engine processes or both. If you choose "GML", then you will get the events, functions and scripts being called - each step while the "Engine" view will only show the engine calls required by the project, enabling you to see any bottlenecks in the way that your project is handling things. If you select "Both", then both sets of data will - be displayed, but note that when combined with the "Bottom Up" view, the different script and function calls will be nested within the engine calls and you will need to click the Expand Debug Icon to expand these out to see them.

-


+

The View Target permits you to choose between viewing the project GML (event and code data), the background engine processes or both. If you choose My Code, then you will get the events, functions and scripts being called each step while the Engine Code view will only show the engine calls required by the project, enabling you to see any bottlenecks in the way that your project is handling things. If you select Combined, then both sets of data will be displayed, but note that when combined with the Bottom Up view, the different script and function calls will be nested within the engine calls and you will need to click the Expand Debug Icon to expand these out to see them.

+

 


The profile data is shown in four columns, and clicking on any of them will sort the data according to the column criteria.

Profile Display

 

 

-

 

application_surface_enable

This function enables or disables the application surface.

-

By default the application surface is enabled and all drawing for the Draw Events will be done to that and the surface drawn to the screen. However on some older devices and specific chipsets this may result in poorer performance. In those cases you can switch off drawing to the application surface and all Draw event drawing will then be done directly to the display buffer.

+

By default, the application surface is enabled and all drawing for the Draw Events will be done to that and the surface drawn to the screen. However, on some older devices and specific chipsets this may result in poorer performance. In those cases you can switch off drawing to the application surface and all Draw event drawing will then be done directly to the display buffer.

You can use this function to enable or disable the application surface at any time in your game, but you should note that it requires at least one frame (step) for the changes to take effect. Switching it off will switch off all aspect ratio correction, as set in the Game Options for the target platform. This means that you should have some method in place that scales the game to the required device, window or screen dimensions. If you switch it back on again, then the Game Options will take effect again the next step.

It is recommended that you use this function carefully as it will impact on how everything is drawn to the screen. In general you would want to have it as an option in a menu of your game, or call it only once at the start of your game and write your code around whether you have it enabled or disabled.

 Disabling the application surface will disable all Filters and Effects.

diff --git a/Manual/contents/The_Asset_Editors/Object_Properties/Draw_Events.htm b/Manual/contents/The_Asset_Editors/Object_Properties/Draw_Events.htm index c7762e8d5..736a4a987 100644 --- a/Manual/contents/The_Asset_Editors/Object_Properties/Draw_Events.htm +++ b/Manual/contents/The_Asset_Editors/Object_Properties/Draw_Events.htm @@ -18,7 +18,7 @@

Draw Events

The Draw EventThe Draw event category is the one that has all the events that govern what you see on the screen when you run your game. It is split into various separate events to better handle the different drawing requirements for your game. The image below illustrates the order in which the events are performed: 

Object Editor Draw DiagramThe normal Draw event falls into three sub-types: The Draw Begin, the standard Draw and the Draw End events. In general, you will only need to use the standard Draw event and you should be aware that all instances in a room will have this event triggered each step of the game, so this event will always be called as long as the instance has the visible flag set to true. It is important to understand that even if you have defined nothing for this sub-event in the object properties (i.e.: no code nor actions), if the object has a sprite assigned it will still have a Draw event which will be triggered. This is because GameMaker has two ways to draw things in the Draw event:

The rest of the Draw events are explained in the sections listed below:

From dbb190e8c0ad3279343f01625441492b3a246793 Mon Sep 17 00:00:00 2001 From: YYBartT Date: Tue, 14 Jan 2025 12:22:40 +0100 Subject: [PATCH 08/14] docs(general): Link to anchor "Editing Individual Tiles" not working on "Tile Map Elements" page. YoYoGames/GameMaker-Bugs#8920 Fixed incorrect link --- .../Rooms/Tile_Map_Layers/Tile_Map_Layers.htm | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Manual/contents/GameMaker_Language/GML_Reference/Asset_Management/Rooms/Tile_Map_Layers/Tile_Map_Layers.htm b/Manual/contents/GameMaker_Language/GML_Reference/Asset_Management/Rooms/Tile_Map_Layers/Tile_Map_Layers.htm index 96195858b..2dbc187d0 100644 --- a/Manual/contents/GameMaker_Language/GML_Reference/Asset_Management/Rooms/Tile_Map_Layers/Tile_Map_Layers.htm +++ b/Manual/contents/GameMaker_Language/GML_Reference/Asset_Management/Rooms/Tile_Map_Layers/Tile_Map_Layers.htm @@ -61,7 +61,7 @@

Tile Data "Blob"

Tile Map Bit Mask

You have the possibility of adding your own bit mask to a tile map in order to use bits of the tile data "blob" for your own use, although this is for advanced users only as you will be masking off bits that are reserved for the tile index. There are 19 bits reserved for your tile indices, but if you only use 8 of them, then you have eleven bits left over that can be used to create a custom mask. This mask can then be used and checked in code to create custom tile collisions or whatever.

The bit mask is "and"-ed & against the tile data when the tile map is drawn (so it doesn't affect any of the other functionality), meaning that bits which aren't in the mask are ignored, but can still be read and written to by the user for their own purposes.

-

However, you would normally not need to create your own tile data blobs, and would instead use the function tilemap_get to get the tile data, then you would manipulate it using the functions for Editing Individual Tiles, and then you would set it again using tilemap_set.

+

However, you would normally not need to create your own tile data blobs, and would instead use the function tilemap_get to get the tile data, then you would manipulate it using the functions for Editing Individual Tiles, and then you would set it again using tilemap_set.

 Aside from a mask per tile map, there is also a global one. The two are bitwise "and"-ed & together internally by GameMaker before being used for drawing.

Calculating the Mask Bits

To get an initial index mask value you take the number of tiles in the tile set and subtract 1, so a 16x16 tile set has 256 tiles and a mask value of 255 (or $ff in hexadecimal). If the tile set has a number of tiles that's not a power of two, then round up to the nearest power of two to get the mask, for example a tile set that is 20x20 has 400 tiles, which you would round up to 512, and so get a mask index value of 511 ($1ff in hexadecimal). Apart from the index mask, normally you would want to preserve the flip, rotate and mirror values that are assigned to a tile too, to help with that there are the constants under Tile Mask Constant that can be used. These can be bitwise "or"-ed | together with the index mask value to preserve those bits of data.

@@ -122,7 +122,7 @@

Editing Individual Tiles

Next: Background Elements
-
© Copyright YoYo Games Ltd. 2023 All Rights Reserved
+
© Copyright YoYo Games Ltd. 2024 All Rights Reserved
-

GM_build_date

-

This constant holds the date and time on which the executable being run was built by GameMaker. The value can be parsed using the Date and Time functions and is taken from the system UTC value at compile time.

+

GM_build_date

+

This constant holds the date and time on which the executable being run was built by GameMaker. The value can be parsed using the Date And Time functions and is taken from the system UTC value at compile time.

 

Syntax:

-

GM_build_date;

+

GM_build_date

 

Returns:

-

Datetime

+

Datetime

 

Example:

draw_text(32, 32, date_time_string(GM_build_date));
@@ -29,7 +29,6 @@

Example:

The above code will draw the version number for the game and the date and time it was compiled on.

 

 

-

 

GM_build_type

-

This string constant holds the type of the build: "exe" for a created executable or "run" for a test run started from the IDE.

+

This string constant holds the type of the build: "exe" for a created executable or "run" for a test run started from the IDE.

 

Syntax:

-

GM_build_type;

+

GM_build_type

 

Returns:

String

@@ -29,7 +29,6 @@

Example:

The above code will draw the build type of the currently running executable.

 

 

-