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…


Hoarding Problems on Lua

I need a way of checking whether every entity does not have a value. That way, I can find out whether every opponent is not hunting. That way, I can check if the game can play the normal theme again.

I now also need a way of making either a system or a plain function that accepts two entities. This would work with the collision system.

This is hurting me.

My current plans are putting in “boilerplate” functionality that might work, writing the rest of the game while pretending that the functionality definitely works, then requesting the help from the people at Lexaloffle, but I am leaning ever more towards changing the platform to ChaiLove or even the Game Boy Advance, even though the game is about done and has assets that specifically target the pico-8.


My website had been temporarily shut down because the website did not have the funds. When I came to restore the website, I found that the plans have changed. Because Nearly Free Speech has to handle a lot more distributed denial-of-service attacks, my web host had to raise their prices.

I feel sad that they had to do this, though I was wondering until recently how they handled those attacks. I actually have no problem with paying those prices, especially when I know why.

Currently, there are 3 tiers:

  • Non-production websites (those that are just “see what I can do” websites) pay 0.01 USD daily and get 1 GB of bandwidth per day.
  • Production websites (websites that are part of a business) pay 0.05 USD daily and get 10 GB of bandwidth per day. They also get access to dynamic content (PHP, Ruby on Rails…).
  • Critical websites (websites that are the business themselves) pay 0.50 USD daily and get 100 GB of bandwidth per day. They also get access to dynamic content and extra help in website issues.

Yes. The higher prices are that low. One of the main draws of Nearly Free Speech is their astronomically low prices. The only problem is that, you cannot turn a production website into a non-production website or a critical website into one of the other two.

Though my website qualifies under “non-production” because my website is a beta version website, I chose a production website. I mean, eventually, I would have to switch anyways because, if I “make it big” (so to speak), I would have to worry about all of the bandwidth my website would have due to all of the visitors my website would have. (My website may be my business, but my business currently neither has the need or generates the revenue that justifies the critical plan.) I also need to check how the dynamic content works with my website. There is also the fact that I actually like their hosting service and want to support them.

Besides, the price is just 0.05 USD per day. That would make… 18.30 USD per year?

After this… I should deal with iptables hacks and firewall rules…

Hoarding bytes?

The bad news is that, in my latest commit, Re-Hoard has 47,344 bytes, while the maximum is 65,536. I feel worried about running out, though, because I am getting close to the end plus I already put in did the audio-visual assets, I feel that I could fit everything in there.

The good news is that the latest commit also uses 4,628 tokens compared to a maximum of 8,192. That is a little over half of the maximum.

The real problem is the maximum compressed size, which is 15,360 bytes. Both of eevee’s games in Lexaloffle suffered from this compression. I already know of some ways of getting under that maximum, but I would rather code in full then optimize normally then test the code before I deal with that problem.

Re-shooting (or Re-Firing)

I got a new trouble. The Fearful and Surprised opponents have independently-acting weapons, that is, weapons that are their own entities. The problem is that they are too independent; my plan is that one weapon directly corresponds to one opponent. That means that, if a Fearful or Surprised opponent uses a weapon, the same opponent cannot use a new weapon until the old one disappears. However, the way things are, an opponent makes a weapon that is not related to an opponent; there is no way of knowing to which opponent a weapon is tied. In my game, an entity acts independent of another entity. (This caused a lot of difficulty in my collision system which, at times, needs to know with what specific entity another one has collided.)

My idea of working around this is that a weapon raises a global count while an opponent cannot use a weapon if the count exceeds the number of corresponding opponents. The problem with that is that there may be a possibility of one opponent using a weapon multiple times instead of one at a time, not letting the other opponents of the same emotion use their weapons…

…though that may be moot if there are enough opponents of the same emotion because the first might be busy walking while the other sets a weapon.

I just want to rest on this problem a little more before I go back to coding.


Earlier, I mentioned that Lua’s lack of an object-oriented system was restricting me.

These days, I learned that the alternative, the entity-component system, may be itself restricting. One thing is that I do not know whether I can check if every entity that has a component does not have a component set to a certain value. Another is functions (or, rather, “subfunctions,” because they are parts of systems); some functionality some systems have can be abstracted away into subfunctions, but I am not sure if the subfunctions would work with the entire entity-component system in general or that I need to give the components’ values before the subfunctions would work first.

This has me worry if I could actually do the game in the pico-8 at all.

This is obviously very bad because I am so close. All of the art assets, which specifically target the pico-8 are there. I planned everything I could thoroughly then added stuff that I needed to plan once I went along programming. I worked a lot of the game; the end appears to be in sight. The worst part is that I had been working on the game since the latter half of 2016. Development just picked up when I decided to knuckle down and actually plan the thing thoroughly, but I am taking too much time with this game.

I am still working on the game, regardless, but a change of platform is not out of the question.


(Despite the above, this has nothing to do with my decision to look at Red or ChaiScript. These problems were forming over the days.)

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…