The “libre” paradox

There is a great amount of discordance in the worldwide community at large regarding what kinds of software should be made free, open-source, or commercial. Even I, who am not a developer of any prominent software, have had to tackle this question myself, especially after the Aseprite fiasco regarding its conversion from commercial GPLv2 to commercial closed-source.

My empirical findings about software production models is that while commercial software can achieve results quickly and efficiently, open-source software runs on ideas and thus tend to achieve results with greater quality. Developers might be hired to write a specific program in six months, yet a developer has all the time in the world to think about the design of a personal project before even putting down a line of code. Moreover, academics (assuming, of course, that academics are the ones who work on FOSS projects, since they are too busy for a full-time job, but are keen to write code for societal good) have an affinity for peer review, encouraging only the best development and security practices, under risk of scrutiny otherwise.

It is of no surprise, then, why companies tend to cherry-pick code and design from FOSS projects to fuel something slightly better.

When a new idea is introduced for the first time, it is competition and money that drive results. When Bell Labs et al. dominated computing research for a long time, and the threatening Soviet Union begrudged the United States government to fund the research of NASA, these are prime examples of manifestations of driving factors for research and innovation.

But neither Bell Labs and NASA ever sold products to consumers. Instead, other companies were founded to fill this gap – not to create something radically new (often, when this occurs, they miserably fail or dramatically succeed), but rather to simply take the next step. The research has already been complete – just put it in a box, along with an instructions manual, and sell it to consumers. There’s nothing like it on the market, so it’s a perfect choice for consumers. Rake in the cash. Corner the market. And soon, a new company will form itself to take yet another baby step in innovation, and that one will be fruitful too.

When the innovation has become so clear and obvious to the public that it can be learned by undergraduates or any interested student, it is then time to charitably introduce the innovation to others. The modern computer has existed for a long time, yet Eben Upton and the Raspberry Pi Foundation took the “small” step of putting a SoC on a small board and selling it for $35. At the time, I don’t think it would have been easy to find a technologically up-to-date, general-purpose computing device at that price point and form factor. But because the Raspberry Pi Foundation did it, now many businesses exist for the sole purpose of manufacturing and selling low-cost single-board computers. As a result of this work of charity, computers are now easily accessible to all. What’s more, students can and must take courses covering the architecture of the modern computer, and some students are even tasked with constructing one from scratch.

Likewise, once an open-source project is done on a particular topic, that particular topic is essentially “done“. There are not many businesses out there that sell consumer operating systems anymore; if people seek a free operating system, there’s GNU. It’s done; why look further? Any improvements needed are a code contribution away, solving the problem for thousands of others as well. Why should companies strive to produce new modeling software if they must compete with programs like Blender and existing commercial software such as Maya?

My observation is that open-source software is the endgame. It is impossible for a commercial software with the same features as an open-source program to compete with each other; the open-source program will win consistently. Conversely, commercial software stems from open-source algorithms waiting to be applied, be it TensorFlow or Opus.

Basically, it makes sense to start a company to churn out commercial software if one is willing to apply existing research to consumer applications (take small steps); join a larger company to rapidly develop and deploy something innovative; or join academia to write about theory in its most idealistic form.

Under these observations, startup businesses fail because they attempt to innovate too much too quickly. The job is not to innovate immensely all at once – the job is to found a business under a basic, yet promising idea (the seed), produce results, and then continue taking small, gradual steps toward innovation. The rate of innovation will be unquestionable by investors – if you survive for two years, putting your new features and products at a healthy pace, then people will naturally predict the same rate for the coming future, and be more willing to invest.

Yet you would never find enough resources to make a successful startup for, say, building giant mechs or launching payloads into space. There’s just too much research to be done, and the many people who are capable (and in demand) to perform this research need coin to sustain themselves. In contrast, the military can pour any amount of money they wish to a particular project, and they could have a big walking mech that looks like the one from Avatar in less than 36 months. (I’d wager the military has already been working on this as a top-secret project.)

