The craft behind Super Mario Land DX

Hi, I'm Iván Delgado, also known as toruzz in the romhacking community. I'm a software developer and a graphic designer, and I've been modifying classic games for many years.

I'm mostly known for my colorizations, or in other words, for turning original Game Boy games into full-fledged Game Boy Color titles by rewriting parts of their code and rebuilding their visuals.

I started as a teenager when I discovered Spanish fan-translation communities. At the time I barely spoke any English, and those translations helped me get into a lot of games. But there was an important omission that really bothered me — somehow, all Ocarina of Time translations into Spanish were terrible. Since Nintendo Spain packed the original game with a translation book containing all the text in both English and Spanish, I decided to follow some guides and try to make a translation myself. That project ended up taking me two years.

In Spain, Ocarina of Time included a book with all texts in both English and Spanish

From there, I became increasingly interested in the more technical side of romhacking. I really admired people who could modify games at a low level, like inserting variable-width fonts. Years later, I finally challenged myself to learn Game Boy assembly and implemented one in Link's Awakening. That was the turning point where I realized I could take on much more ambitious projects.

I spent a lot of time with the original Super Mario Land growing up, and it's a game that simply screams nostalgia to me. Its music in particular left a strong impression, and even today it instantly takes me back.

With all its shortcomings, it's one of those games that never really left me, even when I wasn't actively playing it anymore. And those memories, that magic we experienced as kids - that's in part what I try to rekindle with my works.

So I guess it not only defined my childhood, but also, in a way, who I am as a romhacker.

The idea of doing my first colorization came from wanting to push myself technically. Inspired by Drenn's color patch for Pokémon Red (which isn't a traditional romhack, as it was based on a full disassembly), I wanted to create something similar but with a strong focus on making it feel as close as possible to an official release. After a long trial and error process, I felt I was onto something and chose For the Frog the Bell Tolls as my first serious attempt.

Pokémon Red Full Color by Drenn & FroggestSpirit

As I kept learning more and more, I realized I needed to start fresh with a cleaner approach. I chose a new project that would better reflect my goal of achieving an official-looking result, which led me to Super Mario Land 2. It took a long time, but I was reasonably happy with the result.

When I was ready to go back and restart work on For the Frog the Bell Tolls, I realized that if I was going to invest that much time into a project, I wanted it to be something more personal. So, with the 30th anniversary about a year away, I decided to work on Super Mario Land instead as a kind of personal tribute to the game and the Game Boy itself. I even included a hidden "happy birthday" inside the game.

This is in your copy too

So in the end, that combination (technical ambition, personal nostalgia, and timing) was really the spark behind Super Mario Land DX.

For such an early game, I would say the code isn't especially messy, but coming from Super Mario Land 2 it does feel very archaic in many ways.

For example, implementing different physics for Luigi was surprisingly difficult. In this game, movement is largely driven by a small speed table that determines how many pixels Mario moves at a given moment, which makes even small variations in physics harder to implement than you might expect.

There are also a lot of tricks to save space in the cartridge, typical of early Game Boy games. For example, parts of the map repeat because the game reuses small "screens" of level data. That screen-based structure in itself feels antiquated compared to later games.

When I started working on the game, I quickly realized that the original sprite system was too restrictive to work with, with rigid assumptions about sprite layout and attributes. My solution was to completely rewrite the sprite system from scratch to make it more flexible and efficient.

That change helped with lag when too many enemies are shown on the screen. That said, the biggest improvement came from enabling Game Boy Color's double-speed mode, which effectively doubles the CPU speed. That, however, introduces its own timing issues, so part of the work involved adjusting the game's timing logic to keep everything running correctly.

While it's true that the Game Boy Color is limited to 8 palettes of 4 colors for background (and the same for sprites), there are ways to make the game feel much richer than those numbers suggest.

Part of it is just making good artistic decisions, but there are also technical tricks. In a game like Super Mario Land, with enemy placement and level progression being predictable, you can dynamically change palettes as the player moves through the level.

An image with some of my notes for the changes introduced in SMLDX v2.0

