And there we have it: the Windows bug in my project is no longer! Ironically, in this case it's more like a thanks to Windows for picking up this bug! Contrary to my initial belief that the problem was related to some kind of pointer issue with my sprite class, it actually wasn't. It was one of those bugs where you smack yourself in the head and say "How could I be so stupid?" It was something that could be easily overlooked by anyone, however. When I initially wrote my ls_sprite class, I didn't have the intention of creating single frame non-animated sprites. Later on, it became pretty obvious that it should be able to handle this situation. In the constructor for a single-frame sprite, I missed setting a (now known to be) critical variable to an initial value of 0. Without setting this variable, a sprite would function perectly fine, but may or may not draw itself depending on what the initial value of that variable was when an instance of the sprite class was created. It appears that during all of my testing in OSX I was lucky in having that variable automagically set to zero. Under Windows, this wasn't the case. I'm glad this bug came up when it did, because it has saved me from getting burned further down the road when the sprite class is a lot more robust than it is now.

Work on the project slows down quite a bit due to this bug. I would have my laptop with me all the time, but I wouldn't work on it because I didn't want to add new things while this bug was just hoveringaround. If there was something fundamentally wrong with my sprite class, I didn't want to continue using it in fear that it might need to be changed dramatically. I couldn't however, debug it using my laptop, since it's a Mac (I only could observe this bug using Windows). Ah, sweet victory.

In the time between finding the bug and tucking the little sneak away I have meddled around in a lot of Cocoa development with OS X. In fact, I've actually come quite a ways with it. I haven't dropped the idea of writing a little bug tracker/to-do list application native to OS X. Having that as something to fall back on when I'm too fried from working on my main project really is helpful. I'm still considering whether or not I will host the intermediate workings of my OS X applications here or not.

There's not much to report about the project. I still haven't fully debugged the issue with regards to Windows. In fact, to be honest, I haven't even looked at that issue since it happened. For some reason I'm avoiding it; most likely because my Windows machine isn't mobile and limits the opportunities I have to work on it when I'm in a more motivated state. I've been finding that during lunch break at work I'm quite motivated to get things done with my projects. It sounds very strange, especially since I'm doing programming for a job.

That said, I actually have been progressing a lot with my Cocoa programming. It's quite exciting, actually, to be working with a new platform. I've been working on a little project that does nothing but generate oodles of random worthless things. It's a great way to learn all of the UI Classes that Cocoa supports. Once I have it in a nice and finished state I will most likely post more information about it here.

Now, haven't I become quite the secretive little news poster? I'm beginning to keep everything a secret until it's just about ready to be released. :)

It's been a while since my last post. Not much has happened since I discovered this "Windows only" bug. I'm sure the bug doesn't only exist in Windows, but rather, it is only easily observable when running the game under Windows. I have some pretty extensive logging added into my sprite class. It has been run and tested on the OS X side of the world, but not the Windows side yet. I'm contemplating whether to have two "versions" of the sprite class, or just add debugging information straight to the main version of it and #define whether I want debugging or not. The latter can actualy prove to be more of a hassle than the former due to the fact that to properly and efficiently do debugging via the logfiles I had to modify the class's constructor. Either way works in the end. I'm quite sure that this debugging won't reveal too much extra information that I don't already know when I run it on Windows, but it still doesn't hurt. Hopefully I'll bump into what's causing this error just by chance. Of course, it will end up being one of those bugs where you smack yourself in the forehead and say "Of course this was happening."

In the meanwhile during the period of time I wasn't debugging things in the Windows world I started wading my way through developing Cocoa applications under OS X. It is actually unbelivably easy (so far). I believe it may not be a far stretch to say that the bug tracking software I would like to write may actually be a serious possibility.