But do you see how much we have departed from the idea of “libre?” My conclusion is this: businesses do things quickly, while charitable people do things right. Once the research has been completed and the applications have been pitched and sold, it is then time to transition and spread the innovation to the general public. That is the cycle of innovation.

Personal protection

You may know my blog well for my rants, but if you have been or are planning to look into my personal life, you should know that I have hidden these posts. They have provided great insight into myself, but being public on the open Internet, they can also be used against me in unpredictable ways.

They explain in great detail, for instance, why I seem to lack the motivation to work on my projects, what effect this incurs on me, and what grim outlooks I have had on life in the past two years – but I do believe there are some people out there who are willing to argue nonetheless about my personal life, arguments which take mental energy and time to address.

I may open these posts in the future, but for now, a little bit of privacy might be appreciated.


I feel like publishing what songs followed me around in my head while I was in Japan, so I’ll list them here:

Kyoto and rural areas: Xyce – A summer afternoon
Crossing over Rainbow Bridge: Mirror’s Edge menu theme
Tokyo: Bôa – Duvet
Plane taking off back to Japan: SAVESTATES – When They Find You, Don’t Tell Them You’re Dead
After returning to Japan: Zabutom – My alien shoes

I think they are fairly dumb song choices, but I really could not get them off my head, so if you want to add to the atmosphere while reading the trip account of Japan, you can play the corresponding song.

Not sure why anyone wants to know this, though.

The problem of image formats

In the making of Animated Chatroom, I’ve been encountering a major snag: none of the popular image formats seem to fit my needs. I need an alpha channel (that isn’t 1-bit!), animation support, and good compression. Here are the candidates:

  • GIF – used since the 90s. Good compression, excellent animation support, but palletized and 1-bit transparency. I can’t use it for the complex 3D sprites, though. Dithering hacks are still used to this day to try to mask the limitations of GIF.
  • APNG – It’s meant for transparent animations, but has poor support by most libraries. Not even standardized; some browsers may be looking to remove it (already?). Many implementations implement it poorly, by stacking each PNG frame next to the other, without compressing the blocks shared by both frames, leading to an inflated file size (often more than GIF).
  • WebM – Alpha support was thoroughly devised in VP8 via the YUVA420P pixel format, yet left as an afterthought in the conception of VP9. Nevertheless, VP8 has excellent compression, but again, the consideration of supporting YUVA420P is cast aside in many implementations of FFmpeg decoders, leading to the alpha layer getting silently converted to a black or white matte.
  • PNG image sequence – Brute force solution. No inter-frame compression, leading to intolerable sizes.
  • MNG – Are there even up-to-date implementations of MNG? Does anyone even use MNG in 2018? I thought so.
  • WebP – Seems decent, but inferior compression and lossy by default.
  • FLIF – Are we really ready to enter into “the future”? While FLIF may fit the bill for literally all of my needs, there is no stable support to be found anywhere, except in the form of a native library. I need support for Python if I am to get anywhere.
  • My own format – Why in the world would I want to do this? I would rather put LZ4 on APNG than reinvent the wheel.

For now, I don’t have much of a choice for animated image support except GIF, until certain bugs are fixed in pyglet that prevent alpha support when decoding via FFmpeg.

Gearing up

It’s time to start work on Animated Chatroom. It is a monumental project; the largest project to date that I have ever desired to undertake.

My resources are somewhat scarce, but it could be worse. The two resources which I am in great scarcity of are developers (human resources) and energy (something which tends to be inversely proportional to time). The developers I seek are either not competent enough to produce modular code, or they live in a very different time zone that complicates any coordinative effort. My energy is drained from playing with my brother or doing real-life tasks which I have been postponing for too long, such as cleaning some things up.

There is another question that compounds a desire to do everything other than work on Animated Chatroom: where do I even start?

Well, let’s see what Torvalds has to say about his success:

