Messages

31

Graphics / Re: setFrameLimit - curious effect

« on: February 20, 2024, 11:56:03 am »

Maybe try setting the frame limit, but calling the generate function around 20 times in a loop (should use most of the available frame time) and time each call. That might be enough to see the CPU speed up.
(Not suggesting doing that permanently, just to test the hypothesis).
Maybe try some different loop counts to see how much work it needs before it clocks up.

32

Graphics / Re: setFrameLimit - curious effect

« on: February 16, 2024, 12:23:39 am »

I'm getting a feeling your turbo frequency idea might be what's going on.
Turbo does small increments to clock frequency when the workload is high (apparently number of cores in use too) and thermal limits haven't been hit. So a single threaded SFML app doing mostly sleeping for framerate limits with occasional spikes from generate() isn't sustaining the workload long enough for turbo to raise the clock as much.
I don't know if there's an app for intel that can show that. I've got an AMD one for my threadripper (Ryzen Master).

33

Graphics / Re: LineStrip VertexArray and ConvexShape problem

« on: February 15, 2024, 01:08:51 pm »

I'm a little hesitant to mention it (since it is barely documented and you'll be on your own getting it to work), but another way to go for vector art is to use NanoVG. It's kind of like a real time version of SVG using OpenGL.
Here's a pic of your data (the points vector) rendered using this code (in an SFML project):

        nvgBeginFrame(vg, 1920, 1080, 1);
        nvgBeginPath(vg);
        nvgFillColor(vg, nvgRGBA(255, 0, 0, 255));
        nvgStrokeColor(vg, nvgRGBA(255, 255, 0, 255));
        nvgStrokeWidth(vg, 2);
        nvgTranslate(vg, 100,100);
        nvgBeginPath(vg);
        nvgMoveTo(vg, points[0].x, points[0].y);
        for (int i=1; i<points.size(); ++i)
        {
                nvgLineTo(vg, points[i].x, points[i].y);
        }
        nvgClosePath(vg);
        nvgFill(vg);
        nvgStroke(vg);
        nvgEndFrame(vg);
 

It works within SFML fine, but you have to be a little careful. To get concave shapes it needs a stencil buffer, so you need to set the SFML window context to 8 bit stencil. You also need to call resetGLStates() on the SFML window after any NanoVG rendering, because NanoVG messes with opengl states that SFML expects to not be changed.
Performance won't be as good (since its more dynamic remaking the shape every frame, not just a vertex array generated once), but there's a lot of features in it.
https://github.com/memononen/nanovg

34

General / Re: Can't static link SFML

« on: February 13, 2024, 02:55:38 pm »

If we pick one error line and take a look at it:
1>sfml-window-s-d.lib(WindowImplWin32.obj) : error LNK2019: unresolved external symbol __imp__SetWindowLongW@12 referenced in function "public: __thiscall sf::priv::WindowImplWin32::WindowImplWin32(struct HWND__ *)" (??0WindowImplWin32@priv@sf@@QAE@PAUHWND__@@@Z)

