Colocation : contribuer au loyer en fonction de ses revenus

Dans notre colocation, on contribue aux loyer et aux dépenses en fonction de nos revenus. Plutôt que de payer chaque mois un loyer fixe, on met au pot en fonction de l’argent avec lequel on vit ce mois-ci.

Pourquoi on a eu envie de mettre ça en place ? Comment on en est arrivé à ce fonctionnement ? De quelle manière ça se passe en pratique ? Cet article raconte tout ça.

Photographie d’une rue de Paris Mettre au pot en fonction de ses rentrées d’argent, une pratique commune à beaucoup d’habitats partagés ? Sans doute que oui.

Envies

Au début, comme tout le monde, chaque personne dans la coloc payait le même loyer (ou presque, avec juste de légères variations en fonction de la taille de la chambre).

Et puis tout ça est parti d’une impression persistante qu’un euro de loyer n’a pas la même valeur pour tout le monde. Sortir 500 € quand on vit avec 650 € par mois, ce n’est pas pareil que quand on a un salaire de 1500 € qui tombe tous les mois.

Dans mon cas à moi, c’était aussi un moment où j’étais malheureux là où je travaillais ; mais j’hésitais à changer de boulot, et à devenir indépendant, un peu par peur d’une perte de revenus dans l’intervalle. Rien de très important – mais en regardant mieux, on s’est mis à voir autour de nous plein de situations comme ça, où des gens restent dans un travail qui les rend malheureux ou qui fait du mal au monde, pour une raison simple : la peur de ne plus pouvoir payer le loyer.

On voyait aussi les gens qui avaient des revenus irréguliers : certains mois, ça passe, mais c’est parfois suivi de mois de creux, où sortir toute la thune du loyer devient compliqué.

Discuter ensemble

On a fini, un soir de février, par s’asseoir tous autour de la table de la cuisine, et par en discuter ensemble. On s’est parlé de nos expériences, déjà : de ce que ça nous fait de payer un loyer, ce que ça peut freiner ou rendre difficile, et commencer à imaginer comment ça pourrait être autrement.

Est-ce que c’est une bonne idée d’avoir des loyers variables ? On pourrait faire ça en fonction de la situation matérielle des gens (boulot, chômage, travail précaire). Et si on se retrouvait chaque mois et qu’on discutait de combien on met chacun·e ? Ou alors est-ce qu’on ferait une formule fixe ? Mais est-ce que ça varierait chaque mois ou pas ?

La discussion a fait émerger plein de sujets intéressants. Par exemple, que la question du logement est anxiogène pour pas mal de gens. Payer un loyer fixe, même élevé, c’est quelque part l’assurance d’avoir un toit – et passer à des loyers variables envoie un peu d’incertitude là dessus.

On s’est aussi rendu compte en discutant que quelque part, en habitant tous ensemble, il est parfois plus facile de donner que de prendre. Les gens dont la situation actuelle fait qu’iels contribueraient moins ne se sentaient pas toujours à l’aise avec ça. On s’est demandé comment faire émerger un sentiment de justice là dessus, qui fasse que tout le monde ait l’impression de participer à un système juste, même aux moments de moindre contribution.

Quelques discussions aussi autour de « qu’est-ce qu’un revenu ? » Si on module le loyer en fonction de ce avec quoi les gens vivent, comment est-ce qu’on le définit ? Est-ce que les allocations chômage rentrent dedans ? Les aides au transport ? Les étrennes de la grand-mère ?

Et de l’autre côté, qu’est-ce qui rentre dans le loyer ? Le loyer général de l’appart, évidemment. Mais les charges, l’internet, les assurances s’il y en a : qu’est-ce que qu’on veut aussi faire rentrer dans un budget commun ?

En commençant à explorer des modes de répartition, on s’est aussi rendu compte de notre inégalité face aux chiffres. Si certain·es d’entre nous voyaient immédiatement les enjeux et les impacts d’une formule simple pour calculer les revenus, c’était beaucoup moins immédiat pour beaucoup d’autres. Pourtant, pour que tout le monde ait le sentiment d’un système juste, il fallait que le mode de répartition soit vraiment compréhensible intuitivement par tout le monde.

