Messages

46

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.

47

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

48

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

49

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.

50

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.

51

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

52

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.

53

General discussions / Re: Verifying Claims Made in an Article : SFML Cannot Do 3D?

« on: January 24, 2022, 10:45:01 am »

I've managed to render 3D models using the SFML graphics module with some shader trickery, and by forcing normal/depth data into the colour property of sf::VertexArray - and made a couple of games with that technique:

https://fallahn.itch.io/did
and
https://fallahn.itch.io/purcitop-garden

The gist of it is to replace the model/view/projection matrices with your own in a custom vertex shader, and to store the normal vector in the vertex RGB channel, and vertex z-depth as a normalised value in the vertex alpha channel. It kinda works, although to be honest the amount of OpenGL you need to learn to understand how SFML works under the hood means it's probably not worth the effort (other than the learning exercise) and I should probably just use OpenGL directly for the performance gain 

If you're curious source is available here: https://github.com/fallahn/osgc/tree/master/did and here https://github.com/fallahn/osgc/tree/master/lightmapper for a model format converter I made to go with it (yes, I even went as far as to create a specific model format...)

54

Graphics / Re: Transformations not being applied to the points of the vectors

« on: December 04, 2021, 10:26:45 pm »

You most likely want to use getTransform() (inherited from sf::Transformable) with your RenderStates used to draw the array:

https://www.sfml-dev.org/tutorials/2.5/graphics-vertex-array.php#creating-an-sfml-like-entity

55

Graphics / Re: [SOLVED] Dissolve Sprite Shader Not Working When Using Sprite Sheet

« on: October 27, 2021, 12:10:51 pm »

Your best bet is to add 2 uniforms for texture size and texture rect size, and set them each time you draw a sprite. This is probably also applicable if you try to build on mac (and possibly linux) as they require a core version of OpenGL and a declaration of #version 120 at the top of your shader. (Windows drivers often supply a 'compatibility' context which is why your current solution works for you) textureSize() requires #version 130 or greater, and would therefore become unavailable.

If you want to use the graphics module on OS X, you are limited to using a legacy context which implies OpenGL version 2.1.

https://www.sfml-dev.org/tutorials/2.5/window-opengl.php

https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/textureSize.xhtml

#version 120

uniform sampler2D source;
uniform sampler2D noiseTexture;
uniform float dissolveAmount;
uniform vec2 u_textureSize;
uniform vec2 u_rectSize;

void main()
{
        vec2 textureCoordinates = gl_TexCoord[0].xy;
       
        float edgeThickness = 0.1;
        vec4 edgeColor = vec4(255, 0, 0, 100);
        float noiseTiling = 0.8;
       
        vec2 textureScale = u_textureSize / u_rectSize;

        ...
}

 

56

Graphics / Re: Use SFML in a video processing pipeline - use offscreen buffer

« on: October 11, 2021, 11:02:05 pm »

Thats an image buffer of

uint8_t * pixels

a. Copy image buffer to Texture
 

void sf::Texture::update        (       const Uint8 *   pixels  )

b. Render using SFML to texture

c. Copy sf::Texture to sf::Image

or
a. Use sf::Image with you buffer copied to sf::Image
b. Copy sf::Image to sf::Texture
c. Copy sf::Texture to sf::Image


Are these the two options you described ?

That's correct. SFML uses glGetTexImage under the hood:
https://github.com/SFML/SFML/blob/master/src/SFML/Graphics/Texture.cpp#L369

(or glReadPixels if using GLES)

and glTexSubImage2D for uploading
https://github.com/SFML/SFML/blob/master/src/SFML/Graphics/Texture.cpp#L425

This might be fine for your needs (I've used it for rendering the output of emulators for example) but it will of course start to suffer with larger video resolutions. You can only really know for sure by testing it out 

57

Graphics / Re: How to draw a buffer as a line

« on: October 10, 2021, 04:56:44 pm »

Assuming your buffer is a vector or an array of bytes you can use sf::Texture::update()

https://www.sfml-dev.org/documentation/2.5.1/classsf_1_1Texture.php#ae4eab5c6781316840b0c50ad08370963

to upload it to a texture.

58

Graphics / Re: How do i modify the alpha of a textured vertex entity sf::Quad?

« on: October 09, 2021, 11:28:17 am »

This should actually behave as you expect - the vertex colours are multiplied (after being normalised) with the texture colours. So a vertex alpha of 0.5 (127) should make a texture colour alpha 0.5 (if it started  as 1 aka 255), 0.25 if it was 0.5 and so on. If the alpha of the texture is already 0 it should remain so (0 * 0.5 == 0).

Are you using the correct blend mode, which should be sf::BlendAlpha?

Sharing some of your code might also help

59

Graphics / Re: Use SFML in a video processing pipeline - use offscreen buffer

« on: October 09, 2021, 11:09:09 am »

If you can, use the sf::Image as the buffer, it is essentally a wrapper for std::vector<uint8>, or update an sf::Texture directly from your existing buffer, to prevent making an unnecessary copy of it:

https://www.sfml-dev.org/documentation/2.5.1/classsf_1_1Texture.php#ae4eab5c6781316840b0c50ad08370963

Once your buffer is copied to the texture it can be rendered in the same way as any other sf::Texture/sf::Sprite combo, presumably including your video overlays.

You can return the render texture to an image with sf::Texture::copyToImage() although it's not particularly swift:

https://www.sfml-dev.org/documentation/2.5.1/classsf_1_1Texture.php#a77e18a70de2e525ac5e4a7cd95f614b9

At this point I'd be tempted to use some OpenGL directly to copy the output stright to your buffer - although it's worth trying first to see what kind of performance you get.

60

Graphics / Re: sf::Text::setString() doesn't work for inconstant integers

« on: October 09, 2021, 11:00:01 am »

Try

FPS = to_string(int(1.f / *dt))

Even if that's not the solution it always helps to be explicit with your constant types (1, 1u, 1ul, 1.f, 1.0 etc...) to be better sure than implicit conversions like this.

As a side note it's not really necessary to pass dt as a pointer, when passing by value will do, if only because it'll be copying a smaller 32bit float float instead of a 64bit pointer  Here is an interesting discussion on the topic: https://stackoverflow.com/questions/270408/is-it-better-in-c-to-pass-by-value-or-pass-by-constant-reference and one, for when you do pass by reference, on const correctness: https://isocpp.org/wiki/faq/const-correctness