diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml index 5bdc01960..74904c219 100644 --- a/.github/workflows/build.yml +++ b/.github/workflows/build.yml @@ -40,7 +40,7 @@ jobs: shell: cmd working-directory: Manual - name: Upload robohelp zip file - uses: actions/upload-artifact@v3 + uses: actions/upload-artifact@v4 with: name: YoYoStudioRoboHelp path: output\RoboHelp\*.zip diff --git a/Manual/contents/Additional_Information/Errors/Compiler_Errors.htm b/Manual/contents/Additional_Information/Errors/Compiler_Errors.htm index cfbfcbdf2..8e06ebde7 100644 --- a/Manual/contents/Additional_Information/Errors/Compiler_Errors.htm +++ b/Manual/contents/Additional_Information/Errors/Compiler_Errors.htm @@ -162,7 +162,7 @@
A buffer (in programming) is basically a space within the system memory that is used to store small packets of data for just about anything (for example: data transfer, collisions, colour data, etc.). Since it is held in system memory it is very fast to access, and a buffer would generally be used for very short-term storage, like receiving network information before processing it, or for storing a checkpoint in your game (this is explained in the example given further down the page).
-
Buffers are created by allocating a space in the system memory, calculated in byte s, which is then reserved for your game as long as your game is running or until you delete the buffer using the appropriate function (you can find all the GML buffer functions listed here). This means that even when your game is not in focus (for example, on a mobile device when you take a call the game will be put into the background) the buffer will still exist, however if the game is closed or re-started the buffer will be lost.
Buffers are created by allocating a space in the system memory, calculated in byte s, which is then reserved for your game as long as your game is running or until you delete the buffer using the appropriate function (you can find all the GML buffer functions listed here). This means that even when your game is not in focus (for example, on a mobile device when you take a call the game will be put into the background) the buffer will still exist, however if the game is closed or re-started the buffer will be lost.
Restarting the game will not clear or delete the buffer! But it will prevent any further access to the previously created buffer as the ID handle will have been lost, causing a memory leak which will crash your game eventually. So, when re-starting a game, remember to delete any buffers first.
GameMaker permits the creation of four different buffer types. The reason for this is that buffers are designed to be a highly optimised temporary storage medium, and as such you should create a buffer that is appropriate to the type of data that you wish it to store, otherwise you could get errors or cause a bottleneck in your code. Before explaining this further, let's look at the four available buffer types (defined as constants in GML):
-
| Constant | -Description | -
|---|---|
| buffer_fixed | -- A buffer of a fixed size in bytes. The size is set when the buffer is created and cannot be changed again. |
-
| buffer_grow | -- A buffer that will grow dynamically as data is added. You create it with an initial size (which should be an approximation of the size of the data expected to be stored), and then it will expand to accept further data that overflows this initial size. |
-
| buffer_wrap | -- A buffer where the data will wrap. When the data being added reaches the limit of the buffer size, the overwrite will be placed back at the start of the buffer, and further writing will continue from that point. |
-
| buffer_fast | -- This is a special "stripped down" buffer that is extremely fast to read/write to. However it can only be used with buffer_u8 data types, and must be 1 byte aligned. (Information on data types and byte alignment can be found further down this page). |
-
Those are the buffer types available to you when using GameMaker, and which one you choose will greatly depend on the use you wish to put it to. For example, a grow buffer would be used for storing a "snapshot" of data to create a save game since you do not know the actual amount of data that is going to be placed in it, or a fast buffer would be used when you know that the values you are working with are all between 0 and 255 or -128 and 127, for example when processing ARGB data from an image.
When creating a buffer, you should always try to create it to a size that is appropriate to the type, with the general rule being that it should be created to accommodate the maximum size of data that it is to store, and if in doubt, use a grow buffer to prevent overwrite errors.
player_buffer = buffer_create(16384, buffer_fixed, 2);
That would create a fixed buffer of 16384 bytes and byte-aligned to 2, with the function returning a buffer handle that is stored in a variable for later referencing of this buffer.
When reading and writing data to a buffer, you do it in "chunks" of data defined by their "data type". The "data type" sets the number of bytes allocated within the buffer for the value being written, and it is essential that you get this correct otherwise you will get some very strange results (or even errors) for your code.
+When reading and writing data to a buffer, you do it in "chunks" of data defined by their "data type". The "data type" sets the number of bytes allocated within the buffer for the value being written, and it is essential that you get this correct, otherwise you will get some very strange results (or even errors) for your code.
Buffers are written to (and read from) sequentially, in that one piece of data is written after another, with each piece of data being of a set type. This means that you should ideally be aware of what data you are writing to the buffer at all times. These data types are defined in GML by the following constants:
So, say you have created a buffer and you want to write information to it, then you would use something like the following code:
@@ -136,7 +109,7 @@To add behaviours to objects you can construct your code using Actions from the different libraries available to you from the Action Toolbox. To start with you'll need to make a new GML Visual project and then make a new object (you can assign a sprite to the object too if required). In your new object you can start to add events, and in the events add your GML Visual code actions.
-
Note that when you add a new event, a "code" window is opened with a tab for the given event (see the image above), and you can now drag any action you wish from the Toolbox on the right into the Action Block pane of the code window. Now, while it's true that you can add any action, that doesn't mean that they will all work or that the project will compile with them. Some actions require at least one variable to work, while others - like the Draw actions - will only work if used in a specific event. How do you know which ones to use? Well, generally, it's simply a question of using logic... if an action requires a variable and we haven't defined one yet, then we shouldn't be using it until we've added an action to create the variable.
When you drag an action from the Toolbox into the main Action Block workspace, it will expand to show you the available arguments (parameters) that you can fill in and change to set the behaviour. In the image below, we have dragged an Assign Variable action from the Toolbox Common library into the action block workspace:
-
You can see that the new action is also shown on the left of the code window in a shorthand form. This list of actions, called the action Overview, can be clicked on to quickly navigate to that action for editing. You can continue to add actions to the event should you need to, with each new action being "chained" to the previous one to show the flow of the GML Visual code you are constructing. Note that the area where you can drop further actions is highlighted for you underneath the initial action, and, depending on the action you are using, different areas will highlight to show where in the chain you can add it:
As you add actions to the workspace, they will be "chained" to the actions above so you can see how the GML Visual code flows, with one action leading to another, and the overview pane shows them in shorthand form and in order of execution:
Some actions will place code in a separate chain away from the main flow - things like If Variable will create a sub-chain of actions that should occur if the correct conditions are met before continuing on with the main chain:
Note that when using actions that can have a side chain block like this, the action will have two areas highlighted for dropping further actions:
To add behaviours to objects you can construct your code using Actions from the different libraries available to you from the Action Toolbox. To start with you'll need to make a new GML Visual project and then make a new object (you can assign a sprite to the object too if required). In your new object you can start to add events, and in the events add your GML Visual code actions.
+
Note that when you add a new event, a "code" window is opened with a tab for the given event (see the image above), and you can now drag any action you wish from the Toolbox on the right into the Action Block pane of the code window. Now, while it's true that you can add any action, that doesn't mean that they will all work or that the project will compile with them. Some actions require at least one variable to work, while others - like the Draw actions - will only work if used in a specific event. How do you know which ones to use? Well, generally, it's simply a question of using logic... if an action requires a variable and we haven't defined one yet, then we shouldn't be using it until we've added an action to create the variable.
When you drag an action from the Toolbox into the main Action Block workspace, it will expand to show you the available arguments (parameters) that you can fill in and change to set the behaviour. In the image below, we have dragged an Assign Variable action from the Toolbox Common library into the action block workspace:
+
You can see that the new action is also shown on the left of the code window in a shorthand form. This list of actions, called the action Overview, can be clicked on to quickly navigate to that action for editing. You can continue to add actions to the event should you need to, with each new action being "chained" to the previous one to show the flow of the GML Visual code you are constructing. Note that the area where you can drop further actions is highlighted for you underneath the initial action, and, depending on the action you are using, different areas will highlight to show where in the chain you can add it:
As you add actions to the workspace, they will be "chained" to the actions above so you can see how the GML Visual code flows, with one action leading to another, and the overview pane shows them in shorthand form and in order of execution:
Some actions will place code in a separate chain away from the main flow - things like If Variable will create a sub-chain of actions that should occur if the correct conditions are met before continuing on with the main chain:
Note that when using actions that can have a side chain block like this, the action will have two areas highlighted for dropping further actions:
You can change the position of actions within the chain by simply clicking
and dragging them into the new position that you require, and if you do a click
and hold for a second then move the mouse, you can move the action within the workspace while maintaining its place within the action block chain.
It is also possible to add comments to GML Visual actions, so you can leave notes beside different blocks to explain what they do (which is especially useful when working in a team):
+
You can find out more about this feature from the page on the Right Mouse Button Menu.
That's the basics of using the GML Visual code editor, but there are further important details explained in the sections below:
++ +
It is important to note that many actions offer a "target" variable, which can be flagged as "Temporary", for example:
+
What this means is that you can supply a variable which is the target to hold the value returned by the action. In the example action above, the action will return the volume of the audio resource that you select, so you supply a target variable to hold this value so you can reference it later.
Now, this target variable will need to have been declared previously either using Assign Variable (which creates an Instance Variable) or Declare Temporary Variable (which creates a Local Temporary Variable) If you check the "Temp" option, then you can simply add a variable name and the action will create that variable and set it to hold the return value for you (creating a temporary local variable). Any actions used after this can now access the value in the temporary variable, but only within the same Event or Script. Temporary variables are only available within the scope that they were created. For more in depth information on variables and variable scope, please see here.
++
Not only variables have scopes (see the Target Variables section, above), actions can have different scopes too. In fact, almost all actions can be given a different scope to work in, set from the drop down window opened in the action itself as shown here:
+
You can also set the scope for all further actions using the special action Apply to. For more information on this feature of the GML Visual actions, please see here:
You can change the position of actions within the chain by simply clicking
and dragging them into the new position that you require, and if you do a click
and hold for a second then move the mouse, you can move the action within the workspace while maintaining its place within the action block chain.
It is also possible to add comments to GML Visual actions, so you can leave notes beside different blocks to explain what they do (which is especially useful when working in a team):
-
You can find out more about this feature from the page on the Right Mouse Button Menu.
That's the basics of using the GML Visual code editor, but there are further important details explained in the sections below:
-- -
It is important to note that many actions offer a "target" variable, which can be flagged as "Temporary", for example:
-
What this means is that you can supply a variable which is the target to hold the value returned by the action. In the example action above, the action will return the volume of the audio resource that you select, so you supply a target variable to hold this value so you can reference it later.
Now, this target variable will need to have been declared previously either using Assign Variable (which creates an Instance Variable) or Declare Temporary Variable (which creates a Local Temporary Variable) If you check the "Temp" option, then you can simply add a variable name and the action will create that variable and set it to hold the return value for you (creating a temporary local variable). Any actions used after this can now access the value in the temporary variable, but only within the same Event or Script. Temporary variables are only available within the scope that they were created. For more in depth information on variables and variable scope, please see here.
--
Not only variables have scopes (see the Target Variables section, above), actions can have different scopes too. In fact, almost all actions can be given a different scope to work in, set from the drop down window opened in the action itself as shown here:
-
You can also set the scope for all further actions using the special action Apply to. For more information on this feature of the GML Visual actions, please see here:
-
When working with GML Visual you will have to add variables and expressions into the different input fields of the actions. However, as you do this you will often get the Auto Complete window popping up to help you:
-
This pop up window will list all the built in GML (GameMaker Language) variables, constants and functions, as well as any resources that contain the initial letters of what you were typing. It can be used to quickly find the resource or variable that you are wanting for the action without having to type it all in yourself. For example, if all your rooms are prefixed "rm_" then typing that and waiting a moment will show the auto complete window with all the assets beginning with "rm_". Note that all the built in variables that are shown in the auto complete window can be used anywhere where a variable or expression is expected in an action, as can most GML functions.
-
Sometimes when using an action you will see a small plus icon
to the side. This means that you can expand the action to perform extra tasks or take further arguments. For example, if you look at the Declare Temporary Variables action, you can see that it has this icon:
When you click the icon, the action will expand and permit you to declare more variables, making it easier and faster to define multiple variables at the same time.
The icon can also be used for those actions that require optional arguments, like the Choose action, which permits you to add various different values to be returned:

-
-
-