Author Topic: New global inputs in SFML 2 (Read 28465 times)

sammyF · « **Reply #45 on:** July 16, 2011, 10:46:52 am »

Quote from: "Laurent"

Don't forget that:
- SFML 2 is not even in alpha state so I can change whatever I want, whenever I want :lol:
- once SFML 2 is officially released, I won't break the API anymore in the 2.x branch

Laurent, if I understand correctly 1.6 isn't maintained anymore, and 2.0 isn't even in alpha yet and will probably have some major API changes in the future and should therefore not be used at all?

sammy

Laurent · « **Reply #46 on:** July 16, 2011, 11:24:41 am »

Absolutely.

OniLinkPlus · « **Reply #47 on:** July 17, 2011, 06:45:34 am »

Quote from: "sammyF"

Laurent, if I understand correctly ... should therefore not be used at all?

sammy

Not at all. Yes, it's true that some things may change, but that's hardly a problem, considering that SFML2 is actually far more stable than SFML 1.x. In fact, if you use an ATi Graphics Card with recent drivers, SFML 1.x based applications won't work at all. This problem has been fixed in SFML2.

tntexplosivesltd · « **Reply #48 on:** July 18, 2011, 04:06:33 pm »

No, SFML 1.6 works fine for my ATI card with the latest drivers. I still prefer SFML 2 though

OniLinkPlus · « **Reply #49 on:** July 18, 2011, 10:31:07 pm »

Quote from: "tntexplosivesltd"

No, SFML 1.6 works fine for my ATI card with the latest drivers. I still prefer SFML 2 though

What card do you use and what driver version? Laurent spent months trying to fix that bug.

Laurent · « **Reply #50 on:** July 18, 2011, 10:40:16 pm »

The ATI bug happens only on Windows with dynamic libraries.

ahuimanu · « **Reply #51 on:** July 19, 2011, 09:31:14 pm »

Quote from: "Laurent"

Absolutely.

new guy here. Does this mean use 2.0 or use 1.6?

Laurent · « **Reply #52 on:** July 19, 2011, 10:20:03 pm »

Quote

new guy here. Does this mean use 2.0 or use 1.6?

It means use SFML 2.0, unless you need absolute API stability for the next few months.

Nexus · « **Reply #53 on:** July 19, 2011, 11:49:15 pm »

Quote from: "Laurent"

It means use SFML 2.0, unless you need absolute API stability for the next few months.

In this case he can still use a fixed Git revision of SFML 2. The 1.6 API is only "stable" because it is unmaintained

Once SFML 2 is released, there are certainly fewer API modifications to take care of than when coming from SFML 1.6. Plus, many new features and bugfixes are available.

TheEnigmist · « **Reply #54 on:** July 23, 2011, 09:35:54 pm »

I'm back some day ago on SFML, i see that input are changed, how can i control input keyboard for move a sprite?

Nexus · « **Reply #55 on:** July 24, 2011, 12:05:11 am »

You must now use sf::Keyboard::IsKeyPressed() instead of sf::Input::IsKeyDown(). And key enumerators are now inside the class sf::Keyboard instead of the namespace sf::Key.

Generally, sf::Input has been split into the 3 classes sf::Mouse, sf::Keyboard and sf::Joystick. More can be found at the documentation...

SuperV1234 · « **Reply #56 on:** July 24, 2011, 11:20:57 pm »

I'm not happy of this change. I understand that it makes more sense in terms of abstraction and OOP-design, but having input related to a window was much more easier to manage.

What's the best solution to make the new "global input" system behave like the old one? How can I check if the key/mouse-presses are inside a window?

Nexus · « **Reply #57 on:** July 24, 2011, 11:44:49 pm »

I have had the same doubt, see the first page.

In short, you have two possibilities:

Catch LostFocus and GainedFocus events, ignore realtime input as long as the window has no focus
Store bool arrays on your own and flip their elements when the corresponding key/mouse/joystick events are fired

Both options are rather unconvenient compared to before. That's why I abstracted the functionality away in Thor's Action system, so that users don't have to manually watch out for focus events. I would recommend you to do something similar.

SuperV1234 · « **Reply #58 on:** July 25, 2011, 12:41:58 am »

Couldn't Laurent release the previous method as an additional class or something? It seems to work much better. I tried catching/losing focus but when I work with InputBoxes it still gives a lot of problems

Nexus · « **Reply #59 on:** July 25, 2011, 01:33:00 am »

Quote from: "SuperV1234"

Couldn't Laurent release the previous method as an additional class or something?

He certainly could, but this is a bad idea. Users would get confused and would not know which method to use to get realtime input. The whole functionality formerly provided by sf::Input can also be achieved with sf::Mouse, sf::Keyboard and sf::Joystick. It is just this issue which is more complicated to achieve, in general the new input system is much cleaner.

Quote from: "SuperV1234"

I tried catching/losing focus but when I work with InputBoxes it still gives a lot of problems

Can you explain the problem more concretely? Maybe not here, I think you should open a new thread in the Window subforum