Messages

1

Graphics / Re: Draw sprite to renderwindow automatically

« on: December 23, 2022, 05:39:34 pm »

A simple approach would be to place your sprites in a vector, and loop over it when you draw:

std::vector<sf::Sprite> sprites;

//insert sprites here

for (const auto& sprite : sprites)
{
    window.draw(sprite);
}

However if you're getting more serious about your code design I highly recommend reading SFML Game Development and Game Programming Patterns - both of which I found invaluable when I was learning SFML.

2

General / Re: VertexArray size impacting gl_Vertex value in Vertex shader

« on: December 14, 2022, 05:21:16 pm »

To be honest that's probably the best work around you'll get. For a while I supplied my own set of matrices to the vertex shader (and did my own funky 3D things with it) but then decided if I was going to put in that much work I might as well just switch to pure OpenGL. Credit to SFML though, I wouldn't have learned enough about OpenGL without it 

3

General / Re: Render to several render textures in one draw ?

« on: December 14, 2022, 02:25:46 pm »

I did make an SFML-compatible(ish) MRT some time ago, which you can check out here:

https://github.com/fallahn/xygine/blob/legacy/xygine/include/xygine/MultiRenderTexture.hpp

I say 'ish' it breaks compatibility with the version of OpenGL SFML uses, so while it works on Windows using a compatibility context it won't work on macOS (and I think linux was spotty too, but it's been a while and I don't recall for sure  )

4

General / Re: VertexArray size impacting gl_Vertex value in Vertex shader

« on: December 14, 2022, 02:17:51 pm »

This is an SFML optimisation - if a drawable has four or fewer vertices then the positions are pretransformed to world-view coordinates, and the model-view matrix is set to an identity. I came across this when working with a lighting shader and the inverse of the model-view matrix wasn't giving me what I expected.

5

Graphics / Re: SFML and Shaders

« on: November 19, 2022, 02:52:57 pm »

Another thing, in general... How do you get the position sent to the shaders in SFML?
I haven't seen any good tutorial on it yet.
Like in "proper" openGL you usually use in vertex shader:

layout (location = 0) in vec3 aPos;

void main()
{
   gl_Position = vec4(aPos.x, aPos.y, aPos.z, 1.0);
}

but I'm not sure if this works in SFML like that?
All the examples I've seen use deprecated 1.0 stuff, that is really old.
I mean I try to use 3.3 core, and even that's old, but at least it's a bit modern...

If you're using the graphics module of SFML then up to version 2.5 (maybe 2.6, I've not kept up) you're restricted to GLSL 1.2 / #version 120 without a compatibility context. So, you're probably OK to use other versions of GLSL on Windows, maybe on Linux, and not at all on macOS which only supports core profiles.

The vertex position is provided in gl_Vertex and the world/view/projection matrix in gl_ModelViewProjectionMatrix - see the shader tutorial. It might also be worth noting that SFML drawables with 4 or fewer vertices will have their positions in world space with an identity matrix set for model/world matrix (this has caught me out before when trying to do lighting stuff, trying to take the inverse of it will just give you another identity matrix).

6

Graphics / Re: Render Overlap with TileLayer from tmxlite

« on: October 28, 2022, 11:10:27 pm »

Tmxlite itself doesn't have any particular utilities for this sort of thing - it's designed purely as a way to convert tmx map data into C++ data structures. However some time ago I did write a post about z-ordering with Tiled which might help you set up your maps:
https://trederia.blogspot.com/2014/08/z-ordering-of-sprites-in-tiled-maps.html

There's also this post by Elias Daler which is useful:
https://eliasdaler.wordpress.com/2013/11/20/z-order-in-top-down-2d-games/

And, if you can, check out Titan Souls on Steam. The game includes all the tmx map files in its assets directory which can be very enlightening. (No affiliation, I just like the game )

7

Graphics / Re: How to add a depth buffer to isometric textures?

« on: October 28, 2022, 10:52:25 pm »

It's possible to add depth to SFML drawables, but it depends on your definition of 'hack' It also requires a bit of knowledge about OpenGL, particularly shaders. The gist is that normally in the vertex shader you take the coordinates of each vertex of a drawable and convert them, usually through a world/view/projection matrix, into your display's coordinates so that the drawable is rendered on screen in the correct place. This is done automatically by SFML, but it is possible to override the behaviour with custom shaders. SFML is by nature 2D so it makes sense that at the vertex shader stage only the x and y coordinates of the vertices are provided. However, with a bit of experimenting I was able to store z/depth data in the vertex colour property. Here's the result:

http://www.youtube.com/watch?v=30wvsDwAKHs

