Messages

31

General / Re: I'm losing my mind implementing a fixed frame rate.

« on: February 07, 2024, 04:28:36 pm »

No, you're right.
The previous position can be created and copied from the current position at the start of each loop as I suggested here as it's a small variable; it can be const actually!
The Kairos example, however, is based on the idea that when it is scaled up, most likely would be better to be created once.
For example, if, instead of a single position, you were to store every position of everything as well as everything's rotation, colour, size and many other things (including things involving statistics or other information) in one place (as you likely would when using the "time state" idea), this should probably be only created once and updated often. (you would have two of these objects: current and previous; maybe three with one having all interpolated values for that frame)

Since you already found Kairos, why are you not using it?

32

Graphics / Re: RectangleShape.getPosition always returns 0 for value

« on: February 04, 2024, 01:03:56 pm »

There is no code here that actually alters "box" so it's not clear as to if there's an issue elsewhere.

Could printf be an issue here?

Consider adding brackets to your bool assignments as it's not perfectly clear the intention of the code.

SFML has in-built rectangle testing:

bool isIn = box.getGlobalBounds().contains(mPos);

I notice that mPos is integers so it's likely that this is a pixel location (mouse, probably?). Remember to convert this position to the view before using in world co-ordinates:

sf::Vector2f position(window.mapPixelToCoords(mPos));

33

General / Re: I'm losing my mind implementing a fixed frame rate.

« on: February 04, 2024, 12:55:26 pm »

It's important to realise that "position" is never aware of what the graphics are doing. It's the thing that is updated and should not affected by any of the "graphics effects", which is what interpolation is.
This means that "position" should not be set to the circle's position as the circle has been adjusted by interpolation. The position value should continue as if interpolation never happened. The interpolation is only added as an "visual effect" to adjust what we see; it shouldn't be a part of the logic (the actual position).

To fix this, remove "position = circle.getPosition();". The circle should not be affecting what position does.

Shouldn't the "within main loop" section be within the loop?



After that, you could consider adding vertical sync to reduce the number of actual frames. The good thing about this setup is that the logic will not change at all; it will still make the same identical calculations in the updates because the amount of time processed is always the same, regardless of how long it took since the last frame. The only calculations that change are visual (the interpolation) and these should not be affecting the actual logic. If vertical sync isn't an option, you could always use setFramerateLimit.

34

General / Re: I'm losing my mind implementing a fixed frame rate.

« on: February 03, 2024, 06:12:04 pm »

It's worth noting that using a fixed time step and making it independent of the frame rate means that you care much less about the frame rate as the logic itself it always going to be done in the same step of time and therefore limits can be set based on expected values.

Interpolation is probably the most complicated step.

First thing I notice is that you're moving the actual position of the circle based on the alpha. This movement should only be done as part of the update. The only thing that should be done outside of the update is 'temporary' adjustment for the render.
So, you could move it, draw it and move it back.

Interpolation, by the way should be on actual positions. That is, to do it, you require the current position, its previous position and the length of time that the frame took.
You take the alpha as already you did well.
Then, interpolate between the previous and current position.
Note that it's easier to store the information separate to the circle.
Maybe something like this:

// setup
sf::Vector2f position(0, window.getSize().y / 2); // this is the position of the circle that you are moving

    // within main loop
    sf::Vector2f previousPosition();

        // within fixed step update
        previousPosition = position;
        position += direction * speed; // we now have both a current position and a previous position and they're different

    // interpolation (still within main loop, before drawing)
    sf::Vector2f interpolatedPosition((position - previousPosition) * alpha); // you already have an "alpha" value ;)
    circle.setPosition(interpolationPosition);

Note that this means your interpolated position is always slightly behind the actual position giving up to a frame of lag. This is explained in Fix You Timestep.

Saving the position and previous position is a good way to understand how the interpolation works because for everything that updates, there needs to be a current and previous version. Side note: the current and previous values are spoken of as "states" in Fix Your Timestep so the current state is all of the current values and previous states is all of their equivalent previous values.

Note that extrapolation is different because, although it removes the lag, it does so by guessing where it's going to go. If it changes direction, the extrapolation was wrong and the movement jerks.

Interpolation is the way to go for sure

Side note: the previous values should be updated in the timestep loop as shown so that the alpha should always be within the range of a fixed step (0 - 1).

35

Graphics / Re: LineStrip VertexArray and ConvexShape problem

« on: February 03, 2024, 05:39:00 pm »

I encountered a runtime error. I wanted to provide more details, but I believe you've already understood the situation.

What was the runtime error? Did you catch it and output the message?

What I'm trying to do is allowing the user to input corner information as a percentage, and then I scale these percentage points using setSize() by multiplying each point with a scalar value. I want to draw inner and outer arcs between these scaled corners based on user preferences. Additionally, I'm rounding each corner both inward and outward, and I've handled all of this using trigonometric calculations. Everything is actually working fine; the only issue arises when drawing inner concave arcs. The problem occurs as the apex of the arc approaches the center of the shape. Interestingly, this problem is specific to inner concave arcs. Moreover, when I tried the code from GitHub, I encountered a runtime error. I wanted to provide more details, but I believe you've already understood the situation.

