Game Development in South Africa

Joshua Dallman is well-known around the indie scene and runs Red Thumb Games out on the West Coast. Recently, he accepted a freelance designer/producer role for a game developer in South Africa. During his six months there, he made games, witnessed crime, bribed cops, and found out how diverse and beautiful the country is. Since his journey to South Africa parallels my own journey to Cancun in many respects, I thought some of you might find it an enjoyable read.

Game Dev in South Africa

 Red Thumb Games

Support for Arbitrary Resolutions

One of the things that I never got around to implementing in my game framework was wide screen support. I’ve had basic windowed/full-screen support, but it has always been ‘dumb’; the framework tried to set the resolution to the prescribed size (typically 1024×768 ) and if it failed, then the game wouldn’t run.

This is definitely not the ideal behavior and a little development on my subnotebook was all I needed to realize it needed fixed pronto.

You see, the maximum/native resolution of the Acer is 1024 x 600 — a wide screen format. My current framework works OK in full-screen mode with this, but it’s not ideal as it produces stretching. In windowed mode, it’s even worse. The framework will create the window with the specified size but it won’t fit in my screen space, leaving a large portion of the window off-screen.

I was curious as to how modern casual games handle this, so I went over to Reflexive and downloaded Totem Tribe (a nicely done lost village simulation.) In full-screen, it didn’t adjust for my wide-screen, instead stretching a 4:3 aspect. It looked OK, but not great. Also, when I came out of full screen and exited the app, all of my other open applications were re-sized; that’s annoying.

In windowed mode, it didn’t behave ideally either: the window was larger than my screen space clipping both the top and bottom off.  This was definitely a little disappointing. But it also inspired me to get it right.

In both windowed and full-screen mode, my framework now tries to find a supported resolution in the native aspect ratio of the display device. Then it will find the closest match to the specified resolution for the game. 

This works pretty well for full screen mode, allowing true 16:9 support as well as traditional 4:3. 

Windowed mode posed one more complication. If my target resolution was 1024×768, it would create a window that covered the whole desktop. Choosing to create a window in the native aspect resolution (in this case the closest supported resolution was 1024×600) still filled up too much space, and the result is just ugly. So I had to write an extra line of code that uses the minimum of the specified dimensions and 75% of the current desktop resolution’s dimensions. 

This way, if I have a 320×240 window, it’s no problem and if I have a 1024×768 window, it cuts it down to 768×450. This result is very pleasing. Below is a  screenshot showing a 1024×768 target resolution window after the resolution-solver cuts the window based on the delimiting 1024×600 desktop resolution. Notice the native aspect ratio is preserved.

With both windowed and full-screen, there was one last problem with rendering. Having an arbitrary resolution had no ill-effects on my game space rendering; the clipping functions were already set up for this. Unfortunately, all of my screen space rendering was murdered, so things like UI elements and menus were all messed up. The solution here, was simply to store relative positions for all screen space objects versus absolute positions. A relatively simple solution, and now the framework finally has arbitrary resolution support!

 

1024x768 window run through the resolution solver. Good!

Subnotebooks and Game Development

A little over a year ago, a few pc manufacturers  (led by Asus) decided to release a series of subnotebooks that were even smaller and more lightweight than previous models. The little devils were supposed to be ultra portable and equally rugged. These miniature laptops are often now called “netbooks” and have gained a large install base and have received much fanfare.

I haven’t had a laptop in almost 2 years, but I’ve been wanting to get one ever since. Subnotebooks piqued my interest, but I was worried that they might be underpowered or impractical for game development. After doing some research, I found that these small computers actually punch a decent punch so I decided to ask around with other developers to see if they had any experience using one for game development. Surprisingly, I received several responses from current devs who both use and enjoy their subnotebook to develop on as a secondary computer.

To be clear, I don’t want a subnotebook to be used as my primary dev machine. However, I like to code when I’m on the move, plus this would probably be the only computer I take with me to Mexico. Once there, I’ll likely just buy a desktop to serve as my main dev machine. Of course, I  have no idea how long the interim will be, so it’s pretty crucial that whatever laptop I get can at least run my games. 

A week ago, I decided to take the plunge, and I picked up an Asus Eee 900 model. Everything seemed great at first, but a few of the keys on the keyboard didn’t work. After finding this was a fairly common problem with the Eee, I took it back and picked up a different one. I had choices between Dell, HP, and Acer. I’ve never owned an Acer, but I’ve had bad experiences with both HP (quality of parts) and Dell (customer service), so I went for the Acer Aspire One. 

And I love it.

The model I picked up has the 1.6 Ghz Intel Atom processor, with 1 GB RAM, integrated graphics and Windows XP. I chose a model with a SSD versus a regular HDD, which has much less space ( 8GB SSD + 8GB SD card) but is more rugged and much faster. It’s also dead silent. After the Best Buy gift cards I graciously received this past Christmas, I dropped a total of a $150 on the computer, which makes it by far, the cheapest new computer I’ve ever bought.

With an 8GB primary drive and Windows XP, you only have about 2.5 gigs of space left. So the first order of business was cleaning up the Windows install. Eventually I managed to get this down about a meg, giving me a little over 3 gigs on the SSD and about 6 gigs on the SD card. None of the subnotebooks I looked at had optical disk drives (which are large, heavy, and loud) so I had to borrow a friend’s external DVD drive to get Visual Studio 8 professional installed. Unfortunately, I had to install this to the SSD (I probably could have convinced Windows to use the SD card, but it seemed risky.) 

After Visual Studio was good to go, I was able to install the DirectX and PTK SDKs to the SD card without any problems. Shortly after that, I transferred over my projects and hit ‘build’. 

Stupid linker errors. After fiddling with some environment variables and my IDE settings, I finally had a successful build. I was a little worried that my build/link times would be slow on this machine, and while they are surely slower than my desktop, I was actually surprised at how well the little notebook handled itself.

So after a few hours of Windows tinkering, installing, and tweaking, I was finally ready to run my test app. Eureka! Not only did the Acer run my app, it was running at a cool 70 FPS. Very surprising and quite terrific. The test app is rendering 4 scrolling, alpha enabled, tile maps at 1200 x 600 with 200 64×64 rotated sprites.

Needless to say, I’m very happy with the purchase and I think this light-weight and compact laptop and I will be very good friends for a long time.

Below is a shot of the computer (cigarettes for scale) running one of my test apps in OpenGL.