Tinker Tinker

Seems like I have found my groove right now.  I kind of suspected that there would have been the mad rush at the beginning of the project to work on it and it would peter out a bit over time.  At least now I am getting a better sense of how long this will take.  At first I was stary-eyed and had great plans and thinking "how hard could this be."  Though I knew it was not a simple undertaking, but still I did not have enough exposure to fully understand what I needed to learn.

At this point I am slowly working my way though the RTS programing book.  Though I have started to do things more in my own way then blindly copping from the text.  The primary reason was not knowing enough about DirectX to do things better than what was stated in the book.  But now I am entering in to the Logic stage of the game design and not so much dealing with DirectX itself.  I think when I am done with the DX9 version of the game, I can then start to replace everything with DX10.  That exercise will help me get a better understanding of the structures and methods of the game engine itself.  

I am trying to keep the DirectX9 parts of the program limited to a small number of classes.  That way I can just replace the underpinnings.  We will see how that goes.  But it is a good idea for now.

On the Other Side

This week is Fallout New Vegas. 

Way back when, I watched the closing credits of Fallout 2 after a very fun romp though the NorCal wasteland.  I did my typical "Talkie/Sniper" build which is how I usually play any CRPG.  At least for the first run though.  Then a name popped up on the screen.  It was a name of Warhammer GM in High School.  And I went, is that him. A few months later we met up for our 10 year High School Reunion, and I found out that it was him.  I thanked him profusely for all the time he caused me to waste :)

The Fallout series has had gone though many hands over the past 15 some odd years.  And with Fallout New Vegas it has found its way under the guidance of my old GM from High School once again. 

Like any good Fallout game there is a lot going on, and I have only just begun.  However I thought I would share some of random thoughts on the game.  Hopefully non-spoiler. 

I have poked at some of the reviews of the game and one thing is quite common in most of them.  They use the phase "Built on a two year old engine."  By this most of the reviewers are making comments that the game is "out of date" technologically speaking.  But I would postulate that most CRPG players don't give as much credence to the latest technology.  Fallout 2 was still bucking the trend when it came out still in a crude tile based 2D format.  Even the Bualder's Gate series was pushing the 2D media further.  But it isn't the latest flashy graphics that I want.  I am there to play in the world and make a difference.

Now I come from the old table top era where we were lucky if we painted miniatures on the board.  A good RPG stimulates the mind to create more than what appears.  So I don't need the flash.  I need the story and world.  I still think Spiderweb games are some of the best CRPGs out on the market.  And they are very basic in their graphics. 

I think it is kind of missing the point to talk extensively about the engine of the game being up to date. 

Now being stable and with minimal bugs is a different story. 

Being an old gamer, I started with Bethsoft games with Daggerfall.  And for the most part I have had the same impression of any Bethsoft game.  Great story and world.  Lousy engine :).  But it is always big and fun.  Just quirky at times. 

Fallout New Vegas is much more of that. 

But I would not want it any other way.

Now where is the bloody sniper rifle.

Meat and Potatos

So I have finished what would be the foundation part of the RTS programing book.  That is mostly on textures and skinning and the heavy lifting of DirectX.  Now it is time to put all the pieces together.  First though, I need to take a step back.  The code in the book is fairly simple.  In that there isn't any real resource management, and much of the initialization information is hard coded in.  The author does state that this is intentional just to focus on the aspects of the game programing, and not what would be considered more generalized programing.  Basically the resource manager is left as an "Exercise for the Reader." 

Fortunately, this is where I can start re-using from the MazeMover project.  I did create a INI file parser and simplified resource manager for the SDL objects.  Now to adapt both for each other. 

This is were things get creative.  I have to now look at both sets of code and figure out what each is really doing.  So right now it is a lot reading and poking and seeing what has to be done.  This is were the power of code encapsulation really comes in to play.  I can now muck around with all the various implementations but still present the classes as they are in the book.

Still it means pulling some parts out and fitting in new ones, but if done correctly then the application itself does not change. 

Flying though the sky

So I have finished all of Chapter 4 and I am on the final exercise of Chapter 5 of the RTS programming book.  Right now I am have an issue with the vertex shaders and the terrain.  Once again, this will require going though the example code and taking a look at mine to see what little step I have forgotten.

