Commit ae907958 by Nathan Bean

### Fixed typo in collision shapes

parent 8646b2c4
 --- title: "The Game Class" pre: "2. " weight: 20 weight: 20 date: 2018-08-24T10:53:26-05:00 --- ... ...
 ... ... @@ -73,25 +73,25 @@ \$\$ This can then be compared to the sum of the two circle’s radii, giving us an indication of the relationship between the two shapes: \$\$ (r_2 + r1) < \sqrt{(x_2 - x_1)^2 + (y_2 - y_1)^2} \quad \text{The circles do not intersect} (r_2 + r_1) < \sqrt{(x_2 - x_1)^2 + (y_2 - y_1)^2} \quad \text{The circles do not intersect} \$\$ \$\$ (r_2 + r1) = \sqrt{(x_2 - x_1)^2 + (y_2 - y_1)^2} \quad \text{The circles touch} (r_2 + r_1) = \sqrt{(x_2 - x_1)^2 + (y_2 - y_1)^2} \quad \text{The circles touch} \$\$ \$\$ (r_2 + r1) > \sqrt{(x_2 - x_1)^2 + (y_2 - y_1)^2} \quad \text{The circles overlap} (r_2 + r_1) > \sqrt{(x_2 - x_1)^2 + (y_2 - y_1)^2} \quad \text{The circles overlap} \$\$ However, computing the square root is a costly operation in computational terms, so we will typically square both sides of the equation and use a comparison of the squares instead: \$\$ (r_2 + r1)^2 < (x_2 - x_1)^2 + (y_2 - y_1)^2 \quad \text{The circles do not intersect} (r_2 + r_1)^2 < (x_2 - x_1)^2 + (y_2 - y_1)^2 \quad \text{The circles do not intersect} \$\$ \$\$ (r_2 + r1)^2 = (x_2 - x_1)^2 + (y_2 - y_1)^2 \quad \text{The circles touch} (r_2 + r_1)^2 = (x_2 - x_1)^2 + (y_2 - y_1)^2 \quad \text{The circles touch} \$\$ \$\$ (r_2 + r1)^2 > (x_2 - x_1)^2 + (y_2 - y_1)^2 \quad \text{The circles overlap} (r_2 + r_1)^2 > (x_2 - x_1)^2 + (y_2 - y_1)^2 \quad \text{The circles overlap} \$\$ From these inequalities we can very easily write a test for determining if our shapes collide. ... ...
 --- title: "Introduction" pre: "1. " weight: 10 date: 2020-03-20T10:53:05-05:00 --- The creation of assets (textures, audio, models, etc) is a major aspect of game development. In fact, asset creators account for most of a game development team (often a 90/10 split between asset creators and programmers). So creating and using assets is a very important part of creating games! To make this process manageable, most assets are created with other software tools - editors specific to the kind of asset we are dealing with. Asset creators become quite proficient with these tools, and provide their assets in a save file form specific to one of these tools. We can load these files directly in our game, especially if our game targets Windows, where we have a lot of available supporting libraries. But those file formats are tailored towards the needs of the editor program - they often contain data we don't need, or format it in a way that must be transformed to use in our games. And the processing involved in loading can be a lot more involved than we like, causing long load times. One way around this is the use of a _Content Pipeline_ which transforms assets from an editor-specific file format to one optimized for our games. This happens during the _build_ process, so the transformed asset files are bundled with our executable, ready to be utilized. This chapter will describe the content pipeline approach specific to XNA. \ No newline at end of file
 --- title: "The Content Pipeline" pre: "2. " weight: 20 date: 2020-03-20T10:53:05-05:00 --- As we described in the introduction, the XNA Content Pipeline's purpose is to transform asset files (content) in to a form most readily useable by our games. It is implemented as a separate build step that is run every time we compile our game. In fact, each XNA game is actually _two_ projects - the _Content_ project, and the _Game_ project. The pipeline is broken up into several steps: 1. Importing the asset data 2. Processing the asset data 3. Serializing the asset data 4. Loading the serialized asset data You can see the process here: ![XNA Content Pipeline]({{}}) Each of these steps is accomplished by a different class. \ No newline at end of file
 --- title: "Extending the Pipeline" pre: "3. " weight: 30 date: 2020-03-20T10:53:05-05:00 --- You might be wondering why the content pipeline in XNA was created this way - with importers, processors, content writers, and content readers. The answer is simple - modularity. If you want to load a new image format that the `TextureImporter` does not handle, you can write your own custom importer to load its data into a `TextureContent` object, and then still use the existing `TextureProcessor` and serialization process. Alternatively, you may want to handle a new content type that has no associated classes in XNA at all. In this case, you will need to write a custom importer, processor, writer, and reader. The tilemaps created by Tiled that we discussed in the previous chapter are a good candidate for this - so let's use that as an example. In this case, our input file is a .tmx file, which is really just a specialized XML file. We can load this data using a process much like the `Squared.Tilemap` example in the last chapter. Once loaded, we want to convert the data into a form more akin to how we want to represent tilemaps in _our specific game_, i.e. transform the tile properties into specific properties we define for our game's tiles, and change the objects into actual spawn points, etc. Our custom content processor can accomplish these tasks. In addition to loading the tilemap, we'd also like to create the textures that correspond to the tilesets, so that we don't have to load them separately. This is also something we can do with a custom content processor. \ No newline at end of file
 --- title: "Extending the Pipeline" pre: "3. " weight: 30 date: 2020-03-20T10:53:05-05:00 --- You might be wondering why the content pipeline in XNA was created this way - with importers, processors, content writers, and content readers. The answer is simple - modularity. If you want to load a new image format that the `TextureImporter` does not handle, you can write your own custom importer to load its data into a `TextureContent` object, and then still use the existing `TextureProcessor` and serialization process. Alternatively, you may want to handle a new content type that has no associated classes in XNA at all. In this case, you will need to write a custom importer, processor, writer, and reader. The tilemaps created by Tiled that we discussed in the previous chapter are a good candidate for this - so let's use that as an example. In this case, our input file is a .tmx file, which is really just a specialized XML file. We can load this data using a process much like the `Squared.Tilemap` example in the last chapter. Once loaded, we want to convert the data into a form more akin to how we want to represent tilemaps in _our specific game_, i.e. transform the tile properties into specific properties we define for our game's tiles, and change the objects into actual spawn points, etc. Our custom content processor can accomplish these tasks. In addition to loading the tilemap, we'd also like to create the textures that correspond to the tilesets, so that we don't have to load them separately. This is also something we can do with a custom content processor. \ No newline at end of file
 --- title: "Extending the Pipeline" pre: "3. " weight: 30 date: 2020-03-20T10:53:05-05:00 --- You might be wondering why the content pipeline in XNA was created this way - with importers, processors, content writers, and content readers. The answer is simple - modularity. If you want to load a new image format that the `TextureImporter` does not handle, you can write your own custom importer to load its data into a `TextureContent` object, and then still use the existing `TextureProcessor` and serialization process. Alternatively, you may want to handle a new content type that has no associated classes in XNA at all. In this case, you will need to write a custom importer, processor, writer, and reader. The tilemaps created by Tiled that we discussed in the previous chapter are a good candidate for this - so let's use that as an example. In this case, our input file is a .tmx file, which is really just a specialized XML file. We can load this data using a process much like the `Squared.Tilemap` example in the last chapter. Once loaded, we want to convert the data into a form more akin to how we want to represent tilemaps in _our specific game_, i.e. transform the tile properties into specific properties we define for our game's tiles, and change the objects into actual spawn points, etc. Our custom content processor can accomplish these tasks. In addition to loading the tilemap, we'd also like to create the textures that correspond to the tilesets, so that we don't have to load them separately. This is also something we can do with a custom content processor. \ No newline at end of file
 +++ title = "11. Content Pipeline" date = 2020-03-20T10:53:05-05:00 weight = 100 chapter = true +++ ### Chapter 11 # The Content Pipeline Get Your Assets into the Game!

via GIPHY

\ No newline at end of file
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment