Messages

31

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 ]
 

32

Graphics / Re: Erase only one rectangleShape

« on: July 21, 2022, 11:30:57 am »

As exploiter says, erasing mid-iteration is not a good idea. Instead consider std::remove_if.

doors.erase(std::remove_if(doors.begin(), doors.end(), Predicate(const Door&)), doors.end());
 

Predicate is a functor, std::function, function pointer or lambda that returns true on a condition when an element should be removed. Each element in your vector is automatically passed to it as a parameter. In your case you can use a lambda to decide if the door collides

[playerBounds](const Door& door)
{
    return playerBounds.intersects(door.getGlobalBounds());
}
 

33

Graphics / Re: Collision dont work exactly

« on: July 21, 2022, 11:23:17 am »

If it helps I wrote a post some time back which covers basic collision detection with SFML: https://trederia.blogspot.com/2016/02/2d-physics-101-pong.html

34

Graphics / Re: Touch joystick border radius

« on: June 22, 2022, 10:40:21 am »

Regular circle-circle collision detection will work (there are plenty of tutorials out there), but instead of making sure the minimum distance between centres is always >= the sum of the radii, you make sure the *maximum* distance is <= large radius minus the small radius

35

Audio / Re: music sound lowered

« on: May 10, 2022, 10:55:24 am »

It's an automatic gain control applied by OpenAL to try to make sure that the total volume doesn't exceed an internal limit and start to distort. It can even vary between speaker setups, I've noticed the effect is much more noticeable with 2 channels than it is for surround.

I've experimented a bit and found that the best way to try and counteract the effect is to lower the gain of OpenAL sources - which is the same as setting their volume in SFML. As a starting point assuming that the internal max gain is 100, set both of your sources to 50. If you play both at once you should find that the music shouldn't get as quiet, if at all, when both sounds play, because the total gain is <= max gain.

These numbers are a rough guess, and to find the perfect amount of gain with minimal quietening effect you'll have to experiment, but it should demonstrate what I mean. A good estimation for an average gain is to take the max gain and divide it by the number of sounds you expect to be playing at any one time.

Of course the overall volume will now sound quieter. This can be compensated for by increasing the listener volume, but it also helps to set the actual level of your audio files (in an audio editor) to as loud as possible (or at the very least make sure they all have the same level), then let OpenAL/SFML attenuate as needed.

HTH

36

Graphics / Re: Can't draw 2 big textures

« on: May 04, 2022, 07:35:39 pm »

12000px is *very* large for a texture and your GPU might not support it. You can check the max texture size your hardware supports with sf::Texture::getMaximumSize() https://www.sfml-dev.org/documentation/2.5.1/classsf_1_1Texture.php#a0bf905d487b104b758549c2e9e20a3fb and split it into smaller textures if you need to.

For southpark style animation a better choice might be to use software like Spine or Spriter

37

General / Re: link errors

« on: April 05, 2022, 10:26:02 am »

To clarify: It doesn't matter if Visual Studio itself is a 32 bit or 64 bit application. Either version can compile 32 or 64 bit programs. You just need SFML to match the program you're compiling.

38

General / Re: link errors

« on: April 04, 2022, 11:13:38 pm »

I downloaded SFML-2.5.1-windows-vc14-32-bit from the SFML site.

 I'm compiling for debug x64

You can't mix 32/64 bit libs/build. You either need the 64bit libs, or switch to a 32 bit build 

39

Graphics / Re: sf::RenderTexture not working properly

« on: March 31, 2022, 05:31:49 pm »

A couple of things:
First I can't see where you call display() on the render texture, this could well be the problem. However it might also be worth doing the drawing with each target sequentially:

texture.clear();
....
texture.display();

window.clear();
....
window.display();
 

Also rather than use a reference to the active target, use a pointer, as it's possible you may end up copying something at some point, and SFML will create a new texture (and potentially even discard the old one) if a RenderTexture is copied, which could end up throwing things out of sync.

40

Window / Re: Failed to activate OpenGL: the handle is invalid

« on: March 12, 2022, 11:18:03 am »

