[SOLVED] How to do (composed) transparency? shaders?

[danikaze]

Hello!

I've searched for this question in this forum but I couldn't find it so, I want to know how to apply a % of transparency to several sprites/images at the same time.

Let me explain this:

Think about Photoshop (or gimp if you like). While the alpha channel of each sprite is like the opacity of each layer in Photoshop, and it's easily modificable, what I want to do is change the opacity of a group/folder of layers in Photoshop. That is, draw several images and then and only then apply the opacity value.

Here's an example:
Think of a playable character composed by 3 images (head/body/feet).
Let's say I do (pseudo-code)

player.alpha(60%)

I want to show this:


But applying alpha to each image, it would draw this:


So my question is, how to do this? Do I need to play with OpenGL (I never touched it and I don't know how) or there's a way in SFML?

Thanks!

[attachment deleted by admin]

[FRex]

Draw everything with 255 a to render texture then draw sprite using render texture's texture with desired a.

[danikaze]

Draw everything with 255 a to render texture then draw sprite using render texture's texture with desired a.

Yeah that's the simple way... "pregenerate graphics"...
But if the character is updating animations every frame... is there any way to do this propertly?

[Laurent]

It's not a preprocessing solution, it's a real-time one. It just involves drawing an extra sprite, so it's very cheap.

[danikaze]

It's not a preprocessing solution, it's a real-time one. It just involves drawing an extra sprite, so it's very cheap.

I see... so there's no need for shaders or anything else?

I thought this would be a heavy solution... and now that I see exploit3r sentence makes me think it again:

But keep in mind drawing to the render texture every frame is quite a heavy task, it's like drawing two frames at once, so if it's not really needed don't do this every frame iteration.

I would need to do it every frame (that's why I thought about shaders, to let the GPU do the heavy task)

[Laurent]

Shaders wouldn't help, you really need an intermediate rendering here.

I thought this would be a heavy solution... and now that I see exploit3r sentence makes me think it again

He's wrong

Let me show you why:
- drawing to a render-texture rather than to a render-window is the same operation, it's not more (or less) expensive
- drawing the render-texture to the render-window involves nothing special, it's just a single sprite to draw

And that's all.

[danikaze]

That's very nice then.

Anyway, taking further the question and talking about optimization now (if you don't mind), this way would need to create a renderTexture, therefore you need to know the total size of the sprites (ok, something easy), but you also need to clear it every frame before rendering other frames into the texture, and then draw it.

Ok ok, I know it's not a very heavy operation (and probably it will be the way I'll start with), but I think it could be optimized using shaders. Is it too hard/not worthable to do it? Everything that could save a few FPS is great (specially when you have to do it every frame, multiple times -20/30- per frame)

[model76]

I would advise you to write your software first, as simply and straight forward as you can, and then look at optimizing it later. Otherwise you could easily be spending your time optimizing the wrong thing, and complicating your code unnecessarily.

[danikaze]

I would advise you to write your software first, as simply and straight forward as you can, and then look at optimizing it later. Otherwise you could easily be spending your time optimizing the wrong thing, and complicating your code unnecessarily.

I know I know, it's not the first game I write
But I want to plan my architecture for the next one as complete as possible

[Laurent]

I think it could be optimized using shaders

Shaders are not a magic solution to every problem.

Before talking about technical details, you should first find the right algorithm, i.e. how to draw 3 transparent sprites as a single uniform one. Chances are that an intermediate texture cannot be avoided.

Once you find a solution/idea/algorithm, we can start talking about whether shaders can help you to implement it or not.

[danikaze]

Yeah probably.
I have to do a research first about openGL and shaders, but I'll stick to this solution for now.

Thanks for everything

[danikaze]

I tested it, finally!

Actually, drawing into a RenderTexture is about 15x slower than drawing directly into the RenderWindow...

Main code (shared part)

#include <SFML/Graphics.hpp>
#include <iostream>

using namespace std;

/*
 *
*/
int main()
{
        sf::RenderWindow window(sf::VideoMode(800, 600), "SFML tests");
        sf::RenderTexture screenBuffer;
        screenBuffer.create(window.getSize().x, window.getSize().y);
        sf::CircleShape shape(100.f);
        shape.setFillColor(sf::Color::Green);
        shape.setOutlineColor(sf::Color::Yellow);
        shape.setOutlineThickness(5);
        shape.setPointCount(shape.getPointCount()*1.5);
        shape.setOrigin(100, 100);
        shape.setPosition(400, 300);
        sf::Clock clock;

        sf::Texture texture;
        texture.loadFromFile("bin/img.png");
        sf::Sprite sprite(texture);

        while (window.isOpen())
        {
                sf::Event event;
                while (window.pollEvent(event))
                {
                        switch (event.type)
                        {
                        case sf::Event::Closed:
                                window.close();
                                break;
                        default:
                                break;
                        }
                }
               
                /* TEST PART, LOOK BELOW */

                window.display();
                cout << clock.restart().asMicroseconds() << endl;
        }

        return 0;
}
 

RenderWindow test part: (output: ~14800 microseconds)

        for(int i=0; i<1000; ++i)
        {
                window.clear();
                sprite.setColor(sf::Color(255, 255, 255));
                window.draw(sprite);

                window.draw(shape);

                sprite.setColor(sf::Color(255, 255, 255, 100));
                window.draw(sprite);
        }

 

RenderTexture test part: (output: ~222000 microseconds)

        for(int i=0; i<1000; ++i)
        {
                screenBuffer.clear();
                sprite.setColor(sf::Color(255, 255, 255));
                screenBuffer.draw(sprite);

                screenBuffer.draw(shape);

                sprite.setColor(sf::Color(255, 255, 255, 100));
                screenBuffer.draw(sprite);
                screenBuffer.display();

                window.draw(sf::Sprite(screenBuffer.getTexture()));
        }
 

Am I doing something wrong?

[Laurent]

What takes time is to switch from one target to another.So if these 1000 iterations are only for testing purpose, you can ignore the results.

[danikaze]

Yes, that's for testing purpose, but in a real situation wouldn't be the same?
I mean, switching need to be done, whether it is a test or not.

SFML looks great, but I'd like to know its limitations, and I'm seeing it's not the same writing to RenderTexture than directly to the screen, and 15 times slower it's something to take into account

What's exactly the switch it needs to do? From target texture? (RenderWindow/RenderTexture).
In a game probably will be more switching than in this test, so if that's the case, I'd design my architecture in a different way.

Thanks for all!

[masskiller]

SFML looks great, but I'd like to know its limitations, and I'm seeing it's not the same writing to RenderTexture than directly to the screen, and 15 times slower it's something to take into account

This is definitely not normal, they last about the same time in normal circumstances.