Nobody should start to undertake a large project. You start with a small trivial project, and you should never expect it to get large. If you do, you’ll just overdesign and generally think it is more important than it likely is at that stage. Or worse, you might be scared away by the sheer size of the work you envision. So start small, and think about the details. Don’t think about some big picture and fancy design. If it doesn’t solve some fairly immediate need, it’s almost certainly over-designed. And don’t expect people to jump in and help you. That’s not how these things work. You need to get something half-way useful first, and then others will say “hey, that almost works for me”, and they’ll get involved in the project.

Okay, Benevolent Dictator Linus…

You start with a small trivial project, and you should never expect it to get large. If you do, you’ll just overdesign and generally think it is more important than it likely is at that stage.

All right, so we started with a small trivial project. It was called Attorney Online 2. It was good. And then it tanked because of poor design. I want Animated Chatroom to not go through that pain again.

Or worse, you might be scared away by the sheer size of the work you envision.

Which I am.All right, so what features do we not need? Let’s cut nodes until we get something less overwhelming.

Better. That’s almost the bare minimum that I need.

In list format:

  1. Core animation engine.
  2. Asset loader.
  3. Basic network.
  4. Basic UI.

That’s all, I guess I don’t care about anything else right now. So let’s cut it down even further.

Okay. So version 0.1 will barely have a UI. It’s just figuring out how stuff should work.

It’s clear that VNVM is at the center of this entire project. If I can design VNVM correctly, then this project has a chance; otherwise, a poor execution will lead to a shaky foundation.

The Visual Novel Virtual Machine

What is the purpose of the Visual Novel Virtual Machine project? The purpose is to bring sequences of animations and dialogue sequences, the bread and butter of visual novels, to a portable environment. From reverse engineering performed by others, it turns out that major visual novels also use a bytecode to control dialogue and game events. In the VNVM world, this is called VNASM (Visual Novel Assembly).

Within characters, emotes are simply small bits of VNASM, which are then called by the parent game (which also runs in the VNVM). Recording a game is just a matter of storing what code was emitted and when. The point is that essentially all VNASM is compiled or emitted by a front-end, rendering it unnecessary to understand VNASM to write a character. (But, it would kinda be nice to be able to inline it, wouldn’t it?)

This makes VNVM satisfactory for both scripted and network environments. In a network situation, where the execution is left open, there is a simple wait loop that awaits the next instruction from the network buffer. New clients simply retrieve the full execution state of the VNVM to get going. The server controls what kinds of commands can be sent to it; most likely, an in-character chat will look something like this as a request made to the server:

{ emote: "thinking", message: "Hmm... \p{2} I wonder if I can get this to work right..." }

The \p marker denotes a pause of 2 seconds, which the server parses out to emit a delay of 2 seconds (of course, limiting the number to a reasonable amount). The server then pushes the reference to the character who wants to talk, as well as the message to be said, and calls char_0b7aa8::thinking where 0b7aa8 is the character’s ID. This denotes that the named subroutine thinking is located in a segment of VNVM code named char_0b7aa8.

More to follow later.

Rethinking Attorney Online assets

It seems fairly obvious that FanatSors was not expecting a complex level of gameplay when he released the Delphi-made Attorney Online back in 2012.

Yet AO still exists, with about 150-200 daily players who frequent the couple dozen servers, with the most popular being /aog/’s Attorney Online Vidya. OmniTroid’s Qt-based, open-source AO2 client is now the de facto client, touting “advanced” features such as color, Unicode support, and parametrized preanimations. Likewise, the open-source tsuserver3 and esoteric-but-still-open-source serverD are the two choices of hosting for AO. Today, however, the legends of FanatSors and OmniTroid have faded away.
An overview of the Attorney Online family.

Most players and case-writers are regularly impacted by the technical limits and quirks of the engine. Configuration of each character is all done in a single INI file, defining each emote as an octothorpe-delimited sequence of animations to be played. Each animation refers to a GIF file prefixed by an (a) or (b); that is, the format and naming scheme must be precise in the file system level.

