Sunday, February 20, 2011

A beginner's philosophy in fixing problems in Linux

I am quite sorry I haven't posted in two weeks, but that probably doesn't matter since no one reads this. I've been a little bit preoccupied by school, although this weekend I was actually more occupied by my car. I did my first oil change and it took a few hours because I didn't know how to do it! Next up is a brake job.

Anyways, I was having some problems with CEGUI... and I fixed them. Do you want to know how? I upgraded to a newer version of OGRE and CEGUI... in the process I also reinstalled, but I don't truly know if it was the upgrade or the re-installation that fixed the problem. This reminds me of my first days in linux though. Back before Ubuntu 10.04 was out, in late 2009, I installed Ubuntu 8.04 thinking it would be better for me as a beginner (seeing as it was the "LTS" which I understood to mean perfect). I don't exactly remember what problems I was having, but upgrading to Ubuntu 9.10 fixed them. Later, (and again I don't remember the specifics), I had experienced some problem with my graphics card in Ubuntu; needless to say, updating the driver fixed it for me. I could probably name a hundred other times upgrading software has fixed a problem for me (or downgrading from 64-bit to 32-bit), but for the sake of your time I won't.

As far as stuff in OGRE has been progressing, I promised screenshots so here is one. Overall, my progress has been getting stuff to work and creating an overall framework. This screenshot is something I put together while testing animation, and some of the entities are left over from when I was running the application for the first time.

Sunday, February 6, 2011

The Evolution of the Supersonic Game Engine

This week has been incredible; it is Super Bowl Sunday today of course (Go Packers!) and cold weather has hit hard on several places throughout the States, notably Chicago's blizzard, and for some reason, Dallas has been big on the news.. I think I heard somewhere that since it snowed in Dallas this week, right before the Super Bowl, it's possible that now Dallas is cursed and might not have the Super Bowl again... Actually I'm not sure of that, I think I head it but I can't give you a source on that so moving on; should be a good game!

Well in Colorado, where I'm from, we've had some nice weather... It was only like -3 degrees (Fahrenheit). Of course a few areas such as Evergreen seem to have experienced temperatures of -20? And I did not get one snow day from Red Rocks! Awesome! The high school I go to did close for Tuesday and Wednesday, so I had a little bit of time to do extra homework then. Due to that, yesterday I had a good 10 hours of coding.

To be exact, that was seven hours of coding and three hours of debugging. I can't get into the habit of testing code as I write it, so I sit down and just code for a few hours without running any of it. I have to admit though, I have discovered I absolutely love Python for one big reason. I remember writing a few things in C++, I spend a long time designing a class (I never liked using UML, I would design it by writing class definitions and comments) and then I would write the class, and test it. The testing process involved practically coding an entire project to test each element, and this is why I don't test while coding. Well in Python, after writing the class, testing it is as simple as opening the command line interpreter, and typing code such as the following:

  >>> from SampleModule import SampleClass
  >>> import OtherThings as ABunchOfCrap
  >>> import SuchAsOsOrTimeOrSys as YouProbablyNeedThese
  >>> sampleObject = SampleClass (param1, param2)
  >>> sampleObject.doSomething (param42)
  >>> sampleObject.rootForPackers (theyAreTheBest)
  >>> sampleObject.rootForSteelers ()
  Traceback (most recent call last):
    File "", line 1, in
  NameError: name 'steelers' is not defined
  >>>


Well I guess that was biased, but you get the point. I did have a good time debugging. I made myself slightly familiar with pydb, and then I learned of the existence of pdb which served my purposes just as well. Part of the debug process for me though was trying to figure out why the log manager didn't work. I had perfectly working code when I started, and then when I started debugging, I spent about an hour trying to figure out why I kept getting an error message about some kind of threading.

I haven't figured out how to fix the code and make it work, I just commented out all the places I send messages to the log manager. I did make progress with at least an error message to refer to when I tested the project in Ubuntu. I switched to Windows to see if the error happened there and--well I didn't get any kind of error message, I did get a message to the effect of "'python.exe' crashed. Sorry. Checking the internet for solutions........ No solutions; sucks for you! Bye bye loser!"

After commenting the code out, the application wouldn't display anything on the screen for some reason.. Well I was using the Borg pattern and in order to call functions from my framework (which is where I used the Borg pattern) I would do something similar to OgreFramework().someFunction (someParams). While working through pydb with the code, I realized that everytime I call OgreFramework().something, it runs OgreFramework.__init__(), and in there, I set every single variable to 0 or False or "" or [] or {} or... well you get the point.

I did the variables as such so I could keep track of what variables I was using, but what that did: 1) it would have caused a huge memory leak if there was no garbage collector... Heck it probably still caused a memory leak somehow and 2) OgreFramework.m_pRoot which I stored the OGRE.Root object in was a blank reference; when I asked it to render the scene it threw an exception that I didn't catch. Well I am still able to keep track of variables as such, I just moved all the 'definitions' outside the __init__ function, and when I call the inherited classes __init__ function, I set a flag to see if I had already done so. What I should probably do is instead of calling OgreFramework() everywhere, say framework = OgreFramework() framework.doSomething()

Well I promised screenshots, but right now I don't have anything pretty, just the media that comes with OGRE, like the ogre head, the robot, the ninja, etc. If anyone has read this, and thinks I could possibly benefit from some better design problem (that might fix my problems with the Borg pattern) let me know! This week, I have a framework and state manager that at least works, and I have a pretty good idea of what I will be doing for the rest of the project. Instead of making a "game engine," however, I'll be making a physics demo to 1) submit for some scholarships possible, 2) better my understanding of physics so I can do well in my Calc-based Physics class, and 3) I can get more acquainted with OGRE and Python. I will then convert it into an engine, but I would much rather move the whole thing to C++ if I make an engine.