libgba is so Advanced…

After I read through the basic of targetting the Game Boy Advance, I decided to take a look at the libgba libraries that devKit Pro, the standard tool of targeting the console, has.

I am surprised that there are two libraries that deal with multiplayer. I am even more surprised that there is support of the Nintendo e-Reader! (Despite what most people say, I actually enjoyed playing with the Nintendo e-Reader.)

That probably explains why devKitPro keeps being developed despite the Game Boy Advance being discontinued in 2010.

I hope that ShinyQuagsire23’s research on the Wireless Adapter gets in libgba one day…


ChaiLove is a First Choice

I decided that, if I were to make my games, I would make ChaiLove my first priority.

I came along when I looked at Red, a programming language that had a simplified grammar that deploys executables in hard-to-believe small file-sizes to plenty of platforms. After thinking over the potential (if true), I wondered: why target ChaiLove or the Game Boy Advance over Red?

My answer was that I liked Libretro so much that I wanted to specifically take advantage of Libretro. I also realized that, because part of what I liked of Red was the simpler syntax, ChaiLove would be a good fit my preferences opposed to the Game Boy Advance. In fact, the only real advantage I have in targeting the Game Boy Advance, other than being able to play my games in the Game Boy Advance SP I have, would be protection against the possibility that ChaiScript, due to its eventual reliance on C++11, would not make games that would run on old platforms… or the 3DS or PSP.

I would still explore Game Boy Advance development due to the accessible knowledge of low-level programming, the still widely-used C language, and having an available backup if my worries on the portability of ChaiScript come true, but ChaiScript’s mixing strength with ease of use (a big asset to me) had bumped up ChaiLove’s place.

Libretro multiplayer

Recently, Raidus is putting netplay that works with the Game Boy and the Game Boy Color. The functionality even works with different games, which would make Pokémon multiplayer actually functional! This is a change from the way Libretro once did things!

This would radically change my game plans.

  • If I decide to make a game “from scratch,” then I would not have to worry about using an external library when making my game. (I hope that I can still make a type of Pokémon Communication Center, though, which would mean that I would make a separate but related game that is supposed to be a server instead of a client.)
  • If I decide to target ChaiLove, then I feel more comfortable in how Rob Loach’s implementation of networking would turn out. This may complicate things on his end, though, because he is the one implementing the API.
  • If  I decide to target the Game Boy Advance, then all I have to do is implement functionality of the Game Link Cable and let Libretro worry about implementing the actual functionality!

In all, thank you so much, Radius!

Game Boy Advance Sound Systems

While looking at the Tonc audio introduction got me familiar with how the Game Boy Advance handled audio at the low level, I ended up reading on how a lot of people are either making their own sound players/mixers or teaching others how to code them. That means that, even if I did understand low-level sound programming, I would be essentially “reinventing the wheel”. Furthermore, when I considered all the people making sound players/mixers, that means that someone’s sound system must have matured through the years, even being released freely. I decided that finding someone else’s sound system would lead to a more efficient product.

So far:

  • Because I plan on having my games have the GPLv3 License, I have already decided to skip any audio systems that are not freely-licensed themselves. That means that I have to skip over the fabulous Apex Audio System which manages to mix an astoundingly low footprint with astoundingly high quality. I can hope that the Apex Audio System follows Krawall’s lead on freely licensing itself years later.
  • Krawall, itself, though, uses not only the problematic Cmake but also C++. I want to make my games in C.
  • BoyScout not only uses its own exclusive format (which makes finding freely-licensed music far more difficult) but does not seem to work itself. I mean, no matter what keys I press, the tracker does not work!
  • F.R.A.S. is not only old but also does not support every effect when playing .mod files.

Right now, my options seem to be MaxMod and GSMAudio. MaxMod is not only up-to-date but also plays .it, .s3m, and .xm files, which I read that are better formats compared to .mod files. GSMAudio is an interesting case because GSMAudio seems to make streaming files work in the Game Boy Advance. Apparently, I can just use a .wav file (or convert a .flac file to a .wav file because both are lossless formats), then to the .gsm format, then play the audio through the GSM Player. According to the webpage, I can store up to 150 minutes of audio in a 32 Megabyte (256 Megabit) cartridge, that is, the effective maximum file size a Game Boy Advance game. While that would give me access to a lot more music and free me from worrying on getting good soundbanks, the file size is a concern, especially when you consider that MIDI-style formats make smaller files, being mere instructions instead of wholesale music.

My concern with both is music quality. I mean, I read that the sound of the Game Boy Advance, especially concerning ports of Super Nintendo Entertainment System games, is bad. While I understand that there is normally an inverse relationship with quality and file size, I want to mitigate that problem when I can while still keeping file sizes small. If I were to use the pool of Game Boy Advance games that I have played and draw an example of a game that had great audio, I would pick Lilo & Stitch 2: Hämsterviel Havoc. I mean, while you can still hear the physical shortcomings coming from the Game Boy Advance, the audio quality is astonishingly clear and smooth, especially when playing trumpets. If that type of audio quality is infeasible due to the file sizes the music would have to be, my alternative would be the prequel Lilo & Stitch. The music in that game has an aesthetic that has a light nostalgic touch from apparently embracing the electronic nature the sound hardware has, but still keeps a high fidelity without sounding… muddy.

