I am very thankful that I learned C.

One of the reasons I have learned C was because of the job opportunities.

My prediction came true.

Recently, I went to an on-site programming screening. After I did a survey on my career background, I was given test…

…s. Though my specialty is on back-end programming (working with Delphi, Java, Python, and so on), the range of skills I could do had the supervisor, instead of choosing 1 test that best fits me, concluded that I may do every test I could. I think that I am allowed to say this because I am not mentioning the specific company or exercises, but one of the tests was back-end, another was networking & databases, and another was website scripts.

Unfortunately, after I left my attempt with coding Re-Hoard in JavaScript, I forgot JavaScript. There was also a problem with JQuery, a library that I did not know that I would need to learn. A few problems dealt with more abstract or hardware-related aspects of networking. However, the remaining problems involved the two computer languages that I had been learning: C and SQL. Sure, I made a mistake in an SQL problem by writing “IFNOTEXISTS” instead of “IF NOT EXISTS”, and the C exercises may have actually used C++ or, at least, a version of C that is later than the one used in the 1st edition of The C Programming Language (because the exercises used void), but the exercises not only made sense but sometimes became easy! I did not work on every C exercise, though; one required knowledge of a character set. Another I did half-done; that exercise required me to parse a stream and print a webpage. In that exercise, I did what I could, mostly focusing on the webpage, but that exercise seemed to be intermediate-level. Never the less, I was very thankful over and over because of my knowledge of C and SQL.

I got a “proper” interview scheduled.

I did not attend this blog recently because, other than health problems, I was busy learning Ruby. I wonder how far that language would take me.


I finished studying C.

When I worked with ChaiScript, I suspended learning C because I do not want to cause any learning conflict when using 2 programming languages at the same time. After I suspended development on Re-Hoard and Reckless Abandon, I went on learning Ruby because of something else. However, I decided to stop learning Ruby and finish going through the 1st edition of The C Programming Language. After all:

  • I should finish what I have started, especially at learning such an important language.
  • I effectively had about only 20 pages of book remaining.
  • I have been going job-hunting, but I did not put C in my résumé because I did not go through the whole book. Telling my potential employers “C is not in my résumé that I attached, but I am actually learning the language!” was ugly.
  • One of my alternative projects needs C anyways.

Given all this, I spent yesterday and today finishing my studies. Surprisingly, after I go through the definitions and lvalue stuff in the Appendix, most of the content is stuff I already know.

Finishing this book is a worthy accomplishment to me. Putting 1st edition of The C Programming Language on the “storage” bookshelf… storing the Gabite fake Pokémon card that was my bookmark… I feel that I gave them some sort of “honorable discharge”.


…that essential programming language…

…that knowledge is mine, now.

Shifting gears

I spent 2 years working on Re-Hoard (and Reckless Abandon) without any workable product.

Half of that was laziness and lack of direction. Half of that was struggling with inadequate programming languages.

While I get used to working with DevKitPro, what would I be actually producing in the meantime?

In light of these facts, I shall temporarily suspend work on Re-Hoard and Reckless Abandon.

Instead, I have something else coming up.

I have a Launchpad account.


What motivated me was the confirmation that Microsoft bought GitHub. Sure, GitHub needed the support because GitHub was losing money (though I wonder how much GitHub lost in 2017 and this year). I also do not have a problem with using proprietary software; I did develop on the pico-8. However, not only do I want to eventually be part of a completely free-and-open-source (“liberal”?) software ecosystem, but I am also worried at how Microsoft would affect GitHub… or use the data.

I picked launchpad because that was the only free-and-open-source code repository that supported translations, a feature that I hold in high importance.

I am not going to get rid of my GitHub account. I still depend on Rob Loach, whose software is still only on GitHub. Even if I do finish developing my ChaiLove games, I still want to keep track of others who do not want to move. Most importantly, I would like to wait and see what actually happens after Microsoft gets GitHub; my Launchpad account is just a backup plan. However, any new developments of mine would be in Launchpad.

I might put up a presence in other source code repositories (including GitLab) if there are enough people there.

Why not make a game from scratch?

When I was learning C, I figured out that, because Libretro also uses C, I could simply target Libretro instead of the Game Boy Advance. Not only would this route free me of the restrictions of the Game Boy Advance but also gives me far more flexibility with what libraries and other functionality I could include (say, movies). Plus, the whole point was that I wanted to actually take advantage of the unique features Libretro has.

