In our texture, first we draw the stripes that will give our game its signature look. To do that, we define a function named RenderStripes that accepts the type of stripe and the number of stripes. The type of stripe is described by an enum named EStripeType, which you will find in the GameGlobals.cpp file. This is quite a large function with a lot of new things to learn. So, we'll discuss it part by part instead of all at once:

void Terrain::RenderStripes(EStripeType stripe_type, int num_stripes)
{
  // allocate memory for the position & colour arrays
  ccVertex2F* vertices = (ccVertex2F*)malloc(sizeof(ccVertex2F) * num_stripes * 6);
  ccColor4F* colors = (ccColor4F*)malloc(sizeof(ccColor4F) * num_stripes * 6);

  // initialise variables
  int num_vertices = 0;
  float x1 = 0.0f, x2 = 0.0f, y1 = 0.0f, y2 = 0.0f, dx = 0.0f, dy = 0.0f;

  // select between two colours or many colours
  bool two_colors = (CCRANDOM_MINUS1_1() > 0);
  ccColor4F color1 = GameGlobals::GetRandomColor();
  ccColor4F color2 = GameGlobals::GetRandomColor();
  ccColor4F c;

We begin by allocating memory for our two arrays, vertices and colors, which are of the type ccVertex2F and ccColor4F, respectively. These arrays will hold the position and color data at each vertex for each stripe. We then have a counter for the total number of vertices generated followed by variables to represent the coordinates of each vertex composing the stripe. The EStripeType enum that is passed as an argument to this function describes three types of stripes, that is, horizontal, diagonal (top-left to bottom-right), and diagonal (bottom-left to top-right). We will go over the code for each of them separately, starting with the horizontal stripes:

if(stripe_type == E_STRIPE_HORIZONTAL)
  {
    // initialise variables for the horizontal stripe
    dx = 0;
    dy = (float)STRIPE_TEXTURE_SIZE / (float)num_stripes;
    
    x1 = 0;
    y1 = 0;
    
    x2 = STRIPE_TEXTURE_SIZE;
    y2 = 0;
    
    // generate position & colour for each vertex of the stripe
    for (int i = 0; i < num_stripes; ++ i)
    {
      c = two_colors ? (i%2 ? color1 : color2) : 
        GameGlobals::GetRandomColor();

      colors[num_vertices] = c;
      vertices[num_vertices ++] = vertex2(x1, y1);
      colors[num_vertices] = c;
      vertices[num_vertices ++] = vertex2(x2, y2);
      colors[num_vertices] = c;
      vertices[num_vertices ++] = vertex2(x1, y1 + dy);
      colors[num_vertices] = c;
      vertices[num_vertices ++] = vertices[num_vertices - 2];
      colors[num_vertices] = c;
      vertices[num_vertices ++] = vertices[num_vertices - 2];
      colors[num_vertices] = c;
      vertices[num_vertices ++] = vertex2(x2, y2 + dy);

      y1 += dy;
      y2 += dy;
    }
  }

Before we discuss the code, here is a visual representation of what this code block results in:

As you can see in the preceding figure, each stripe is nothing but a rectangle described by four vertices (v0, v1, v2, v3). However, we will draw this rectangle as two separate triangles. The two triangles will be described by vertices (v0, v1, v2) and (v1, v2, v3) respectively. That makes a total of six vertices for each stripe and that is why we multiply num_stripes by the number six while allocating memory to vertices and colors.

At the top of the block, we have defined the delta movement for both x and y coordinates into variables dx and dy respectively, followed by the initial values for the first stripe. We then write a loop that calculates six vertices for each stripe. In the loop, we either select from the two colors (as in the preceding figure) or we select a random color for each stripe. What follows is code to describe the six vertices (v0, v1, v2) and (v1, v2, v3) that will complete a single stripe. The loop terminates by incrementing y1 and y2 by dy to calculate vertices for the next stripe.

Now, let's look at code that generates vertices for the diagonal stripes:

else
{
  // initialise variables based on type of stripe
  dx = (float)STRIPE_TEXTURE_SIZE * 2 / (float)num_stripes;
  dy = 0;
    
  x1 = -STRIPE_TEXTURE_SIZE;
  y1 = (stripe_type == E_STRIPE_SLOPE_DOWN) ? 0 : 
      STRIPE_TEXTURE_SIZE;
    
  x2 = 0;
  y2 = (stripe_type == E_STRIPE_SLOPE_DOWN) ? 
    STRIPE_TEXTURE_SIZE : 0;
    
  // generate position & colours for two stripes at a time
  for (int i = 0; i < num_stripes / 2; ++ i)
  {
    c = two_colors ? (i%2 ? color1 : color2) : 
      GameGlobals::GetRandomColor();

    for(int j = 0; j < 2; ++ j)
    {
      colors[num_vertices] = c;
      vertices[num_vertices ++] = vertex2(x1 + j * 
        STRIPE_TEXTURE_SIZE, y1);
      colors[num_vertices] = c;
      vertices[num_vertices ++] = vertex2(x1 + j * 
        STRIPE_TEXTURE_SIZE + dx, y1);
      colors[num_vertices] = c;
      vertices[num_vertices ++] = vertex2(x2 + j * 
        STRIPE_TEXTURE_SIZE, y2);
      colors[num_vertices] = c;
      vertices[num_vertices ++] = vertices[num_vertices - 2];
      colors[num_vertices] = c;
      vertices[num_vertices ++] = vertices[num_vertices - 2];
      colors[num_vertices] = c;
      vertices[num_vertices ++] = vertex2(x2 + j * 
        STRIPE_TEXTURE_SIZE + dx, y2);
    }

    x1 += dx;
    x2 += dx;
  }
}

Before we discuss the code, here is a visual representation of what this code block results in when the stripe type is E_STRIPE_SLOPE_DOWN:

The logic we'll use to draw diagonal stripes will be quite different as compared to horizontal stripes. As you can see in the preceding figure, vertex v0 of the first stripe starts far out to the left of the actual texture (indicated by the black outlined square in the center). Thus, we initialize x1 with a value equal to -STRIPE_TEXTURE_SIZE and x2 with 0.

The variables y1 and y2 are defined based on whether our stripe will be top-left to bottom-right (E_STRIPE_SLOPE_DOWN) or bottom-left to top-right (E_STRIPE_SLOPE_UP). We then define a nested structure of loops that draws two stripes at a time. So, the vertices generated within the inner for loop will be for stripe-1 (green) and stripe-3 (green), then stripe-2 (yellow) and stripe-4 (yellow), and so on.

Now that we've calculated vertices for the various types of stripes, it is time to actually make the OpenGL calls that will do the rendering for us. So, let's take a look at the last part of the RenderStripes function:

// we're dealing with position & colour data here
setShaderProgram(CCShaderCache::sharedShaderCache()->programForKey(kCCShader_PositionColor));
CC_NODE_DRAW_SETUP();

// enable position & colour attributes
ccGLEnableVertexAttribs(kCCVertexAttribFlag_Position | kCCVertexAttribFlag_Color);
// pass position & colour data
glVertexAttribPointer(kCCVertexAttrib_Position, 2, GL_FLOAT, GL_FALSE, 0, vertices);
glVertexAttribPointer(kCCVertexAttrib_Color, 4, GL_FLOAT, GL_TRUE, 0, colors);
// set the blend function
glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_ALPHA);
// draw it...GL_TRIANGLES style!
glDrawArrays(GL_TRIANGLES, 0, (GLsizei)num_vertices);