Comparing the two (using the MaxMod Game Boy Advance demo against a compiled GSM Player file) by playing both of them in an actual Game Boy Advance SP system without using headphones, GSM Player won in terms of audio quality, though MaxMod is still very good.

I wonder what soundbank MaxMod uses…

No longer fearing the low level

Going through Jasper Vijn’s tutorial on making games that target the Game Boy Advance was honestly eye-opening. I mean, this tutorial convinced me of the virtues of coding in C. Compilation became approachable. Makefiles became my friends. I no longer fear pointers or raw memory-addresses. My knowledge of low-level graphics programming got such a big boost; Libretro’s software-rendering example made a lot more (though not yet absolute) sense! I mean, I actually know what a pitch is! (Low-level sound still freaks me out a little, though that may be because I did not get to that part of the tutorial yet.)

The biggest part was that I was worried that my Master’s Degree in Software Engineering was pointless because I had little practical knowledge (think makefiles and that stuff), while I had trouble picking apart rather advanced C++ code. I am not sure if that was due to the simplicity of Mr. Vijn’s tutorial, but I could not only actually understand the stuff (if I take things piecemeal), but a few things went without saying! (Of course I would abstract away stuff that I would otherwise repeat in my code!)

Whether I target the Game Boy Advance or not when programming games, I thank Mr. Vijn so much!

ChaiLove or Game Boy Advance

Summarizing part of my pathway in game development, I was initially excited in developing games in LÖVE and the pico-8. However, I hit into the deficiencies of Lua… mainly how Lua does not have support of classes. Because of this, I spent my time searching for alternatives. Two platforms ended up fitting my needs: ChaiLove and the Nintendo Game Boy Advance.

To me, ChaiLove is LÖVE without the problems. More specifically, ChaiLove retains LÖVE’s ease of programming (and, in fact, is modeled after LÖVE’s API), flexibility in programming, abstraction of lower-level requirements (rendering graphics being the big one), and freedom from compilation while adding the benefits of C++/ChaiScript (actual classes!), taking advantage of Libretro, and meaningful active development. In fact, the Libretro blog post explicitly mentions potential portability to other consoles because ChaiLove targets Libretro!

Before ChaiLove appeared, though, I seriously considered using a more indirect approach in trying to write a “universal” game. In this case, instead of trying to code from scratch a game that works in every platform that RetroArch supports, I could simply look for a game system that every version of RetroArch can emulate, then write a game that targets that system. This approach also provides (theoretically) infinite forward-compatibility. Though I initially considered this approach because ChaiLove did not yet exist, the fact that ChaiLove depends on ChaiScript, which depends on C++14, motivated me towards considering the indirect approach again. After all, Visual Studio 2003, which is the latest compiler that can generate binaries that work with Windows 95 and the original Xbox OG console (the one before the XBOX 360), does not support even C++11… or C11, in that matter.

After currently comparing the systems that Windows 95, the Nintendo 3DS, and the PlayStation Portable can play, I decided that the best system was the Game Boy Advance. My reasoning was that:

  • I should avoid any emulators that prohibit commercial use (an issue that plagues Libretro and its contributors to no end)…
  • …or anything that requires an official BIOS.
  • My theoretical game Wuu Shyng is based on the mainline Pokémon series, which is played in the handheld GameBoy and DS product lines. A result of these game being played on handheld systems is that the contents of two different save files interact with each other; home systems that use save files usually rely on the contents of only one save file, instead.
  • My games are based on a maximum of 3 action buttons and 1 menu button. A lot of the systems that Windows 95, the Nintendo 3DS, and the PlayStation Portable can play use 2 action buttons and 2 menu buttons, instead.
  • While I could target the original Game Boy or the Game Boy Color systems, I read, repeatedly, that games that target those systems needs to be written in Z80 Assembly language, even when C compilers exist.
  • The Game Boy Advance has a lot of strength. Mario Pinball Land used 3D graphics. The Game Boy Advance Video series used full-motion videos.
  • The games I want to make are essentially Super Nintendo/Game Boy Advance games, anyways.

Targeting the Game Boy Advance is a very different paradigm, though. I have to code the game in C instead of C++, which uses structures instead of proper classes. The Game Boy Advance does not play actual audio files, but, rather, MIDI-style files that say what sound samples should be played. (I am not good at making full songs, plus there seems to be a lack of freely-licensed music that can be played in the Game Boy Advance.) Sprites have to be converted to bits (which was a big problem when I looking into coding a game from scratch). Homebrew information on the Game Link Cable (a big thing, given Wuu Shyng and its influence from Pokémon) is rare; homebrew information regarding the Wireless Adapter (something that would be very beneficial) is even worse. Of course, I would have to compile, though I would also have to use a toolkit (in this case, devkitARM, a part of devkitPro). Finally, the Game Boy Advance, being a dedicated handheld device, has more programming restrictions… a lot of them.

