Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - sidewinder

Pages: [1] 2
1
So my question is if I'm trying to run some SFML code on an integrated graphics card, it gets obvious that its a lot slower just by doing some testing/profiling.

What I'm having trouble with is figuring out exactly what is slower, and how that could be handled.

  • How would one profile what happens on the GPU more specifically, I've used VTune for cpu, is there something you could recommend to understand what is hard on a GPU?
  • Reading up on some games that are working on a intel gpu, what you see a lot is that "the game is more cpu heavy", what should one avoid in SFML to make it easier on the gpu?
  • Finally, is this even worth thinking about  ::)

2
SFML projects / Re: Isometric RTS
« on: July 28, 2021, 03:01:22 pm »
This looks very nice? Any updates? I saw on your github that you still do stuff ;-)

3
SFML projects / Re: Candle - 2D basic lighting for SFML
« on: February 17, 2021, 09:45:16 pm »
Looks nice! How many lights and light blockers can it handle?

4
SFML projects / Re: Selba Ward
« on: February 16, 2021, 08:38:06 pm »
My guess is that this is, as binary1248 put it, a "feature and not a bug".
See the explanation of RT with Shaders on this GitHub issue and the related forum post.

Not sure if Selba Ward could be adjusted to account for RT usage.

Aha, makes sense. It's a bit much to try and reverse engineer the selba ward shaders right now, but now I at least know what I need to do if I want to try this again.

Thanks!

5
SFML projects / Re: Selba Ward
« on: February 16, 2021, 06:03:52 pm »
You need to treat your render texture like a window - that is, create it only once, then call renderTexture.clear() before you draw on it, followed by renderTexture.display() when you've finished drawing.

Seems reasonable, and when/if I use it for real I'll do it that way  :)

I changed it in my experiment and its still upside down. And it works with a regular sprite  ???
I also tried to turn of the shaders with setUseShader(false) and then it works, so the problem seems to be in the shaders.

6
SFML projects / Re: Selba Ward
« on: February 16, 2021, 02:48:08 pm »
Threadomancy incoming!

I decided to give the ElasticSprite a go but for some reason it draws the texture upside down. If I replace it with a regular sprite this does not happen.

The reduced relevant code would look something like this:

UPSIDE DOWN:
Quote
while (window.isOpen())
{
 window.clear();
 sf::RenderTexture pre;
 pre.create(resolutionX, resolutionY);
 //Write lots of stuff to pre
 pre.display();
 sw::ElasticSprite esprite(pre.getTexture());
 window.draw(esprite);
 window.display();
}

NOT UPSIDE DOWN
Quote
while (window.isOpen())
{
 window.clear();
 sf::RenderTexture pre;
 pre.create(resolutionX, resolutionY);
 //Write lots of stuff to pre
 pre.display();
 sf::Sprite sprite(pre.getTexture());
 window.draw(sprite);
 window.display();
}

Is there something I'm not allowed to do with my rendertexture before I write it using the elastic sprite?
 
 



7
Graphics / Square light sources
« on: January 23, 2021, 09:53:16 pm »
Hi,

I was wondering if anyone had done light with shadows that does not originate from a single point (and become circles)

If you know of any examples I'd like to see them. Also if anyone have some ideas of how the equivalent ray-casting would work?

8
SFML projects / Re: Jin Conception 2D Pixel Art JRPG
« on: January 14, 2021, 05:10:16 pm »
Very Nice!!

is all the animations done using pixel sprites or do you do some of them with shaders?

9
You probably need to feed the shader with actual pixel coordinates instead of view positions

Here is how I do something similar:
                       
sf::Vector2i pos = window.mapCoordsToPixel(sf::Vector2f(light.x, light.y));
shader.setParameter("light_position", pos.x, pos.y);
 

Have a look at these two:
Vector2f    mapPixelToCoords (const Vector2i &point) const
Vector2i    mapCoordsToPixel (const Vector2f &point) const
here:
https://www.sfml-dev.org/documentation/2.5.1/classsf_1_1RenderTarget.php

10
Graphics / Re: Rendering via a RenderingTexture
« on: May 10, 2019, 08:54:34 pm »
To which other channels do you refer to, G and B? Do you read the R channel and put them on top?

G and B yes, I just draw them all with sf::BlendAdd

11
Graphics / Re: Maximum capability of VertexArray rendering
« on: May 08, 2019, 01:41:42 pm »
Thanks!

So now I got it working, and I get a pretty good grasp of which parts take the longest.

Just drawing the pre-filled buffer gives me about 1500 fps
Updating the whole buffer gives no real change as you predicted, 7-8 fps
Updating 1/10 of the buffer, 250 fps.

Feels like I can make quite a lot of improvements with this!


12
Graphics / Re: Maximum capability of VertexArray rendering
« on: May 07, 2019, 09:50:04 pm »
Not mentioned here so far, but often times, especially for effects like fire, you don't actually want/need to update all the data from and by the CPU, but instead you can just write a shader. That way you move the fire "calculation" from the CPU to the GPU and you only have to transfer a few vertices or ideally just one position.

Additionally, don't forget that games are usually just one deception after the other. So just because you see other games having implemented X, doesn't actually mean that they did, it's more likely that they just made it look like they did, while applying various tricks to make it look so. ;)

Good insights!

About shaders, I actually used shaders to blur and fade the light, but as I use them its something I apply to the draw like:

window.draw(lightSprite, &shader);