You can also create this exact shape with triangles quite simply yourself. You can split it into vertical pieces (vertical stripes where the top is at an angle). So, the bottom line would have as many points on that line as the curve has. This makes it a lot closer to a graph display (I'm actually currently working on some graph stuff at the moment and the bar graph is pretty much ready and would solve this, I reckon, so look out for that soon!). Basically, you can use separate triangles or a triangle strip (if careful) for that.

Another method would be to create triangles between each point of the curve, the previous point of the curve and a bottom corner (the closest bottom corner). You may need a triangle to fill the bottom corners and the central point of the curve.

EDIT:
Now, you can try Zuhyou. Use the Line (graph) and switch on area and switch off line. Then, you just set the values of the top part to form the curve. Basically, you're settings the values to create the line of the top. Note that Zuhyou's Line uses fixed steps between each value.

36

Graphics / Re: Drawing Vertex Array with big Texture

« on: January 29, 2024, 03:34:32 pm »

Those ArrayTextures sound like a cool feature, I must admit. I'd not heard of them before!

37

General / Re: SFML only read and set uniform in GLSL Vertex Shader

« on: January 29, 2024, 03:33:07 pm »

Not at all. You're welcome and hope it helps!

38

General / Re: SFML only read and set uniform in GLSL Vertex Shader

« on: January 29, 2024, 03:10:29 am »

If you want a shader to have both a vertex shader and a fragment shader, you specify them together:

shader.loadFromFile("some_directory_to_vertex", "some_directory_to_fragment")

see here for more info:
https://www.sfml-dev.org/documentation/2.6.1/classsf_1_1Shader.php#ac9d7289966fcef562eeb92271c03e3dc

Note: the reason there's no semi-colon in my line of code is that this method should be used as a conditional. i.e. the return value of it should be tested
e.g.

if (!shader.loadFromFile("some_directory_to_vertex", "some_directory_to_fragment"))
    return EXIT_FAILURE;

39

Graphics / Re: Drawing Vertex Array with big Texture

« on: January 28, 2024, 07:00:50 pm »

Haha! I checked the master to see if that issue was around but didn't think to check before then. I'm still using 2.6.0 so you can probably ignore my ignorant post above.

40

Graphics / Re: Drawing Vertex Array with big Texture

« on: January 28, 2024, 05:37:32 pm »

sf::Texture::getMaximumSize()

I've noticed that this cannot be used immediately and requires a little bit of preparation first (albeit not much).
I don't know the exact requirement for preparation before this method can be called. However, creating an sf::RenderWindow first does seem to work. Just creating a sf::Context doesn't help.

41

Graphics / Re: Drawing Vertex Array with big Texture

« on: January 25, 2024, 02:56:07 pm »

Yes, if you split a texture into multiple textures, you'd need to make multiple vertex arrays with multiple draw calls.

As far as I know, Thor's "big texture" is used by its "big sprite" and that can automatically draw its parts. I have no experience with using it with vertex arrays.

Ah, frame animation. The bane of image storage.
From what you've said, it sounds like you have a single-sized text that can have multiple frames of animation per character.
If this is the case - and all of the text animates together (where when the 1st character is on frame 3, the 10th character is also on frame 3) - then you can store a single set of characters per texture and switch the texture depending on the frame, allowing a single texture for the entire text.

However, if you need different frames per character, you will need multiple vertex arrays for each texture as mentioned previously. However, you can do some optimisation such as fitting multiple (some not all) frames of character sets on the same image/texture as well as drawing all of the characters that can be drawn by that texture be drawn at once. This would require some sorting. The number of textures used would be no more than the number of different frames that characters are using - if still using only one frame per texture.

Any shader will need to be adjusted to take into account multiple textures and also know which one each part needs to use.

42

Graphics / Re: Drawing Vertex Array with big Texture

« on: January 25, 2024, 04:27:51 am »

I'm not sure I fully understand what your "specific case" is.

First thing to note is that you cannot have a texture larger that the maximum size; that maximum is given by the limitations of the graphics hardware.

What exactly are you trying to achieve? If you need a larger image to be displayed that can be stored on a texture, you can break it into multiple textures and draw them next to each other. It takes multiple draw calls, of course, as each texture switch requires a draw call. This is - I believe - what Thor's big texture and big sprite do.
A very low-end graphics card may have some issues if there are too many textures though as the ability to store all those images require the memory to do so.

As for which texture size to use, there's not guarantee. You can put some effort into providing smaller-sized images so that they will fit on a smaller texture (in addition to the size you actually prefer) to allow lower end graphics cards to use your textures.
With that said, it's generally accepted that you can "safely" use a texture size of about 2048x2048 since the majority of cards - even lower ones now - can do this. 1024x1024 is an almost certainty for compatibility. The 2k ones should be available even on phones.

Maybe this list can help (1% cannot use 2k, pretty much everyone can use 1k):
https://feedback.wildfiregames.com/report/opengl/feature/GL_MAX_TEXTURE_SIZE

This is also an interesting list:
https://store.steampowered.com/hwsurvey?platform=pc

43

General / Re: Is there a better way to do the line rotation and player directions

« on: January 24, 2024, 06:06:31 pm »

Did the answers given on the other thread that you made about this topic not help?
https://en.sfml-dev.org/forums/index.php?topic=29391.msg181091#msg181091

44

General / Re: How do I make a rectangle move at the direction of a line

« on: January 23, 2024, 06:34:09 pm »

Will fix that right up, thanks!

You're welcome.

How do I rotate the line the direction is decided like this

        line.setPosition(shape.getPosition().x - (shape.getSize().x),shape.getPosition().y + (shape.getSize().y/2));

It would depend on what "line" is. If it's a rectangle, set its rotation to the direction you already calculated. If it's a vertex array (2-vertex line), set its start and end points by using the offset you just calculated.

45

General / Re: How do I make a rectangle move at the direction of a line

« on: January 22, 2024, 06:22:46 pm »

Here's an example...

Could this line:
https://github.com/eXpl0it3r/Examples/blob/master/SFML/RotatingTriangle.cpp#L26

auto deltaPosition = sf::Vector2f{ mousePosition.x - triangle.getPosition().x, mousePosition.y - triangle.getPosition().y };

not just be this:

auto deltaPosition = mousePosition - triangle.getPosition();