Messages

1

SFML projects / Wallbreaker (Arkanoid clone)

« on: October 28, 2019, 01:14:12 pm »

Hi,

This is Wallbreaker, a clone of the old classic Arkanoid/Breakout games.



There are various power-ups and you can create/edit your own levels with the built-in editor.



This is a very simple game, but it's quite complete. I just wanted a small project that I could actually finish to play with the SFML API. You can found:
- a particle system
- animations (move, zoom, and fade effects)
- a custom GUI module
- bitmap fonts
- state management
Some people might be interested in that so I decided to properly release it. Feel free to have a look!

Windows release: https://github.com/abodelot/wallbreaker/releases/download/v0.3/wallbreaker_0.3-windows.zip
Github project: https://github.com/abodelot/wallbreaker

2

Feature requests / Re: Friendly string mapping to Keyboard::Key

« on: October 28, 2019, 12:29:16 pm »

Hi,

I second this request. This will be very useful for any project featuring custom keyboard mapping.

Should this be added to the github issue tracker?

3

Graphics / Re: Unexpected alpha-blending result with render texture

« on: April 20, 2019, 08:53:13 am »

you can use white transparent instead of black transparent if it better suits your needs

This is a very handy solution for my use case, thank you.

Just curious, is there any reason for sf::Color::Transparent being defined as black transparent (instead of white transparent?).

4

Graphics / Re: Unexpected alpha-blending result with render texture

« on: April 18, 2019, 06:57:26 pm »

Hey,

You apply the blending twice. Once when you render it to the render texture and once when you render it to the window.

How comes the blending is applied twice? The shape white that I labeled "weird blending" is only drawn once!

If I'm not mistaken, when I draw the shape white drawn on the RT, the result is stored inside the RT.

So, I'd expect drawing this RT to a render window would behave the same as drawing a PNG with transparency.

keep a fully opaque alpha channel on the RT (-> custom blending).

This alone makes a difference. If I clear the RT with an opaque color (instead of sf::Color::Transparent), I got the expected result (the two squares look the same).

But I think I have a better understanding of my issue now: I saved the RT to png file. (see attachement).

We can see that rendering rgba(255, 255, 255, 128) on sf::Color::Transparent results in rgba(128, 128, 128, 128), because sf::Color::Transparent is defined as "black" rgba(0, 0, 0, 0).

Whereas I was expecting the result to be rgba(255, 255, 255, 128).

So, is this behavior of sf::BlendAlpha + sf::Color::Transparent intended?

Thanks,

5

Graphics / Re: Inheritance of sf::Sprite

« on: April 18, 2019, 06:27:59 pm »

Sprite objects do not own a copy of a texture object (and do not allocate textures objects), they only point to an already existing texture.

From sprite setTexture documentation:

The texture argument refers to a texture that must exist as long as the sprite uses it. Indeed, the sprite
doesn't store its own copy of the texture, but rather keeps a pointer to the one that you passed to this function.

Multiple sprite objects can point to the same texture. You need to manage life cycle of your texture objects separately, and you should not attempt to deallocate textures when a sprite is deleted.

6

Graphics / Unexpected alpha-blending result with render texture

« on: April 17, 2019, 06:48:21 pm »

Hi,

I want to draw a white square with half-opacity (alpha 128), but the alpha-blending isn't rendered as expected when I draw on a render texture.

Why don't the two following methods render the same result?

Method A:
    1. Draw something on a render texture
    2. Draw the render texture on render window
    3. Draw a white square with half-opacity on render window

Method B:
    1. Draw something on a render texture
    2. Draw a white square with half opacity on the render texture
    3. Draw the render texture on render window

#include <SFML/Graphics.hpp>

int main()
{
    sf::RenderWindow window(sf::VideoMode(320, 240), "sfml", sf::Style::Close);

    sf::RectangleShape black({20 ,240});
    black.setPosition(100, 0);
    black.setFillColor(sf::Color::Black);

    sf::RectangleShape white({60, 60});
    white.setPosition(80, 50);
    white.setFillColor(sf::Color(255, 255, 255, 128));

    sf::RenderTexture texture;
    texture.create(window.getSize().x, window.getSize().y);
    sf::Sprite sprite(texture.getTexture());

    // Method A: Draw white square on render texture
    texture.clear(sf::Color::Transparent);
    texture.draw(black);
    texture.draw(white);
    texture.display();

    white.setPosition(80, 160);
    while (window.isOpen()) {
        sf::Event event;
        while (window.pollEvent(event)) {
            if (event.type == sf::Event::Closed) {
                window.close();
            }
        }
        // Method B: Draw white square on render window
        window.clear(sf::Color::Blue);
        window.draw(sprite);
        window.draw(white);
        window.display();
    }
    return 0;
}
 

Image result in attachement.


Am I missing something?

- OS: Debian 9
- GPU: Mesa DRI Intel(R) Haswell Mobile (0xa16)
- SFML Version: 2.5.1

7

Graphics / Re: Drawing inside the Game loop / RectangleShape?

« on: April 17, 2019, 06:43:08 pm »

The code is incomplete, so it's quite hard to tell.

Are you sure you don't set another position to your sprite inside the game loop?

