Thursday, November 21, 2013

Making the TEXTURE Class

This post continues a series of posts in which I discuss how to rewrite the various modules presented in Game and Graphics Programming for iOS and Android with OpenGL ES 2.0.  The code is well organized but, as presented in the book, does very little to leverage the advantages of using the C++ language.  The code, as described in this post, can be downloaded from GitHub using the tag chapter3.  While rewriting the TEXTURE data type into a proper C++ class I made many of the same changes as were discussed in previous posts.  The changes to the TEXTURE class include:
In the post describing implementation of the OBJ class I mentioned that the function OBJ_build_texture() needs to become the TEXTURE::build() method member of the TEXTURE class.  If you examine the file SDK/common/texture.cpp you'll see that I've moved, and renamed the function from the file SDK/common/obj.cpp.

There is only one change to the code which is new, and it's fairly minor.  While making the TEXTURE::load_pvr() method from the old TEXTURE_load_pvr() function I noticed that the logic to confirm that the file being operated on is, indeed, a PVR file was, IMHO, more complicated than it needs to be.  The old code loads a 4 byte integer, performs a series of bit shift and bit mask operations against the integer value and then compares the results of the shifting and masking against the various ASCII characters which are supposed to be in the tag of a valid PVR header.  I simplified the code by creating a "char *" which points to the tag area of the PVR header, and then I simply used strncmp(3) to do the comparison.  Is my code faster or slower than the original code?  I don't know; I didn't do any benchmarking but I do think it's a lot easier to read, and the TEXTURE::load_pvr() method is only used in the beginning of the application to initialize the needed data structures.  That is, the animation loop isn't continuously calling this method so, IMHO, maintainability is more important than speed.

Just as there was very little new to talk about regarding the changes to the TEXTURE class there is little to change in the sample program chapter3‑4 to use the new, class oriented implementation of TEXTURE.  The call to the old TEXTURE_create() function gets replaced with "new TEXTURE(…)".  Finally, the call to the old TEXTURE_free() function gets replaced with "delete texture".

In the next post I'll continue with the sample code from Chapter 4 and since Chapter 4 doesn't introduce any new modules I'll spend some time talking about various other code clean-ups which, IMHO, should be made.

No comments:

Post a Comment