However, from what I see, targeting the Game Boy Advance is within my skill set. I mean, the Tonc guide and devkitARM’s libgba libraries seem to make the Game Boy Advance accessible. I have the 1st edition of The C Programming Language, a book that is not only enjoyable and digestible but also would definitely produce C that is compatible with Windows 95. Use of C also means that I, in theory, could use plenty of the C libraries out there that would help my game development. I would not have to worry about different display resolutions because I would only have to focus on keeping things 240 * 160. Implementing multiplayer through either the Game Link Cable or the Wireless Adapter bypasses Libretro’s current netplay system which is opposed to the way I want to make multiplayer, which is based on handheld game systems, anyways. (I would still have to do something about programming a server because I want to implement a type of Pokémon Communication Center in Wuu Shyng.) Game Boy Advance games (excluding a couple of Game Boy Advance Video cartridges) go up to 32 Megabytes, that is, significantly small by current standards. (Thought the main influence on file size comes from the programmer, getting a maximum file size, especially one that small, is comforting to the downloader.)  There are also more platforms that can play Game Boy Advance games… including the Game Boy Advance SP that I currently have.

Honestly, I am actually getting excited from the possibilities. I am eager in getting Re-Hoard and Reckless Abandon done!

Is ChaiLove a good fit?

Looking at my previous journals, I noticed that LÖVE had a lot of benefits: because of its specific focus towards game programming, the “batteries” are included (especially on video!), yet I can extend the capabilities more (say, if I wanted to add networking or adaptable resolutions), all in a language that has more simplicity over C++ yet does not require building! The disadvantages are that Lua, the language LÖVE uses, loses some important functionality C++ has (most notably classes) while Lutro, the Libretro implementation of LÖVE, seems to have been slowed, plus I can run things out of Libretro, anyway, despite me wanting to make games that take advantage of Libretro.

Though my current plans were to use a custom arrangement of C++ libraries and make an API that connects them all together, ChaiLove seems to be LÖVE, but without the aforementioned negatives. I mean, ChaiLove is not only undergoing active development but is also specific to Libretro. More importantly, ChaiLove uses ChaiScript, which is based on C++ and therefore has its strengths, including classes.

This just makes ChaiLove more attractive. There also seems to be some writing over other possible ports, though I am a bit wary over the possible lack of ability of being able to run ChaiLove in consoles that might not be able to handle C++14.

If I could use my own C++ libraries in my game, this would be excellent.

Chai Chai Chai

ChaiScript is a new scripting language more directly based on C++. That means actual classes and stronger overall capabilities.

ChaiLove is essentially LÖVE with ChaiScript. LÖVE has spoiled me with its mature functionality and many user-provided libraries, but ChaiLove actually seems complete.


This puts me at a crossroads. In one thing, ChaiLove combines LÖVE’s ease of use and freedom from compilation with C++’s functionality. On the other hand, ChaiScript requires C++14 since version 6.0.0, which was previously C++11 since version 5.3.0, which was Boost up to version 4.3.0. Stone Soup got those problems with C++11 being too new to old compilers, making my “a game that runs in any platform that runs RetroArch or even just Libretro” difficult.

I shall keep an eye on ChaiLove, but I am not permanently switching from my plans of making a game “from scratch”.

Touch-ups on the game package

I knew that there were some things missing!

Strings: The Better String Library seems more robust and secure than the standard C++ strings. The library also has rudimentary UTF-8 support, though I fear that I may have to supplement the library with better support.

Databases: Though there were many popular options, I decided on SQLite because of its simplicity, light weight, no need of a client-server model, public domain license, and, most importantly, its specific intention in being embedded in programs. All of these make SQLite a great fit to my games, which I intend to be economic and playable in even relatively weak systems!

Internationalization: This is very important in my case: at the very least, I am selling games to the Puerto Rico, Dominican Republic, and United States markets! Fortunately, I found Poedit. I never liked the idea of using spreadsheets in localization, thus using Poedit’s gettext files, which are a simpler localization format, were much better. Other than the required UTF-8 support, Poedit also recognizes pluralized forms and “ballpark” translations. The features I want are on the free version, though I can always compile the program myself if I needed to do so.

Documentation: ROBODoc is flexible almost incredibly; ROBODoc not only supports any language that supports comments but also exports to a lot of other formats. I wonder how I am going to write the comments in a way that does not get in the way of the code, though, especially since I read Clean Code

Logging: I do not exactly know what exactly is logging other than what a log is. However, this may be useful in case my game gets errors. Now, I think of using plog, but with g3log‘s crash-safe sinks. After all, while I like plog’s ease of use and UTF-8 support, g3log’s sinks that hold the log data give g3log resistance against crashes. I do not want to chose between ease of use and crash safety, even if that means that I would have to do more work myself.