Also, you should not call window.draw / window.display only if a given event happened.

Keep the rendering outside of the event handling method, see examples in tutorial https://www.sfml-dev.org/tutorials/2.5/graphics-draw.php

8

Window / Re: Best way to save a screenshot

« on: April 01, 2019, 09:28:59 am »

Thanks for the confirmation.

I've added an entry to the Github wiki, under "Tutorials" section.

Nice to see all the core team is still active btw (I haven't used SFML since 2.1 release I think).

9

Window / Best way to save a screenshot

« on: March 31, 2019, 07:12:59 pm »

Hi,

I'm trying to catch up with last SFML releases, and noticed that RenderWindow::capture is now deprecated:

Use a sf::Texture and its sf::Texture::update(const Window&) function and copy its contents into an sf::Image instead.

My use case is saving to a image file what is currently rendered on a render window.

Is the following code the best approach for SFML >= 2.4?

sf::Texture texture;
texture.create(render_window.getSize().x, render_window.getSize().y);
texture.update(render_window);
if (texture.copyToImage().saveToFile(filename))
{
    std::cout << "screenshot saved to " << filename << std::endl;
}
 

Also, this seems like quite a common task. Maybe it should be added in the wiki?

10

Feature requests / Re: Return type of sf::String::toUtfX

« on: July 08, 2014, 09:33:56 pm »

Error message with -std=c++11:

(click to show/hide)

string_utf8.cpp: In function ‘int main()’:
string_utf8.cpp:7:26: error: cannot bind ‘std::ostream {aka std::basic_ostream<char>}’ lvalue to ‘std::basic_ostream<char>&&’
In file included from /usr/local/include/SFML/System/Err.hpp:32:0,
                 from /usr/local/include/SFML/System.hpp:34,
                 from string_utf8.cpp:1:
/usr/include/c++/4.7/ostream:600:5: error:   initializing argument 1 of ‘std::basic_ostream<_CharT, _Traits>& std::operator<<(std::basic_ostream<_CharT, _Traits>&&, const _Tp&) [with _CharT = char; _Traits = std::char_traits<char>; _Tp = std::basic_string<unsigned char>]’

Anyway, changing the return type now (for 2.x I mean) is not possible since it would break some code.

Ha, I didn't know SFML team was this strict about API breaks. Too bad then.

In the meantime, use `toAnsiString` (if I'm not mistaken it should do the same thing)

This one discards non-ANSI characters.

11

Feature requests / Re: Return type of sf::String::toUtfX

« on: July 08, 2014, 08:49:22 pm »

So using cout or fstream is not a problem.

It is, the following code doesn't compile:

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

int main()
{
        sf::String str("sfml string");
        std::cout << str.toUtf8() << std::endl;
}

(gcc 4.7.2)

Regarding 3rd party lib, I think it isn't an argument since anybody can find a 3rd party lib that is not compatible.

But std objects offer a common ground so different pieces of code can work together, especially for something as common as strings. You can always find a workaround, but I don't see the point of using basic_string<Uint8> where there's a standard, more convenient alternative with no drawback (AFAIK).

with c++11 we have std::u16string and std::u32string so it might be a good idea to use them (with std::string for utf8) when we switch to c++11.

That would be very nice indeed, but I believe we'll stick to c++03 for still a little while

12

Graphics / Re: origin

« on: July 08, 2014, 06:15:44 pm »

How your parent/child relationship is defined? Show us an example code.
You want the position of the children be relative to the parent's position?

Origin is just the reference point for transformations, I'm not sure of what you're trying to achieve.

13

Feature requests / Return type of sf::String::toUtfX

« on: July 08, 2014, 06:00:35 pm »

Currently, sf::String::toUtf8 returns a std::basic_string<Uint8> object.

I think It would be better if toUtf8 returned a std::string, because this method isn't very useful: you can't do much with these std::basic_string<> objects, and you need to convert them if you want to do very basic things such as:

• display them with std::cout
• write them in a file
• use them in a 3rd party library...

Doing any of these things requires a conversion which could be avoided:

std::basic_string<sf::Uint8> tmp = sfString.toUtf8();
std::string utf8(tmp.begin(), tmp.end());
 

So, why not returning standard, more convenient objects?
Same remark for toUtf16 / std::wstring.

14

Feature requests / Re: Make sf::Font abstract, in order to make sf::Text re-usable for bitmap fonts

« on: June 29, 2014, 09:16:12 pm »

They just have a bitmap look, but I don't think they are bitmap fonts. TTF is a scalable format.

I'm not sure about this. They are rendered "pixel perfect" only if your sf::Text has the same character size the bitmap font was designed for. If you use a different size, the text is scaled and looks blurry.

15

Feature requests / Re: AW: Re: Make sf::Font abstract, in order to make sf::Text re-usable for bitmap fonts

« on: June 29, 2014, 02:27:02 pm »

What do you mean by that? What kind of bitmap font is supported by sf::Font?

What Laurent said, and there's also bitmap fonts in ttf format (see http://www.dafont.com/fr/bitmap.php).
Many people who use bitmap fonts want a pixel perfect rendering (no hinting/blending/smoothing), something retro-looking which look nice at small size (the exact size designed for the font).