Remaking NAVIGATION and FONT into Classes

This post continues my series about rewriting the code from Game and Graphics Programming for iOS and Android with OpenGL ES 2.0 to better leverage C++ abilities.  In Chapter 8 the author introduces his module which wraps the Recast and Detour libraries.  This wrapper is the NAVIGATION module.  Also, the author introduces his module for drawing text.  While previous code displayed text on the screen, it did so use Wavefront objects, not by dynamically rendering strings.  Now, with the addition of the FONT module, any string can be rendered at runtime.

To get a copy of the code as described in this post pull a copy from GitHub using the tag chapter8.

Many of the changes to the NAVIGATION module are routine, that is, they are things which have been seen numerous times in previous posts:

• where appropriate change while loops to for loops, and
• where appropriate change unsigned char to bool or const bool.

The first change to NAVIGATION which is out of the ordinary is the old function NAVIGATION_set_default_configuration().  The old NAVIGATION_init() function used it to initialize the data member navigationconfiguration which, unsurprisingly, is of data type NAVIGATIONCONFIGURATION.  I changed NAVIGATIONCONFIGURATION into a C++ class, and remade NAVIGATION_set_default_configuration() into its constructor.  The NAVIGATION constructor implicitly calls the NAVIGATIONCONFIGURATION constructor to initialize the NAVIGATION object's navigationconfiguration data member.

While rewriting the old NAVIGATION_build() function into a class method I recognized that the "OBJ *obj" and, "unsigned int mesh_index" parameters were indicating that the actual argument to the NAVIGATION_build() function is an OBJMESH object so the signature for NAVIGATION::build() reflects this actuality.  Inside the NAVIGATION::build() method the code needs to access some of parent's data structures.  I've discussed similar situations in the post where I described rewriting SDK/common/obj.cpp.

On to rewriting the FONT module.

I fixed a bug in the FONT::load() method (fka FONT_load()).  There was only one return statement and it always returned false.  I added a second return statement which returns true for those situations where the method is successful.

When rewriting the FONT::load() method I noticed that when the sample code calls this method it always passes in this‑>name as the parameter filename.  As a class method FONT::load() already has access to this‑>name without having it passed in as a parameter.  I debated about whether I should remove filename from the parameter list for the method and rewrite the body of the method to use this‑>name explicitly.  Ultimately, I decided against this because, I speculated, there may actually be some useful case where the filename is different than this‑>name.

Changes to the various sample programs to use the "class-ified" versions of NAVIGATION and FONT are straight forward so I'm omitting their description from this post.

In my next post I'm going to discuss rewriting the SOUND, and  THREAD.