Jump to content

Input with Action Sets!

reepblue

151 views

As you may have known, I've been dabbling with input methods for a while now using SDL2. Since then, I've learned how to do similar functions using the Leadwerks API. The goal was to make a inout system that's easily re-bindable, and allows for controllers to "just work". My first research of a goof system comes from a talk at Steam DevDays 2016 as they discuss how to allow integration with the Steam Controller. 

 

My thought was: "If I can create my own Action System, I can bind any controller with any API I want". The SDL experiments was a result of this, but they ended up being sloppy when you tried to merge the window polling from SDL into Leadwerks.

The next goal was to remove SDL2 out of the picture. I've created functions to allow reading and simulations of button presses with the Leadwerks Window class.

//-----------------------------------------------------------------------------
// Purpose: 
//-----------------------------------------------------------------------------
bool InputSystem::KeyHit(const int keycode)
{
	auto window = GetActiveEngineWindow();
	if (keycode < 7) return window->MouseHit(keycode);
	return window->KeyHit(keycode);
}

//-----------------------------------------------------------------------------
// Purpose: 
//-----------------------------------------------------------------------------
bool InputSystem::KeyDown(const int keycode)
{
	auto window = GetActiveEngineWindow();
	if (window != NULL)
	{
		if (keycode < 7) return window->MouseDown(keycode);
		return window->KeyDown(keycode);
	}
	return false;
}

//-----------------------------------------------------------------------------
// Purpose: 
//-----------------------------------------------------------------------------
void InputSystem::SimulateKeyHit(const char keycode)
{
	auto window = GetActiveEngineWindow();
	if (window != NULL)
	{
		if (keycode < 7)  window->mousehitstate[keycode] = true;
		window->keyhitstate[keycode] = true;
	}
}

//-----------------------------------------------------------------------------
// Purpose: 
//-----------------------------------------------------------------------------
void InputSystem::SimulateKeyDown(const char keycode)
{
	auto window = GetActiveEngineWindow();
	if (window != NULL)
	{
		if (keycode < 7)  window->mousedownstate[keycode] = true;
		window->keydownstate[keycode] = true;
	}
}

The simulate keys are very important for controllers. for this case, we would trick the window class thinking a key was pressed on the keyboard. The only direct input we would need from the controller is the value analog sticks which I haven't touch as of yet.

 Using JSON, we can load and save our bindings in multiple Action Sets!

{
    "keyBindings": {
        "actionStates": {
            "Menu": {
                "selectActive": 1,
                "selectDown": 40,
                "selectLeft": 37,
                "selectRight": 39,
                "selectUp": 38
            },
            "Walking": {
                "crouch": 17,
                "firePrimary": 1,
                "fireSecondary": 2,
                "flashLight": 70,
                "interact": 69,
                "jump": 32,
                "moveBackward": 83,
                "moveForward": 87,
                "moveLeft": 65,
                "moveRight": 68,
                "reloadWeapon": 82
            }
        }
    }
}

You may want a key to do something different when your game is in a certain state. For this example, when the Active Action Set is set to "Menu", Only KEY_UP, KEY_DOWN, KEY_LEFT, KEY_RIGHT, and KEY_LBUTTON will work. You can still hover over your buttons with the mouse, but when it comes time to implement the controller for example, you'd just call GetActionHit(L"selectActive") to select the highlighted/active button. If the state is set to walking, then all those keys for Menu gets ignored in-favor of the walking commands. All keys/buttons are flushed between switching states!

Here's example code of this working. "Interact" gets ignored when "Menu" is set as the default action and vise-versa.

	while (window->KeyDown(KEY_END) == false and window->Closed() == false)
	{
		if (window->KeyHit(KEY_TILDE))
		{
			if (InputSystem::GetActiveActionSet() == L"Menu")
			{
				SetActionSet(L"Walking");
			}
			else
			{
				SetActionSet(L"Menu");
			}
		}

		// Under "Menu"
		if (GetActionHit(L"selectUp"))
		{
			DMsg("selectUp!");
		}

		// Under "Walking"
		if (GetActionHit(L"interact"))
		{
			DMsg("interact!");
		}
}

Only things I didn't implement as of yet is actual controller support and saving changes to the json file which might need to be game specific. I also want to wait until the UI is done before I decide how to do this.

