There are two kinds of data backup: local and remote. Both Mac and Windows have built-in applications that work with “local” external USB, firewire, and eSATA drives. There are also a bunch of “free” back-up software packages that run from your computer. However, in the past couple years, the cost of remote/cloud-based backup has incredibly declined. For instance, CrashPlan+ which support file versioning, unlimited data, access to restore your data from any web-enabled computer, and next day delivery of your data (if you have a catastrophic crash) is around $50/year.

Most importantly, a very high percentage of designers and artists are primarily moving to working on laptops and from multiple locations. This growing laptop trend changes the dynamic of backup and what the user has access to when working from different locations. They may also not have room to attach external drives. I’ve been personally using CrashPlan+ for over a year and it’s been great! Now there are other web services out there (such as mozy.com) that offer low-cost, cloud-based backup to check out.

The key thing is to seriously start thinking about remote/cloud-based backup as part of your strategy to safeguard your creative data.

Summarizing my needs:
1) I need consistent, fast text output for debugging.
2) I need clear messages from my program which indicate what went wrong.
3) I would like some kind of performance profiling tool, to measure what parts are too slow, so I can optimize them.
4) I would like to have some idea about what my RAM usage is, to help spot memory leaks.

First, I need to come up with a standard way of keeping track of memory and the call stack. The call stack is the tricky part. As long as I have to do some re-arranging of the engine to fit the SDL way of doing things, I might as well go try adding some low-level experimental stuff to the “core” of the engine while I’m there. Every time there is any memory allocated, it will be allocated via the core, so I can keep track of it. Similarly, every time a call is made, it will also call the core to notify what call was made. I am worried about the performance overhead of calling the core that often so I’ll make it optional via a compile-time macro. While I’m at it, with the stack trace I can additionally measure the amount of time spent during each call. These ideas should hopefully take care of needs 2, 3, and 4.

Finally, for need #1, I would like a way to display the information gathered, right in the app, in real-time. There aren’t really any existing solutions for this — at least not simple/light-weight ones. You’d think that it would be fairly common to render text and stuff like this, but unfortunately you have to do that yourself. It just so happens that I’ve already developed something similar for this. I plan on tightly integrating it with the “core” I talked about above, and I’ll call it the Core Console. Here’s what it looks like with a raster graphics and semigraphics test (all the lines and dots and stuff are the graphics test, and the command line is at the bottom, with the date being text output just above it):

Trance's Core Console

That’s all rendered in software, to a single texture. It’s really fast and light-weight, and I expect it will work perfectly for debugging and analysis right in the game, without the need for external tools.

- Jake

- Casey

Actually, I’m pretty excited about this, since it is the first time I’ve ever made a cross-platform game demo, even though it’s a tiny one. It works! Woohoo! As planned for the main recipe, this uses OpenGL, GNU make, and SDL on all three platforms. Additionally, on Windows, I use MinGW to provide a common Unix-like build environment, to help match what I use on OS X and Linux. Seems to be working out pretty well so far!

Now that we have basic windowing and graphics up on all platforms, it’s time to get to work on the engine, 3QuadX, so we can do something a little more sophisticated.

- Jake

All the program does is output the string, “Hello, World!” from the main program and “Hello from libFoo too!”, to prove that the library is being called correctly. HelloWorld is notably simple, but it’s the traditional starting point for just about any new programming adventure. Here are the screenshots from each desktop platform:

(I named my Windows and Linux installations, beavis and butthead ;-P)

HelloWorld on Mac OS X

HelloWorld on Linux

HelloWorld on Windows 7

So there it is in all its glory (and about as exciting as dirt), our first truly cross-platform compatible program

What’s really cool about it is that, as planned, I use only one set of source files and Makefile for all platforms, as opposed to an IDE project for each platform. To actually build the program on each platform, all I have to do is boot into the appropriate OS, then navigate to the project folder on the command line and type “make”, and it magically spits out the appropriate build for that platform. Yes, it is that easy!

That said, figuring out how to set it all up to be automatic like this took quite a bit of effort. Writing the Makefile itself, which manages the build process, took lots of trial and error and reading/studying/etc. Once I got it working on the Mac, it was trivial to get it running on Linux. Windows, on the other hand, was not as easy, but I managed to figure it out too, as you can see.

So the first step is accomplished, woohoo!

Next up: Make it a proper application on each platform, instead of a little command line executable. I’ll probably delve into SDL for that.

- Jake

I think one of the major misconceptions that non-programmers have about game development in general is that all this stuff is pretty standard right? Should be easy to do right? I mean, games are everywhere! Heck, you already have Ace1 running on iOS, so can’t you just “port” it? Unfortunately, that’s easier said than done, which is why a lot of developers go with a third-party “game engine” like Unity3D. We very seriously considered going that route ourselves, but for several reasons, which I may get into in another entry, we decided against it. So I’m on my own trying to figure this one out, and it has been quite the challenge!

First, let’s talk about the basic tool needed to construct a game (or any app for that matter). On the Mac (and for iOS), the main tool everyone uses is called Xcode. It is what we call an IDE (Integrated Development Environment). There are other IDEs which you will find on other platforms, for instance, Visual Studio on Windows. The main point to realize is that they’re all different, just like word processors are different, even though they do the same thing. To make Ace2 work on Windows and Linux I would have to know how to use three different IDEs and set up the project on each one, which is a lot of work. Fortunately, there is an alternative, called “GNU make”, which I will refer to as make for short. make is available on many platforms, including Mac/Win/Linux, and can be used for iOS and even Android too, which is exactly what we need. Unfortunately, learning how to use make isn’t something I’ve been able to pick up very easily. make is completely text-based, and is a command-line utility. If that sounds user-unfriendly to you, then you understand the situation perfectly.

