This prevents other input devices from interfering with the expected calls
that the Keyboard tests should make.
Signed-off-by: Chris Burel <burelc@amazon.com>
This allows for all the global static `InputChannelId`s to be `constexpr`
as well, which prevents some global constructors, including some CRC32
calculations on application startup.
Signed-off-by: Chris Burel <burelc@amazon.com>
* Create a new InputContextComponent.
- An InputContextComponent is used to configure (at edit time) the data necessary to create an AzFrameowrk::InputContext (at run time). The lifecycle of any InputContextComponent is controlled by the AZ::Entity it is attached to (adhering to the same rules as any other AZ::Component), and the InputContext which it owns is created/destroyed when the component is activated/deactivated.
- The underlying AzFramework::InputContext and AzFramework::InputMapping* classes already exist, along with comprehensive unit tests (see Code/Framework/AzFramework/Tests/InputTests.cpp). All changes in this PR are simply to allow input contexts / input mappings to be defined/edited from the editor using data.
- The new InputContextComponent is similar in many respects to the InputConfigurationComponent found in the StartingPointInput Gem, the main difference being that the user-defined input mapping objects the new component creates are identical (from the perspective of any input consumer) to 'raw' engine-defined input channels (the existing AzFramework::InputMapping class inherits from the existing AzFramework::InputChannel class). This means that any system which consumes input (in either C++ or lua) can seamlessly interchange between obtaining input using either the 'raw' engine-defined input channels (eg. InputDeviceGamepad::Button::A, InputDeviceKeyboard::Key::AlphanumericA, etc.) or any user-defined input mapping, which can now be defined from the editor using data. Ultimately I would like to deprecate the StartingPointInput::InputConfigurationComponent in favour of this new InputContextComponent, which isn't realistic at present because the former is used pervasively throughout many different projects, and it integrates with ScriptCanvas in a way that I have yet to replicate, but this is a step towards the goal of a unified, engine-wide input context/input mapping solution that can be used interchangeably by any system, project, or Gem.
Signed-off-by: bosnichd <bosnichd@amazon.com>
* Edited some reflected property descriptions for clarity.
Signed-off-by: bosnichd <bosnichd@amazon.com>
* Fix clang builds:
- Add a missing virtual destructor.
- Fix the scope of two reflected property attribute functions.
Signed-off-by: bosnichd <bosnichd@amazon.com>
* Fix for InputContextComponent being reflected twice in some cirsumstances.
Signed-off-by: bosnichd <bosnichd@amazon.com>
* Updates in response to PR feedback.
Signed-off-by: bosnichd <bosnichd@amazon.com>
* More updates based on review feedback.
Signed-off-by: bosnichd <bosnichd@amazon.com>
* Modernization + small fix.
Modernize ( `bool`/`override`/other) code in AzCore, AzFramework, AzQtComponents, AzToolsFramework, etc.
Replaced a `bind` or two, use `using` in a few places as well.
Fix nullptr comparison of AZStd::function.
Signed-off-by: nemerle <96597+nemerle@users.noreply.github.com>
* Apply review-based changes
Signed-off-by: nemerle <96597+nemerle@users.noreply.github.com>
* Final update copyright headers to reference license files at the repo root
Signed-off-by: spham <spham@amazon.com>
* Fix copyright validator unit tests to support the stale O3DE header scenario
Signed-off-by: spham <spham@amazon.com>
Chris Burel
bosnichd
Artur K
michabr
Steve Pham
nvsickle
alexpete