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.

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.


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!

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.

P = NG

After my previous adventures in rendering .png files to a software framebuffer, I realised that I needed to convert between lodepng’s RGBA 4-bits-per-pixel format to Libretro’s RGB565 format. My studies since my last post brought me to pixconv.c which has a function, conv_rgba4444_argb8888, that does just that type of conversion. I need to give the function the following in this order:

  1. the output variable
  2. the input variable
  3. the dimensions of the image file
  4. the output pitch
  5. the input pitch

In theory, all I had to do was add lodepng and pixconv.c to my project, run a test.png file through those two, and put the resulting data in the framebuffer.

The result was a mess. Learning that <iostream>, a stape at my studies of C++, was worthless when working in C, was actually the easy part. Even if I did not exactly know what type of data type were the variables that held the RGBA4444 and RGB565 arrays (I settled on unsigned char when void did not work), the makefile refused to recognize lodepng_decode32_file and logepng_error_text, even after I put those two types in various places (though not at the same time) inside the actual libretro_test.c file. I learned that this issue comes from the linker, which is related to the makefile.

At this point, I decided to give up at least temporarily. I mean, while there is the possibility that this is the last problem and that I actually have everything else right, I decided that this matter requires advanced knowledge that is specialized on C++. I mean, I have a Master’s Degree in Software Engineering, but my actual usage of the fundamentals of C++ and related languages were all in Integrated Development Environments. I barely know anything more than how to run make (not “CMake”, but “make”)!

This lack of specialized knowledge is also the reason why I am no longer pursing either adapting a current C++ engine to Libretro or, per Radius’ suggestion, using OpenGL. I still would have to deal with compiling the C++ code in those situations.

In light of this, I was looking more seriously at Rust, which has bindings to Libretro. While Rust is not object-oriented in the conventional sense, Rust has features that have just about the same functionality anyway. The problem is checking how the current game engines that use Rust render graphics. After all, I want to use software rendering because I want my games to be played at the full range of consoles that run Retroarch, not just the ones that can handle both versions of OpenGL.

I am also seriously considering going back to Lua per my original plans. Not only does LÖVE have no need of a distinct compilation process but also displays graphics through an API that works great and easy. In fact, the ease of use LÖVE provides is the reason why I picked using LÖVE instead of straight C++ in the first place! The main reason why I am not so sure is because that the reason why I wanted to leave Lua in the first place was because Lua did not have any proper support of object-oriented programming. I would much rather use the real deal, especially since Re-Hoard needs object-oriented programming! Even if there is an alternative, this lack of functionality may hamper heavily my plans of future games!

I tried to see how Lutro, Libretro’s interpreter of LÖVE, displays games written in LÖVE. I mean, LÖVE apparently uses SDL, but that does not seem to be a problem to Lutro. However, I got overwhelmed once again.

Eevee is right; if I were to write from scratch, I would be essentially inventing the universe if I needed to get off the ground. Then there is compilation afterwards.

Broken Physics; Broken Graphics

I am starting to change my mind.

I looked into Chipmunk after Box2D warned me about Box2D requiring a lot of C++ experience. However, Chipmunk itself seems too complex. Worse, I could not find an API-indifferent way of putting graphics on the physics objects!

I looked into other game engines, but they, true to my predictions, use SDL or OpenGL and do not seem to have ways of rendering directly to the framebuffer. Speaking of the framebuffer, I am still awaiting on information on what exactly is a framebuffer in the first place. On Radius’ defense, Radius is probably taking time out of a busy day in making an appropriate reply.

I just feel frustrated because I feel lost. Radius gave me a much-needed nudge, but I need more.

I am not going back to Lua because I need the capabilities that C++ or Rust give. Even so, the Rust libraries and engines probably have the same dependencies on SDL or OpenGL that the other game engines have.

I should be spending this time working on my PICO-8 games.

I shall look at rpng, Libretro’s own decoder of .png graphics. That, being of Libretro itself, should have a way of rendering directly to the framebuffer.

Lua to the End?

From the beginning of my game career, I intended to make games that use Libretro, a C/C++ library that can be used in writing emulators and standalone games. The reason why I learned Lua in the first place was because, compared to using straight C or C++, writing games in Lua and relying on the Lutro core seemed to be the more comfortable option. Indeed, because Lua programs do not need to be compiled, I ended up saving myself plenty of precious time in my last two college projects back when I took my Master’s Degree. Developing my final project using LÖVE instead of trying to understand the Libretro library, especially given the one-trimester deadline, spared me from a lot of grief. That knowledge of Lua also helped me develop games for the PICO-8, an all-in-one platform that not only helped me get used to normal game development but also has several channels of delivery, my favourite one being uploading the game itself in image format. You can even play these games in your browser with little fuss!

However, I am starting to feel the limitations Lua has. While Reckless Abandon has simple code, Re-Hoard has a game plan that needs object-oriented programming when generating random anti-hoarders, each with their own patrolling and hunting styles, per stage. Lua does not have any object-oriented functionality; other people fake that functionality using metatables. Even with that fake functionality, I fear that I would be better off relying on the real thing. Besides, if Lua lacked true object-oriented functionality, then what else would Lua lack? Other consideration include less layers of abstraction that might interfere with my wanting to interact with Libretro itself, the bigger maturity of C++ tools and libraries, and practice in a language that is still in high demand in the workplace. In fact, the more advanced aspects of Lua actually use a C library!

On the other hand, the gains from the lack of a compilation time proved to be an assets when I debugged my college projects. Also, LÖVE games store their assets as-is instead of they being baked directly in the program; I can edit a sprite or switch around a song and see the effects when running the game anew.

Despite these benefits, I am seriously considering working on my new games with C++ from now on. In fact, though Reckless Abandon would stay a PICO-8 game, I might move Re-Hoard to C++.

I just need to figure out how to display and move .png sprites and implement collision detection while I use Libretro.