Forem: Blue Fire

How to avoid ghost lines and render artifacts in Flame

Erick — Tue, 12 Aug 2025 13:18:11 +0000

If you ever developed a 2d game, you might have had to deal with “strange rendering artifacts” when using sprites from a sprite sheet.

Consider the screenshot below:

If you have a good eye, you might already have noticed the artifacts that I am talking about, but since this screenshot was compressed and scaled down to be presented here in a web page, it might be hard to spot them both, so let me zoom in in the issues:

Note this “ghost line” between the tiles.

Note how a thin line appears on the left side of the knight

You make sure that your src position and src size is exact, you make sure that your tiles are correctly aligned with each other, yet, you can't get rid of these annoying lines.

And that is not really your fault! These artifacts can happen in a variety of different contexts, they are common to happen when any camera transformation is used, be it zoom or translation, it can happen if you scale up or down the sprite, or even when you simply have it positioned with long decimal values.

Still, no matter the context, the root cause is the same: computers have a limited precision on float numbers and their decimal values.

That imprecision can make sprites that are supposed to be perfectly aligned, as in if they are positioned edge to edge on each other, to be rendered with a very thin line between them, causing what we call ghost lines.

The issue we see in the knight is a bit different; first, take a look at the whole sprite sheet that we are using:

Let's zoom in a bit in our knight:

Note how we have the sprite of another knight on the left, and that sprite touches the border of the knight that we are rendering.

Even though we set the src position correctly to start on the exact pixel, when rendering the whole scene, when all the underlying transformations are applied, that imprecision will make the rendering of our sprite accidentally “grabbing a small section” of the rest of the sprite sheet, and a thin line from the sword of the other sprite will be rendered alongside our own sprite. This is what we call a “texture leak”.

Solutions

There are several ways to fix these problems, in this article we will suggest a couple of them which are the ways that in our experience works the best and are the ones we recommend.

We presented two different issues, so let's tackle them individually.

Ghost lines busting! Who you gonna call?

A reliable way of fixing those ghost lines that appear between aligned tiles is to use a technique known in the game development world as “pixel bleeding”.

The idea is that we render the sprites a little bit bigger than its original size, that way, the added size will cover that thin line, but it is so small that will not be noticeable by the human eye.

Starting on Flame v1.3.0 all sprites and sprite components can be rendered with this bleeding effect:

    const bleedValue = 0.04;

    final spriteImages = await images.load('little-adventures.png');
    world.add(
      SpriteComponent.fromImage(
        spriteImages,
        srcSize: Vector2.all(8),
        srcPosition: Vector2.zero(),
        position: Vector2(-(resX / 2), (resY / 2) - 8),
        size: Vector2.all(8),
        bleed: bleedValue,
      ),
    );

Note the bleed attribute on the SpriteComponent.fromImage and how we are passing a value of 0.04 to it. That will make the sprite be rendered with 0.04 pixels on each border, covering the ghost line!

Note that the exact bleed value depends on multiple factors: The size of the sprite, the zoom level or the current viewport, bigger sprites might require larger values and so on, before settling in a bleed value, be sure to test the game in different resolutions and zoom levels, and depending on how dynamic the zoom of the game is, consider making the bleed value proportional to the applied zoom.

Texture leaking plumbing!

A simple technique to fix this problem is to “isolate” that sprite in the memory. This means that when rendering the sprite in the game we will not be rendering a portion of an image, but rather be rendering an image that has only the sprite we want to render.

Of course you could get rid of the sprite sheet and make every single texture of your game a single image, that could cause many other issues though like increased IO operations etc.

So, starting on Flame v1.30.0 we provide a new feature that allows you to still use sprite sheets, while being able to isolate sprite in memory to avoid the memory leaks: Raster Sprites.

Raster sounds like a fancy word, but a raster image, or raster sprite simply means “an image in the memory”. When using raster sprites, Flame will under the hood extract the sprite from your sprite sheet and make an image in memory that represents that single sprite, avoiding the possibility of textures leaking into each other.

