Working out the more boring parts of the project like memory, linked lists, etc

This week I'm working on the more mundane parts of the project.  I am choosing the 'best' version of hashtable, list and vector implementations and:

• convert them over to use the newly created malloc wrapper (zmem.c), specifically utilizing the automatic destructor-on-free callback mechanism
• 
  
• clean them up with consistent naming
• 
  
• test for memory leaks

Then once i got vector.c, hashtable.c and linkedlist.c working at least enough to start using them:

• Take my latest opengl based project, and separate out the  GL init and basic 'raw' rendering parts from the functionality of the app.

• Convert it over to use zmem and my new structures.

• Begin packaging up the basic functionality into a simple graphics library
• 
  

Why am I jumping into graphics right away?  Motivation.  It is hard for me to stay motivated on a project that is not producing results.  Once I can allocate opengl graphics buffers and get something on the screen, and see that the app does something interesting, I can stay motivated on the project.  Trying to build the 'perfect hashtable' or 'perfect malloc wrapper' implementation can take a long time, and there is no clear definition of how to perfect I would like to get.  Without an application, I don't know how simple or complex the API has to be; what's the point of implementing a feature that is not going to be used very often?

Once I can cleanly allocate memory, define destructors to free that memory, and can perform basic vector manipulation (which is basically just create vector, add item, remove item, and access/iterate/index those items), I can jump into graphics.  I will probably not need hashtables for basic graphics; I usually don't use those until much higher level coding.  (Usually to assign string names to objects, and look them up later.)  Linked lists will also probably be used by graphics.

Started work on Project Z

I have started my latest project, which, for lack of a better name, I am now calling project Z.  (There are too many Project X's on github.)

What is Project Z?  This is an attempt to take several years worth of writing random graphics or sound related programs I've written, and attempting to extract the useful bits out of them and create a working game development / game engine library.

The project is 'on' github here:  http://wiki.github.com/carangil/ProjectZ/  However no code has yet been posted, only a couple of wiki pages. 

This project seems huge... Where do you start?  Well, many of my projects end up recreating some of the classic structures, such as linked lists, hashtables or vectors.  Also, many of them also utilize some kind of thin wrapper on top of malloc, with various stupid names such as xmalloc.  These usually end up being a call to malloc, followed by a NULL check, with the program exiting if allocation failed.  So, I will begin there.  I am currently working on a simple malloc wrapper, which has better options than just 'die on fail.'  I am also selecting my 'best linked list', 'best vector', and 'best hashtable' implementations from the code I have, and cleaning them up.

You may be wondering how a professional's personal code base can become so disorganized.  Well, the code has been around since before I went 'pro'...  I started playing around with OpenGL in high school.  In college, a lot of my time was spent on school projects.  In both H.S. and college, I didn't want to 'waste' my time with writing design docs and doing actual 'engineering;'  I just wanted to jump into some code and see what happens.  Now that I have been developing software professionally for a couple of years, I find most of my old designs rather gross.  However, I would not go back and change anything; I am very glad that I have recklessly jumped into coding. If I had spent the time to properly design these things, I might not have had the time to code them.  By just diving into it, I have lot of working code that does a lot of interesting things.  It is messy, messy code that must be cleaned-up, rewritten, and restructured into a well-engineered framework, but at least I have seen the algorithms work for myself; it is not just a theoretical design sitting on paper.

Test Post

This is a test post.  Whatever.