Explorer les effets

Assez vite, il est donc apparu que, plutôt que de décider chaque mois de combien on met au pot, on préférait une formule de répartition fixe. Ça donne un sentiment de stabilité et d’absence de surprise qui semblait convenir à tout le monde.

Mais quelle formule, et selon quels critères ? Et surtout, comment rendre les différents enjeux de différentes formules vraiment accessibles à tout le monde ?

On a commencé par dessiner des grands graphiques, et à disséquer des formules possibles – mais au final l’un d’entre nous a proposé de faire des simulateurs interactifs de répartition.

Ça ressemblait par exemple à ça :

Une capture d'écran du simulateur interactif d'une des formules. Un des simulateurs qu’on a mis en place (voir la version interactive).

L’idée, c’est que si on peut changer les paramètres d’une formule, et voir le résultat en temps réel, hébin ça aide beaucoup à comprendre comment la formule fonctionne, et quel effet elle pourrait avoir sur soi. Et puis ça aide aussi à voir combien il faudrait que chacun·e mette pour équilibrer le budget ; ou encore à simuler rapidement ce qui se passe si quelqu’un·e n’a pas de revenus pendant quelques mois.

Pour évaluer les différents moyens de répartir un loyer, on a créé plusieurs simulateurs de ce que ça donnerait. Par exemple, un des simulateurs explorait un loyer qui soit exactement un pourcentage des revenus. Un autre représentait la situation avec une part fixe de loyer, et une part variable. Et encore un autre l’idée d’un revenu de base assuré par la coloc (versé quand on n’a vraiment rien pour vivre ce mois-ci).

Fonctionnement actuel

Au final, le fonctionnement actuel utilise un revenu de base. Concrètement, chaque début de mois :

Ça veut dire que les gros revenus contribuent plus que les petits (ce qui est l’effet désiré). Mais surtout, si un mois vous êtes court·e pour le loyer, ou complètement à sec, non seulement vous ne payez pas (ou peu) de loyer, mais en plus la coloc vous verse de l’argent. Histoire d’assurer le minimum.

(On a préféré ça à un système progressif par tranches, parce que ça permet que les mois se compensent entre eux. Par exemple si on attend des allocs qui ne viennent pas, et qu’un mois on est à zéro, mais qu’on reçoit le double le mois suivant, pas de souci : ça fait pile comme si on avait contribué les deux mois.)

Avec ces sous, on paye le loyer de la partie de la coloc qu’on loue – mais aussi les charges (eau, électricité, internet), les assurances habitation, et les achats ponctuels de matériel pour la coloc. (En revanche, pour la lessive et le papier-toilette, chacun continue à se débrouiller.)

Au final, ce moyen de répartition permet d’être prévisible. Même si le loyer est variable chaque mois, la formule de calcul est fixe : pas besoin de discuter de la répartition des contributions chaque mois. En revanche, quand la situation à long-terme des habitant·es change (par exemple une nouvelle personne dans la coloc’, un changement de revenus, ou une fin de droits au chômage), là on se pose à nouveau autour d’une table avec le simulateur pour ré-équilibrer le budget, en mettant à jour la formule.

En pratique

Concrètement, chaque mois on doit verser nos contributions. Pour cela, on a essayé de simplifier les choses au maximum.

  1. On estime avec combien on vit ce mois-ci. Salaire, chômage, allocations, économies perso… On ne flique pas les gens, c’est autogéré.
  2. On indique ses revenus dans un tableur partagé. La contribution à verser est automatiquement calculée en fonction de la formule en cours.
  3. On fait un virement sur le compte de la coloc si on doit verser des sous – ou un virement du compte vers soi si on récupère des sous ce mois-ci.

Le tableur du budget a deux intérêts :

Tout le monde peut voir l’état des finances à n’importe quel moment. Ça nous a semble important pour l’auto-gestion que la responsabilité d’équilibrer les finances soit partagée par tout le monde – et que l’info soit donc visible et compréhensible facilement.

