After dealing with some painstaking issues that are related to Allegro (possibly a bug) I have finished the Linux port of Zep's Dreamland! It should run on most flavors of Linux without any problems. Please note that the actual ReadMe has only been modified for the Linux version of the game. The Mac OS X and Windows versions did not have their ReadMe's updated to reflect this Linux port.

Enjoy, and don't forget to try out the additional level sets!

Added to the list of stable distributions Zep's Dreamland runs on are Mandrake, Debian, and SuSe. The screenshots section is finally updated. Thanks go to Simon for letting me use his screenshots of ZD running in Mandrake. Other than that, nothing new on the ZD:Linux front. I'll be doing some recompiling soon to get things in a prepped state for release. I still do not have a definite expectation as to when that will be.

I've been going through and seriously refactoring the code for the current project. Most of what I did was add and modify comments. During that process, though, I noticed some major inconsistencies in my naming scheme. While trying to write comments for some code that wasn't inherently self explanatory I found myself wondering exactly what it did. My choice of variable names made things a little more difficult than they should have been. I realized that I really did need to come up with some good naming conventions to fix things such as, for instance, the following set of similar variables: ls_sprite *walk, ls_sprite *jumping_sprite, ls_sprite *sprite_falling. Three different ways to name variables of the same type. Why shouldn't walk be special enough to have _sprite tagged onto it? I found that this made for some very confusing code. Thus I dedicated some time to devising a naming convention that I hope to stick to. So far I've decided to prefix certain variable names depending on just what exactly they are. For instance, all variables which are sprites will be prefixed with "spr_" and all Allegro SAMPLES will be prefixed with "snd_". This makes reading the code seem a lot more obvious in what it is doing simply by reading it. As for whether I will keep this naming convention, I'm not sure. I may switch from a prefix style to a suffix style, or choose something different altogether. When it gets town to it, though, I just want to have something in place that is consistent and that I will be happy to use throughout my project.

In the long run, it will only end up helping me. With sloppy (or even worse, no) naming convention it becomes harder to keep track of your code, especially as it grows. At least, this is what I've found. I still have a lot more things to think out when it comes down to how exactly I'm going to name everything. I'd rather not get ridiculous and start naming things with a prefix of what class their derived from, ala: base_object_nameofrealobject. I want to keep it concise and efficient, yet easy to understand. I'll be going over more and more methods, and possibly doing a little bit of research in this topic before I set anything in stone. So far, though, I've updated all sprites, SAMPLES, and DATAFILEs to use a the specific prefixes: spr_, snd_, and dat_, respectively.

Many of the issues I had while running Zep's Dreamland under linux were simply due to the fact that my configuration is somewhat lacking. On other systems it runs generally fine. Now both the game and editor have been compiled under linux and tossed into an archive for some select users to test. I still am waiting for a few more to test things out for me.

As for the "unannounced" project I have added a bunch of nice comments to one of my more cluttered files and, let me tell you, it feels a lot nicer to have them there. Next up is the rest of the files that need more informational commenting. After that it's onto more real coding.

I'm considering making placeholder pages for the projects that haven't been revealed yet to help differentiate between the current project, and the other long-term project that is completely "behind the scenes." To clarify things for now, at least, here is the current run down of things:

The "current" project is what I'm working on at the current time with most of my efforts. The "other" long-term project is a more story driven one that will take a much longer timeframe to even begin the coding phase for. With this "other" project I am still only developing basic storyline. Hopefully this helps clear up a few things. If I mention "current project", you can rest assured it is the one I've been talking about more in my recent posts. If I do, however, end up talking about my more story-driven project, I will most likely address is as the "long-term" project, or quite simply: "the more story driven project." It's confusing right now because I haven't revealed the potential names for either of them. Once I get enough headway into the current project, things will start to be revealed; starting with new "current screenshots." They are horribly old, but I have nothing to take a screenshot of that won't give away what the current project is.

Sit tight.

