Welcome, Guest. Please login or register. Did you miss your activation email?

Recent Posts

Pages: 1 ... 5 6 [7] 8 9 10
61
Window / Re: Private Joystick Structures
« Last post by Reicha7 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
62
Window / Re: Private Joystick Structures
« Last post by kojack on April 18, 2025, 07:59:09 pm »
I think the joystick system does need a bit of a refresh. It's still stuck in the ancient past of 32 button limits (DirectInput moved to 128 button limit in 1997).

I don't think the JoystickState class really needs to be obscured, it isn't implementation specific (all platforms share the same struct). It might be handy for user code to be able to grab the state via a function in the Joystick namespace, such as for recording snapshots of input state.
63
Window / Re: Private Joystick Structures
« Last post by Reicha7 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
64
Window / Re: Private Joystick Structures
« Last post by kojack on April 17, 2025, 10:21:48 am »
You can access the joystick manager without modifying any source, its not actually private, just in a namespace called priv.
For example I just did this and it works for my gamepad:
auto state = sf::priv::JoystickManager::getInstance().getState(0);
All buttons and axes are then in the state variable.

Although the manager's header and a bunch of dependent ones are located in the source directories rather than the header directories, so you may need to add some additional include paths when you build.

The most likely reason for the way its designed is to prevent excessive dependencies being pulled in. Including just joystick.hpp has little impact, it's header is pretty minimal. But including joystickmanager.hpp will also pull in dinput.h and mmsystem.h (when doing windows builds). If the end user doesn't need to use dinput and mmsystem themselves, then its best to not pull them into any cpp that wants joystick access.
This also means an sdk build has minimal headers needed, for example you don't need directinput headers available if you are just using a prebuilt sdk, because the joystickmanager is just internal to the sfml libs.
65
Window / Private Joystick Structures
« Last post by Reicha7 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?
66
General discussions / Re: Rendering to outside of a window possible?
« Last post by Hapax on April 16, 2025, 10:49:21 am »
If you have a lot of things drawn - or are otherwise having performance issues - you may need to consider optimising what is drawn by "culling" things that are not in the range of the window as this is not done automatically. You can do this simply by using the method you described. More complicated methods exist including using "chunks" that can in turn reduce the number of intersecting tests but, again, this is much more complicated.

As an answer to the question, yes, things outside of the window will still be processed by the rendering process. Note, though, that this is basically all of the shaders up to the fragment shader; this shader only applies to actual pixels that are visible. So, the fragment shader will not be run on the things outside of the window but the vertex shader - for example - will still be run on every vertex (that you draw).
67
General discussions / Rendering to outside of a window possible?
« Last post by rjack on April 15, 2025, 05:36:46 pm »
hello,
I am a beginner so appologies for, maybe trival, question.

Does SFML, by default, render an object to a window whereby an object is positioned outside of the window's frame?

I mean, lets have a tiny sprite at position Vector2f(-1000.f,-1000.f) and my window is atVec2(0,0).
If I say, (sf::RenderWindow) window.draw (sprite) in my game loop, is it going to be still "rendered"? Obviously I am not gonna see it anyway but would the CPU/GraphicsCard procesing power still be used for this task?

If positive, than I guess I ll have to make sure first, whether the sprite intersects with the window rect, and only if positive, let it draw, right?
68
C / Re: SFML 3 C Binding?
« Last post by MetalCoder on April 04, 2025, 01:44:08 am »
We've already published an release candidate: https://github.com/SFML/CSFML/tree/3.0.0-rc.1

So far there hasn't been any negative feedback on it, which means, once we find the time, it will be officially released.
Would be great if you could give it a try and see if you spot any issues. :)

Thanks. I noticed there is no angle feature in the C binding.
69
C / Re: SFML 3 C Binding?
« Last post by eXpl0it3r on April 03, 2025, 07:57:32 am »
We've already published an release candidate: https://github.com/SFML/CSFML/tree/3.0.0-rc.1

So far there hasn't been any negative feedback on it, which means, once we find the time, it will be officially released.
Would be great if you could give it a try and see if you spot any issues. :)
70
C / SFML 3 C Binding?
« Last post by MetalCoder on April 02, 2025, 11:55:47 pm »
Hi all,

What would be needed for the C binding SFML to be upgraded to SFML 3? I wouldn't mind helping out if I can.
Pages: 1 ... 5 6 [7] 8 9 10
anything