Une capture d'écran du tableur utilisé pour l'autogestion du budget Notre tableur partagé des finances. On l’utilise pour calculer nos contributions, et suivre l’état de la trésorerie. Consulter ou copier le tableur d’exemple

Où ça en est aujourd’hui

Après quelques années d’utilisation de ce système, on a l’impression qu’il y a des choses qui fonctionnent particulièrement bien :

Et puis évidemment il y a parfois des points de friction :

Mais tout ça se discute bien collectivement.

En tout cas l’expérience est vraiment positive. Ca fait du bien de sentir qu’on tend vers plus de justice (même à toute petite échelle), les discussions pour mettre en place les règles se passent bien, les contributions arrivent en temps voulu. A priori on va continuer comme ça pendant un bon moment !

Normalement ce fonctionnement et les outils qui vont avec sont assez réutilisable. Si vous envisagez de monter le même système dans une coloc’ ou un habitat partagé à vous, n’hésitez pas à vous en servir.

Ressources

Utiliser Signal sans smartphone

Si vous utilisez la messagerie Signal, vous savez sans doute qu’il est possible d’envoyer et de recevoir des messages sur Signal depuis votre ordinateur, en utilisant l’application officielle.

Mais sur ordinateur, il n’est pas encore possible de créer un compte Signal : on ne peut officiellement que relier un compte qui existe déjà sur un smartphone.

J’ai cherché un peu, et en fait il existe un moyen d’utiliser Signal sans smartphone. On peut utiliser un outil en ligne de commande pour créer un compte sans installer l’application mobile, et ensuite y relier l’application Signal pour ordinateur.

J’ai testé ça l’autre jour, et ça a bien fonctionné. La création du compte, est un peu technique ; mais après plus besoin d’y toucher : une fois que l’appli Signal est connectée sur l’ordinateur, elle fonctionne normalement, sans commandes particulières.

Une capture d'écran de l'application Signal pour ordinateur.

Mode d’emploi

Pour ma part j’ai suivi ces instruction :

  1. Installez l’utilitaire signal-cli, qui permet de créer un compte Signal sans smartphone.

     # Sous mac
     brew install signal-cli
     # Sous Linux, suivre les instruction ici :
     # https://github.com/AsamK/signal-cli/wiki/Quickstart
    
  2. Demandez la création du compte, en remplaçant +33600000000 par votre propre numéro de téléphone :

    signal-cli -u +33600000000 register
    

    (Au besoin, ajoutez l’option --voice à la fin de la ligne pour avoir un appel vocal à la place ; par exemple si vous utilisez une ligne fixe.)

  3. (optionnel) Si vous voyez un message “Captcha invalid or required for verification” :

    • Ouvrez la page https://signalcaptchas.org/registration/generate.html,
    • Résolvez le test demandé ; une page blanche apparaît,
    • Ouvrez la Console du navigateur web, et cherchez un message parlant de signalcaptcha://<plein de chiffres et de lettres>,
    • Copiez tous les chiffres et les lettres juste après signalcaptcha://,
    • Demandez à nouveau la création du compte, mais cette fois-ci en rajoutant le captcha que vous venez de copier :

      signal-cli -u +33600000000 register --captcha 'les chiffres et lettres que vous avez copié'
      
  4. Vérifiez le compte. Vous allez recevoir un SMS avec un code de vérification. Notez-le (avec ou sans le tiret, ça n’a pas d’importance), puis entrez cette commande :

    signal-cli -u +33600000000 verify 000000
    

    (en remplaçant 000000 par votre code de vérification).

  5. Créez un profil Signal. Cela vous permettra de rejoindre les groupes de discussion.

    signal-cli -u +33600000000 updateProfile --name 'Votre nom ou pseudo'
    
  6. Téléchargez l’appli Signal pour votre ordinateur, et ouvrez-la.
  7. L’application va vous demander de scanner un QR-code. Prenez une capture d’écran du code, et envoyez-le sur https://zxing.org (par exemple) pour le décoder. Cela vous donnera un texte qui commence par tsdevice:// ; copiez-le.
  8. Associez l’appli pour ordinateur à votre compte Signal, en collant le texte décodé depuis le QR-code.

    signal-cli -u +33600000000 addDevice --uri 'tsdevice:/…'
    