But the way you say "ideally just one position", how would that look? Can you do a draw with just the shader? Or an empty vertexArray or what? Also, can you keep a state in the shader, like previous position on particles and such?

13
Graphics / Re: Maximum capability of VertexArray rendering
« on: May 07, 2019, 05:07:44 pm »
Thanks for the answer!

You can try sf::VertexBuffer, which is the same as sf::VertexArray but which lives on the GPU. However since you have to reupload the data every frame anyway, I doubt it would make a significant difference.

Ah, I see, looking at the documentation I guess this would be the way to do it for example updating only the first and fourth.


sf::Vertex particles[40000];
sf::VertexBuffer buffer(sf::Quads);
buffer.create(40000);

    //Update the first particle
    buffer.update(particles,1080,0);
    //Update the fourth particle
    buffer.update(particles,1080,1080*4);

window.draw(buffer);

 

One weird thing though, when I set the sf::Vertex particles[size]; to a large enough size the whole program refuse to start Do you have any idea why or is that something compiler dependent?

That sounds really high to me. What kind of environment has 100 different lights in the same area?

Maybe :) I was thinking of some diablo 3 -esque scene where lots of spells are filling up the whole screen ;)


You should first decide what effect(s) you want to implement, and then try to find the most efficient way to do it -- the latter depends on the former ;) Not the other way round

You are right ofc, here are the stuff I was trying to implement.

First I did this fire particle effect:


And then I wanted to enhance it a bit with some lighting effects, and I realized that the fps dropped quite a bit compared to the fire. Not unreasonably but I felt that I wanted to know more of that the actual limitations would be, and what was possible.



Buffer seems like the way to go. And an adjustment of my expectations ;)

There is always the possibility of pre-rendering some of the stuff as well, but where is the fun in that?



 

14
Graphics / Maximum capability of VertexArray rendering
« on: May 07, 2019, 01:03:18 pm »
Hello!

First of, I have tried to find the answer to these question in the forums, I can find a lot of people talking around the subject, but no-one that actually answers the questions more then touching the subjects. If there are, please give me the link(s) :-)

I'm playing around with different rendering techniques in SFML and from what I can understand drawing VertexArrays directly would be the most efficient way without resorting to writing yourself in opengl?

When I tried VertexArrays it was a lot quicker than sprites/shapes, but I feel that I cant really grasp what the maximum capability is. So I decided to test this.

Here is my minimal test-code for testing with 1 million particles where each particle is a square or quad:

#include "SFML/Graphics.hpp"
#include <iostream>
using namespace std;

int main(int argc, char *argv[])
{
  //Create objects
  sf::RenderWindow window;
  window.create(sf::VideoMode(1024, 768), "Test");

  //One million rectangle particles are 4 million vertices
  sf::VertexArray particles(sf::Quads, 4000000);

  sf::Clock clock;
  int microsecondsInSecond = 1000000;

  sf::Text text;
  sf::Font font;
  //Change this to an actual font location
  font.loadFromFile("content/VeraMono.ttf");
  text.setFont(font);
  text.setCharacterSize(24);
  text.setFillColor(sf::Color::Red);

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

    //simulate updating the position and color of the particles
    for (int i = 0; i < 1000000; i++)
    {
      particles[i * 4].position = sf::Vector2f(100, 100);
      particles[i * 4 + 1].position = sf::Vector2f(200, 100);
      particles[i * 4 + 2].position = sf::Vector2f(200, 200);
      particles[i * 4 + 3].position = sf::Vector2f(100, 200);
      for (int j = i * 4; j < i * 4 + 4; j++)
      {
        particles[i].color.r = static_cast<sf::Uint8>(255);
        particles[i].color.g = static_cast<sf::Uint8>(255);
        particles[i].color.b = static_cast<sf::Uint8>(255);
        particles[i].color.a = static_cast<sf::Uint8>(255);
      }
    }

    //clear window with black
    window.clear(sf::Color::Black);

    //Draw
    window.draw(particles);
    window.draw(text);
    window.display();

    //Print current aproximate fps
    std::string fps("fps: " + std::to_string((microsecondsInSecond / clock.restart().asMicroseconds())));
    text.setString(fps);
  }
}
 

On a pretty decent desktop computer this gives me an approximate fps of around 7-8. That seems way to low :-/
With 100 000 particles I get around 70.

So three questions:

  • Did I make some mistake in my code that makes it slow?
  • Is there some other way in SFML to make it even faster?
  • Am I naive to think that a million particles each frame should be doable? (I recall people mentioning "drawing millions of vertices" in other threads, but I could have misunderstood)
  • Is one million particles unreasonable in any way? Should I try to rewrite my particle effects so that they use fewer particles?

For a naive example when drawing a circle of light, that could be for example 360 triangles to form up the circle, 360 * 3= 1080. If 100 000 particles is the limit for keeping above 60 fps, that means I could only keep 100 lights on screen at the same time? That seems low...


15
Graphics / Re: Rendering via a RenderingTexture
« on: April 28, 2019, 10:37:21 pm »
I would recommend the full-sized render texture, at least at first. Try it and see. If you have issues, consider other approaches.

Thanks for the answer!
Yeah, that's the one I'm trying now. Seems to work pretty well


Do you want the yellow in your effects? How are you achieving yellow from adding reds together?

Yes, I wanted it to look like fire, it is not completely red, small parts in the other channels produce the yellow when they are put together :)

Here are some other versions of colours:


RBG codes from left to right:
255, 52, 11
11, 55, 255
10, 100, 10


Pages: [1] 2