With careful planning and a lot of trial and error, you can determine which enemies can use two layers of color without causing many issues. Even then, there's always a minor issue here and there — for instance, in World 4-2 you can find an orange Chibibo. Fortunately, as long as the visual consistency is strong, those small inconsistencies tend to go unnoticed.

As soon as you start adding color to the original graphics, you quickly realize it makes some inconsistencies much more noticeable. The biggest issue is obvious — some sprites have outlines while others don't, which creates an uneven and sometimes distracting look.

When working on these projects, I try to put myself in the shoes of the original developers. So I had to ask myself: is this inconsistency something they would have addressed if they had the hardware to do so?

There's no definitive answer, of course, but I felt that this was the kind of issue Nintendo wouldn't have ignored, at least not entirely. So I thought of redrawing the graphics as a problem that needed solving. It wasn't an easy task given the extremely low resolution and other constraints, but having extra colors helped me convey more information within the same space.

I was also very aware that this would be a divisive decision, so I included the original graphics as an option.

Absolutely, a lot of the color choices come simply from how the worlds made me feel.

To me, the Muda Kingdom always had a "sea breeze" atmosphere, something fresh and open. Even if it doesn't make much sense, having a final underwater level reinforces that feeling for me.

In contrast, Birabuto being based on ancient Egypt felt, well, Egyptian. That means it naturally leans into warmer tones and has a sense of mystery, especially in 1-3. In fact, my first version of 1-1 had a very sunny, amber sky, but I ultimately decided it didn't feel like a proper Mario opening without a blue (or purple!) sky.

An early, unreleased version of 1-1 (Apr 2017)

In the end, my choices are largely aesthetic and guided by intuition, but I try my best to keep coherence and readability.

My approach follows a simple rule: I'm willing to change things if they were originally the result of hardware limitations, if it feels like an honest improvement, or if leaving them untouched would create issues or distractions that weren't as noticeable before. Other than that, I always try to respect the spirit of the original game.

To me, a DX version is essentially a way to explore a "what if" scenario. As a fan, I try to get as close as possible to my own interpretation of what Nintendo might have done if they had revisited the game back then.

So if something like a bug is part of the original feel and doesn't negatively impact the experience, I'd rather leave it as it is.

Back then, Nintendo seemed to have a simple rule with the "DX" releases - it wasn't just about the color, the games needed something extra being added to the gameplay.

I wanted to stay true to that idea and, for a Mario game, adding a second character with different physics is a natural way to introduce replayability. It's something we still see in modern Mario re-releases, so it felt like the most natural addition I could make.

My impression is that Nintendo typically takes action when there's brand confusion, money involved, or overlap with an official release. So I tend to think that fan projects that respect their IP and don't create problems are tacitly in the clear.

But does Nintendo being Nintendo influence how I share my work? Well, yes. But as long as I keep in mind those boundaries and distribute patches rather than full games, I think I should be fine. I see it as a legal gray area rather than something clearly prohibited.

I've thought about changing the way I distribute my patches to ensure there's a real cartridge present (using specific hardware to patch the game), but ultimately I don't think that would change anything.

At the end of the day, if Nintendo ever asked me to stop, I wouldn't have any issue with it. I'd simply move on to something else.

This is something I didn't fully realize at first, but over time I've come to understand how much of an impact these projects can have.

I remember a parent telling me how happy they were that their child finally played their favorite game thanks to my hack. Moments like that feel very real.

Bringing these classics to a broader audience was never the original goal, but I now recognize how meaningful that can be and it's become one of my main sources of motivation.

Super Mario Land 2 was a much more challenging and time-consuming project compared to the original, which is probably to be expected since I was still learning while working on it. A lot of that knowledge carried over to Super Mario Land, which made the process much more efficient.

This is a bit ironic, but I'm currently working on... Super Mario Land! Yes, again.

For the longest time, I've been looking for a way to port Game Boy games to the Game Boy Advance, and I've finally built a solid foundation to make that possible. If everything goes well, it should lead to the best version of any game I've ever worked on.