To use Raster sprites in flame, simply use the RasterSpriteComponent instead of the SpriteComponent. Both components share the same API.

    world.add(
      RasterSpriteComponent.fromImage(
        spriteImages,
        srcSize: Vector2.all(8),
        srcPosition: Vector2(8, 88),
        position: Vector2(-(resX / 2) + 16, (resY / 2) - 16),
        size: Vector2.all(8),
      ),
    );

Mix and match

Note that if you have multiple tiles in the same texture atlas, whereas their edges are side to side, you might need to combine both techniques and use the bleedValue attribute in a RasterComponent in order to avoid both ghost lines and texture leaks.

Flame tiled

If you use Flame Tiled for your tiled map you might still notice ghost lines as these features have not yet been implemented in that package by the time of the writing of this article, but stay tuned for future updates.

Wrapping up!

With these two techniques you should be able to get rid of any unexpected rending artifacts in your game!

Check out the official docs for the Pixel Bleeding and Sprite Rasterization and check this repository for the full example used for this article.

If by any chance you find yourself in an edge case where neither of the presented solutions work, don't hesitate in reaching out to the Flame team on our Discord!

Flame 1.0 is here!

Luan Nico — Wed, 08 Dec 2021 18:56:50 +0000

Hi there, folks! It's been a while since our last article, but if you are following Flame on GitHub or participating in our Discord, you know very well that we have not been idle. Far from it. In fact, you might have noticed more and more Release Candidates being put out regularly, mostly with some needed updates and cleanups, a few new core features, bug fixes, and incorporating valuable feedback from our amazing Game Jam. That is because both the team and the community have been working together, relentlessly, to make Flame the best it can be.

And, first of all, I would like to make it very clear that we are not done with this goal, not even close -- the pile of things we know could be improved, extended or added is only shadowed by the mountain that we don't even know about yet. So the first thing I would like to reassure everyone, with this article, is that nothing really changes in that regard. We will still be putting out PRs, receiving invaluable help from the community, making improvements, new features, bug fixes. We will still be at discord, helping out new people, having deep, productive discussions with veterans, and collaborating together to keep growing and enhancing all Blue Fire's projects.

That being said, we do have a key milestone to share. You might have already heard about it on the Flutter 2.8 release article, or maybe got a sneak peek on pub; but, regardless, we wanted to double down and proudly announce we just released Flame 1.0.0. Yes, it's official, and finally here! What an end-of-year holiday gift to us to finally be able to say that, given all the work that has been put into it! We are very happy with the current state of our code and the capabilities provided, and we think it's time to make this commitment. Thank you so much for every single one of you, that contributed with PRs, discussions, questions (that led us to improve some docs or reconceptualize some API), monetary donations via our Patreon, or that used Flame, made something great, participated in any way, gave us a star on GitHub, or just for reading and sharing this article. Thank you, from the bottom of our hearts.

And let me reiterate; we are still going to keep improving, updating, fixing, enhancing Flame. In fact, I hope version 1.0.0 lives very briefly on pub, to be replaced with 1.0.1, 1.1.0, whichever comes first, very soon. This just means we believe the current API is stable, and we won't be making big, breaking changes that often, or without warning. Expect more structured, stable updates, especially new features. It also means we can focus our attention now to improving our docs, bridge packages, tooling, examples and tutorials to make sure this awesome ecosystem that came about works seamlessly and frictionlessly, and that people can easily welcome people to join and learn. We are also happy to have established and to carry on this partnership with the Flutter team to make sure we all pave a future together for Flame and our beloved community.

And on that note, we ask you to update your dependency, head over to Discord to continue the discussion, and if you haven't, please check Flutter's article about all the amazing things packed on Flutter 2.8, and let us know if you have any feedback! Thanks everyone again for everything, and have a great day!

Fireslime is now Blue Fire

Erick — Thu, 19 Aug 2021 13:07:26 +0000