Pour moi c’était suffisant : l’appli Signal sur mon ordinateur s’est automatiquement connectée au bout de quelques instants, et m’a permis d’envoyer et de recevoir des messages.

ℹ️ Pensez à lancer l’appli Signal régulièrement (ou à la garder ouverte) : au bout de 30 jours sans lancement, l’application sera déconnectée du compte, et ne ne recevra plus les nouveaux messages. Si cela arrive, il parait qu’il faut refaire la procédure avec le QR-code de l’application (l’étape 7).

Résumé

Si vous cherchez juste les instructions à taper rapidement, voici un résumé des commandes expliquées plus haut :

# Remplacez par votre n° de téléphone
PHONE='+33600000000'
# Mac
brew install signal-cli
# Linux
# Voir https://github.com/AsamK/signal-cli/wiki/Quickstart
# Allez sur https://signalcaptchas.org/registration/generate.html pour récupérer un captcha
signal-cli -u $PHONE register --captcha <les lettres et chiffres après signalcaptcha://>
signal-cli -u $PHONE verify <code reçu par SMS>
signal-cli -u $PHONE updateProfile --name <votre nom>
signal-cli -u $PHONE addDevice --uri <lien tsdevice:/ dans le qr-code de l’appli pour ordinateur>

Signal évolue régulièrement : si vous voyez une rectification à apporter à ces instructions, envoyez-moi un message sur Mastodon.

Préparer du Yogi Tea maison

Le Yogi Tea à la cannelle et aux épices, c’est bien bon. Pour en faire une version maison, je mélange (pour 4 tasses) :

Faire bouillir le tout pendant 20mn - 1/2h fera un excellent thé de cannelle.

Variante rapide et économique

Si on manque de temps, ou qu’on préfère utiliser des ingrédients plus simples, on peut utiliser des ingrédients en poudre. Pour cela, je mélange (pour une tasse) :

Link's Awakening Disassembly Progress Report part 12

This article is part of an ongoing “Disassembling Link’s Awakening” series, where I attempt to gain some understanding on how special effects were implemented in this game.

✨ New contributors

First let’s congratulate the following new contributors, who made their first commit to the project during the past months:

🔀 Building revisions

For a long time, this project only disassembled the source code for a single version of the game: the US v1.0 release.

A few months ago, Marijn van der Werf started to add support for the German version of the game.

Not an easy task. Not only the dialogs differ from the US version, of course – but there are quite some more differences: a few tilemaps (like the translated Game Over screen), some tiles (e.g. extra alphabet letters), a handful of regional differences…

But in the end, after carefully finding all the differences in the game resources and code, and storing the differences with the baseline English version into German-specific files, Marijn managed to add German support to the disassembly.

Zelda: Link's Awakening File Selection menu in German
The File Selection menu in all its German glory.

But Marijn didn’t stop there.

While he was at it, he casually added support for every version of the game ever released.

In all languages.

Japanese v1.0? Got it. French v1.2? Here you go. English v1.1? There it is.

Zelda: Link's Awakening File Selection menu in Japanese Zelda: Link's Awakening File Selection menu in French
It is now easy to study the Japanese or French games: they will be compiled along the other versions.

These versions all have many small differences between them. Some places were improved, some bugs were patched. Supporting all these versions meant identifying each of those small changes.

Zelda: Link's Awakening Title screen in Japanese Zelda: Link's Awakening Title screen menu in English
Some changes are obvious, like the Title screen between languages.
But other patches are much more subtle.

Moreover, the version are not linear: some patches applied to the Japanese 1.1 and 1.2 versions are not present in other languages’ 1.1 and 1.2 releases.

Fortunately, Xkeeper took some time to research and document these patches: when they were written, what they do. The resulting matrix accurately the complexity of the actual revisions:

