Engine feature – Progress Update – 2

Updated to the engine feature that I’m developing, detailed here.

As discussed in my previous post , I’ve completed the work on the basic features of my engine and started working on stretch goals and overall making the library better.

Updates for this week:

  1. Button remapping now works with both Lua and Binary files

Users can specify which buttons are to be mapped to which other buttons in the settings.ini file that is present in the game directory. The remapping syntax looks like the following. I had to make sure that it is still easily accessible to the users, while being fast to read in code.

I also created a launcher application in WPF using C#. Which shows a GUI for remapping buttons. The application then writes out a binary file with the new mappings when the user selects OK or keeps the current mappings when cancelled and then opens the game.

My library checks for the existence of both the lua and the binary files and compares the timestamps for these files and opens the file which has the latest edited timestamp. My launcher currently supports remapping of one controller, where as the Lua file supports remapping of all four controllers.

2. Support for function callbacks of subscribed functions.

Users can register functions which are to be called when a particular button is pressed. This is especially useful for buttons such as menu, since the game does not have to check for button press on every update. The library provides functions to register and de-register function callbacks. All the buttons and sticks are supported along with multiple controller support. The register function accepts a function pointer to the required callback function. The syntax looks like the following.

And registering a function looks like the following.

All the callbacks happen asynchronously using std::async. Hence the library does not expect any return values from the callback functions. I have worked with asynchronous calls before using C#, but this is the first time i used it in C++.

Since i have to check the controller state for every tick to check for changes, instead of calling my update function in the core application thread, I have the core update function of my library running on a new thread and use a while loop to continuously check for changes in controller state. Creating a new thread, helps in not bogging down the application thread and better check for changes.

I am using windows specific “CreateThread” function to create thread, and wait for the thread to exit safely before closing the application instead of using “ExitThread“, since it is preferred to return from the function than using ExitThread for C++ applications as discussed in the article.


Things I’m planning on working for next week:

  1. Polish the library
  2. New “really far” Stretch goal: Create a sound library to playback audio from the controller’s headphone jack.

Leave a Reply

Your email address will not be published. Required fields are marked *