The key parts: "unresolved external symbol" means it can't find something (most likely because a library is missing), and the next symbol is __imp__SetWindowLongW. If we ignore the __imp__ part and google for SetWindowLongW, Microsoft's documentation is here: https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setwindowlongw
Down the bottom of that page it says SetWindowLongW is part of user32.lib.
(Looks like all of the other error lines are also things from user32.lib.

Looking at the linker line, user32.lib isn't listed, so it needs to be added.

35

General / Re: Can't get SFML on VS 2022

« on: February 08, 2024, 05:23:07 am »

Don't worry, it does get pretty confusing at the beginning. Visual Studio doesn't go out of its way to make it easier either (as we'll see soon).

SFML 32bit will be fine, as long as your project has the platform set to Win32/X86 instead of X64.

For the missing DLLs...
When the run a program, it looks in a few places for the dlls. One is the system path (set in Windows, every directory in the path will be searched). The other is the "working directory".
If you run a program by clicking on it in explorer, the working directory is set to the same directory as where the program is. So if you click on c:\game\main.exe, it will search c:\game for the dlls.

This is where VS is annoying.
Running a program from inside of Visual Studio uses a working directory set in the project properties. The default is $(ProjectDir), which means it will look for the dlls in the same directory as the .vcxproj file, not where the exe ended up!
I always change the working directory to $(TargetDir), that makes it look for dlls where the exe is.

The setting is in Debugging / Working Directory. If you set it to $(TargetDir) and copy the SFML dlls into the same directory as the exe file you built, it should hopefully work.

36

General / Re: Can't get SFML on VS 2022

« on: February 08, 2024, 03:48:37 am »

The include paths thing was for the compile error from the top.

Visual studio can build Windows executables (exe) and libraries (dlls) as either 32bit or 64bit. The important part is that they can't be mixed. The executable and all libraries must be the same bit size or they are incompatible. So you should get the SFML that matches what you want your project to be.

Windows itself used to have 32bit and 64bit versions. The 32bit Windows can only run 32bit programs. The 64bit Windows can run both 32bit and 64bit programs.

My personal preference is 64bit, I stopped doing anything C++ related in 32bit many years ago (some of my stuff uses a lot of ram). But 32bit does have a wider audience (some people still using old 32bit versions of windows).

37

General / Re: Can't get SFML on VS 2022

« on: February 08, 2024, 02:06:14 am »

Mixing the 32bit SFML download with 64bit platform in the project settings isn't going to work, but that's not the cause of the issue here. (you can't mix 32bit and 64bit).

The error in the first post says it can't find SFML/Graphics.hpp. So the code most likely has:
#include <SFML/Graphics.hpp>

But your settings have the additional includes set to: C:\users\xxxxxx\Downloads\SFML-2.6.1-windows-vc17-32-bit\SFML-2.6.1\include\SFML
Visual Studio adds the #include path to the additional includes path, so it was looking for:
C:\users\xxxxxx\Downloads\SFML-2.6.1-windows-vc17-32-bit\SFML-2.6.1\include\SFML\SFML\Graphics.hpp
(double SFML).

If you change the additional includes to: C:\users\xxxxxx\Downloads\SFML-2.6.1-windows-vc17-32-bit\SFML-2.6.1\include it should work.

(Or so both #include <Graphics.hpp> and #include <SFML/Graphics.hpp> work, you can set the additional includes path to: C:\users\xxxxxx\Downloads\SFML-2.6.1-windows-vc17-32-bit\SFML-2.6.1\include;C:\users\xxxxxx\Downloads\SFML-2.6.1-windows-vc17-32-bit\SFML-2.6.1\include\SFML )

38

Graphics / Re: sf::Rect

« on: February 05, 2024, 10:44:21 pm »

I'd forgotten too, had a suspicion and had to google around to verify.

I assume without the static cast it would just give some warnings during the build about having to truncate ints to smaller types (if a Rect<short or char> was used) but would otherwise work. Floats or doubles wouldn't need the cast.

Or maybe the template would get confused. I should test it, I'm curious now.

39

Graphics / Re: load font error -

« on: February 05, 2024, 10:19:28 am »

Including the fonts seems to work in both cases but when i hit the build button i get loads of error messages

When you say "including the fonts" you don't mean #include do you? Because that would definitely cause compile errors.

40

System / Re: Failed to activate OpenGL context: Failed to activate the window's context

« on: February 05, 2024, 08:47:58 am »

Threads with SFML rendering need special care. https://www.sfml-dev.org/tutorials/2.6/window-opengl.php#rendering-from-threads
Basically an opengl context can only be active on one thread at a time. You need to deactivate the window's context on the main thread and enable the window's context in the thread before rendering there will work.
(Then deactivate it in the thread and reactivate in the main thread to do the other rendering).

41

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

« on: February 04, 2024, 09:25:20 pm »

It's not the issue you are asking about, but in your addMenu function you are creating a temporary font variable, loading a font with it and setting the font on the text object.
The issue is setFont doesn't store the font in the text object, it just stores a pointer to the font. The font itself must be kept alive, otherwise the result is undefined behavior.

42

Graphics / Re: sf::Rect

« on: February 04, 2024, 10:13:36 am »

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")

43

Graphics / Re: LineStrip VertexArray and ConvexShape problem

« on: February 01, 2024, 11:15:34 pm »

ConvexShape needs shapes to be convex. That means no inward angles like the curved top part. Your shape is concave, which is harder to draw filled.

Why concave doesn't work is Shapes (like ConvexShape) use a triangle fan from the centre. To reach the top corners from the centre, it has to draw over the top of the curved parts, resulting in the triangle shape instead of the curve.

There's no built in way to do concave shapes in SFML (that I know of), you'll need to generate a triangle mesh using an algorithm like "ear clipping" (it can turn concave into triangles that don't overlap). But implementing that can be tricky.

Or depending on how you intend to use it, maybe do something like draw a white rectangle then a black circle over the top.

44

General / Re: Can't resolve LNK2001 "unresolved symbol"

« on: January 28, 2024, 03:56:15 am »

When SFML is linked statically, you have to manually link in all of the dependency libraries.
In your case it looks like you haven't added opengl32 and freetype as addition libraries.

There's a table of what you need to link here: https://www.sfml-dev.org/tutorials/2.5/start-cb.php (around half way down).

45

Graphics / Re: Drawing Vertex Array with big Texture

« on: January 27, 2024, 04:10:13 am »

Of course these max sizes are the theoretical max size supported by the gpu/driver. It doesn't necessarily mean you can actually create one that big because it might not currently fit in memory.
For example a single 16384x16384 texture takes up 1GB of video ram.

Array textures do look like a good solution, especially since they do eliminate edge bleeding that atlases can suffer from. But getting that into SFML might be a little tricky. I've also heard bindless textures are the new preferred way, but I've never looked into them (again, not in SFML so might be tricky).