With the help of a good friend of mine I was able to get my Linux system running a little more properly now. With a working network connection I was able to hit the web and download Allegro as well as grab the source-code to my projects. I ran my first compile-through of Zep's Dreamland tonight and it went rather well. Only a few errors occured during the compile, all easily fixable. Needless to say, I had a running version of Zep's Dreamland in Linux shortly thereafter. I had a few people test a prebuilt binary on different distributions of Linux. The results were different in some areas, but generally the game actually works like it should! Here is a list of the current distributions it did run under, along with the issues associated with them:

Gentoo: Runs fine, but no midi.
Slackware: Runs fine, no midi, no fullscreen.
Topographical Linux (via Windows): Runs fine, no sound, no midi, no fullscreen.
Fedora 2: Runs, but crashes after some time in an internal Allegro function.


It appears that most distributions have troubles with switching to and from fullscreen mode as well as midi issues, both of which I will have to address in the near future. Sound seems to work fine in the systems that support it. The random crashes under Fedora 2 keep me skeptical. I will have to do more testing in this area. All in all it seems like having a prebuild binary will work quite well in most cases. This is the approach I will take for the time being.

I have yet to compile the current project under Linux for testing. I will most likely be directing a bit more of my attention to ZD:Linux as I would really like to have a fully working version of it for the major distributions of Linux.

Today I did a re-port of the current code from the Windows fixes back over to MacOS X. As suspected, everything worked perfectly fine without any glitches or issues. Perfection, or something close to it.

I also (finally) installed Linux onto one of my older laptops. I'm still in the process of getting everything up, running, and completely configured. Currently I'm running into issues with a specific PCMCIA card; something which I hope to have resolved soon. Whether or not this signifies future releases of my games for Linux I cannot be sure of. Yes, I want to bring Zep's Dreamland to Linux very much, but I'm still not ready to release the source code for it yet. Pre-compiled binaries aren't always the best way to go, but that is the direction I'd like to follow for the time being. So, if anything, that's how it will be.

I spent a large portion of my time today fixing up those bugs with the sprites I mentioned two days ago. They are completely worked out and now the Windows version of the current state of the project runs exactly as the Mac OS version does. This is great news. The bugs were very minor, but took a long time to actually figure out. Both of them were small pointer errors that were hard to track down. One actually caused the game to crash while the other caused glitches in how sprites were displayed. All that needed to be changed was two lines of code, but it sure eluded me for quite some time. Of course, these fixes need to be rechecked on the Mac OS side of things to make sure they play nice-nice. I can't see any reason why they won't, but I'd like to make sure.

While doing all of this debugging I ended up throwing in a bunch of extra stuff onto the screen: mirrored player sprites, a plethora of other sprites, as well as other things. It really was quite fun to watch all the objects in action on the screen. In fact, when creating multiple instances of the player I made the assumption that when in the air they wouldn't fall; but obviously they did. It just made me smile when I realized that the way I built things up could never allow something like that to happen. Strange enough to say it; the debugging session today let me view some of the much cooler parts of what I've coded so far.

Happy New Year to everyone! To be honest, this past week of vacation really has been just that. I haven't had any classes, haven't started work yet, and, most important to you, haven't seriously worked on anything at all. Evidently I used this week to do a whole lot of game playing and relaxing.

I have a newly acquired Windows machine to do some real work on now (my old machine has been slowly starting to die, unfortunately). I have pseudo-ported all my current work over to the Windows world. Everything compiled fine minus a few warnings that don't make much of a difference (such as: "no newline at end of file"). When running the game, however, I noticed some strange behavior. Ironically the game doesn't work quite correctly at all, and I'm not 100% sure what is causing the issues. My best guess is that it's some pointer funkiness as mostly everything works but some of the sprite work is a little messed up. It could also be some kind of strange formatting or update to allegro's datafile routines; as I'm using a newer version on my Windows machine at the moment. So far everything works as it should except for a few animations and movement left or right. The game simply crashes. I haven't looked into it any further than that though.

Tomorrow starts my return to work. After settling in I hope to get back into the grove and start working on things at least once every other day. We'll see how it goes!