Messages

1

Window / Re: Private Joystick Structures

« on: April 18, 2025, 09:27:18 pm »

Yeah that's basically all I ended up needing to do.

I made a fork of SFML with the changes for posterity: https://github.com/archieyates/arya-SFML/commit/507e7be415838a9f83204da612aac2d255b0ae19

2

Window / Re: Private Joystick Structures

« on: April 18, 2025, 03:09:50 pm »

I see what you mean about the include paths. Ended up hitting a number of issues trying to include certain files.

Honestly I still believe that just moving a few things (the definition of Joystick State, the location of EnumArray.hpp) and adding some extra functions to Joystick.hpp will fit more in line with what I need without having to mess around trying to include a bulkier file like JoystickManager

3

Window / Private Joystick Structures

« on: April 17, 2025, 02:32:29 am »

Is there a specific reason why certain structures like the Joystick Manager, Joystick states etc. are private?

I'm working on my own Gamepad wrapper for Joysticks that will support DirectInput and XInput so needs to generically cache button states achieved in different manners. I see that Joystick class let's me request on a per-button basis but that call is then going through and getting the manager each time to retrieve a single value when if I could get the manager myself I could just directly iterate through its button states myself.

I'm building from source so I could just go and move JoystickManager to public (which does have a few knock-ons from what I've seen) but I was also curious as to why it was hidden away beyond just not wanting to risk it being used incorrectly?

4

General / Re: Trying to inspect Textures stalls Visual Studio

« on: March 19, 2025, 01:00:30 am »

Oh it also turns out that somehow I had set up my project on my HDD rather than my SSD. Switching over to SSD seems to have helped too!

That's probably the real issue at play here

5

General / Re: Trying to inspect Textures stalls Visual Studio

« on: March 18, 2025, 11:55:10 pm »

Yeah I tried rebuilding and even got latest to see if maybe there was one version. I used these cmake settings (attached), launched in VS, hit rebuild, and then moved the built lib files into my project location but same issue.

It does seem to be intermittent actually as I had it stall on prebuilt as well so maybe it is my PC. Prebuilt does seem to have it happen less often though

I will just use prebuilt for now as there's nothing I needed from compiling from source other than the chance to learn a bit

6

General / Re: Trying to inspect Textures stalls Visual Studio

« on: March 18, 2025, 11:06:26 am »

Never heard of such an issue, so maybe it's more some temporary VS problem?

Yeah it's not something I've ever seen before either and it only happened when I was using my own built SFML 3.0 static libs.

I will see if I can get the dynamic libs to build again.

7

General / Re: Trying to inspect Textures stalls Visual Studio

« on: March 18, 2025, 12:43:48 am »

Of course as soon as I download prebuilt 3.0 it works fine so clearly I messed up something when trying to follow the cmake instructions...

8

General / Trying to inspect Textures stalls Visual Studio

« on: March 18, 2025, 12:36:27 am »

Now I will preface by saying this could be a VS issue or something with my PC although I'd hope my processor has the power to handle it but I've been through all the typical steps so wanted to see if anyone has had this issue with SFML before.

I have an SFML 3.0 project and I built the libs myself using cmake. I couldn't get it to create the dynamic libraries so have linked it statically but am not sure that's even the issue.

It all compiles and runs fine but I wanted to check to make sure some texture swapping was working properly and every time I tried to inspect the sf::texture (as either a local, member variable, ptr etc.) it would cause Visual Studio to say it was busy and then usually abort the execution complaining that "The debugger's worker process (msvsmon.exe) unexpectedly exited"

As a sanity check I made a quick new empty project and tested it with 2.6 dynamically linked, 2.6 statically linked (both using the pre-built download from SFML resources), and 3.0 that I built myself. With this empty project that just creates a texture and renders an empty window I could inspect the 2.6 texture but not on 3.0; same issue as before.

Could this be an issue with how I've built 3.0 myself or is this some other known issue people have come across before with 3.0? It's not like I can't work at all like this but it's very odd and I've never seen something like this before.

Cheers

9

General / Re: Link Errors moving from 2.6 to 3.0

« on: January 21, 2025, 10:47:14 pm »

Yeah adding SFML static pre-processor to each project setup seems to have fixed it all

10

General / Re: Link Errors moving from 2.6 to 3.0

« on: January 21, 2025, 12:03:14 pm »

Yeah I was doing some reading and it does seem that my understanding of "daisy-chaining" static libs doesn't work how I thought.

It is kind of odd that it did seem to work before. I could reference my "Vendor" project in the my app and it was fine which suggested the Core lib was chaining the Vendor lib.

I'll try out your suggestion for the preprocessor macro stuff tonight.

11

General / Link Errors moving from 2.6 to 3.0

« on: January 21, 2025, 02:36:25 am »

Hello,

So I will preface this but saying that whilst I know my way around C++ I have never had to do much project setup in work environments so I wanted to use this project as an opportunity to learn.

I was making a simple SFML app with a couple of different projects making up the solution. There is a Vendor project which, in theory, builds all the 3rd party stuff I download into a static library. I have my own Core project which links Vendor and also builds as a static library. Finally I have my App project which builds as a Console App.

I have been using Premake to get all this set up (as I find the Lua a bit easier to work with than CMake) and had it comfortably linking with the non-static SFML libs (downloaded from the website rather than self-built) so it could build the app exe no problem and I just had to include the SFML dlls with it.

I've now decided to try upgrading to 3.0 and building SFML myself to get at least a little familiar with CMake. Building the libraries all seemed good and it spit out all the static debug library files I needed (although for the non-sfml libs like FLAC it added a "d" to them so I just created a separate folder for "shared" libs and downloaded them from the site separately).

I hook up my project to point at my new libs and include locations and both my Vendor and Core static libraries build fine but as soon as I attempt to build the app (which should automatically include the dependencies of Core which includes those of Vendor) I get linker errors.

This probably isn't anything SFML-specific and is just me failing to understand something I probably should know by now but figured I'd ask for advice here.

Included a link with some images: https://imgur.com/a/sfml-3-0-error-4CyR2YF and can provide more info if needed.

Cheers