Programming Games for Android

As I said, to load textures comfortably we can make use of a assetManager. It is a class that loads a lot of resources at once and let us then get them from a few. We can save it in a single repository for not having to instantiate new textures all the time. The Manager will save the Game, because all screens have access to the Game through the variable. I create my assetManager,

and then I make a getter. With this I can access the Manager with game.getManager (). I'll do that load all the images we have here, we'll see how to load music then. To do this, I'll do in the create () method that instantiates the new Manager. And then to load resources we will use a method called load (). With load (), which is a particular method, we can tell as a parameter the name of the resource will load,

and then you have to pass a parameter of type Class ... Class? Yes, because you have to tell what type it is what we charge, if it is a Texture, one TextureRegion, a Sound ... With this the assetManager can determine which charging system using this resource, but it must be said, with Texture.class, for example. I have to repeat this with each of the resources, as can be Overfloor, Skewers and Player. And to load all we have to call

to FinishLoading (). With this it will be charged synchronously: stop the game while charging resources. When do multiple screens we see that we can make a smooth load screen using asynchronous loads, so that we can see a progress bar and see how it goes for not unnerve the player if it will take a long time. To use this texture, all that remains is to instantiate my texture by game.getManager ()

to access the manager, and then attention: get. For a resource, as it may be, player.png. As I said it was kind Texture, you know it's a texture, and as I keep it in a variable of type Texture also knows he must return as well. The only thing left is to pass this playerTexture, and already I have added to the Stage. If now I try to represent on screen, it is perfectly placed. Insurance? Not at all. I'll show you one thing

that must be taken into account, and that is when I do the draw (), Box2D and Scene2D have their origins in different positions. I spoke to you in Scene2D the origin of the actors is in the lower left corner, but Box2D is in the center, so that we will always position something Scene2D screen by Box2D we must take into account the offset precisely. What I will do is that here when I set the position,

before using the conversion parameter, I will subtract half a meter to place it on the left side. And the same vertically. Yes now, when it represents you are going to draw there. And this is better because, if I now try to draw at position (0.5, 0.5), it automatically appears in Part Full bottom of the screen, because subtraction is well done. The only thing left to do is update the real world. I'll put where it's up.

And just in the render () before calling act (), to give you time ... wait. In fact ... I'll get him later for that act () you can update forces. Among act () and draw () will call world.step () to update it. Remember: delta, 6, 2; the parameters that we saw earlier. With this we are able to see how things happen. Attentive to this. Uy, see you later. As we are updating the world already takes into account the gravity.

And as gravity alters its position, updating the actor always going to draw on what you tell Box2D that must be drawn. It is important to do in this order. We will use act () first to introduce forces; after the step () to apply these forces and update world and severity; and finally draw () to draw it with the parameters that we have calculated. I told you the draw () should be the last to prevent what not draw

what has the physical model, as this can introduce problems of gameplay. With this we already have done. If I may now, before you start the next episode will be creating other entities created with exactly the same code to this, but so do not be to do the same.