This is not the main challenge, however. The challenge is managing assets.

Every server asks their users to download an archive, spanning up to 7 GB in size, containing character sprites, music tracks, backgrounds, evidence images, and sound effects that may be needed during gameplay. Assets are only identified by their folder name; this is the only unique identifier attached to an asset. These are the problems with using an internal name as the sole identifier:

  • Two servers may offer different content, but under the same internal name, causing a hard clash. Content could be isolated per-server, but this causes a serious redundancy problem.
  • Two servers may offer the same content, but under different internal names. This causes excessive redundancy.
  • Two servers may offer just about the same content, with a small difference. In this case, there is no hierarchy established as to which one is derived from the other one.

Upon requesting a character list for my proposed new standard base, nuVanilla (and receiving a monumental list!), it felt that the amount of dimensions that the assets needed to be examined in were too many to use a conventional spreadsheet for, so I opted for a full-blown database. My choice was split between MySQL/MariaDB and PostgreSQL, but I remembered that I wanted to learn Postgres, as the performance and versatility claimed to be far greater than MariaDB could offer.

One immediate issue is the sheer number of many-to-many relationships that manifest, causing an effective decoupling of many columns:

  • Multiple packs can include the same asset.
  • The same asset could be under different internal names.
  • Multiple assets can have the same internal name.
  • Multiple assets can represent the same character.
  • Assets of the same character can come from different games.
  • Assets can be in different formats, such as 256×192 or even 1280×720 (yes, some people resize their sprites to match their theme’s viewport size).

How do I represent uniqueness of assets, then? I can’t even hash the char.ini, because the char.ini contains the internal name of the asset. What’s more, there is no standard way to hash multiple files at a time; in this case, I would want to hash all of the emote images at the same time. (For now, however, I am hashing the char.ini until I find an adequate solution.)

One solution would be to give every asset a UUID. This would, in theory, add an additional layer of “uniqueness” into each asset. However, this still does not resolve the original problem: two assets with the same content but different internal names would still be detected as “different” upon submission, since the hash of each char.ini would be different. And this would compound a new problem on top of the old one: modifiers of an asset would be burdened with updating the UUID of the asset they are editing; forgetting to update it could only cause an error when uploading it to some centralized database.

What modifications can be done to an asset?

  • A small correction to frame data – minimal change
  • Emote additions – significant change
  • Internal name change – minimal change
  • SFX name change – minimal change

Three out of four of these changes are minimal changes. Thus, it would not make sense to consider them completely different assets. We can try to establish a hierarchy of assets, to see which asset succeeded the other, but that is no substitute for a diff. The data stored remains redundant.

Therefore, I can conclude Attorney Online assets cannot be accurately uniquely identified for management, and attempting to set up a database to manage them would take me nowhere.

I should then refocus my efforts to designing asset structure in Animated Chatroom.

Each asset would have a definition file (such as char.json), which would state the name of the character, its ancestors, and a reference to the sprite file. The format of the definition file would probably be JSON, while the sprite file would then be written in something like Spritelang.

The asset is then bundled using tar and signed using GPG. This verifies the identity of the packager of the asset (for increased trust, the packager’s key can be cross-signed by a responsible admin, who in turned is cross-signed by the Animated Chatroom Root Key. All of these keys can be uploaded onto a general-purpose key server, like The signature of a package need not be specifically signed by the AC official root key; just a key that is cross-signed by someone on the keychain. The absence of a signature does not mean that the asset contains malicious content and therefore cannot be trusted; rather, the purpose of the signature is to assure that the contents of an asset have not been modified, and to seal the credits of an asset. After the tar has been signed, the tar can then be compressed in a desired format such as xz (which is basically 7-Zip but using a byte stream as opposed to an embedded archive). In this case, the unique identifier of the asset is the key ID of the GPG signature. This is the strongest possible hash: not only is the data factored in, but also the identity of the individual who authored the asset.

Now that we have established a strong, unique identifier to our data, we need to solve the data redundancy problem.

Children of ancestors use an incremental tar file, which minimizes the content stored in the child. Even deleted content can be tracked if incremental tars are applied correctly. We may also employ a similar scheme as the Docker Image Specification (version 1), but it’s clear that someone did not read into tar’s ability to do incremental archiving out of the box. (“NOTE: For this reason, it is not possible to create an image root filesystem which contains a file or directory with a name beginning with .wh.. ” It requires little thinking to realize that this is a tremendously absurd limitation, just to add the ability of identifying deleted objects. If anything, deleted files should have been put in a separate file, for the sake of not introducing an artificial limitation to the file system.)

Incremental versioning has a major implication for authoring assets: authored assets are immutable. No, sir, the Animated Chatroom authoring tool will not allow you to modify an asset that has already been successfully packaged and signed, unless you choose one of the following options:

  • Create an asset that is a child of the asset you want to modify. This is not a favorable option if you have not published the parent asset. However, the authoring tool will set the hierarchy up for you.
  • Create a new asset, derived from the data of the parent asset. There is no hierarchy established, it’s just a hard copy of the parent asset. This is favorable only when the parent asset has not been published.

Acquiring modified versions of an asset would be simple under this system:

  • The desired version of the asset is downloaded and unzipped. (We don’t need to untar the entire asset yet.)
  • The signature is verified, and a warning is displayed if the signature is invalid.
  • The definition file is untarred and checked for an ancestor. If an ancestor exists, a recursive download request is made on the ancestor.
  • The asset contents are untarred on the target folder.

Asset servers for Animated Chatroom web clients can establish this hierarchy – without the expected redundancy! – by using symbolic links to represent files that are identical to the parent.

Finally, we can track what assets we have downloaded and what asset repositories we are currently using, by storing local data in an SQLite database file.

Instead of a name-based character list, servers use character IDs to disambiguate between different versions of the same character. A server can then offer download sources for specific characters, such as if a character was made “in-house,” so to speak.

What are the improvements over this design over the old design devised by FanatSors?

  • Authorship is immutable. This is important mostly for original content: repository owners will refuse to publish assets that refuse to identify the original creator of content. However, in the case of ripped content, it is desirable to preserve information about who ripped it, but ultimately, it is all copyrighted by the publisher of the game (Capcom, Chunsoft, etc.).
  • Downloading is automatic. Under the old system, players were too lazy to download zip files to play on new servers, and server owners were too lazy to compose zip files for players to download every time new content is suggested. Now, server admins need only do a graphical lookup of the assets they want to add on the server, confirm the additions, and the new content is immediately requested for download by clients, all seamlessly and in the background.
  • Name clashing is no more, since we established that internal names are no good as a unique identifier.
  • Asset content is deduplicated (to the best of the ability of this system).
  • Asset management is decentralized. I don’t own the database – in fact, nobody does. You can host part of the repertoire of Animated Chatroom content, but you can never host all of it.
    • On a similar note, this makes Animated Chatroom effectively immune to cease-and-desist notifications. I can take down the offending content on my servers, but due to technical restrictions, I cannot be responsible for the content hosted by other servers. The cease-and-desist notifications would have to be sent to each offending server.

This concludes an overview of the proposed design of asset management in Animated Chatroom. I hope you found this design enlightening for any future adventures in software development.

Reverse engineering LIMG

LIMG is the custom image format used in Professor Layton and the Unwound Future. Like many Level-5 shenanigans, it’s a custom format for absolutely no reason other than to serve as a deterrent for future reverse engineers (no pun intended).

After taking Tinke and applying it to the game’s image, we can easily find that the animations are CANIs, which get decompressed via LZ10 and passed through a QuickBMS script to get split into LIMGs. But what now? Tinke does not recognize the LIMG format, and all we get is an incoherent mess, which we can explore by opening the file as either a tile or a map. This process works best with small images.

We can, for instance, open up /lt3/menu/level5_a.limg, and expect the Level-5 wordmark. We can achieve getting the wordmark with an offset of 0x680, a 128×16 size image, horizontal image pattern, and 8×8 tile size, with still some artifacts and wrong color.

We can then take a look at the LIMG in hexadecimal, and try to find these values. We start off with the FourCC (LIMG), then what seems to be the 32-bit base offset value, … and then what?

That’s where I’m stuck. I need to know where the palette data is, etc.

Visual Novel VM

I’ve been feeling somewhat delusional lately because of this. I am not sure if it is a good idea because (1) it has never been done before; (2) it seems like a misapplication of an interpreter/state machine model; and (3) it takes some work to set up.

In theory, you could turn any sequence of API calls and basic arithmetic into a machine-readable language. Not all encodings are Turing-complete instruction sets, but a number of them are. For instance, I discovered that PostScript is actually a Turing-complete, stack-based language. You can do math in PostScript, define functions, and do things that are far beyond the scope of executing print jobs. If you keep this in mind, you can find that an instruction-based model is not a misapplication for a scripted visual novel. The other question stands, however: is it practical?

The goal behind VNVM is to make visual novels self-containing and portable by adding a layer of abstraction to the behavior of sprites, with the ability for instructions to be sent over the network without any danger of exploitation. While sandboxing is achievable with Lua and Python, I would end up placing an excess amount of emphasis on the security layer to prevent arbitrary code execution, which is ridiculous to defend against using a bytecode that is far more complicated than I really need. Moreover, using Lua in tandem with Python already raises eyebrows: why use two different scripting languages?

A side effect of this project is that you would be able to write visual novels in assembly, if you so choose to. You can also port the VM to the browser, to a GBA, to any platform you can play games on. But the final goal is to make any sort of visual novel play faithfully, without the end user needing to see the backend at all.

Delusional and worried that I was wasting my time, I wondered why the instruction set was so complicated. After taking some inspiration from PostScript, I realized that this approach of a VM, albeit somewhat strange, is workable. I just have to change the instruction set from register-based to stack-based, which was an easy change and eliminated about 100 lines from my code.

My main target right now is Ace Attorney. Currently, case engines are written in exotic languages, such as Delphi, Multimedia Fusion, or some “custom-made” language that looks very similar to AutoIt. VNVM, I admit, is no exception; however, my main argument is that its applications surpass Ace Attorney, and I plan to automate the construction process of a faithful case engine by creating a Python script that emits VNVM machine code. I have already written an assembler; now I am to write a script that uses inline assembly to directly produce machine code.

One useful application of VNVM is writing the behavior of sprites. Users of Attorney Online are accustomed to using .ini files to define emotes, sounds, and delays. But from a technical standpoint, this system is bunk: what if I want my sprite images to be organized in some other way in the file system? What if I need 8-bit transparency in my animations? What if there is something floating around me while I do everything? It is clear that .ini files cannot cover all cases, and even at the introduction of some complexity, the system falls flat on its insufficiency.

My idea was a domain-specific language called Spritelang. This is a macro-based language, which, unfortunately, has rather complicated syntax rules, surpassing my knowledge of compiler theory and the writing of tokenizers. I would certainly write it in JetBrains’ MPS, but I underestimated the notes when they said “this might take about a day’s worth of your time.” The meta-language is not an easy one to understand, but I can sense its immense power currently beyond my reach.

Japan: the hyperfunctional society: part 2

Day 5

I don’t believe there was a wake-up call. I take in the view from the massive windows (supposedly, you can see Mt. Fuji, as remarked by my teacher in one of the earlier travel meetings as an opportunity that she has never been able to have from a hotel room, but it’s cloudy, so it is unfortunately not possible). I will not forget this view. Again, I curse at myself for not bringing my DSLR; the view is too magnificent to be taken by my two cameras, although it is raining and hazy. (more…)