Messages

1

Graphics / Re: Vertex Array shapes

« on: April 02, 2021, 10:35:32 pm »

Looks like you're trying to draw rectangular outlines using LineStrip....

The diagonals sound like you're connecting two opposite points. Remember that with a line strip every point is connected to the previous one so if you're creating a 'grid' of lines, remember that each vertex much not be diagonal from the previous one.

Chances are, your quad is created (by the sounds of it) by vertices in a zig-zig "Z" shape. Try creating them in order around the rectangle.
If you find that connecting ones are creating diagonals, you may need to add extra vertices in order to trace around the grid to get to the next position instead of just going straight there.

2

SFML projects / Re: Selba Ward

« on: March 28, 2021, 07:29:33 pm »

Yes, I believe this is related to the post linked by eXpl0it3r.

Luckily, there seems to be a simple solution (hack?)! You can invert the texture rectangle in the Elastic Sprite for drawing to a render texture. This is a pretty simple, one-time change although if you need to draw to a render texture and the main window (or even a render texture on a render texture!), you may need to keep switching the texture rectangle.

To flip the texture:
if you use the entire texture - and the texture is set to repeat - you can just negate the height.
if you use a section of a texture, you can add the current height to "top" and then negate the height.

I guess this isn't a big deal-breaker for using Elastic Sprite (or anything with shaders on a render texture) but I suppose it shouldn't be too difficult to add a "flip switch" either


p.s. No problem for the necro. This thread is allowed to be necroed (otherwise there might be multiple threads relating to the same subject)

3

SFML wiki / Re: Rectangular Boundary Collision

« on: March 28, 2021, 07:00:56 pm »

Ah, thanks!

Glad you found some use of this. It's been here for years 

Yes, I'd say it would be best to filter out tests before using it; it's not the best idea to test collision between all objects if they aren't near each other.

One thing to note, however, is that this should be just doing the standard rectangle intersection test unless it's not completely sure of the result so the more complex tests should only be happening if they really need it.

4

Graphics / Re: Trying to use a sf::RectangleShape's Origin for the position of some text.

« on: January 19, 2021, 01:15:31 am »

I don't know why you're using the rectangle's origin (in the rectangle's local co-ordinate system) for the text's origin (in the text's local co-ordinate system).

If you want the origin to be the centre for both, set that origin based on each object size (and position offset for text). Then, once the origins are correctly set, you can set both of their positions to the same position and they would both have their centres in the same place (they would be aligned to their centres).

For texts, use the local bounds to calculate where the local origin should be. Remember that not just the size (width and height) but the offset (left and top) should be taken into account.

To set the origin of a text to its centre:

// "text" is the text object
const sf::FloatRect textLocalBounds{ text.getLocalBounds() };
text.setOrigin({ (localBounds.left + localBounds.width) / 2.f, (localBounds.top + localBounds.height) / 2.f });

Important note: this code should be executed whenever (and after) the text string is changed and it's based on the actual text string.
(or simply executed every loop - before it is drawn)

5

Graphics / Re: Trying to Return a sf::Text from class to be drawn in main function

« on: January 17, 2021, 11:51:52 pm »

You're creating temporary fonts, assigning them to texts and then allowing them to be destroyed. Drawing that text then attempts to use the font that no longer exists and results in an access violation.

Fonts must exist as long as they are used.

This means that it - like other (heavy) resources (like images and sound buffers) - should be loaded once (usually in advance, near the beginning) and reused. It should be stored safely and passed (by reference or pointer) around to functions that need them. They should almost never be destroyed!

Basic example:

void drawAText(sf::Font& font, sf::RenderWindow& window)
{
    sf::Text text;
    text.setFont(font);
    text.setString("SOME TEXT");
    window.draw(text);
}

int main()
{
    sf::Font font;
    if (!font.loadFromFile("font.ttf"))
        return EXIT_FAILURE;

    sf::RenderWindow window(sf::VideoMode(800u, 600u), "");

    while (window.isOpen())
    {
        // handle events here as usual

        window.clear();
        drawAText(font, window);
        window.display();
    }
}

6

Graphics / Re: Array of different Shapes

« on: January 17, 2021, 09:53:53 pm »

Each derived type is a type of its own so multiple shapes cannot be in the same vector; a vector can only store things of the same type. Storing just the base type doesn't allow the derived type to be stored as a base type "is not" a derived type.

This can be "solved" using pointers. That is, the vector would be a pointer all of the same type and then they would have to "converted" to the correct type later when actually used. Although it's possible, it's very confusing and extremely error prone.

The easiest and safest solution is, as you already suggested, is to create separate vectors of each type of (derived) shape and just them as required (re-create the shape on the other vector when changing shape type, for example).

7

Graphics / Re: Rotate a Image around its center/Axis

« on: December 28, 2020, 07:29:08 pm »

Just as a general rule to remember, transformables always rotate around its origin.

So, yes, as said above, if you want to rotate around its centre, its origin must be at its centre.

Indeed, all transformations are based around the origin: scale will scale outwards from its origin and setting its position technically sets where its origin will be (this means that you will likely need to reposition it after changing its origin - set its new position to where you want its centre to be, for example).

8

Window / Re: Opening windows hidden

« on: December 27, 2020, 05:13:27 pm »

You could create the window tiny (1x1, for example) and quickly move it offscreen and resize it. You can then set it to be 'hidden'. This can be much less noticeable than working with a full size window.

That said, it looks like the ability to open a window without it being visible could well be available in the future...
https://en.sfml-dev.org/forums/index.php?topic=23578.0

9

Graphics / Re: 2D lighting with SFML

« on: December 17, 2020, 12:04:24 am »

Yes, you need to clear, draw and display both the render texture and the window.

You are welcome! Pleased to help

10

Graphics / Re: 2D lighting with SFML

« on: December 16, 2020, 09:21:49 pm »

You could render that triangle fan (as white) to a render texture (the same size as the window) and then draw that render texture to the window with a multiplicative blend mode, leaving everything as-is where it is white and turning to black anything that is black.

11

Feature requests / Re: Why is there no TriangleShape?

« on: December 09, 2020, 06:24:16 pm »

It's also worth noting that the provided shapes are quite strictly bound by a 2D rectangular area and can only be in one form within it. Triangles can be in many forms within that rectangular area.

12

General / Re: Large delays with window visuals updating despite timer not reporting any gaps

« on: December 08, 2020, 06:59:28 pm »

One thing I can see is that you are using the timer's elapsed time to measure the frame but you may also have reset it previously.

13

Pull Requests & Testing / Re: Audio effects: Reverb, chrous, delay etc

« on: November 17, 2020, 01:37:32 pm »

Sounds great!
If they are now available, it makes sense to include them, for sure.

14

Graphics / Re: Rendering multiple sprites at once (white square problem)

« on: November 17, 2020, 01:25:56 pm »

Remember that when you use a std::vector, they can be moved when resized. This means that any pointer to a vector's elements are no longer pointing to the correct thing.
When you set a texture, you are assigning a pointer to that texture.

If those elements are moved (along with their textures), you will need to re-assign the pointer (re-set the texture). Basically, add them all to the vector first, then set the textures. Or, reserve or pre-size the vector so that it doesn't get moved.

15

Window / Re: how scale window

« on: November 17, 2020, 01:20:36 pm »

As part of the tutorial linked above, see https://www.sfml-dev.org/tutorials/2.5/graphics-view.php#defining-what-the-view-views

You will likely want a view that starts at (0, 0) with a size of 320x240, right?