TLDR: Fireslime, the team behind the Flame Engine, is changing their name to Blue Fire. We are also moving away from the idea of being just an indie game studio and want to focus more on maintaining Open Source projects and create an open and friendly community around those projects.

Almost 3 years ago, I (Erick) and Luan started a little project together. We both enjoyed game development, and after talking about some ideas, we created Fireslime, a small, informal, Indie Game Studio.

When Fireslime started, Luan had already created the very first version of Flame, a Flutter based game engine. Since we both liked learning and exploring new things, we decided to use Flame as the engine of our games; that way, we could slowly improve the engine, while we developed the game. But back then, our focus was mainly on building games, and not the game engine itself. Flame was just a means to an end for us, a tool to create our games.

As time passed, we created multiple games. We even fully released two of them, and launched two demo versions. They didn't manage to make much success on their own, but they helped us grow Flame.

Suddenly, we started to realize that the people who were in the community Discord (that we created for the Fireslime's games) were actually there because of the Flame Engine or the other open source projects we maintain, and not for the games themselves.

As the Flame Engine and our other projects grew, so did the time we spent on them. Which inadvertently meant that we spent less time working on our games.

Over time, more people joined the team as maintainers, the first to join was Renan, a software developer, bad gamer and bad comedian. After Renan the next one to join was Lukas, a developer, keyboard builder, backpacker and climber. And last but not least, Jochum, an open source enthusiast, GitLab fanboy, collector of strange linux devices and proud owner of a Commodore 64. And while the team grew, that initial idea of being a game studio was steadily fading.

So we decided to finally embrace this situation that we found ourselves in, and officially announce our new goal and focus: working on Open Source projects and building a friendly community around our Flutter and Dart projects.

Fireslime was a name that we decided on originally for a game studio, as it was playful and friendly. But with our new focus in mind, we wanted something different; something open and something that had its roots in both Fireslime and Flutter. So, as a team, we chose the name Blue Fire.

"Blue" expresses our focus and love for the Flutter framework and Dart, on which our projects are built and our community lives. And "Fire" represents our roots, our history and our connection to the Flame Engine.

Does that mean that we will no longer build games? No! Our biggest project is the Flame Engine, and the best way of validating and testing such a game engine, is to build games with it. But now that we have our goal and focus clear, we can honestly say that we are committed to Flame, Flutter and our other Open Source projects (be it our other libraries or games), with the hopes to help and grow both the Flame and Flutter community and their corresponding ecosystem.

So, from us as Fireslime, we thank everyone that has supported, helped and followed us over these last few years. And we hope you will all keep supporting us as Blue Fire as well, and be part of our community!

The Blue Fire team wishes you happy coding.

Flame 1.0 on the horizons

Luan Nico — Sat, 05 Sep 2020 19:18:03 +0000

There is a TL;DR at the end so at least you have to scroll and see what you are missing.

Hi there, folks! We have some exciting changes to talk about and some even bigger ones on the horizon, so I decided to write down this post to share what's been going on with Flame recently (with a big announcement in the end!).

Some of you might have seen activity on GitHub, and a few of you have been actively helping, so I think it's no surprise we have plans of moving towards Flame 1.0 in the near future! It's been a long journey through these years since I created the Flame engine. Since then, a lot of amazing people from the community came forward to help us grow this platform so much, but we always kept it on v0 (0.x versions). That allowed us to "move fast and break things", even though we actively avoided big breaking changes after the first few releases.

But a major side-effect of such a broad, helpful and kind community was that we learned and discovered a lot about Flame, games in Flutter, and how to make our lives even easier. So we collected a lot of feedback and ideas and decided that it was time to go to v1. Finally launch Flame 1.0, a more established and robust API.

What will change? We do not want to break everything for nothing. Also, we are still committed to our core values, the first words in this repo since day one: a simple, modular game engine. So nothing huge will change, actually. But we will break a few things. We are taking this opportunity to make a few changes we always wanted to do but didn't want to create confusion on people migrating from 0.x to 0.(x+1). But this is 1.0, and we have allowed ourselves some changes.

You can, of course, take a peek on those changes on GitHub -- I encourage you to do so, I am really excited about them. And we would like to take this opportunity to ask for other ideas. If you have something in mind that would be a breaking change but you think would be worth it to add to v1, please open an issue to discuss (just make sure it has not already been discussed or implemented).

But I would like to talk about one change in particular here, one that we partially rolled out to some extent to 0.x and one that will definitely be the most glaring one. In the beginning, everything that we added to Flame was a necessary building block, in my view, to create games; from the most simple to the most advanced ones. As time progressed, though, we started to add some more edge case features. This is in line with our modular approach - we never made anything mandatory or "in the way". But for some stuff, we decided to make separated packages. For example, we had flame_gamepad for gamepad support, but box2d support was "included" in the flame package. There was no particular rule that led us to that decision (we didn't want any native code on Flame itself but that never stopped Flame to depend on plugins with native code). Also, dart and pub have a very nice tree-shaking algorithm, so we thought it didn't really matter.

Now, for 1.0, after a lot of discussions, we decided to move to a more package separated approach. We want everything that is not absolutely core to be its own package. That way, Flame will not have many (if at all) dependencies. It will never have any native code. And anything that is an integration with something else should all be separated plugins.

These plugins will be called flame_* and will live in our GitHub/pub organizations. They can still be built and maintained by us, but also there can be other new ones entirely by the community (like the awesome package bonfire, for example, be sure to check it out).

This will allow Flame to be simpler and leaner, have fewer dependencies (and therefore fewer breaking points). The packages we are planning on extracting are:

flame_audio
flame_flare (and flame_rive)
flame_box2d
flame_tiled

These plugins will peer depend on flame and have the same nice helpers we are used to. For example, we also happen to maintain our fork of the box2d.dart package, which is a Flame-agnostic port of box2d to dart. Flame, likewise, will know nothing of box2d. And flame_box2d will have all the binding code, the Box2dComponents, the connections, the helpers to make it all work. Similarly, flame_audio will depend on audioplayers (and possibly other audio libraries) and provide everything flame currently adds vis-à-vis sound (like AudioPool). And so on.

One reason we started doing this already is due to some technical difficulties, especially with the plugins that depend on others. For example, the tiled package was updated to use a new Flutter version, forcing Flame, which depends on it, to do so as well. With this change, flame_tiled will be solely responsible for updating tiled and keeping it compatible. No one that does not use tiled will have to care for this particular issue.

In order to keep it all consistent, we will be creating a brand new flame_example, that will contain all flame packages and use Dashbook to provide all the examples we have now on doc/examples, and many more, making sure they all work together nicely.

We hope this change will make our life easier to maintain our packages and also make everyone's lives easier as well by making it simple to "pick and choose" the modules you need and not care about the others.

Now, let's set all the 1.0 hype aside for a second, so we can get to the rest of the news, our second big announcement.

We are also thrilled to share that we will be holding a recurring online event focusing on the Flame community: FlameCon.

Our plan is to create a space for people to share the awesome things that they build with Flame, and it will be open to everyone that wants both to present, or just to watch.

The first edition will be held on Sept 16, 2020 at 20:00 UTC, and will host two talks:

Building RPG games with Bonfire, in which Rafael Barbosa, the author of Bonfire will present about this awesome RPG engine built on top of Flame.
Optimizing sprite usage with Fire Atlas, in which Erick Zanardo will show what this tool is and how it can help you optimize and organize the sprites on your Flame game.

To participate in the event, check our official page here, and be sure to join the out MeetUp group; all needed information will be provided on those links!

That is it for now, everyone! We are really excited and working hard to bring v1.0 to fruition, and we are really, really excited to be hosting our first ever FlameCon!

TL;DR: Flame 1.0 is in the oven and first Flamecon will be held on Sept 16 at 20:00 UTC.