So far it is just a fancy terrain map with some functions for later use.  Most of the problems I have encountered so far usually stem from tying to understand the subtleties of graphics programming in Direct X.  It is kind of interesting, I am not much of an artist so I don't know much about creating texture files and actual models.  However, I know all the math that goes on behind the scenes.   Matrix multiplication and inverses.  Using dot products to find projections and distances.

I am getting in to DirectX.  Well at least I am enjoying programming 3D graphics.  It just makes sense.  Put things in the world, then "do the math" to show it on the screen.  I was thinking about writing my own 2D Isometric view engine, but being the engineer that I am, I would rather use someone else tools then build my own. 

It is the little things

After beating my head against the wall, I called in a friend to help look at and debug the code.  If I were in a collaborative environment to begin with, I would have asked for another set of eyes sooner.  But after lunch at a nearby sub shop, I had him poke at my code.

Although the exact error was not found at that time, he did show me some more tricks working with Visual Studio and at least gave me a fresh perspective on where to focus my search.  After narrowing down the location, I was able to go back to the example code and figure out what I was missing.

In short, it was the typical "off by one" error.  In this case I was using a <= when it should have been <.  So after that was done, a few more errors in math were found in the rendering portion and finally I had completed the exercise.  Now I have half of a nice random terrain generator.

This is designed for an RTS so it has peaks and valleys.  I am not sure if I will have non-flat terrain in YAR itself, but it other aspects, such as path finding and object placement will be useful.  Orginally I was thinking of doing a simple 2D iso tile system, but it seems fairly straight forward to do this as a terrain/texture mesh over a 3D surface, even if the surface is going to be flat.  Since most of the heavy lifting has been done in DirectX (and OpenGL) like matrix transformations and what not, I might as well stay here as well.  I will be easier to make it simpler later.

Hitting a New Wall

I am slowing working my way though Programming an RTS Game using Direct 3D.  Only on Chapter 4 but I am taking my time to go over the code in the book and the full code on the CD to understand what I am doing.  Not to mention going back to some DirectX resources to see why I am doing what I am doing.

However, I have hit my first real stumper.  Some how I am getting corrupt memory in my initializations.  Annoyingly it happens at slightly different points in the code when I run it.  But the error is some type of heap corruption or other misaligned memory.  Unfortunately I have yet to see where the real problem is.  Also the example code itself runs fine, yet mine does not.  Now being the good learner, I am adding my own coding paradigm to the example code, so there are differences.  But I am not sure what difference is causing the error in question.

The upside is that I am getting more familiar with the Visual Studio Debugger.  It is kind of fun and for the most part I have been able to figure it out.  Right-Click is your friend.  Now I am still a little green trying to read some of the raw assembly code, but I got though reading UNIX trace/truss commands so this will just take some time to start seeing the patterns that have useful information.

FORTRAN is the Latin of Engineering

If you went to Engineering school in the 80's you most likely had to take a programing in FORTRAN class.  As I started in 1989, I too took FORTRAN.  Two years later, entering freshmen learned C instead of FORTRAN.  Granted I also took the C programing class as an elective, but FORTRAN was the required language.  Also I think my year was one of the last years to have a mechanical drawing class with actual boards, pencils and T-Squares.  And although I had my father's slide-ruler, we were allowed to use electronic calculators. 

So learning "old" technology is very comfortable for me even if it is academic.  Such is how I feel right now working with DirectX9.  It is on the way out since XP is finally no longer allowed to be put on new systems and soon that will be moot since it wont have the support of new hardware anyway.  I should be learning DX10 or DX11.  However there is a lot more written and available for DX9.  Currently most of the books of the variety "Programming $GAME with DirectX" are written for DX9.  So I have a lot more examples to pull from.

Now in my case $GAME = RTS. Though I do have access to the online copy of RPG as well.  So between the two of them I am getting a good idea of all the moving pieces that go in to a fairly typical, though small, game that I want to create for YAR.

I have found learning "old" methods very useful, though it has pigeon-holed me a few times.  On the other hand, I am one of the people that can bring grognards up a few centuries and use at least more modern equipment then what they were using.  Also since I am spending as much time learning the concepts of 3D graphics programing (like texturing and  transforms) I can use all the examples I can get.  My quick look in to DX10 shows that the concepts are still there but the implementation has changed (like Vertex and Index Buffers.)   You still have to know how to use those items from a conceptual standpoint regardless of the API.  When I poke a OpenGL sometime in the future, I will not have to learn basic 3D programing.