As for controllers, we can use SteamInput, but what if your game isn't on Steam? You can try to implement XInput yourself if you want. I tried to add Controller support with SDL2, but people reported issues. And then, what about VR controllers? What matters right now is that we have room to add these features later on. All I need to do is use the GetActionHit/Down Commands and the rest doesn't matter.

  • Like 1


0 Comments


Recommended Comments

There are no comments to display.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Blog Entries

    • By Josh in Josh's Dev Blog 0
      A new update is available for beta testers.
      Terrain
      The terrain building API is now available and you can begin working with it, This allows you to construct and modify terrains in pure code. Terrain supports up to 256 materials, each with its own albedo, normal, and displacement maps. Collision and raycasting are currently not supported.
      Fast C++ Builds
      Precompiled headers have been integrated into the example project. The Debug build will compile in about 20 seconds the first run, and compile in just 2-3 seconds thereafter. An example class is included which shows how to add files to your game project for optimum compile times. Even if you edit one of your header files, your game will still compile in just a few seconds in debug mode! Integrating precompiled headers into the engine actually brought the size of the static libraries down significantly, so the download is only about 350 MB now.
      Enums Everywhere
      Integer arguments have been replaced with enum values for window styles, entity bounds, and load flags. This is nice because the C++ compiler has some error checking so you don't do something like this:
      LoadTexture("grass.dds", WINDOW_FULLSCREEN); Operators have been added to allow combining enum values as bitwise flags.
      A new LOAD_DUMP_INFO LoadFlags value has been added which will print out information about loaded files (I need this to debug the GLTF loader!).
      Early Spring Cleaning
      Almost all the pre-processor macros have been removed from the Visual Studio project, with just a couple ones left. Overall the headers and project structure have been massively cleaned up.
    • By Josh in Josh's Dev Blog 6
      An often-requested feature for terrain building commands in Leadwerks 5 is being implemented. Here is my script to create a terrain. This creates a 256 x 256 terrain with one terrain point every meter, and a maximum height of +/- 50 meters:
      --Create terrain local terrain = CreateTerrain(world,256,256) terrain:SetScale(256,100,256) Here is what it looks like:

      A single material layer is then added to the terrain.
      --Add a material layer local mtl = LoadMaterial("Materials/Dirt/dirt01.mat") local layerID = terrain:AddLayer(mtl) We don't have to do anything else to make the material appear because by default the entire terrain is set to use the first layer, if a material is available there:

      Next we will raise a few terrain points.
      --Modify terrain height for x=-5,5 do for y=-5,5 do h = (1 - (math.sqrt(x*x + y*y)) / 5) * 20 terrain:SetElevation(127 + x, 127 + y, h) end end And then we will update the normals for that whole section, all at once. Notice that we specify a larger grid for the normals update, because the terrain points next to the ones we modified will have their normals affected by the change in height of the neighboring pixel.
      --Update normals of modified and neighboring points terrain:UpdateNormals(127 - 6, 127 - 6, 13, 13) Now we have a small hill.

      Next let's add another layer and apply it to terrain points that are on the side of the hill we just created:
      --Add another layer mtl = LoadMaterial("Materials/Rough-rockface1.json") rockLayerID = terrain:AddLayer(mtl) --Apply layer to sides of hill for x=-5,5 do for y=-5,5 do slope = terrain:GetSlope(127 + x, 127 + y) alpha = math.min(slope / 15, 1.0) terrain:SetMaterial(rockLayerID, 127 + x, 127 + y, alpha) end end We could improve the appearance by giving it a more gradual change in the rock layer alpha, but it's okay for now.

      This gives you an idea of the basic terrain building API in Leadwerks 5, and it will serve as the foundation for more advanced terrain features. This will be included in the next beta.
    • By Josh in Josh's Dev Blog 1
      Here are some things I did in the last couple days to fix a computer that was basically unusable.
      It seems that Superfetch was rebranded to "SysMain" in an update and automatically re-enabled. If your computer is grinding away either the CPU or disk usage while doing nothing, this is the culprit. Disable it in Windows services.
      The XBox games bar is suspect. I recommend disabling it now that FRAPS supports Vulkan.
      Some features in Visual Studio are making it unusably slow.
      In Project settings > Link > Debugging, set "Generate Debug Info" to "DEBUG:FASTLINK" (in the debug build only) for faster linking.
      Disable these two settings in the general program Options:
      Enable Diagnostic Tools while debugging Show elapsed time PerfTip while debugging
×
×
  • Create New...