From 5332c1e81b4462e66c5be6e24f9e237733343d01 Mon Sep 17 00:00:00 2001
From: gurpreetsinghmatharoo This section contains all the functions related to using the mipmapping functions. Before using these functions you should have enabled mipmapping for the required texture pages in the Texture Group Editor and/or enabled mipmapping for those sprites that have been set to use only a single texture page from the General Game Options. The image below shows the difference mipmapping can make when rendering your project: This section contains all the functions related to using the mipmapping functions. Before using these functions you should have enabled mipmapping for the required texture pages in the Texture Group Editor and/or enabled it for sprites that use separate texture pages from the General Game Options, and then at runtime enable mipmapping using this function. Mipmapping generates lower resolution textures for drawing at appropriate distance levels. There will be multiple mipmap "levels", where 0 is the original texture, 1 is the half the size of 0, 2 is half the size of 1, and so on (you can control the minimum and maximum mipmap levels used). For each subsequent mipmap level, a 2x2 block from the previous mipmap level is sampled (i.e. 4 pixels) to create one pixel, resulting in a texture that is half the size. Mipmapping can cause bleeding issues if multiple sprites are close together on the texture page and pixels from both happen to be sampled into a 2x2 block. This is where the border size option for a Texture Group comes into play as it creates a gap of the given size between each sprite on a texture page. Since a border is added around each individual sprite, a border size of 8 allows mipmaps to be scaled up to its sixteenth level without bleeding (as then the actual gap between two sprites would be 8 + 8 = 16). The image below shows the difference mipmapping can make when rendering your project: Once you have enabled mipmapping for the project or a texture page, you can then use the following functions to get and set values which will change how things will look in your project when run. Before an instance in GameMaker can have physical properties it must have a fixture assigned to it. A fixture binds a shape or form to the instance and this adds material properties such as density, friction, and restitution. Fixtures can be boxes, circles, polygons or any other simple shape you wish as GameMaker provides functions that enable you to define your own shape point by point, and then once you have your shape you can go ahead and define its physical properties too. These properties are what govern the way the instance with the fixture assigned to it will react with other instances in the physics world. Before an instance in GameMaker can have physical properties it must have a fixture assigned to it. A fixture binds a shape or form to the instance and this adds material properties such as density, friction, and restitution. Your physics object will already have a basic fixture assigned to it via the Object Editor if it has "Uses Physics" checked. This fixture cannot be changed at runtime, however you can assign additional fixtures using the functions listed on this page. If you do not wish to use the default fixture, disable "Uses Physics" for your object and assign a fixture at runtime which will enable Physics for the instance. Fixtures can be boxes, circles, polygons or any other simple shape you wish as GameMaker provides functions that enable you to define your own shape point by point, and then once you have your shape you can go ahead and define its physical properties too. These properties are what govern the way the instance with the fixture assigned to it will react with other instances in the physics world. Creating a fixture requires you to call and store the value from physics_fixture_create, set up a shape (see shape functions in the list below), add points, assign any optional properties and then bind the fixture to an instance: fix = physics_fixture_create(); The code above sets the collision group to 1 so the fixture collides with other fixtures (as this is the default collision group for fixtures created via the IDE) and sets a density so it is affected by gravity. It then binds the fixture to the current instance. You can test this by calling physics_draw_debug in a Draw event to draw the fixtures associated with the instance to the screen for debugging purposes. You can define one fixture and have it bound to multiple instances (think of a pool table, where all the balls have the same physical properties, yet each one is a discreet entity). You can also bind multiple fixtures to a single instance and combine the physical properties (for example, using two triangular polygon fixtures to create a star) You can define the following properties for a fixture: So as you can see, with just a few simple functions, GameMaker can help you to create complex systems and interactions which will give your games an unprecedented sense of realism. You can define one fixture and have it bound to multiple instances (think of a pool table, where all the balls have the same physical properties, yet each one is a discreet entity). You can also bind multiple fixtures to a single instance and combine the physical properties (for example, using two triangular polygon fixtures to create a star) So as you can see, with just a few simple functions, GameMaker can help you to create complex systems and interactions which will give your games an unprecedented sense of realism. Two physics instances are "in contact" when their bounding boxes overlap (i.e. the rectangular regions surrounding their actual shapes). In this case, calling one of the physics_set_* functions on a bound fixture will change the value of the property, but in order to force the physics engine to also take this new value into account, you'll need to deactivate and reactivate the physics instance using phy_active: var _new_friction = 100;Mipmapping
- Function Reference
Getters
@@ -57,7 +60,7 @@ Setters
© Copyright YoYo Games Ltd. 2023 All Rights Reserved
+ © Copyright YoYo Games Ltd. 2024 All Rights Reserved
Fixtures
- Creating a Basic Fixture
+
+
+ physics_fixture_set_polygon_shape(fix);
+
+ // Basic 60x60 square
+ physics_fixture_add_point(fix, -30, -30);
+ physics_fixture_add_point(fix, 30, -30);
+ physics_fixture_add_point(fix, 30, 30);
+ physics_fixture_add_point(fix, -30, 30);
+
+ physics_fixture_set_collision_group(fix, 1);
+ physics_fixture_set_density(fix, 1);
+
+ physics_fixture_bind(fix, id);
+ Properties
+
- Properties
Updating Existing Contacts
- phy_active = false;
+ phy_active = false;
physics_set_friction(fixture_id, _new_friction);
- phy_active = true;
-
The following functions are for creating, binding, setting collisions and then deleting fixtures:
@@ -86,7 +107,7 @@The first step in setting up a fixture is creating it with this function. The returning index should be stored in a variable to be used in all further functions that are used to define and use this fixture.
+
physics_fixture_create()
Physics Fixture ID
+
fix_Ball = physics_fixture_create();
@@ -37,7 +38,7 @@When you first create a new object resource, there is a check-box marked Uses Physics, which is not checked by default. Selecting this option will radically change the behaviour of your object when an instance of it is placed in a room, as this switches on the object's physical properties and means that its "traditional" movement and collision functions are no longer valid (but only when the room it is placed on is also marked as being a physics room. See the section on the Room Editor Properties). When you check this, the object resource window opens a new chained window for the physics editor:
-Before you start to edit the values for the physics behaviours it's a good idea to first set the collision shape. With the "normal" collision system your collisions are based off of the mask of the sprite assigned to the object, but with physics enabled this is no longer the case. We need to assign a collision shape to the object ourselves (this is properly called a fixture, see The Physics Functions for more information), which can either be a circle, a rectangle or a polygon shape that you yourself define. Clicking on the Modify Collision Shape button will open the following chained window to edit the shape:
+ +You can enable Physics for any object at runtime by assigning a Fixture to it.
+Before you start to edit the values for the physics behaviours it's a good idea to first set the collision shape. With the "normal" collision system your collisions are based off of the mask of the sprite assigned to the object, but with physics enabled this is no longer the case. We need to assign a collision shape to the object ourselves (this is properly called a fixture, see The Physics Functions for more information), which can either be a circle, a rectangle or a polygon shape that you yourself define. Clicking on the Modify Collision Shape button will open the following chained window to edit the shape:
This looks similar to the Path Editor, and functions in much the same way. However, depending on the mask you have chosen, it can be rather more restrictive:
This function saves the contents of a buffer to a file, ready to be read back into memory using the buffer_load function.
+
On HTML5 the contents of the buffer will be saved as base64 encoded strings when using this function.
This function saves part of the contents of a buffer to a file asynchronously, ready to be read back into memory using any of the buffer_load_* functions.
+This function saves part of the contents of a buffer to a file asynchronously, ready to be read back into memory using any of the buffer_load_* functions.
The "offset" defines the start position within the buffer for saving (in bytes), and the "size" is the size of the buffer area to be saved from that offset onwards (also in bytes). This function works asynchronously, and so the game will continue running while being saved.
All files saved using this function will be placed in a "default" folder (unless you are using an async group, then the name of the group replaces "default"). This folder does not need to be included in the filename as it is added automatically by GameMaker. For example the filename path "Data\Player_Save.sav" would actually be saved to "default\Data\Player_Save.sav". When you load the file using the function buffer_load_async, you do not need to supply the "default" part of the path either (but any other file function will require it, except on consoles Xbox, PlayStation and Nintendo Switch).
On HTML5 "default/" is not added automatically and you may have to account for this in your code.
diff --git a/Manual/contents/GameMaker_Language/GML_Reference/Buffers/buffer_save_ext.htm b/Manual/contents/GameMaker_Language/GML_Reference/Buffers/buffer_save_ext.htm index 10762968c..0254f1f02 100644 --- a/Manual/contents/GameMaker_Language/GML_Reference/Buffers/buffer_save_ext.htm +++ b/Manual/contents/GameMaker_Language/GML_Reference/Buffers/buffer_save_ext.htm @@ -15,7 +15,7 @@This function saves part of the contents of a buffer to a file, ready to be read back into memory using the buffer_load function.
+This function saves part of the contents of a buffer to a file, ready to be read back into memory using the buffer_load function.
The "offset" defines the start position within the buffer for saving (in bytes), and the "size" is the size of the buffer area to be saved from that offset onwards (also in bytes).
Building executables via command line requires you to have logged in to the IDE.
In addition to building your project through the IDE, GameMaker allows you to build your projects through a command-line interface using the many options and commands described below. You can use this to build your project, test it and deploy it to multiple platforms by running one batch file, and to set up continuous integration through an automation server such as Jenkins.
This is done by running the Igor.exe executable present within your runtime folder and passing in the options and commands listed on this page.
@@ -25,8 +25,15 @@You must have logged into the IDE with your account at least once before attempting command line building.
+This page covers the following:
+-
To set up CI building on a machine, you will need to do the following:
Igor.exe /uf=[user_folder] /rp=[runtime_path] /project=[project_YYP_file] /cache=[cache_dir_path] /temp=[temp_dir_path] /of=[output_filename] /tf=[target_file] /runtime=YYC /device=[device_IDE_Name] -- Switch Package
-
Here are the options that can be used with the Igor runtime:
-
Here are the options that can be used for testing your builds with Igor:
If you are facing bugs in your test set-up, please submit a bug report and attach your test files which we can review and test on our end.
There is one command that you can use to run tests with Igor:
Igor.exe Tests RunTests [test_directory/test_filename]
You must specify either a test directory or a test file name.