Game Development Reference
In-Depth Information
What just happened?
There is a lot of new information regarding sprites in the previous code. So let's go over it
carefully:
• We started by adding the clouds. We put the sprites inside a vector so we can move
the clouds later. Notice that they are also part of our batch node.
• Next comes the bomb sprite and our first new call:
_bomb->getTexture()->generateMipmap();
• With this we are telling the framework to create antialiased copies of this texture in
diminishing sizes (mipmaps), since we are going to scale it down later. This is op-
tional of course; sprites can be resized without first generating mipmaps, but if you
notice loss of quality in your scaled sprites, you can fix that by creating mipmaps
for their texture.
Note
The texture must have size values in so-called POT (power of 2: 2, 4, 8, 16, 32, 64,
128, 256, 512, 1024, 2048, and so on). Textures in OpenGL must always be sized
this way; when they are not, Cocos2d-x will do one of two things: it will either res-
ize the texture in memory, adding transparent pixels until the image reaches a POT
size, or stop the execution on an assert. With textures used for mipmaps, the frame-
work will stop execution for non-POT textures.
• I add the
sparkle
and the
halo
sprites as children to the
_bomb
sprite. This
will use the container characteristic of nodes to our advantage. When I grow the
bomb, all its children will grow with it.
• Notice too that I use a third parameter to
addChild
for
halo
and
sparkle
:
bomb->addChild(halo, kMiddleground, kSpriteHalo);
• This third parameter is an integer tag from yet another enumerated list declared in
GameLayer.h
. I can use this tag to retrieve a particular child from a sprite as fol-
lows:
auto halo = (Sprite *)
bomb->getChildByTag(kSpriteHalo);
We now have our game screen in place:
