Messages

16

SFML development / Re: SFML concurrency vs C++ standard

« on: March 13, 2017, 09:46:01 pm »

I think keeping the SFML threads is worse than redundant, as they could discourage use of other new threading features like futures and async.

17

General discussions / Re: VertexArray UV coords.

« on: March 10, 2017, 04:56:01 pm »

That's a pretty important one. I ran into the issue implementing high DPI assets: it wasn't possible to simply swap out the textures with higher resolution versions, instead I had to convert from the expected texture size to the actual texture size.
It isn't that big a deal but it is something of a hassle. Ironically, the easiest way to deal with it is to store UV coordinates for everything and only convert to pixels when SFML needs it.

Starting out, I liked the way SFML handled that, so I didn't have to worry about calculating UV coordinates when I knew my textures in pixels. Now though, it is a bit annoying to have to convert to pixels and know that it's just getting converted back to UV coordinates.
The one potential problem with UV coordinates is that they are floats, which means they're going to be less exact than integers, but that problem is exacerbated by converting between coordinate systems.

Maybe it would be best if texture coordinates were normalized, and there was a function to convert from pixels if you prefer working that way.

18

SFML wiki / Re: Tutorial: Building SFML for Android on Windows

« on: March 09, 2017, 09:53:43 pm »

I was pretty excited to see this for a second, before I realised I still couldn't compile for Android from a single codebase like I can for Mac, Windows, and Linux.

19

Feature requests / Re: Vulkan Support

« on: March 03, 2017, 03:33:03 pm »

SFML was never meant to be one of those multi-API rendering engine, just a wrapper on top of a low-level rendering API that already works well on all the target platforms.

I've seriously never seen any valid point in favor of a DirectX or Vulkan back-end, except that "it would be cool". People are not even supposed to care about the underlying API -- who cares that sfml-audio uses OpenAL?.

Multiple backends for the platform, on the other hand, are mandatory for SFML to run on these platforms. So this is not really comparable.

What about cases where different platforms require different rendering APIs? This would surely make it easier to broaden platform support separately from maintaining the high level API of SFML. Supporting the XBox for example requires DirectX, and even for the PS4 it may be preferable to use their GNM or GNMX APIs rather than OpenGL.

20

SFML development / Re: C++ standards

« on: March 02, 2017, 09:17:50 pm »

And just food for a (thought) experiment: If we had a mechanical way to transform SFML into a header-only library, sure it will take a fair bit longer to build your application, but I can guarantee you that it will also run faster than it does "linking the traditional way".

I know this is a bit tangential to the topic, but this would be fantastic.

On Rule of Five vs Zero, I think Zero when possible makes it more clear. That way, if in future you do need to change from one to the other, you won't forget to implement or remove any methods,.

21

Feature requests / Re: Toggle Virtual Keyboard on Windows

« on: January 16, 2017, 09:08:18 pm »

If you aren't using a standard Windows text input, for example if you're using SFML and drawing the text input yourself, then no the virtual keyboard does not come up automatically. You need a way to tell Windows that you're interacting with a text field and that it should bring up a virtual keyboard.
I have imagined the problem with the virtual keyboard coming up when you want to use the physical keyboard, and talk about that here.

22

Feature requests / Re: Add Keyboard/Mouse connection detection

« on: January 16, 2017, 09:02:23 pm »

I do use that pull request, but it doesn't address the issue completely. In fact I don't see a good way to distinguish between a mousemove and a touchmove even with that pull request, as both get sent when you touch the screen.

I just checked and it does look like it's been updated since I last compiled with that PR, so maybe it actually does work properly now.  But in any case it doesn't enable the other use case

23

Feature requests / Toggle Virtual Keyboard on Windows

« on: December 09, 2016, 07:35:10 pm »

It would be good to have a Windows implementation of setVirtualKeyboardVisible, particularly for touchscreen Windows devices.
Keyboard.hpp notes that not all OSes have virtual keyboards and so the function may be OS-dependent, but Windows does have this support and there are many touchscreen Windows devices without keyboards.

Use case:
I have a program that supports Windows tablets and includes text input fields. I want a tap on a text input field to bring up the virtual keyboard automatically, because the virtual keyboard toggle in the Start menu is at best inconvenient, and at worst inaccessible in a full screen program.

To enable this use case completely requires implementation of keyboard detection, as you would not want the virtual keyboard coming up on a keyboard-connected device.

24

Feature requests / Add Keyboard/Mouse connection detection

« on: December 09, 2016, 07:26:21 pm »

It would be useful to be able to check if a keyboard or mouse is or is not connected to the computer.

My use case is this:
I have a Windows program with UI, when a user is using a mouse, I want them to activate hover events, and when they are using a touch screen, I don't want to activate hover events.
The way Windows emulates mouse inputs with a touchscreen makes this impossible in SFML, as the MouseMove event is triggered so it appears the mouse is hovering over a button after the tap completes.

Another use case:
I have a mobile app with text input fields. I want to bring up the virtual keyboard when the user taps on an input field, unless they have a physical keyboard connected to their device.
I believe this is currently impossible in SFML, but I don't develop for Android/iOS so correct me if I'm wrong.

I think it makes the most sense to be able to poll the connection status in sf::Mouse and sf::Keyboard.
Alternatively a rework of the Mouse and Keyboard classes to bring them closer to how Joysticks are implemented might make sense, as it would allow multiple keyboards and mice to be detected as well. I realise that would at least have to wait for SFML3, and may not be a common enough scenario to warrant the effort.