Messages

16

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.

17

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.

18

Graphics / Re: Error compiling with gcc++

« on: August 10, 2023, 11:51:58 am »

Thanks for the information. I use exactly the same version of MinGW and GCC that are described in the tutorial.

For time being I just switch off -flto.

19

Graphics / Re: Error compiling with gcc++

« on: August 08, 2023, 05:48:03 pm »

I find out that the issue is "-flto" link optimization with SFML.
But the reasons for this are completely unknown to me.

20

Graphics / Re: Error compiling with gcc++

« on: August 07, 2023, 07:42:43 pm »

I have found what causes the problem in Codeblocks but do not know what is wrong with the wrong definitions.

This is how it looks working for release version ==> this works
Linker settings in release version:

Other linker options in release version:

Variables in whole project:


This is how I would like to use it be more automatic:
Linker settings in release version: none
Other linker options in release version:

Variables in whole project:


But for whatever reasons it just does not work and only for release version.

Has anybody any idea?

21

Graphics / Re: Error compiling with gcc++

« on: August 06, 2023, 11:14:40 am »

I have tried new blank project in Codeblocks and with

#include <SFML/Grahpics/CircleShape.hpp>

and just declaring sf::CircleShape and there is no problem.

As soon as I put 2 new files into the project, there is a problem.

I have attached both files but I cannot see any issue with it.

There is not many usage of sf::CircleShape in the files:
Voronoi.hpp

using Circles = std::vector<sf::CircleShape>;
Circles inputPoints;
Circles vorPoints;
Circles newPoints;
void addPoints (const Points& inputPoints, Visualisation::Circles& outputPoints, const sf::Color& color);
 

Voronoi.cpp

sf::CircleShape point (s_circleRadius, s_circleRadius/4 + 6);
void VoronoiCut::addPoints (const Points& inputPoints, Visualisation::Circles& outputPoints, const sf::Color& color)
{ // .....
}
 

I have tried to replace sf::CircleShape and using sf::RectangleShape and get same error.
`_ZThn8_N2sf14RectangleShapeD1Ev' referenced in section `.rdata$_ZTVN2sf14RectangleShapeE[_ZTVN2sf14RectangleShapeE]' of C:\C++\_LIB\SFML-2.6.0\lib\libsfml-graphics-s.a(RectangleShape.cpp.obj): defined in discarded section `.gnu.linkonce.t._ZN2sf14RectangleShapeD1Ev[_ZThn8_N2sf14RectangleShapeD1Ev]' of obj\Release\Voronoi\Voronoi.o (symbol from plugin)

22

Graphics / Re: Error compiling with gcc++

« on: August 06, 2023, 09:03:48 am »

Win11, using Codeblocks with gcc 13.1

Using Codeblocks project file.
What do you mean by builds command?

Project is set with these commands.
Release:
gcc.exe -std=c++20 -m64 -Wsign-conversion -std=c++23 -DSFML_STATIC -DTGUI_STATIC -fomit-frame-pointer -fexpensive-optimizations -flto -O3 -pedantic -Wextra -Wall -std=c++20 -m64 -DSFML_STATIC

Debug:
gcc.exe -std=c++20 -m64 -Wsign-conversion -std=c++23 -DSFML_STATIC -DTGUI_STATIC -Wnon-virtual-dtor -Wshadow -Winit-self -Wredundant-decls -Wcast-align -Wundef -Wfloat-equal -Wunreachable-code -Wmissing-declarations -Wswitch-enum -Wswitch-default -Wzero-as-null-pointer-constant -Wmain -pedantic-errors -pedantic -Wextra -Wall -std=c++20 -pg -m64 -Og -g

23

Graphics / Error compiling with gcc++

« on: August 05, 2023, 02:45:19 pm »

I use sf::CircleShape with SFML 2.6 and GCC 13.1.

So far till now I only build debug version and without errors. However for the first time I created release version and I get error. Do you have idea where can be problem?

`_ZThn8_N2sf11CircleShapeD1Ev' referenced in section `.rdata$_ZTVN2sf11CircleShapeE[_ZTVN2sf11CircleShapeE]' of C:\C++\_LIB\SFML-2.6.0\lib\libsfml-graphics-s.a(CircleShape.cpp.obj): defined in discarded section `.gnu.linkonce.t._ZN2sf11CircleShapeD1Ev[_ZThn8_N2sf11CircleShapeD1Ev]' of obj\Release\Voronoi\Voronoi.o (symbol from plugin)
collect2.exe: error: ld returned 1 exit status