|       -       | JP 1.0 | JP 1.1 | JP 1.2 | US 1.0 | US 1.1 | US 1.2 | FR 1.0 | FR 1.1 | DE 1.0 | DE 1.1 |
|:-------------:|:------:|:------:|:------:|:------:|:------:|:------:|:------:|:------:|:------:|:------:|
| `__PATCH_0__` |        |  Yes   |  Yes   |        |  Yes   |  Yes   |  Yes   |  Yes   |  Yes   |  Yes   |
| `__PATCH_1__` |        |        |        |        |        |        |  Yes   |  Yes   |  Yes   |  Yes   |
| `__PATCH_2__` |        |  Yes   |  Yes   |        |        |  Yes   |  Yes   |  Yes   |  Yes   |  Yes   |
| `__PATCH_3__` |        |  Yes   |  Yes   |        |  Yes   |  Yes   |        |        |        |        |
| `__PATCH_4__` |        |        |  Yes   |        |        |  Yes   |        |  Yes   |        |  Yes   |
| `__PATCH_5__` |        |        |        |        |        |        |        |        |  Yes   |  Yes   |
| `__PATCH_6__` |  Yes   |  Yes   |  Yes   |        |        |        |        |        |        |        |
| `__PATCH_7__` |        |        |        |        |        |        |  Yes   |  Yes   |        |        |
| `__PATCH_8__` |        |  Yes   |  Yes   |        |        |        |        |        |        |        |
| `__PATCH_9__` |  Yes   |  Yes   |  Yes   |        |        |        |        |        |  Yes   |  Yes   |
| `__PATCH_A__` |    1   |    1   |    1   |        |        |        |        |        |    2   |    2   |
| `__PATCH_B__` |    1   |    1   |    1   |        |        |        |    2   |    2   |    1   |    1   |
| `__PATCH_C__` |        |        |        |  Yes   |  Yes   |  Yes   |        |        |        |        |

Read the full patches notes to get a idea of what each patch does.

Also, people at The Cutting Room Floor have been documenting the version differences for many years now. So now it’s all a matter of matching the differences in the code to the observable behavior changes.

With this massive work, the ZLADX disassembly can now build ten different revisions of the game, with exact byte-for-byte compatibility.

🧩 Fixing the spritesheets

Sprites modding has been a feature of the ZLADX modding community for a long time. Popular randomizers like Z4R or LADXR allow you to customize the characters visuals by replacing the spritesheets.

However, until now, the spritesheets in the disassembly were not easy to edit. Actually, they were in a sorry state.

Well, that’s not all bad: spritesheets were stored as PNG files, which makes them easy to view, and automatically converted to the Game Boy 2bpp format at compile-time. But many things were confusing in those PNG files. Here’s for instance how the first Link’s sprites appeared in the disassembly:

A sample spritesheet, with anything hardly recognizable
This raw dump of the sprites to a PNG file is not very clear.

It hard to see anything. That’s because this is a raw conversion of the in-ROM 2bpp tiles format to a PNG file. No other conversion is made, which causes the picture to be hard to read.

There are two things missing here.

First, the colors are wrong. Or, more precisely, the grayscale is wrong. When running on a Game Boy Color, the colors are applied at runtime, by matching each tile with a separately-defined color palette. So even on the Game Boy Color, graphics remain stored as grayscale, with 4 possible gray values.

But on the picture above, what should be rendered as the blackest gray value is instead rendered as white. And other grays are wrong to.

Contributor @AriaHiro64 found a fix for this: by tweaking the PNG file to reorder the indexed colors table, they were able to fix the grayscale values – while still retaining compatibility with the tool that transform these PNG files into 2bpp files at compile-time.

The same spritesheet with inverted colors, which makes things slightly easier to see
Proper color indexation already makes it more legible.
Still looks like a puzzle though.

Now it’s easier to see the other missing element: the tiles are not ordered in the most natural way.

This is because on the Game Boy, sprites can be either a single tile (8×8 px) or two tiles (8×16 px). And on Link’s Awakening, most characters made of sprites are at least 16×16 px – that is, each character is composed of two 8×16 sprites stitched together vertically.

So tiles for sprites often differ from tiles used to store background maps. Tiles for background maps are usually stored horizontally, from left to right, as:

1️⃣2️⃣
3️⃣4️⃣

So the conversion of background map tiles from 2bpp tilesheets to PNG is straightforward.

But tiles for sprites are usually stored vertically, from top to bottom, as:

1️⃣3️⃣
2️⃣4️⃣

So naïvely converting a spritesheet to a PNG file yields tiles ordered as 1️⃣ 3️⃣ 2️⃣ 4️⃣, which will look wrong, exactly like on the picture above.

To solve this, we have to go through a process named interleaving: when extracting the original tiles to a PNG file, we fix the tiles ordering by de-interleaving them. The resulting PNG file then has the tiles in the proper order.

And at compile-time, when transforming the PNG files to to the native 2bpp format, the same Python script interleaves the tiles, back to the original representation.

The same spritesheet inverted *and* interleaved, which makes all sprites appear clearly
When properly de-interleaved, Link’s sprites appear in their full glory.

To make this process easier to automate, a simple Make rule specifies that all PNG files prefixed with oam_ are automatically inverted and interleaved at compile-time.

So thanks to these conversion steps, now all spritesheets of the game can be easily browsed and edited. Have a look!

🏞 Decoding the tilemaps

A few months ago, in the disassembly source code, background tilemaps were all stored sequentially in a single ASM file.

This was suboptimal for many reasons:

  1. The tilemaps were not named, which made identifying a tilemap difficult;
  2. The ASM file format could not be imported into a tilemap editor;
  3. The tilemaps are stored encoded, and it was difficult to write a tool to decode a single tilemap to a format readable by a tilemap editor.

But since June, the situation greatly improved. First, Daid wrote a tool to parse the data format used by the tilemaps, and decode the data as readable instructions.

Then another PR identified and named the tilemaps. And last, all tilemaps are now exported them as individual binary files. So you can simply browse the tilemaps, and peach.tilemap.encoded will contain the data you expect.

Having separate files also makes easier to compare the differences between the successive revisions of the game. Before, all tilemaps were stored for each revision. But now only the tilemaps that actually differ from revision to revision are stored (usually mostly the file menus, because they include text that had to be localized).

A screenshot of Tilemap Studio editing a decoded Link's Awakening tilemap
Tilemaps can now be edited graphically using standard tools, like Tilemap Studio.

Why storing the tilemaps encoded?

Ideally, the tilemaps would be stored in a decoded, easily manipulable format (that is, as a raw sequence of tile identifiers). And at compile-time, they would be re-encoded into the format expected by the game engine.

But unfortunately, when developing the original game, the encoded tilemaps were not machine-generated from decoded files. Instead they were hand-written by the original developers. So if we used an automated tool to encode the tilemaps, we wouldn’t get exactly the same result than the hand-written encoding: it would be functionally similar, and produce the same tilemaps, but the exact bytes wouldn’t be the same. Which means we would no longer have a byte-for-byte identical ROM.

Instead, the files are stored in the original encoded format. And to made them easier to edit, the disassembly now includes a command-line tool to decode the tilemaps to the raw binary format suitable for import into tilemap editors.

Initializing the fishing minigame

On a smaller note, Daid documented the initialization values used by the fishing minigame.

Did you ever want to build a custom version of the game with only the bigger fishes? Now is your chance!

Link's Awakening modded fishing game, with only the bigger fishes
Wow, fishes in this pond sure must be well-fed…

What’s next?

Of course many more improvements were done in the past months, much more than what is presented there.

And as for next steps, although the tilemap values are now decoded, the tilemap attributes are not. As the attributes associate a tile to a color palette, that means editing the tilemap colors is still harder than it should be. Fortunately, the tilemap attributes are stored in the same format than the tilemap values, so writing a tool to decode them should be straightforward.

Also the high-level engine documentation is still evolving. It started as an incomplete description of the various systems of Link’s Awakening game engine, but is becoming more and more fleshed out. Many topics are still waiting to be explained though.

Want to read more? Read the other articles of this series, discover more of Link’s Awakening code, or join the discussion on Discord.

Achieving partial translucency on the Game Boy Color

