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

Author Topic: sf::Input Copyable  (Read 22969 times)

0 Members and 2 Guests are viewing this topic.

Caspin

  • Newbie
  • *
  • Posts: 10
    • MSN Messenger - j_nick_terry@hotmail.com
    • View Profile
sf::Input Copyable
« on: April 09, 2008, 04:16:00 pm »
Why is sf::Input Non-Copyable?

I understand that it is prohibitively large and that copying should be done lightly.  Is there another reason?

This came up as I was building an input manager for my game.  I found that I was doing a lot of checking to see if a key was down last frame, rising/falling edge.  My solution was to make the contents of the last sf::Input available.  However, this wont compile with the current sfml, because I cannot copy sf::Input.

-Nick

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
sf::Input Copyable
« Reply #1 on: April 09, 2008, 04:51:51 pm »
Imagine the two following scenarios :

1- Each copy is still linked to its owner window, and receives its events. It wouldn't help much in your case as the copy would always be in the same state as the original one. Plus, it would hurt performance if creating many copies.

2- Each copy is disconnected from its owner window and becomes inactive, left with its last state. To me it wouldn't make much sense, and could be misleading for beginners.

So even if it could be useful in some cases, I think making sf::Input non-copyable is the only good solution.

But keys state is just an array of booleans, you can easily duplicate it.
Laurent Gomila - SFML developer

Caspin

  • Newbie
  • *
  • Posts: 10
    • MSN Messenger - j_nick_terry@hotmail.com
    • View Profile
sf::Input architecture
« Reply #2 on: April 09, 2008, 05:12:33 pm »
Ok, i see now.  I had though the sf::Input was a POD class that the RenderWindow updated after it processed all of the input events.  It is actually performing the event processing.  I agree the Non-Copyable is the way to go with Input.

On another thought could I replace what sf::Input with my own window listener.  The window listener interface is marked as internal now so I couldn't.

I'm not really aching to see an enhancement where I can create my own input processor.  It may be just as easy to do it with sf::Input instead.

I was just putting the idea out there as an enhance to be done when all others have been completed ( that generally means never ).

-Nick

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
sf::Input Copyable
« Reply #3 on: April 09, 2008, 05:39:47 pm »
Quote
I was just putting the idea out there as an enhance to be done when all others have been completed ( that generally means never ).

Yeah, that's the main point... So many important tasks to complete before I can possibly think about this one ;)

However, thanks a lot for your feedback !
Laurent Gomila - SFML developer

 

anything