If you're going to require a thread for each window then the next best thing is to try and isolate the threads as much as possible, so that you don't need to share (memory space) data between them. X Windows (https://en.wikipedia.org/wiki/X_Window_System) uses a client/server architecture so you might gain something by that approach.

Run the logic of your application in its own thread, and use it to create a 'server'. You can then create individual threads for each window you need, completely self containing the drawing and event handling, and then communicate with the server thread using a library such as Enet (http://enet.bespin.org/). Forward events from your window to the server, process them, then have the server broadcast the results to all connected windows (clients) for them to draw.

In this situation you also get the added bonus that your main logic processing is effectively run in a separate thread to graphics and rendering.

Will this introduce lag? Yes, some, but if it's all running on a local machine it will likely be negligible. Depending on your application, it will be fine, for example if you're running some kind of graphing simulation. Turn based games will probably work very well too (I know this from experience https://fallahn.itch.io/vga-golf ). For fast action games there are tried and tested methods which can be implemented to negate perceivable lag, should it be deemed necessary:
https://www.gabrielgambetta.com/client-server-game-architecture.html
https://gafferongames.com/categories/networked-physics/

HTH

41

Graphics / Re: How to color the lines of a Vertex Array

« on: March 03, 2022, 10:39:47 am »

sf::Vertex has a constructor which takes a colour as a parameter, as well as exposing its colour member so you can set it directly:

https://www.sfml-dev.org/documentation/2.5.1/classsf_1_1Vertex.php#a70b0679b4ec531d5bd1a7d0225c7321a
https://www.sfml-dev.org/documentation/2.5.1/classsf_1_1Vertex.php#a799faa0629442e90f07cd2edb568ff80

42

General / Re: SFML shader problem `no matching function for call to `mix(vec4, vec4, error)'`

« on: March 03, 2022, 10:37:04 am »

(r - expand) / (1 - expand)

Depending on your driver/implementation the '1' maybe interpreted as an int, causing an implicit conversion. Try

(r - expand) / (1.0 - expand)

You could (and probably should as general good practice) also include the #version 120 directive at the top of your shader, to make sure you're getting the GLSL version SFML expects.

43

Graphics / Re: Resizing of an Image in SFML 2.5

« on: February 15, 2022, 04:20:21 pm »

Once you have your sprite and have resized it you can draw it to sf::RenderTexture then use sf::RenderTexture::getTexture()::copyToImage() to get it back to an image object. It can be slow but might be fast enough for what you need.

44

General / Re: Rectangle bottom collision issues

« on: February 06, 2022, 04:48:33 pm »

Detecting the collision and stopping falling is not enough on its own. You also have to calculate how much overlap (aka penetration) the collision created and move the character back by that much, so that it lines up with the platform. I wrote a post about simple collision detection some time back, it may be useful here.

https://trederia.blogspot.com/2016/02/2d-physics-101-pong.html

45

Graphics / Re: unefficient drawing

« on: February 05, 2022, 12:38:26 pm »

You can probably alleviate the drawing a bit by rendering each point as a vertex in a vertex array, with the primitive type set to points.

    sf::VertexArray vertexArray(sf::PrimitiveType::Points);

    while(window.isOpen()){
        window.clear();
        while(window.pollEvent(event)){
            if((event.type == Event::KeyPressed) && (event.key.code == Keyboard::Enter) && (!fullscreen)) {
            fullscreen = true;
            window.create(VideoMode(1920, 1080), nameProject, (fullscreen ? Style::Fullscreen : Style::Resize|Style::Close));
         }
            else if((event.type == Event::KeyPressed) && (event.key.code == Keyboard::Escape) && (fullscreen)) {
            fullscreen = false;
            window.create(VideoMode(1920, 1080), nameProject, (fullscreen ? Style::Fullscreen : Style::Resize|Style::Close));
         }
            if((event.type == Event::KeyPressed) && (event.key.code == Keyboard::Space) && (fullscreen)) {
                pause = !pause;
         }
            if(event.type == Event::Closed){
                window.close();
            }
        }

        float dt = gameClock.getElapsedTime().asSeconds();
        gameClock.restart();

        vertexArray.clear();

        for(int i=0; i<player.size(); i++){
            if(fullscreen && !pause){
                player.x+=player.vx*dt;
                player.y+=player.vy*dt;

                if(player.x < player.r){
                    player.x += 2*(player.r-player.x);
                    player.vx *= -1;
                }
                else if(player.x > window.getSize().x-player.r){
                    player.x += 2*(window.getSize().x-player.r-player.x);
                    player.vx *= -1;
                }
                if(player.y < player.r){
                    player.y += 2*(player.r-player.y);
                    player.vy *= -1;
                }
                else if(player.y > window.getSize().y-player.r){
                    player.y += 2*(window.getSize().y-player.r-player.y);
                    player.vy *= -1;
                }
            }
            if(fullscreen){
                player.body.setPosition(player.x-player.r, player.y-player.r);
                vertexArray.append(sf::Vertex(sf::Vector2f(player.x-player.r, player.y-player.r)));
            }
        }

        window.draw(vertexArray);
       
        window.display();
        Sleep(1);
    }
 

This will batch all of your points into a single draw call.