If I were to describe make in one word, that word would be: esoteric

esoteric :
adjective
intended for or likely to be understood by only a small number of people with a specialized knowledge or interest

In my years of experience I have observed that the majority of programmers tend to avoid using make. Most prefer to manage projects in a more graphically visual way, using an IDE. There are good reasons for that, and I would suggest that I think the main reason is because it seems a lot more difficult to read through the bewildering amount of gobbledygook that command-line tools, such as make and gcc, tend to take in and spit out, much less just trying to learn to use them in the first place. That said, most of the good software you’ll find out there is managed with make. If you’ve ever downloaded an open source Unix program, you’ve probably seen all the funky files, one of which was probably titled “Makefile”. If you drag that Makefile onto Text Edit you can see what’s inside it, and chances are, if you’re like me, you probably had no clue what all that garbage meant and promptly closed the window. Well this week I spent some more time studying up on what that junk means.

make looks for a file called Makefile or makefile or GNUmakefile when you type “make” in Terminal in that directory. It opens that file and reads the junk written in there to figure out how you want it to build your project. Basically a Makefile is just a fancy script, containing recipes for how you want each part of your program made. When writing a Makefile, you’re basically programming the computer to make your program. The language used in a Makefile doesn’t have a proper name that I know of. It’s a combination of keywords and syntax, mixed with shell commands.

Simple Makefiles are not a big deal to learn how to do. Unfortunately, what we’re going to be doing with Ace2, including it being cross-platform compatible, means we’re going to be needing some non-trivial things done with the build system, and that is taking me some time to sort out by learning the voodoo Makefile incantations needed to automate the build process for that. Mostly this week I’ve spent lots of time reading and studying about make, gcc (the compiler), and SDL. It’s been one of those back-to-school weeks for me.

In closing, I’ve started to become fond of how make works. I think I like it!

- Jake

This week I have been focusing on two things:
1) getting my 3D model code switched away from Apple API dependencies
2) getting everything running cross-platform ASAP

On task #1: I was working on my 3D model code and realized that it was written in a *very* Apple dependent way. It is so intertwined that I am going to have to rebuild that from scratch, unfortunately.

On task #2: I have come to the conclusion that I need to get things working on all platforms right away so that I can properly implement the 3D model code without having to worry about whether or not it will be portable later on. There are other reasons to do this as well, but that’s the one on my bench at the moment.

To go cross-platform, practically speaking, most developers use SDL: http://www.libsdl.org/

Here is a nice list of games which use SDL: http://en.wikipedia.org/wiki/List_of_games_using_SDL

From my point of view, there are a few hitches to using SDL:

First, while I’ve known about SDL for many years and have recommended it to others countless times, I have never actually used it myself. The reason being that I’ve never had a need or desire for cross-platform API support since I’ve always only developed for the Mac (and iOS). Obviously that is now changing with our plan to bring all of our future games to all desktop platforms. It will take a little time to learn how to effectively use SDL on multiple platforms.

Second, my existing “engine”, called 3Quad, was designed from the core to do things “my way”, not the “SDL way”.

Third, since 3Quad was originally designed for the Mac only, I am able to more easily use Mac-native technologies with it. SDL appears to be somewhat inflexible about how it works, and that is by design and necessity for cross-platform compatibility. In other words, my way of “windowing” on the Mac is better than SDL’s way, if only a little better, but obviously my way isn’t portable.

Fourth, I am not sure if SDL will be allowed on the Mac App Store or not. I assume everything is fine except for the possibility that SDL may be using some non-public API calls for a few things, which would get any app using SDL rejected. One example of such an unsupported API call which I stumbled upon in SDL for the Mac is setAppleMenu, which was removed in 10.4 but apparently still works.

The next obvious question would be: “Well then why not use your native code on the Mac and SDL on the other platforms?”

Answer: That is what I intend to do.

Unfortunately, that is easier said than done. Like I mentioned earlier, in the core of 3Quad, the way I do things is a bit different than the way SDL does things. Not that either way is particularly better than the other, but they’re not directly compatible. But we *need* cross-platform compatibility, and I really don’t see any practical way I can justify *not* going with SDL, so I am going to be forced to do things the SDL way, one way or another.

I have a plan! It’ll take a little extra work, but here’s what I’m going to do: I am going to start rebuilding the engine from scratch and I’m going to call it 3QuadX (the “X” is my super secret code for cross-platform, as in “x-platform”). I’ll be able to reuse the vast majority of code in the engine, so it’s not as tall of an order as it seems at first, but it isn’t going to be a no-brainer either and I figure it’ll take a couple weeks at the very least.

The main idea is to re-implement all my base windowing code and timing code to use SDL on all desktop platforms, equally across Mac/Win/Linux. That way I can fully test the code running on the Mac using SDL in exactly the same way as it would be used on the other platforms. This should allow me to easily deploy to Win/Linux. THEN, what I will do is redo my native Mac code to optionally replace SDL with the flip of a switch, so I can switch back and forth between SDL and my native code on the Mac, arbitrarily. This way I will be able to get the best of both worlds and ensure cross-platform compatibility at the same time.

- Jake

Partake in some Halloween voice-changing fun ;-D

Perfect for Halloween! Scare your friends, trick your Halloween treaters, and give your little brother or sister nightmares!

Feature Highlights:

• “Real-time” manipulation of your voice
• E-mail recordings to your friends
• Sync your recordings in iTunes
• Retina graphics for iPhone 4
• Microphone GAIN adjustment
• Supports wide range of iPhone, iPod touch, and iPad devices

Social Fun

• Recordings sync back to iTunes. (Requires iOS 3.2 or higher)
• Email your recordings to your friends. (This feature currently requires iOS 4 or higher)