Messages

1

Graphics / Re: texture smoothing causes render artifacts

« on: December 02, 2023, 08:45:31 pm »

Thanks for responding Hapax!

"I'm not sure why you want to smooth solid colours..."

Indeed, this is just a solid color example of the problem I'm seeing in the actual game engine that uses textures that are not simple solid colors.


"...this is a common problem when using tiles at non-perfect integer pixels..."

Please help me understand this.  What about my example texture in the code provided is a "non-perfect integer pixel"?  How can I create source texture tilemaps that ARE perfect integer pixels.  I would gladly do whatever this is to avoid having to create tilemaps that have transparent buffer zones around each tile.  I'm just interested in learning how to do this the smart way, or whatever way everyone else does it to avoid this bug.

2

Graphics / texture smoothing causes render artifacts

« on: November 29, 2023, 04:11:58 pm »

I have a simple tilemap game engine that shows vertical and horizontal line artifacts, but only when sf::Texture::setSmooth() is set to true.  Attached is a simplified version of the game engine that demonstrates the problem, along with screenshots for when smoothing is turned on and off.

Simply turning off texture smoothing completely eliminates the artifacts, so either there is a bug here or I'm going about this wrong.

Any help is greatly appreciated!

Code: [Select]

#include <SFML/Graphics.hpp>
#include <SFML/Window.hpp>
#include <string>
#include <vector>

const sf::IntRect mapCharToTileRect(const char ch)
{
    if (ch == 'R') return { 0, 0, 32, 32 };
    else if (ch == 'G') return { 32, 0, 32, 32 };
    else if (ch == 'Y') return { 32, 32, 32, 32 };
    else return { 0, 32, 32, 32 };
}

void fit(sf::Sprite & sprite, const sf::Vector2f & size)
{
    const float scaleHoriz{ size.x / sprite.getLocalBounds().width };
    sprite.setScale(scaleHoriz, scaleHoriz);

    if (sprite.getGlobalBounds().height > size.y)
    {
        const float scaleVert{ size.y / sprite.getLocalBounds().height };
        sprite.setScale(scaleVert, scaleVert);
    }
}

int main(void)
{
    sf::RenderWindow window({ 640, 480, 32 }, "test");

    sf::RenderTexture renderTexture;
    renderTexture.create(64, 64);
    renderTexture.setSmooth(true); // *** artifacts disapear if false ***
    renderTexture.clear();

    sf::RectangleShape rectangleShape;
    rectangleShape.setSize({ 32.0f, 32.0f });

    rectangleShape.setPosition(0.0f, 0.0f);
    rectangleShape.setFillColor(sf::Color::Red);
    renderTexture.draw(rectangleShape);

    rectangleShape.setPosition(32.0f, 0.0f);
    rectangleShape.setFillColor(sf::Color::Green);
    renderTexture.draw(rectangleShape);

    rectangleShape.setPosition(0.0f, 32.0f);
    rectangleShape.setFillColor(sf::Color::Blue);
    renderTexture.draw(rectangleShape);

    rectangleShape.setPosition(32.0f, 32.0f);
    rectangleShape.setFillColor(sf::Color::Yellow);
    renderTexture.draw(rectangleShape);

    renderTexture.display();

    const std::vector<std::string> map = {
        "                  ",
        "   R              ",
        "   G          R   ",
        "   G          G   ",
        "   GGGGGGG    G   ",
        "   GGYGYGGGGGGG   ",
        "   GGGGGGG        ",
        "   GGGYGGGGGG     ",
        "   GGGGGGG  G     ",
        "            G     ",
        "       RGGGGG     ",
        "                  "
    };

    const sf::Vector2f tileSize(40.0f, 40.0f);

    while (window.isOpen())
    {
        sf::Event event;
        while (window.pollEvent(event))
        {
            if (sf::Event::Closed == event.type)
            {
                window.close();
            }
        }

        window.clear();

        const sf::Vector2i mapSize(map.front().size(), map.size());
        for (int y(0); y < mapSize.y; ++y)
        {
            for (int x(0); x < mapSize.x; ++x)
            {
                const char mapChar = map[y][x];
                sf::Sprite sprite(renderTexture.getTexture(), mapCharToTileRect(mapChar));
                fit(sprite, tileSize);
                sprite.setPosition((x * tileSize.x), (y * tileSize.y));
                window.draw(sprite);
            }
        }

        window.display();
    }

    return 0;
}
 

3

Window / Re: [Mac] Fullscreen modes not scaled to screen size

« on: August 08, 2021, 05:23:23 pm »

As it stands, I can't find a solution to this and it appears that my beloved SFML is just broken on MacOS.  Since all other apps/games are not broken by what Apple has done here, isn't this a question of what SFML is doing differently?  I must be missing something.  Can someone explain to me why SFML cannot just do what everyone else is doing?  Anyone?

4

Graphics / Re: sf::Texture Sizes

« on: December 08, 2018, 07:14:21 pm »

Thanks for getting back NGM88, but to clarify...

(1)  So changing which texture you are drawing with is a (relatively) expensive operation, but the size of the current and new texture has no effect on how long it takes?  (or if so, nothing significant?)

(2) Since I'm generating these textures at run-time with sf::RenderTextures, can't I just query the max supported size with sf::Texture::getMaximumSize() and use that?

5

Graphics / sf::Texture Sizes

« on: December 07, 2018, 11:46:31 pm »

I often find myself creating sf::RenderTextures that are optimized to only contain the minimally complete set of images that I need, and then compose/sort them to reduce the number of times I have to switch between them when drawing each frame.

Question:  What size should I make these optimized sf::RenderTextures?

Should I use the largest power-of-2 size supported by the hardware, or will that be slower since it will take longer to switch between them?  Would it be better to have 3 at 4096x4096 because that means fewer transitions, or is it faster to use 12 at 1024x1024 because now switching will take less time?  Or are they the same because the total amount of pixels transferred per frame is the same?

(I'm not getting a clear answer from tests on the machines I have access to.)

6

Graphics / Which draws nothing faster? Drawing a default sprite or skip with if() check?

« on: August 28, 2018, 01:51:18 am »

I noticed early on that drawing a default constructed sprite doesn't end up drawing anything.  I've found myself depending on this often.  I make sf::Drawable classes that always { target.draw(m_sprite); }, even when there is nothing to draw. In these cases I simply leave m_sprite in it's default constructed state.  I assumed that this was faster than wrapping all of these draw calls in an if, such as { if (m_willDraw) target.draw(m_sprite); }, because I assumed that somewhere inside SFML there is already such an if that skips drawing the default sprite.  My instinct was to reduce branch instructions in my draw code.  Am I wrong?

Given what you experts know about SFML's inner workings and assuming typical desktop graphics cards and processors (branch prediction especially) -is there a definitive answer, or is it too close to call and I will need to test?

Thanks for any help!