info:
[ 33.3%] gcc.exe -std=c++20 -m64 -Wsign-conversion -std=c++23 -DSFML_STATIC -DTGUI_STATIC -fomit-frame-pointer -fexpensive-optimizations -flto -O3 -pedantic -Wextra -Wall -std=c++20 -m64 -DSFML_STATIC -IC:\C++\_LIB\SFML-2.6.0\include -IC:\C++\_LIB\TGUI-1.0\include -Iscr -Iscr\Voronoi -ITest -IVoronoi -c C:\C++\TEST\TEST_Voronoi_1\main.cpp -o obj\Release\main.o
[ 66.7%] gcc.exe -std=c++20 -m64 -Wsign-conversion -std=c++23 -DSFML_STATIC -DTGUI_STATIC -fomit-frame-pointer -fexpensive-optimizations -flto -O3 -pedantic -Wextra -Wall -std=c++20 -m64 -DSFML_STATIC -IC:\C++\_LIB\SFML-2.6.0\include -IC:\C++\_LIB\TGUI-1.0\include -Iscr -Iscr\Voronoi -ITest -IVoronoi -c C:\C++\TEST\TEST_Voronoi_1\Voronoi\Voronoi.cpp -o obj\Release\Voronoi\Voronoi.o
[100.0%] g++.exe -LC:\C++\_LIB\SFML-2.6.0\lib -LC:\C++\_LIB\TGUI-1.0\lib -o bin\Release\Voronoi.exe obj\Release\main.o obj\Release\Voronoi\Voronoi.o  -static-libstdc++ -static-libgcc -static -m64 -O3 -flto -s -static-libstdc++ -static-libgcc -static -m64 -lsfml-graphics-s -lsfml-window-s -lsfml-audio-s -lsfml-network-s -lsfml-system-s -lfreetype -lglu32 -lopengl32 -lopenal32 -logg -lflac -lvorbis -lvorbisfile -lvorbisenc -lgdi32 -lwinmm -lws2_32   -mwindows

note: TGUI is not needed now but I will use it later.

24

Graphics / Re: SFML 3.0 future proof

« on: July 16, 2023, 02:47:18 pm »

I will really hate floating-point math.

I was just adding edges on the limiting rectangle. The first idea going through all Voronoi points than sorting them clockwise, adding corners, and making new edges seems simple.

I was completely wrong, it is much more complex.
I need to preserve information on which input points create that edge so I need to go through edges not Voronoi points thus new vector will have some points more times. Still not difficult and it will provide information which input points (cells) own the edge on limiting rectangle.

I tried it, it did not work. I try to find why and I found out that the issue is that these points on the edge of limiting area are not too close to be considered on edge by comparision function using floating point comparison through ulp. So my question was why. I have found that my calculation of these points are based on lineSegmentsIntersection function with edge line is AB and rectangle limiting line PQ:

    inline std::optional<Vector2f> lineSegmentsIntersection (const Vector2f pointA, const Vector2f pointB, const Vector2f pointP, const Vector2f pointQ)
    {
        double ux = pointB.x - pointA.x;
        double uy = pointB.y - pointA.y;
        double px = pointQ.x - pointP.x;
        double py = pointQ.y - pointP.y;

        double denom = ux * py - px * uy;
        if (compareToZero(denom) == std::partial_ordering::equivalent)
        {
            return std::nullopt; // Collinear
        }
        double a = (-uy * (pointA.x - pointP.x) + ux * (pointA.y - pointP.y)) / denom;
        double b = ( px * (pointA.y - pointP.y) - py * (pointA.x - pointP.x)) / denom;

        if (a >= 0 && a <= 1 && b >= 0 && b <= 1)
        {
            // intersection detected
            float x = pointA.x + (b * ux);
            float y = pointA.y + (b * uy);
            return Vector2f(x, y);
        }
        return std::nullopt;
}
 

Everything seems right but there is very small logical error. Intersection point is based on point A, not point P or Q which even if it is float it use integral inside as it is limiting rectangle for visualisation. So just swaping AB with PQ solves the problem.

I think I will have small pause and than I will go through all code to make it more readable before final check that it works for any points with reasonable distance between them.

But floating point math with completely different accuracy in different calculations makes comparison really extreme difficult.

At least next step is done. Voronoi should be completed, so now I will start to implement testing for large random numbers to verify that it handles all possible cases correctly.

25

Graphics / Re: SFML 3.0 future proof

« on: July 11, 2023, 10:22:31 pm »

This is pretty cool. I've recently looked at these sorts of things myself and they're very interesting indeed.

