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 - Garwin

Pages: [1] 2 3 4
Graphics / Re: setFrameLimit - curious effect
« on: February 20, 2024, 09:18:26 am »

Thanks for confirming, that I am not completely out of mind.
It should be no problem as if the application is more processor demanding, there will be less sleep, so no slow down.

Graphics / Re: setFrameLimit - curious effect
« on: February 15, 2024, 07:34:04 pm »
setFramerate() sleeps the thread.
This helps with "over-producing" with no limit and can reduce power used. However, it's not strictly set to that rate.
Once a thread is "slept", it has the possibility of "over-sleeping" as there's no real way of insisting on coming back by a specific time (accurately); this is dependent on operating system's task scheduler.

So, I'd guess that the framerate limit is sleeping during each frame and then the operating system is keeping it a little longer than your hoped-for length of time before returning it.

I would expect it to be faster (shorter frame time) without a framerate limit.

This I would understand but if the measurement of the function is just 2 time points one before that function and after that function which has no call to SFML except sf::Vector2f, that I cannot see how sleep will interfere with it. I do not measure and compare whole loop but only one function inside the loop.

Graphics / setFrameLimit - curious effect
« on: February 14, 2024, 05:50:43 pm »
I am just curious as it is nothing really important.

I have just measured in average on function that generate Voronoi diagram which is inside the main sfml event loop.

auto vorStartTime = std::chrono::steady_clock::now();
auto vorEndTime = std::chrono::steady_clock::now();

Then I print each second the average for this function. Each iteration I add vorEndTime - vorStartTime to the overall time and then divide by a number of loops for that time. Than just checking if elapsed at least 1 second from the last loop and if so print the average.

But what is really strange that it gives me 0.3 - 0.6 ms with setFrameLimit to 60.
But if I switch off any FrameLimit, i get 0.14 - 0.16 ms.

The function
voronoi.generate() is using only sf::Vector2f from the whole SFML library for points.

I am just curious how it can be possible that setting frame limit has effect on function with has practically nothing to do with SFML. Or it can be possible that setting the frame limit makes the processor more idle so that the max turbo frequency of processor is not used (intel i7-1265u 1.8 MHz)

Graphics / Re: sf::Rect
« on: February 10, 2024, 12:16:00 pm »
Good, there is static_cast to show an intention.

However, a much more difficult area is floating point math and comparison of floating points. Mostly, you want the warning as it is unintentional but there are cases in which you want to compare floating points for equality and there is no way to tell the compiler to ignore this case and not issue a warning.

Graphics / Re: sf::Rect
« on: February 05, 2024, 05:29:14 pm »
I would guess it's there to make sure the type is T to match the min and max signature.
For integer datatypes, the type of the result of a + is not always the type of the two operands. If you have a Rect<short>, then left and width are shorts, but left+width is an int.
(From cppreference.com: "In particular, arithmetic operators do not accept types smaller than int as arguments")
Thanks, forgot about this specifiation.

Graphics / sf::Rect
« on: February 04, 2024, 09:12:06 am »
I have looked at the implementation of the Rectangle class and I was surprised to find static_cast.

Why is static_cast there?

from SFML 3.0 branch
template <typename T>
constexpr bool Rect<T>::contains(const Vector2<T>& point) const
    // Not using &#39;std::min&#39; and &#39;std::max&#39; to avoid depending on &#39;<algorithm>&#39;
    const auto min = [](T a, T b) { return (a < b) ? a : b; };
    const auto max = [](T a, T b) { return (a < b) ? b : a; };

    // Rectangles with negative dimensions are allowed, so we must handle them correctly

    // Compute the real min and max of the rectangle on both axes
    const T minX = min(left, static_cast<T>(left + width));
    const T maxX = max(left, static_cast<T>(left + width));
    const T minY = min(top, static_cast<T>(top + height));
    const T maxY = max(top, static_cast<T>(top + height));

    return (point.x >= minX) && (point.x < maxX) && (point.y >= minY) && (point.y < maxY);

Graphics / Re: 2 questions about VertexArray / VertexBuffer
« on: December 21, 2023, 02:34:17 pm »
You can both, look at the documentation.
void    draw (const Vertex *vertices, std::size_t vertexCount, PrimitiveType type, const RenderStates &states=RenderStates::Default)

