Messages

1

Graphics / Re: Optimising CPU to GPU data transition

« on: September 10, 2023, 03:31:51 pm »

200+ FPS would indeed suffice, but my concern was that if the CPU-GPU data transition is the bottleneck, than it will be harder to notice a performance drop after implementing the automaton's processing logic, which should be the bottleneck instead, since it's the core system of my game.

The VertexArray solution does indeed seem interesing. I assume, the performance concern that have been mentioned here https://en.sfml-dev.org/forums/index.php?topic=11550.0 is irrelevant since there will be only one draw call on the entire VertexArray. It does seem that this would consume a bit more RAM instead, adding the vertex positions (although unchanged) to the total amount of data. Maybe it's possible to optimise it by excluding empty cells from it but I'd like to assume the worst case scenario by default, where the screen is always full of particles (not necessarily moving).

I can't let the shader handle the automaton's logic and my particles are represented in full RGBA colour, meaning I won't be able to use single bit per cell. Writing a whole codec just to send data between the two devices sounds like an overkill and a hacky solution, but that's my intuition speaking.

Using the shader actually seems like the most valid solution that I'm definitely going to try first. Additionaly, I assume that I'd be able to pass values higher than 0-255 range allows, which might be useful later to add special effects (e.g. glowing for lava particles with R value higher than 255) using shaders.
I've seen the same recommendation about using the shaders when I was implementing this system with Unity ECS, but in the end it turned out that their Burst-compiled code can operate on par with GPUs which made this issue mostly irrelevant.

Thank you for such a detailed reply!

2

Graphics / Optimising CPU to GPU data transition

« on: September 03, 2023, 04:27:25 pm »

Hello.
I recently started to explore SFML and my little project is to create a game based on falling sand simulation (e.g. like Powder Toy or Noita).
My progress stumbled upon the issue of sending images from CPU to textures on GPU. My curent setup is to change the image every frame according to the rules of the cellular automaton, i.e. edit an instance of sf::Image (e.g. 4096² pixels ins size) and send the result to the corresponding instance of sf::Texture by using Texture::Update(sf::Image&) function.
This texture is used by many sf::Sprite instances that are used to render different rects of that texture, no problem with that.
I would like my in-game particles (each represented by a pixel on the image) to be moving as smoothly as possible, updating the aforementioned texture every frame. My problem is that sending data from CPU to GPU is quite costly to perform every frame: my DIY FPS-meter shows ~205 FPS against ~3–4k FPS when the texture update isn't called but the automaton is still working.
Naturally, I would like the automaton's logic processing to be the bottle neck of my app, but right now it's the CPU/GPU data exchange, which I have no idea how to deal with using the provided SFML API. I am already using only one single texture instance, but I can't go lower than 1 update per frame, since it's the whole point of visualising a cellular automaton.
I tried to search for existing paint applications on SFML, because I assumed they would be updating canvas every frame too, but they seem to be using line primitives for drawing with mouse rather than changing the pixels in the image every frame. I also looked for existing SFML falling sand simulations but what I found is using rectangle primitives for each separate particle which obviously doesn't fit my needs.