However, I found out that there are some good reasons why I would target the Game Boy Advance… at least at the current time.

  • Drawing graphics in the Game Boy Advance actually appears to be more straightforward compared to from scratch (even in Libretro), especially since…
  • …I only have to deal with one screen resolution (240 * 160 pixels) and refresh rate (~60 fps), whereas writing a game from scratch would have to account all of the screen resolutions and refresh rates of any device that might play my game.
  • Trying to work within the restrictions of the Game Boy Advance would lead me to write more concise, more efficient code.
  • The whole point of Libretro is that I would write a program that targets Libretro, then the program would run in any platform that runs RetroArch or similar forntends. The problem is that, in practice, I would still have to consider the different platforms when compiling. A couple examples are that, while a Libretro program would be a .dll file in Windows, the same file would be a .so file in Lignux. There is also the fact that compiling to a game platform would require a difficult-to-set-up toolchain. Keeping track of all these platforms is complex and invites significant error and confusion. In contrast, while targeting the Game Boy Advance, itself a game platform, requires a difficult-to-set-up toolchain, I have to compile to only one platform: the Game Boy Advance itself. The resulting .gba file can be played in any platform that can play Game Boy Advance games.
  • Speaking of platforms, the list of platforms that have a Game Boy Advance emulator overtakes the platforms that support Libretro. More specifically, I can also play Game Boy Advance games through native BSD, BeOS, Dingoo (along with a lot of similar devices), Microsoft DOS, Nintendo DS, Windows Mobile Pocket PC, Windows Phone 8, Windows Phone 10, and any platforms that supports the Java Virtual Machine. Then there is the obvious: I can put my game in a linker that plays the games in an actual, real-life Game Boy Advance.
  • Documentation on the Game Boy Advance, including hardware to writing homebrew, is plentiful. Documentation on Libretro development is far less so. In fact, the “go-to” tutorial of targeting Libretro is literally incomplete, unexplained in many areas, and apparently abandoned since years ago.
  • The documentation on the Game Boy Advance actually helped me understand programming using Libretro. The “pitch” (in graphics programming) and makefiles (in program compilation) were nebulous concepts until I read the documentation on homebrew of the Game Boy Advance.

There is also the fact that there is that simple appeal of playing in my actual Game Boy Advance a game that I have made myself.


I am still going to support Libretro directly later (maybe make a Game Boy Advance “Lite” version and a Libretro “Deluxe” version). Right now, though, I believe that targeting the Game Boy Advance would be a better next step when moving from the pico-8.


My Backup Plans

If everything goes all right, then my code at Re-Hoard should be done in 5 days of work.

Whether the code would work is another matter.

At this point, my idea is writing all of the code I can, revising the code, get my code verified, then pick between:

  • staying with Lua in the pico-8
  • switching to ChaiScript in ChaiLove
  • switching to C in the Game Boy Advance

The reasoning behind writing all of the code first then revising the code is not just because of the possibility that my problem is solvable within the pico-8 ecosystem, but also finishing the code would give me a reasonably complete framework from where I can do a translation if I do switch. Yesterday, while coding, I found that I needed to do a few new sound effects, that is, a gap that would have been more difficult in being fixed had I switched immediately to a different ecosystem.

I normally do not learn one language while using another because I want to avoid mixing up the two languages, but I let this because I plan on moving away from Lua. However, this possible mixup is the reason why I did not learn both C and ChaiScript at the same time.

I decided on learning C first. While the main motivation was simply big interest in the Game Boy Advance at the time, I found that there were more practical reasons why C would get priority over ChaiScript.

  • C is widespread. From what I have seen, C is the most widely-used language in all electronics, beating out even C++ and every dialect of BASIC together! This would make my games written in C very portable.
  • C is marketable. Because of that wide spread, a knowledge of C would be very useful in a lot of business and industrial contexts.
  • C lets me understand the hardware at a lower level. From what I had seen, C is essentially cross-platform assembly language. One of the main benefits of C is its ability of manipulating stuff at the bit level. A knowledge of C would deepen that knowledge of bit manipulation. (Once again, this deep knowledge would help me in an industrial context.) This is important because I finally would get to understand pointers, that is, a common theme in programming.
  • C helps me understand Libretro more. Libretro is a C library first of all.
  • C is reverse-compatible. My main trouble with ChaiScript is that ChaiScript ultimately relies on C++14, which would make things difficult when porting stuff to earlier hardware. This fact became more relevant here when Libretro supporting an old compiler let Libretro resume development that targets Microsoft’s first game console, the XBOX. That means that, even if targeting the Game Boy Advance does not work out, I can still code “from scratch” using an older version of C. Because I am using a book from 40 years ago even before C was standardized into C89, my code would definitely be reverse-compatible.
  • C is mature. ChaiScript is still being developed. While I am fine with waiting until ChaiScript finishes development or at least progresses to a form of maturity, C is already time-tested and, therefore, more reliable. I can write things in C while I wait until ChaiScript matures.

From another perspective, though, ChaiScript may have fit my current priorities more. The development time of Re-Hoard is easily approaching a year. Spending so much time on a simple game is ugly, even though I do not exactly have an audience. ChaiLove not only is deliberately similar to LÖVE (another framework I used) but also abstracts away a lot of close-to-hardware features. Adding assets in ChaiLove is also drag-and-drop, whereas writing a Game Boy Advance program would require conversion and appending the assets. Therefore, using ChaiScript would make a sooner release. There is also the fact that ChaiLove is tied to the Libretro ecosystem whereas making a Game Boy Advance game is not. (I could make a game “from scratch” that implements the Libretro library, but that would be too much work when the goal is getting my games released.)

Maybe I should have started with ChaiScript? I am too deep in C, but I might learn ChaiScript after I finish with the basics of C.


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!