So you can use any container/build in array of sf::Vertex that uses continuous memory.  Just pass to draw call the pointer to the first Vertex, number of vertices, and primitive type.

But as for each PrimitiveType you need a separate draw call, it does not bring the advantage of limiting draw calls.

General discussions / Re: [Rendering] Create sprite each frame?
« on: December 17, 2023, 08:38:52 am »
It is better to store sprites in some container, vector is an obvious option.
Then you can change sprite properties if needed. If you need a link to the exact sprite, you can store ID of sprite as it is not invalidated if the reallocation of the vector occurs.

If your number of sprites is not big, you will not mention the difference.

Graphics / Re: Error compiling with gcc++
« on: December 13, 2023, 07:08:43 pm »
Not exactly. I used same setting from beginning finding that it optimalize functions calls between compilation units.
But I got this error with new version of SMFL, which is strange.

I disable it for time being but have not found anything useful on internet, usually some very old reports of gcc bugs, but it was about version gcc 4.

Graphics / Re: Error compiling with gcc++
« on: December 11, 2023, 08:28:23 pm »
I get more detailed error but so far do not know what to do with it ....

`_ZThn8_N2sf11CircleShapeD1Ev' referenced in section `.rdata$_ZTVN2sf11CircleShapeE[_ZTVN2sf11CircleShapeE]' of ...\_LIB\SFML-2.6.1\lib\libsfml-graphics-s.a(CircleShape.cpp.obj): defined in discarded section `.gnu.linkonce.t._ZN2sf11CircleShapeD1Ev[_ZThn8_N2sf11CircleShapeD1Ev]' of obj\Release\Test.o (symbol from plugin)

Graphics / Re: Error compiling with gcc++
« on: December 09, 2023, 07:35:29 pm »
I find what is doing the issue. But I do not understand why.
If somebody has any clue, it would be helpful.

Simple example code with MinGW 13.1 (version used by SFML) on Codeblocks - Windows 11.
#include <SFML/System/Vector2.hpp>
#include "SFML/Graphics.hpp"

#include <vector>

int main ()
    std::vector<sf::Vector2f> inputPoints;
    std::vector<sf::RectangleShape> circles;

    return 0;

As soon as I add this:
std::vector<sf::RectangleShape> circles;
I get the error:
error: ld returned 1 exit status
without any additional information.

So why just declaring vector of RectangleShape can cause such error.

But if I switch off "-flto" for gcc, it compiles without any issue.

System / Re: std::istream& operator >> for sf::String
« on: December 09, 2023, 06:54:28 pm »
Thanks, in this case, where I parse whole string, I can.

System / std::istream& operator >> for sf::String
« on: December 02, 2023, 11:52:54 am »
I overloaded operator >> for std::istream and sf::String to handle UTF8 encoding.
However I can see there are a lot of copies there:
- from stream to std::string (UTF8)
- from std::string (UTF8) to std::basic_string<sf::Uint32> using sfml function decode
- from std::basic_string<sf::Uint32> to sf::String

I need to use the middle step through std::basic_string<sf::Uint32> as there is no std::back_inserter for sf::String. Is there possibility to decrease number of steps.
note: SFML 2.6.1

Some ideas I have:
- making std::basic_string<sf::Uint32> static and add clear at the end of overload so there is no need to for memory allocation each time

std::istream& operator>> (std::istream& in, sf::String& string)
    std::string u8string;
    in >> u8string;
    auto begin = u8string.begin();
    auto end = u8string. end();
    std::basic_string<sf::Uint32> stringUint32;
    auto output = std::back_inserter(stringUint32);
    while (begin < end)
        sf::Uint32 codepoint;
        begin = sf::Utf<8>::decode(begin, end, codepoint);
        *output++ = codepoint;
    string = stringUint32;
    return in;

Graphics / Re: Cannot find smfl-graphics-2.dll
« on: November 26, 2023, 10:51:21 pm »
If you download MinGW version of SFML from SFML homepage, you will find it under bin folder.

General discussions / Re: VertexArray transformations
« on: November 18, 2023, 08:35:56 am »
It seems to me that you have a lot of memory leaks using "new".

Just a question, how do you expect it to be faster than individual draw calls? You still need to do all transformations and in case you need to "draw" your way texture more times, it means copying a lot of data which then you need to transfer to a graphic card opposite using texture on the graphic card and drawing it several times.

Pages: [1] 2 3 4