Recent Posts

21

Graphics / [solved] shifting center on rotation

« Last post by djarkan on April 20, 2024, 01:42:17 am »

hi

i have my drawables witch have their centre shifted 1 pixel x and y when i rotate them
i choosedodds width and height to have a real center point for the rotation
sprite are 49 * 35 i use setorigin(24,17)
tried 48 * 34 in texturerect or vertexbuffer but no

i don't know how to get rid of that. tried with

made a simple program with sf::sprites and it's the same

thx

original on bottom rotated above. red dot should always be in black roof

#include <SFML/Graphics/RenderWindow.hpp>
#include <SFML/Graphics/CircleShape.hpp>
#include <SFML/Graphics/Sprite.hpp>
#include <SFML/Graphics/Texture.hpp>

int main()
{
    sf::RenderWindow window(sf::VideoMode(300, 300), "Test divers", sf::Style::Close);

    sf::Texture texture;
    texture.loadFromFile("cars.png");
    sf::Sprite car;
    car.setTexture(texture);
    car.setTextureRect(sf::IntRect(0,0,49,35));
    car.setOrigin(24, 17);
    car.setPosition(150,150);
    sf::CircleShape circle(1);
    circle.setFillColor(sf::Color::Red);
    circle.setPosition(car.getPosition());

    window.clear(sf::Color::White);

    window.draw(car);
    window.draw(circle);
    car.setPosition(150,90);
    car.setRotation(180);
    window.draw(car);
    circle.setPosition(car.getPosition());
    window.draw(circle);
    window.display();

    while(1) ;
}

22

General / Pass int/char array to sf::Uint8 array?

« Last post by LakySimi1 on April 19, 2024, 11:52:48 pm »

Hi everyone,
there is a way to pass an int or maybe better, a char array to sf::Uint8* pixels = new sf::Uint8[WIDTH * HEIGHT * 4] ?

Honestly, i'm ignorant, i want to build the array of pixels in a classic int array, which is faster to manipulate, and then show it on screen.

Right now instead i am manipulating pixels.

23

Graphics / Re: Clarification from the sprite tutorial

« Last post by Hapax on April 18, 2024, 09:35:46 am »

Once you've 'sorted' the textures to avoid switching and all is left to do is group (batch) together the objects to avoid multiple draw calls, you can use this simple batcher (that I created):
https://github.com/SFML/SFML/wiki/Source%3A-Simple-Sprite-Batcher

It's simple to use (sprites only) and should always reduce time used to draw. The more sprites to batch, the more effective the batcher is!
Remember, though, that you can only batch sprites that use the same textures.

24

Graphics / Re: Clarification from the sprite tutorial

« Last post by Nafffen on April 17, 2024, 09:25:01 pm »

Very clear thank you very much !

25

Graphics / Re: Clarification from the sprite tutorial

« Last post by Hapax on April 17, 2024, 07:59:23 pm »

I don't know the technically exact cost but larger textures should not incur a significantly larger cost to switch to or from - if any at all - than a smaller texture.
It's the switching that's costly but why it's costly and how costly it may be may or may not be partly related to its size.

The 'solution' to your question is a third option, re-order so that all the draws with the big texture are drawn next to each other (or even as one) and the small texture together the same way.
If they 'must' be drawn in this way, consider adding the small texture to the big texture.
With the 'alternating small textures', you could always combine them both into one, reducing the switching of textures and potentially reducing all of those alternating draw calls to just one.

Just remember, if you're trying to be efficient with your textures, use one at a time (avoiding switching) and draw multiple objects using that texture at once (avoiding excessing draw calls).

So, to provide a possible solution to your original post:
place the textures for both sprites into one image (you can do this programmatically if you'd like), and then load it to a texture. Then, draw each sprite with that same texture but use the texture rectangle (textureRect) to specify which part.

26

General / Re: Why anything after "while (window.pollEvent(Event))" kills framerate ?

« Last post by LakySimi1 on April 17, 2024, 07:40:36 pm »

I also want to make some raytracing experiment but, since the infinitely less complex raycasting is so slow on a 4GHz machine, and it may really means that the pixel-per-pixel approach is wrong, i give it up.. sadly.
I'll share a screenshot of my raycasting engine here:

(click to show/hide)

Multithreading may be an aid, but not a solution i think, since og Doom run flawlessy on a 100MHz 486.. how the heck does it achieve that? Surely it is also GPU based but still, i think it has a lot to do with single pixel drawing.. right?
I kinda know that i have to use the parallel computing o f the GPU.. but how? The only tutorial i find online seems to have the same approach of mine: fill and array and send it to graphic memory.

Compute shaders are totally new to me.. got to search!

27

General / Re: Why anything after "while (window.pollEvent(Event))" kills framerate ?

« Last post by kojack on April 17, 2024, 01:23:22 am »

I like pixel rendering too, but mine tend to be slower (like raytracing) where even 1fps would be great.

A few possibilities:
- multithreading. My understanding is raycasters are usually pretty independent between columns, so dividing the screen into vertical stripes based on core count could help without too much complexity.
- compute shaders. SFML doesn't have them natively, but they let you write algorithms slightly closer to typical CPU style but with GPU backed performance (they don't have the same restrictions as regular shaders).

28

General / Re: Why anything after "while (window.pollEvent(Event))" kills framerate ?

« Last post by LakySimi1 on April 16, 2024, 07:25:16 pm »

A quick calculation shows 1280 x 720 x 250fps means each pixel has only 4ns to be rendered.
Considering a single cpu cycle on a 4GHz cpu is 0.25ns, there's not much head room.

This calculation really makes sense to me, 17.4 cycles per pixel, this perspective help to understand.

Therefore, is a bad news, since i really like to draw pixel-per-pixel, maybe it is even foundamental for a raycasting engine.. any suggestion to achieve the single-pixel draw flexibility?

29

Graphics / Re: Clarification from the sprite tutorial

« Last post by Nafffen on April 13, 2024, 11:19:26 pm »

Hey, thank you for your reply !
Just a following question, is the 'cost' of that texture change related to the size of the texture ?
For example, would it be more efficient to :
- have a big single texture for multiple objects but alternately used with other small textures (Big texture -> Small Texture -> Big Texture -> Small texture)
- have many small textures and alternately called them (Small Texture -> Small Texture -> Small Texture -> Small Texture -> ...)

30

Window / Re: Restart Window inside isOpen loop

« Last post by eXpl0it3r on April 12, 2024, 06:45:08 pm »

If you close and directly re-create the window, you won't just drop out of the loop, but by the time you hit the while condition again, it will already be reported as open again, so you won't leave the loop