It is really interesting but sometimes I think that my brain is just melting even if I find a lot of inspiration elsewhere. :-)
But I have still some issues with floating point math. :-(
There is no problem checking if the Voronoi diagram is correct (brute force is slow but probably error-prone, but I need to implement it and dump it to file what points break the math as till now the easiest way was just to look at a drawing of the Voronoi diagram to catch bugs) but the problem is the identification of these very extreme cases that break (and what is behind them). I have all math using floats with some fixed epsilon (this is not ideal but as standard usage will be around for points between 1e0 and 1e6 max. it should not be a problem) and I am thinking that I will switch private calculations to double precision and store only points as floats and all comparison will be done with floats.  I hope this will solve the issue as I expect that the final test will be about 1 million Voronoi diagrams with random points (min. distance 1 between points) and see if it will pass.

Right now there is the second part, transferring all this information to each cell, to each border (of the cell), and to each border line which can consist of several cells. Because borderline can have lots of points (after some noise is applied) and will not be changed often I think about using sf::VertexBuffer which will contain all border lines and will be drawn just one draw call.

This sounds like a good idea to avoid excess transferals from CPU memory to GPU memory.

I read in API documentation that there is a function that tests if sf::VertexBuffer is available. Just I do not know yet how can I do that if it is available it will use VertexBuffer but otherwise some standard type of array (probably std::vector)

However I would like it to do it as much as possible to close the prepared SFML 3.0 so that there will need no large refactoring. I know that there will be no quads in SFML 3.0 if I read it correctly, so any layers of borderline should be just triangles. Is it right?

Yes, you can use the triangles primitive and specify each one in turn. For an exact quad, this is still just two triangles. Basically, it's now 6 vertices per quad instead of 4 vertices per quad. Although, 2 of those vertices are identical to 2 of the others, of course.
[/quote]
Just a question, why quads will be depreciated? I do know not the details of OpenGL, is that reason that in actual SFML it still breaks quads to triangles which means unnecessary overheads?


Just writing this means that this first step is really more a small beginning if I look at what needs to be done to have really a lot of things just to get 100 % certainty about the correctness of Voronoi diagram and that there is a lot of math to create border lines, split them, merge them in case cells are removed or added and make some efficient sf::VertexBuffer that even changes of borders are just easy to update of the buffer.

26

Graphics / SFML 3.0 future proof

« on: July 11, 2023, 02:10:16 pm »

I am preparing just a small project that will create Voronoi map from a set of points and create borderlines that can user define by layers (eg. gradients) and the owner of the "cell". After everything I am thinking of creating some noise so that borders will be not just lines from one Voronoi point to another.

I have already done the first part - the Voronoi diagram.



Right now there is the second part, transferring all this information to each cell, to each border (of the cell), and to each border line which can consist of several cells. Because borderline can have lots of points (after some noise is applied) and will not be changed often I think about using sf::VertexBuffer which will contain all border lines and will be drawn just one draw call.

However I would like it to do it as much as possible to close the prepared SFML 3.0 so that there will need no large refactoring. I know that there will be no quads in SFML 3.0 if I read it correctly, so any layers of borderline should be just triangles. Is it right?

27

Graphics / Re: sf::Tranformable setOrigin

« on: May 29, 2023, 09:07:30 pm »

Yes, it works universally and that is probably the reason why not have it included in SFML as for convex shapes, bounding box center can be different from center of convex hull (center of mass).

28

Graphics / Re: Black line is not black

« on: May 29, 2023, 09:03:49 pm »

When it comes to 'infinitely thin' lines and points, you should always aim to use the "add a half" system to their co-ordinates. An integer co-ordinate is the top-corner of the pixel you want to use so adding a half to the y (and x) puts the co-ordinates right in the middle of the pixel.
Try that now: add a half to your co-ordinates and voila - black line!

Thanks, I did not know that, you can solve it this way.

29

Graphics / sf::Tranformable setOrigin

« on: May 27, 2023, 08:31:48 pm »

We have 2 overloads of sf::setOrigin:

setOrigin (float x, float y)
setOrigin (const Vector2f& origin)
 

There is another useful overload for getting origin to the center of the shape as it is quite useful as a lot of transformation has sence about center of the entity. For that it would be useful simple function without parameter. Or it could be through enum but it seems to me that function is used quite a lot and it would be really useful having it directly in the class.

setOrigin()
 

SFML has several types of entities:
CircleShape - it is easy by the radius
RectangleShape - it is easy by the size
ConvexShape - average of points
Sprite - from rectangle
Text - from its bounds

30

Graphics / Black line is not black

« on: May 27, 2023, 05:46:22 pm »

I am doing axis of graph by simple using sf::Vertex array.

const sf::Color         AXIS_COLOR          (sf::Color::Black);
   
sf::Vertex              axis[] =
{
    sf::Vertex          (sf::Vector2f       (0.f, GRAPH_SIZE/2), AXIS_COLOR),
    sf::Vertex          (sf::Vector2f       (GRAPH_SIZE, GRAPH_SIZE/2), AXIS_COLOR),
    sf::Vertex          (sf::Vector2f       (GRAPH_SIZE/2, 0.f), AXIS_COLOR),
    sf::Vertex          (sf::Vector2f       (GRAPH_SIZE/2, GRAPH_SIZE), AXIS_COLOR),
};

// and draw it

window.draw (axis, 4, sf::Lines);
 

I am using antialiasing:

sf::ContextSettings settings;
settings.antialiasingLevel = 8;
sf::RenderWindow            window           ({SCREEN_WIDTH,SCREEN_HEIGHT},APPLICATION_NAME, WINDOW_STYLE, settings);
 

However the axis is practically gray and if I set antialiasing to 0, I have a black line.
Is this because of basic coordination use floats?

Is there a way to have both, really black and antialiasing?