This article is part of an ongoing “Disassembling Link’s Awakening” series, where I attempt to gain some understanding on how special effects were implemented in this game.

Neither the original Game Boy or the upgraded Game Boy Color had hardware support for partial translucency. This was always achieved with various hacks and workaround.

Let’s have a look at two of the most elaborated examples of these techniques, as showcased on the Title screen and End credits of Zelda Link’s Awakening.

Progressive fade-in on the title screen

On the title screen, after the main title appears, the “DX” logo appears with a nice, smooth fade.

Link's Awakening Title screen

But wait, the GBC doesn’t have variable opacity values. A sprite pixel can be fully transparent, or fully opaque – but there’s no “fade opacity from 0 to 1”.

So how is this gradual fading effect done?

The trick is that, instead of updating the opacity, the game updates the palette of the “DX” logo. Each frame, the “DX” palette is changed to go gradually from the sky shade to the logo shade. Nice.

title-dx-palettes
The palettes of the “DX” sprite during the fade-in

But wait! That shouldn’t work. The “DX” logo doesn’t sit over a flat-colored surface: it overlaps both the sky and the clouds. So how could changing the palette affect both the “sky → logo” and “clouds → logo” color progression?

Indeed, that’s an issue. And to solve it, the “DX” logo is split into two parts: one set of sprites for the part overlapping the sky, and one set for the part overlapping the clouds. Each part has its own palette, with its own gradual progression.

title-sky
First set of sprites

title-clouds
Second set of sprites

Overall, a lot of effort for a small effect, that looks really easy to perform on modern hardware nowadays. But on the GBC, it actually required a good lot of tricks.

Secret ending: fading Marin in and out

When beating the game without dying once, a portrait of Marin is displayed after the end credits.

marin-ending

We can see the same kind of transparency effects than on the Title screen:

  1. Marin’s face fades in, and displays many colors.
  2. Marin’s face remains half-translucent for a while
  3. A seagull fades in
  4. Marin’s face fades out

That’s a lot to unpack here. Each of these effects is not easily doable using the GBC hardware.

1. Marin’s fades in

The fade-in uses the same palette-update trick than the “DX” logo on the title screen: the sprite palettes are updated every few frames, and move from blue to the actual portrait colors.

marin-ending-palettes

However, notice that the portrait is quite colorful. Some 8x8 areas even display up to 6 different colors at the same time, like Marin’s medallion:


There are more colors on this single tile than the Game Boy Color usually allows.

A standard sprite can only display 4 colors on the GBC (that is, 3 actual colors + a transparent one). So how is it done?

The answer is that the portrait is split into two layers of sprites, each with their own palette.

First layer of Marin's sprites
Layer 1

Second layer of Marin's sprites
Layer 2

It is then composited to get the full portrait.

Composited Marin's portrait
The two layers one on top of each other

This solves the “Many different colors” issue: different layers of 3-colors sprites are overlaid on top of each other.

(However, unlike the DX title logo, the difference of fading between the sky and the clouds is not accounted for. The overlapped cloud areas become blue at the beginning of the animation.)

2. Marin’s face remain half-translucent for a while

Neither the GB or the GBC have half-transparent rendering – but they have the latency of the LCD screen. So the good old 50% transparency trick is used: displaying the portrait only every other frame.

Marin's portrait slowed down
The blinking effect, slowed down.

On full speed, the latency of the original screen then creates the half-transparency effect.

3. A seagull fades in

The seagull fades in gradually, on the middle of Marin’s face.

Same trick: this is done by gradually updating the palettes of the seagull sprite.

4. Marin’s face fades out

Again, Marin’s portrait palettes are gradually shifted to becoming blue again.

And that’s it. A neat composition of several tricks, for a good and moving ending.


So there it is: some of the tricks used to unlock partial translucency on the Game Boy Color hardware. Of course these techniques are quite time-consuming, and thus are only used during a handful of key moments.

A few years later, the hardware translucency support of the Game Boy Advance will make these kind of effects much easier to achieve.

Want to read more? Read the other articles of this series, discover more of Link’s Awakening code, or join the discussion on Discord.