Building a Hex Board

• You should read Dalmau, Chapter 11, 2D Game Programming.
• Many games use a hex based board.
• You can get hex paper from here
  • A hex is one of only three regular shapes that can be used to tessellate the plane.
  • See the Wikipedia Article
  • The other two are a square and a triangle.
  • This allows better options for turning and facing than a square
• I would like to build the following structure
  • A table of tiles, each has a unique ID, plus other terrain information
  • 
  • A map file, which contains the ID of each tile.
• First I would like to load these gifs, not BMPs.
• Therefore I need to install SDL_Image
  • The installation was trivial.
  • You need to
    • #include "SDL_image.h"
    • add -lSDL_image to your libraries
  • The API is fairly simple.
    • No need to initialize this.
    • SDL_Surface * IMG_Load(const char *file)
      • Returns NULL if an error is encountered
      • Attempts to load a surface by calling one of the SDL_Load*
    • const char * IMG_GetError(void) is like SDL_GetError.
    • int IMG_is* will return true if the image is of given type.
    • An example

      thingToDraw = IMG_Load(filename.c_str());
      if(thingToDraw == NULL) {
         cout << "Unable to load " << filename 
              << " " << IMG_GetError() << endl;
         return(-1);
      }
      	      

• SDL only allows for square operations.
• What we will need to do, is employ Transparency
  • This is not using the alpha bits as we will discuss later.
  • This is a technique where we don't draw pixels of a certain color.
  • The real image
  • 
  • I want to set white (255,255,255) to be the transparent color.
  • The image with transparency set
  • 
• SDL allows us to set a color as the transparent color on each surface we are using.
  • int SDL_SetColorKey(SDL_Surface *surface, Uint32 flag, Uint32 key);
  • surface is the surface we want to set the color key on
  • flag is
    • 0 to clear the transparent color (make no color transparent)
    • SDL_SRCCOLORKEY to set the transparent color
    • SDL_RLEACCEL to use run length encoding to speed up drawing the surface.
  • The key is a SDL color key in the proper format to match the surface.
  • Return value is -1 on error or 0 otherwise.
• To get a color pixel
  • Uint32 SDL_MapRGB(SDL_PixelFormat *fmt, Uint8 r, Uint8 g, Uint8 b);
  • fmt is surface->format
  • r, g,b are the 8 bit
• Some example code:

  Uint32 tmpColor;
  tmpColor = SDL_MapRGB(thingToDraw->format, 255,255,255);
  
  SDL_SetColorKey( thingToDraw, SDL_SRCCOLORKEY | SDL_RLEACCEL , tmpColor);
      

• An Example:
  • hexTest.C
  • Makefile
  • You will need The pictures
• Back to Hexes
  • I would like to give coordinates to my hexes as follows
  • 
  • You could rotate this entire thing by 90 degrees.
  • The difference would be the directions you can draw straight lines.
  • We need a way to map the hexes to Cartesian coordinates.
  • First we need to define the radius of a hex.
  • This is the length from the center to an angle.
  • But this is also the length of a side.
  • So each hex is 2*radius (2r) wide.
  • 
  • If we look at an individual triangle, we can compute the hight of the bounding square.
  • 
  • x² +(r/2)² = r²
  • or x = sqrt(3)/2*r
  • So we need to set a value for r
  • And build image tiles that are 2r x sqrt(3)r
  • In my case, I let r = 40, so my tiles are 80x70
• Putting Tiles on the screen
  • I would like a way to map from tile coordinates to screen coordinates.
  • It is easiest to think about the center of the tile when working in game terms.
  • It is easiest to think about the upper left hand corner when thinking in graphics terms.
  • We will need to map between them.
  • If I know the center of the tile (x,y) , then the upper right hand corner will just be (x-r, y-r*sqrt(3))
  • 
  • So now all I need to do is be able to translate hex coordinates to pixel coordinates.
  • (later I will need to go the other way, but that is not until we add mouse interaction)
  • Let r1 = r, and r2 = sqrt(3)*r
  • Let (a,b) be the hex coordinate
  • Notice 1,1 is at (r1,r2)
  • Notice 3,1 is at (3r1, r2)
  • Notice 1,3 is at (r1, 4R2)
  • The general pattern is that the y coordinate is just y = r2*b (both odd and even)
  • The x coordinate is a little more complex
    • Odd hexes it is x = (int(b/2)*3+1)*r1
    • If we observe, the even hexes are off by 1.5
  • So consider this routine

    void hexCorner(int a, int b, int & x, int & y, int r1, int r2) {
              // a, b  is the center of the hex in hex coordinates
              // x,y is the upper right corner in screen coordinates
              // r1 is the major radius, r2 is the minor radius
              x = ((a/2)*3+1)*r1;
              y = (b)*r2;
    
              if (a%2 == 0) {
                  x -= int(1.5*r1);
              }
    
              x -= r1;
              y -= r2; 
    }
    	 

  • We know that there are ceil(height/r2) rows of hexes
  • We know that there are ceil(width/(r1*1.5)) columns of hexes
  • We will need to add one to the (left/top) and one to the (right/bottom) for overlap.
  • 
  • Here the BLUE boarder is the screen
  • Here is some example code
• Notice we are working in two coordinate systems here:
  • Screen coordinates
  • Hex coordinates.
  • We use the screen coordinates to draw things.
  • We use the hex coordinates to move things about in the game.
  • We will probably add a third set of coordinates as well. On screen board coordinates.
    • We will keep track of where we are in the map (a_center,b_center) and keep this centered.
    • We just need to subtract these from the coordinates.
    • We will probably need to test to see if a hex is visible after it has been so moved.
    • 
    • Notice here, we are shifted by 1 in the X direction (on the map) and by 3 in the Y direction (on the map).
    • We will display hex position (2,4) at hex position (2-1, 4-3). and at screen position 0,0.
    • 
  • To draw something given (a,b) the map game coordinates for an object:
    • Translate this to screen hex coordinates (a',b') by subtracting the offset.
    • If (a', b') is visible (or even partially visible) compute the screen coordinates (x,y) as above.
    • Draw the object at (x,y)
  • Consider this code
  • Note again, if we have an object that moves relatively within the hex, we might have another set of transformations locally to the hex.
• This is starting to look like an object to me.
  • It has private data
    • r1, r2 - the radii of the the hexes
    • (a_center, b_center), where the map is centered.
    • At least the type of each hex on the map
    • The size of the map.
  • It has a bunch of supporting routines
    • Routines for changing coordinate systems.
    • Routines for drawing
      • Draw an entire screen
      • Routines for updating hexes that have changed.
• A tar file of this project is here