Constructing a vertex position from this data in the vertex shader essentially makes the vertex 3D, allowing OpenGL to do the depth testing for you. Of course this doesn't necessarily mean that your game has to be 3D - the 2D output can be maintained using an orthographic projection matrix (see link above). The source is available on github if you're curious (there's a link in the video), with a bit of work it might help sort your drawables if you're willing to give up some of your colour data to depth data

8

Graphics / Re: sf::setTextureRect Not Working As Expected?

« on: September 29, 2022, 12:07:23 pm »

The white square problem is usually caused by some unintentional copy of the texture or accidental memory mismanagement. The usual paradigm in SFML is to keep textures external from the drawable classes which use them, so that copying the drawable won't make a copy of the texture. Often some sort of resource management is used. SFML also provides an interface for creating custom drawables such as a Player class in a consistent way by inheriting sf::Transformable and sf::Drawable, which would look something like this:

class Player final : public sf::Transformable, public sf::Drawable
{
public:
    void setTexture(const sf::Texture& texture)
    {
        m_sprite.setTexture(texture);
    }

    void setTextureRect(sf::IntRect rect)
    {
        m_sprite.setTextureRect(rect);
    }

private:
    sf::Sprite m_sprite;
    void draw(sf::RenderTarget& target, sf::RenderStates states) const override
    {
        states.transform *= getTransform();
        target.draw(m_sprite, states);
    }
};
 

How this works is explained in the documentation. Note that the class does not have a texture member. Rather, you would use it like this:

int main()
{
    sf::Texture playerTexture;
    playerTexture.loadFromFile("test.png");

    Player player;
    player.setTexture(playerTexture);
    player.setTextureRect({ 2,2,100,100 });

    sf::RenderWindow window(sf::VideoMode(800, 600), "My window");
    sf::Clock frameClock;

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

        float elapsed = frameClock.restart().asSeconds();
        if (sf::Keyboard::isKeyPressed(sf::Keyboard::Left))
        {
            player.move(-20.f * elapsed, 0.f);
        }
        if (sf::Keyboard::isKeyPressed(sf::Keyboard::Right))
        {
            player.move(20.f * elapsed, 0.f);
        }


        window.clear(sf::Color::Black);
        window.draw(player);
        window.display();
    }

    return 0;
}
 

With the texture in its own scope (either as in the example or stored in a resource manager) copying drawable classes like Player can be done safely without accidentally copying any textures they use. There is also no need to use new/delete in this example, everything is fine on the stack. And even if there were a reason to use the heap smart pointers would be the way to go.

9

Window / Re: How to get unicode to be typed through sf::TextEntered

« on: September 24, 2022, 10:47:06 am »

Unicode is complicated - see this post: https://stackoverflow.com/a/50407375/6740859

Broadly speaking std::string is mostly compatible with utf-8 but you may need to convert to/from codepoints when used with sf::String. In my experience I've found it best to try and stick to a unicode aware string class (like sf::String which is, admittedly, not the standard library but supports full 32 bit characters) and only convert when necessary, such as reading or writing a text file.

10

Graphics / Re: Any way to optimize 'pixelsArray to GPU' process?

« on: September 21, 2022, 11:18:12 pm »

You can use this overload of Texture::update() to update only part of a texture. And FWIW it's possible to use a vector for your array so you don't have to worry about memory management with new/delete:

std::vector<sf::Uint8> pixels(640*480*4);

texture.update(pixels.data());
 

11

General / Re: Function for loading multiple textures?

« on: September 18, 2022, 12:37:37 pm »

If you're using C++17 the filesystem functions will let you parse files from a given directory. eg

#include <filesystem>
#include <iostream>

for (const auto& file : std::filesystem::directory_iterator("assets/images"))
{
    std::cout << file.path() << std::endl;
}

 

You can do your texture loading with file.path() if it's a suitable image. It might also be worth checking out a resource manager if you have a lot of files.

12

Graphics / Re: Debug .. frame per seconds ..

« on: September 07, 2022, 05:34:05 pm »

Debug builds will always be slower, and this can be particularly noticeable in Visual Studio. If you're using VS, try going to your project properties, make sure you're switched to the Debug build layout, and then go to C/C++ -> Code Generation and change Basic Runtime Checks to Default. It's worth looking at the documentation too, just so you're aware of what the option does which you're changing

13

Graphics / Re: Jittery 98 sprites

« on: August 18, 2022, 10:41:22 am »

Are you testing this in a release build, or is this only in debug?
Also do you have an nvidia card? You could try disabling Threaded Optimisation: https://en.sfml-dev.org/forums/index.php?topic=23708.msg161792#msg161792

14

Graphics / Re: Erase only one rectangleShape

« on: July 23, 2022, 11:12:04 pm »

That's right, for the example I put the FloatRects in the vector directly just to simplify - in your case you would have a vector of Door (or whichever class you like that contains a FloatRect / bounds). The point is that you can use remove_if() to search your entire vector for you without manually looping, and without having to worry about deleting in the middle of a loop.

15

Graphics / Re: Erase only one rectangleShape

« on: July 23, 2022, 04:28:37 pm »

std::remove_if works perfectly for removing all instances which intersect. Here's a CME:

template <typename T>
std::ostream& operator << (std::ostream& out, sf::Rectangle<T> r)
{
    out << "[ " << r.left << ", " << r.bottom << ", " << r.width << ", " << r.height << " ]";
    return out;
}

int main()
{
    sf::FloatRect playerBounds = { 0.f, 0.f, 10.f, 10.f };
    std::vector<sf::FloatRect> doors =
    {
        sf::FloatRect(-2.f, 0.f, 10.f, 10.f),
        sf::FloatRect(-20.f, 0.f, 10.f, 10.f),
        sf::FloatRect(2.f, 0.f, 10.f, 10.f),
        sf::FloatRect(0.f, 20.f, 10.f, 10.f),
    };

    std::cout << "Doors before: " << std::endl;
    for (auto door : doors)
    {
        std::cout << door << std::endl;
    }

    doors.erase(std::remove_if(doors.begin(), doors.end(),
        [playerBounds](const sf::FloatRect& door)
        {
            return playerBounds.intersects(door);        
        }), doors.end());

    std::cout << "Doors after: " << std::endl;
    for (auto door : doors)
    {
        std::cout << door << std::endl;
    }

    return 0;
}

 

And the output:

Doors before:
[ -2, 0, 10, 10 ]
[ -20, 0, 10, 10 ]
[ 2, 0, 10, 10 ]
[ 0, 20, 10, 10 ]
Doors after:
[ -20, 0, 10, 10 ]
[ 0, 20, 10, 10 ]