// free what we allocated on top
free(vertices);
free(colors);

We kick off the rendering by setting the shader program for this node. Shaders are a huge aspect of graphics programming, but unfortunately they're way out of the scope of this book. For now, all you need to know is that shaders are simply programs that run on the GPU. Cocos2d-x comes with a bunch of default shaders that are loaded into the CCShaderCache class. You can also create and cache your own shaders into this class.

Here, we're rendering colored stripes and we're dealing only with the position and color for each stripe, which is why we select the kCCShader_PositionColor type of shader. You can find all the default shaders at the following path:

cocos2d-x-2.2.5cocos2dxshaders

We then use a convenience macro CC_NODE_DRAW_SETUP() that sets up the GL server state and links the shader program we set. We then call the ccGLEnableVertexAttribs function, passing in the flags kCCVertexAttribFlag_Position and kCCVertexAttribFlag_Color. This function informs OpenGL which attributes of the vertex will be used while rendering. The ccGLEnableVertexAttribs function has OpenGL function glEnableVertexAttribArray at its heart.

Next, we make two calls to the glVertexAttribPointer function, one each for the position and color attributes that we just enabled. This function basically tells OpenGL how to interpret the data that we're passing into this function via the arrays vertices and colors.

We must now set the blend mode by calling glBlendFunc, which basically specifies how the incoming values (the colored stripes we're about to render) will affect the existing values (so far, we have nothing, though). We pass in GL_ONE as the source factor, which means that all the existing values will be carried forward, and we pass in GL_ONE_MINUS_SRC_ALPHA as the destination factor, which means that the incoming values will be rendered wherever there is transparency in the existing values.

Finally, we call the glDrawArrays function that renders the vertex data that we just passed through glVertexAttribPointer.

The first parameter to glDrawArrays, GL_TRIANGLES, tells OpenGL that it should use all three vertices to draw a single triangle. The second parameter is the starting index from within the array where the vertices will be read. The last parameter is simply the number of vertices that we want rendered.

Now that we're done with the rendering, we must free the two arrays that we allocated memory to, at the start of the function. This winds up the RenderStripe function.

Now that we've drawn our stripes, we can go ahead and beautify the texture with a gradient. Remember that this texture will be applied to a landscape of mountains and we need to create an illusion of a shadow. Thus, our gradient will be light at the top and get darker towards the bottom. Let's take a look at the RenderGradient function from Terrain.cpp:

void Terrain::RenderGradient()
{
  // declare arrays for position & colour data
  ccVertex2F vertices[4];
  ccColor4F colors[4];

  // gradient will be light on top & dark at the bottom
  vertices[0] = vertex2(0, 0);
  vertices[1] = vertex2(STRIPE_TEXTURE_SIZE, 0);
  vertices[2] = vertex2(0, STRIPE_TEXTURE_SIZE);
  vertices[3] = vertex2(STRIPE_TEXTURE_SIZE, STRIPE_TEXTURE_SIZE);
  colors[0] = ccc4f(0.0f, 0.0f, 0.0f, 0.0f);
  colors[1] = ccc4f(0.0f, 0.0f, 0.0f, 0.0f);
  colors[2] = ccc4f(0.0f, 0.0f, 0.0f, 0.75f);
  colors[3] = ccc4f(0.0f, 0.0f, 0.0f, 0.75f);

  // we're dealing with position & colour data here
  setShaderProgram(CCShaderCache::sharedShaderCache()->programForKey(
    kCCShader_PositionColor));
  CC_NODE_DRAW_SETUP();

  // enable position & colour attributes
  ccGLEnableVertexAttribs(kCCVertexAttribFlag_Position | 
    kCCVertexAttribFlag_Color);
  // pass position & colour data
  glVertexAttribPointer(kCCVertexAttrib_Position, 2, 
    GL_FLOAT, GL_FALSE, 0, vertices);
  glVertexAttribPointer(kCCVertexAttrib_Color, 4, 
    GL_FLOAT, GL_FALSE, 0, colors);
  // draw it...GL_TRIANGLE_STRIP style!
  glDrawArrays(GL_TRIANGLE_STRIP, 0, 4);
}

At the start of the function, we define two arrays to hold the position and color information for the gradient. We then fill in the positions as the top-left, top-right, bottom-left, and bottom-right corners into the vertices array. This is followed by filling in the color data, which is a completely transparent black color at the top with 75 percent opacity at the bottom.

Just by doing that, we have created a gradient, as OpenGL will automatically interpolate the alpha values between 0 and 75 percent when it runs the position-color shader. I am sure that you noticed how the arrays have only four elements instead of the six we had for the stripes. This is because we use a different drawing mode, named GL_TRIANGLE_STRIP, this time. GL_TRIANGLE_STRIP informs OpenGL that every triangle it draws will have the first two vertices same as the last two vertices of the previous triangle.

Thus, at the time of rendering, the gradient will be composed of two triangles having vertices {(0, 0), (STRIPE_TEXTURE_SIZE, 0), (0, STRIPE_TEXTURE_SIZE)} and {(STRIPE_TEXTURE_SIZE, 0), (0, STRIPE_TEXTURE_SIZE), (STRIPE_TEXTURE_SIZE, STRIPE_TEXTURE_SIZE)}, respectively.

I'm sure you're wondering why we didn't use GL_TRIANGLE_STRIP while rendering the stripes given that we could have saved two vertices for each stripe. Since GL_TRIANGLE_STRIP causes triangles to share their vertices, all the triangles it draws must be connected or adjacent to each other. If you remember, while calculating vertices for the diagonal stripes, we were drawing two stripes that were apart from each other. That's the reason why we had to use GL_TRIANGLES. So far, this is what our texture looks like:

We will add some more realism to our texture by giving it some shine at the top to resemble sunlight falling on the surface of the hill. The RenderHighlight function from the Terrain.cpp file will do exactly that:

void Terrain::RenderHighlight()
{
  // declare arrays for position & colour data
  ccVertex2F vertices[4];
  ccColor4F colors[4];

  // highlight will be yellowish on top & nothing at the bottom
  vertices[0] = vertex2(0, 0);
  vertices[1] = vertex2(STRIPE_TEXTURE_SIZE, 0);
  vertices[2] = vertex2(0, STRIPE_TEXTURE_SIZE/3);
  vertices[3] = vertex2(STRIPE_TEXTURE_SIZE, STRIPE_TEXTURE_SIZE/3);
  colors[0] = ccc4f(1.0f, 1.0f, 0.5f, 0.4f);
  colors[1] = ccc4f(1.0f, 1.0f, 0.5f, 0.4f);
  colors[2] = ccc4f(1.0f, 1.0f, 0.5f, 0.0f);
  colors[3] = ccc4f(1.0f, 1.0f, 0.5f, 0.0f);

  // we're dealing with position & colour data here
  setShaderProgram(CCShaderCache::sharedShaderCache()->programForKey(
    kCCShader_PositionColor));
  CC_NODE_DRAW_SETUP();

  // enable position & colour attributes
  ccGLEnableVertexAttribs(kCCVertexAttribFlag_Position | 
    kCCVertexAttribFlag_Color);
  // pass position & colour data
  glVertexAttribPointer(kCCVertexAttrib_Position, 2, 
    GL_FLOAT, GL_FALSE, 0, vertices);
  glVertexAttribPointer(kCCVertexAttrib_Color, 4, 
    GL_FLOAT, GL_FALSE, 0, colors);
  // set the blend function
  glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
  // draw it...GL_TRIANGLE_STRIP style!
  glDrawArrays(GL_TRIANGLE_STRIP, 0, 4);
}

Much of the code here is similar to the function RenderGradient, except that the highlight will be applied only to the upper one-third of the texture and the color will be a shade of yellow. Another difference here is the presence of the function glBlendFunc. This is what our texture looks like with some highlight applied:

We now add a thin border to the top of the texture, which when applied to the hills will provide an outline and represent the surface of the hill. The RenderTopBorder function from Terrain.cpp will take care of that. This function bears resemblance to the last two functions, so we shall skip discussing it in detail. The function simply renders a 3-pixel thick gray rectangle at the top of the texture. I'm sure you'll understand this function when you look at it in the source bundle.

Moving on, this is how the texture will look after this function has returned. I've taken the liberty of zooming in so that you can see the border clearly:

We've added a lot of effects to the texture, but it still lacks a material feel and it appears flat. So, we'll add some noise to the texture in the RenderNoise function from the Terrain.cpp file:

void Terrain::RenderNoise()
{
  // create a sprite with readymade noise
  CCSprite* noise = CCSprite::create("noise1.png");
  // set the proper blend function
  ccBlendFunc blend_func;
  blend_func.src = GL_DST_COLOR;
  blend_func.dst = GL_ZERO;
  noise->setBlendFunc(blend_func);
  // position the sprite at the centre of the texture
  noise->setPosition(ccp(STRIPE_TEXTURE_SIZE/2, 
    STRIPE_TEXTURE_SIZE/2));
  // call visit to render the sprite...twice gives added contrast
  noise->visit();
  noise->visit();
}

I'm sure you were expecting more than that! Well, every CCSprite class defines the similar set of OpenGL commands in its draw function like the ones we just wrote. So, all we really need to do here is create a CCSprite with a pre-rendered noise texture and call its visit function.

With the RenderNoise function, we complete the generation of a multicolor, realistic, striped texture. With the complicated rendering behind our back, we can now move forward to the creation of the hills. Before that, this is what the texture looks like after the RenderNoise function has returned:

The hill key points will be nothing but the highest and lowest points on the surface of the hill. We must ensure that a peak is followed by a bottom, and vice versa, to ensure smooth continuity. Also, we would like to control the amount by which a peak rises and the amount a bottom falls. This would enable us to make the terrain easier or more difficult. Let's now take a look at the GenerateHillKeyPoints function from the Terrain.cpp file:

void Terrain::GenerateHillKeyPoints(float start_x)
{
  // initialise variables
  num_hill_key_points_ = 0;

  float x, y, dx, dy, ny;

  // first hill key point will be a bit outside the left edge of the screen
  x = start_x - SCREEN_SIZE.width * 0.25f;
  y = 0;
  hill_key_points_[num_hill_key_points_ ++] = vertex2(x, y);

  // the first peak
  x = start_x;
  y = SCREEN_SIZE.height * 0.4f;
  hill_key_points_[num_hill_key_points_ ++] = vertex2(x, y);

We begin this function by initializing the number of hill key points and variables that will represent the x and y coordinates of each key point. We now initialize the first hill key point as being outside the left edge of the screen and right at the bottom. We then create the first peak at the x coordinate that is passed to this function and at a considerable height from the bottom of the screen. Continuing with the GenerateHillKeyPoints function from the Terrain.cpp file:

  // set the minimum & range quantities
  int min_dx = 160, range_dx = 80;
  int min_dy = 60,  range_dy = 60;
  // +1 - going up, -1 - going  down
  float sign = -1; 
  // set the limits
  float max_height = SCREEN_SIZE.height * 0.5f;
  float min_height = SCREEN_SIZE.height * 0.25f;

Now that we've specified how the start of the hill will look, we can write a simple algorithm to generate the rest of the hill. First, we need to define a few parameters for the algorithm. The min_dx and min_dy variables will represent the minimum distance any two hill key points will have between each other, whereas the range_dx and range_dy variables will be used to select a random distance value that will be added to min_dx and min_dy. The sign variable will be toggled between 1 and -1 so that the algorithm generates a peak followed by a bottom followed by a peak and so on. Finally, we define a couple of constraints that prevent the algorithm from generating key points that are too high or too low.

In the GameGlobals.h file, you will find MAX_HILL_KEY_POINTS defined as 100. So, we have 50 peaks and 50 bottoms.

Let's look at the following code:

// first set of points
while (num_hill_key_points_ < MAX_HILL_KEY_POINTS - 15)
{
  dx = CCRANDOM_0_1() * range_dx + min_dx;
  x += dx;
  dy = CCRANDOM_0_1() * range_dy + min_dy;
  ny = y + dy * sign;
  if(ny > max_height) ny = max_height;
  if(ny < min_height) ny = min_height;
  y = ny;
  sign *= -1;
  hill_key_points_[num_hill_key_points_++] = vertex2(x, y);
}

In the preceding code, we define the majority of the hill key points. The reason we don't define them all in a single loop is because we want to create a kind of ramp at the end of the hill for the penguin to launch off. As you read earlier, we use range_dx/dy in combination with min_dx/dy to generate a delta into dx and dy. We then multiply the y coordinate with sign and restrict it within the appropriate constraints. Finally, we toggle sign by negating it and save the new hill point as a ccVertex2F object in the hill_key_points_ array.

Let's now look at the last part of the function that takes care of generating the ramp-like structure towards the end of the hill. This loop will gradually lower the peak and bottom hill key points so that the last peak is high enough to act like a ramp for the penguin to take off.

Let's look at the following code:

// points that will go lower and lower
  min_height = SCREEN_SIZE.height * 0.1f;
  while (num_hill_key_points_ < MAX_HILL_KEY_POINTS - 2)
  {
    dx = CCRANDOM_0_1() * range_dx + min_dx;
    x += dx;
    dy = CCRANDOM_0_1() * range_dy + min_dy;
    ny = ( (y + dy * sign) < hill_key_points_[
      num_hill_key_points_ - 2].y ) ? (y + dy * sign) : 
      (y + dy * sign * 0.5f);
    if(ny < min_height) ny = min_height;
    y = ny;
    sign *= -1;
    hill_key_points_[num_hill_key_points_++] = vertex2(x, y);
  }

  // finally a nice upward slope...the ramp to launch the penguin
  x += min_dx + range_dx * 3;
  y += min_dy + range_dy * 1.5f;
  hill_key_points_[num_hill_key_points_++] = vertex2(x, y);

  // last point will be way down below
  x += min_dx + range_dx * 1.5f;
  y = 0;
  hill_key_points_[num_hill_key_points_++] = vertex2(x, y);

  // initialise left most & right most key points
  from_key_point_ = 0;
  to_key_point_ = 0;
}

We start the loop by lowering min_height to SCREEN_SIZE.height * 0.1f from SCREEN_SIZE.height * 0.25f. This while loop is similar to the previous one except that it possesses a condition that ensures each peak is lower in elevation than the previous peak. The loop still doesn't create the ramp for us though. That is why we add the last two hill key points by ourselves.

Notice how the first hill key point that we add manually has the range multiplied so as to increase the distance between this key point and the previous, thereby creating a ramp. We then finish the hill structure off by creating the last key point at the bottom of the screen. We will discuss the from_key_point_ and to_key_point_ variables in a bit. For now, I have a screenshot of the hill key points that are generated by this function, so you know exactly what we have achieved:

In the preceding screenshot, you can tell that we have the key points correct. But this is not gameplay material. In order to make things realistic and fun, we will need to give the hills a smooth, curved surface over which the penguin can easily slide and take off too. We will make use of a simple cosine curve to achieve a neatly interpolated curve between two hill key points. If you're rusty on your trigonometry, this is what a cosine curve looks like:

So, we want the y coordinates of the slope to be a factor of a cosine curve as it passes from 0 to pi. All this happens in the GenerateBorderVertices function of Terrain.cpp:

void Terrain::GenerateBorderVertices()
{
  // initialise variables
  num_border_vertices_ = 0;

  ccVertex2F p0, p1, pt0, pt1;
  p0 = hill_key_points_[0];

  for (int i = 1; i < num_hill_key_points_; ++ i)
  {
    p1 = hill_key_points_[i];

    // calculate the number of segments between adjacent key points
    int h_segments = floorf((p1.x - p0.x) / HILL_SEGMENT_WIDTH);
    // calculate delta x
    float dx = (p1.x - p0.x) / h_segments;
    // calculate delta theta
    float da = M_PI / h_segments;
    // calculate x-axis & amplitude for the cosine wave
    float ymid = (p0.y + p1.y) / 2;
    float ampl = (p0.y - p1.y) / 2;
    pt0 = p0;
    border_vertices_[num_border_vertices_++] = pt0;

    // for each segment, calculate x & y coordinate
    for (int j = 1; j < h_segments + 1; ++ j)
    {
      // x coordinate is last coordinate plus delta
      pt1.x = p0.x + j * dx;
      // y coordinate taken from the cosine wave
      pt1.y = ymid + ampl * cosf(da * j);
      border_vertices_[num_border_vertices_ ++] = pt1;
      pt0 = pt1;
    }

    p0 = p1;
  }
}

At the start of the function, we initialize the various variables and counters.

We initialize p0 to point to the first key point in the hill_key_points_ array and start the for loop from 1 instead of 0.

Inside the loop, we initialize p1 and calculate the number of segments between p0 and p1 based on the width of each segment (HILL_SEGMENT_WIDTH value as 15). We must calculate the delta for the x coordinate and for the angle (theta). We then calculate the midpoint of the segment between p0 and p1 in terms of the y coordinate into the ymid variable. This will act as the x axis for our cosine curve. We also define an amplitude that we will multiply by the cosine curve; the larger the amplitude, the greater the distance between the peak and bottom of the cosine curve.

We then run a loop to interpolate from p0 to p1, one segment at a time. Inside the loop, we calculate the vertices of the individual segment that will make up the curve. Notice how we use the cosf function to calculate the y coordinate of the curve. The following screenshot shows what happens when the points generated in the border_vertices_ array are joined:

In this screenshot, you can see the hill key points and the smooth curve that is generated around them. At this point, we have a smoothly interpolated surface of the hill. We can now build a Box2D body with the vertices generated in the GenerateBorderVertices function.

The Box2D body of the hill will be static and its fixture will contain a chain shape. Let's take a look at what exactly happens in the CreateBody function of Terrain.cpp:

void Terrain::CreateBody()
{
  // create a body only the first time...after that only 
    create fixture
  if(body_ == NULL)
  {
    b2BodyDef bd;
    bd.position.Set(0, 0);
    body_ = world_->CreateBody(&bd);
  }
  
  // create array for the vertices
  b2Vec2 vertices[MAX_BORDER_VERTICES];
  int num_vertices = 0;
  // loop through border_vertices_, convert screen 
    coordinates to physics coordinates
  for (int i = 0; i < num_border_vertices_; ++ i)
  {
    vertices[num_vertices ++].Set(SCREEN_TO_WORLD(
      border_vertices_[i].x), SCREEN_TO_WORLD(border_vertices_[i].y));
  }

  // finish up the last two vertices to form a loop
  vertices[num_vertices ++].Set(SCREEN_TO_WORLD(border_vertices_[
    num_border_vertices_ - 1].x), 0);
  vertices[num_vertices ++].Set(SCREEN_TO_WORLD(
    border_vertices_[0].x), 0);
  
  // create the chain fixture with above vertices
  b2ChainShape shape;
  shape.CreateChain(vertices, num_vertices);
  body_->CreateFixture(&shape, 0);
}

We begin by creating a static b2Body object into the member variable body_ of class Terrain. We then declare an array of type b2Vec2 named vertices before filling it up with the vertices we just calculated and fed into border_vertices_. Notice the helper macro SCREEN_TO_WORLD converting the coordinates from pixels to meters. Once this is done, we simply create a b2ChainShape object passing in the vertices array along with the number of vertices the chain should have. We wind up this function by creating a new fixture that will glue body_ to the chain shape.

In our Terrain class, we have written code to generate a striped texture, generate vertices for a smooth curved hill, and even created a Box2D body. We still haven't rendered the hill though. We still need to bind the striped texture to the vertices of the curve and render the hill.