Freescape Engine

This engine is currently my biggest challenge, I still have some doubts of if my keymap support is implemented to its highest degree. The issue I faced is that there were too many files to be aware of while making small changes. Before that I’ll explain how the keymap was being generated per game, The initkeymap was initialized as a virtual function and it was being overridden for each game engine . For example if I wanted to map a key I had to first identify in which engine the actions were being used and in which they were not while keeping in mind the different keys mapped to each engine per game, I usually got lost in my thought process while navigating and had to rethink. Also I changed the structure of how the keymaps were being initialized. Firstly, the common actions were initialized in the parent class of each per game keymap then the actions that were not common between the games and had different keys were being mapped in their own initkeymap overridden  function.

Here is the PR.

Additional Notes

As of now there were few notes as I opened it for review and there were two thing I overlooked:

It seems that different keys are mapped into different platforms, somehow I was not able to Identify that and also there is an issue with the demo mode, I haven’t fully understood what the statement means yet, but that’s a problem for tomorrow’s me.

TOUCHE Engine

I found it odd that keycodes were being stored in _flagsTable[600] but I couldn’t for the life of me find anywhere else in the engine where it was being used. So when the escape key is pressed, KEYCODE_ESCAPE is stored in _flagsTable[600] and somewhere else in the engine it is being processed.

so even though I mapped it into action I had to store the escape keycode in the _flagTable[600] otherwise it wouldn’t work. This is a hack that I am not proud of but could not find another way as of now. Other than that there was nothing in the engine that was hard to tackle.
Here is my PR.

TRECISION Engine

The issue I had with Trecision while mapping it was that the pause was little complicated to figure out as the loop calls itself recursively to see if any key has been pressed then it unpauses.

I disabled the keymap so if any key was pressed it would continue and for that I accommodated JoyInputs too so I introduced bool joyunpause which keeps track of if any joy button was pressed.

Additional Details

I was told by my mentors that I was not mapping joy buttons correctly. One major issue was that I was using JOY_BACK and JOY_GUIDE but these buttons including JOY_START are already in use by either global_keymap or hardware. So I was advised that if there are multiple keys and not enough joy_buttons, to further divide the keymap and enable and disable in different game situations so they do not overlap and that way you can use same joy button for different actions.

GROOVIE Engine

Groovie games are point and click games so they do not need keys to navigate hence I only needed to add one key to the keymapper. I t did have a long and strenuous way of handling key input so had to create functions and variable to access the Action stored.
Here is the PR.

SHERLOCK Engine

Working on GROOVIE could be considered the calm before the storm. This is the first time I am unable to finish an engine. SHERLOCK Engine has two games, the tattoo game and the rose game. The Tattoo game was conventional and you could easily track how key inputs were being handled, unfortunately I was unable to figure out the pipeline of how keys are processed from EVENT_KEYDOWN to the use of each of the below variables in the rose game. This is how they stored the key inputs. I couldn’t track this back to EVENT_KEYDOWN. So the hotkeys come from game data that might be localized with the game, it seemed to me that I was using up too much time without making progress so after requesting my mentors I decided to move on to another engine. Unfortunately, I haven’t created a PR as there is no actual progress to be seen.

LURE Engine

Finally, back to working on engines where EVENT_KEYDOWN is being utilized. There was something unique about this engine and that is there are multiple places where events are being polled unlike previous engine all did it one place, it did make it easier to enable and disable keymap, Another thing, the escape key did multiple different actions but still I considered it all as one action for the clarity, for example it could be used to quit game in main screen or exit the save/restore game popups, i thought maybe, if needed, it is better for user to change key for all of them with one click rather than going to each individual action and changing the key.
Here is my PR.

CINE Engine

It is a lot fun to do testing on if the game is has a beautiful aesthetic and CINE games are one of those. Personally I feel I am getting better at identifying keys and how to tackle engine specific code but CINE has pretty simple and organized code bloc for taking in input so It was usual way of creating a Keymap. Once I did that I realized I forgot to take into account Joy commands so had to fix that.
Here is my PR.

STARK Engine

When I looked at the STARK game, it was intimidating, for some reason I expected the keymap to be more complex but none the less it was simple too, nothing out of the ordinary. hence I was able to complete it with little resistance.
Here is my PR.

CRUISE Engine

CRUISE Engine is made by the same company that made CINE Engine. It was weird because it was the first Engine I had seen using global variable to hold keycode, so I did the same by introducing action which holds the state of customAction.

Another big issue I had faced was the way pause is handled is very unorthodox so I had to introduce a variable endPause to handle that.

And also I had to enable endpause as true on any joy input/mouse input/key input, and disable before kActionPause is checked to replicate behavior similar to before the keymap was introduced
Here is my PR.

Additional Details

As of now these PRs are being reviewed and I have note made the requested changes, will have to do after this blog.

SAGA Engine

I had wasted a day finding where the key inputs were being processed, the best option should’ve been asking the mentors. Once I did that they were able to guide me to how it was being processed and what what I had to change, essentially the ascii were changed to customEngine actions.

Also I had changed the keyboard handler which used to process ascii to accommodate customActions too

Rest was just changing the code so instead of ascii the actions were executed on customAction, also it took an this took most of the week because there were a lot of keys to be taken account of and the key registration was relatively convoluted in terms of defining a new new keymaps. I am still confused if escape key requires a keymap Action as in some places only escape is required and other only return. Would I have to make a keymap Action for both separately or an action that accommodates both, my mentor had advised “My thoughts are that not all the inputs necessarily need keymaps on those, but at least one is likely an improvement”. Thus I have decided that I will keep the action for escape.
You can find the PR here.

HUGO Engine

Hugo is comparatively simple, the keymap inputs were easy to identify and there were few keys. I planned to do a simple engine so I can target at least two engine per week
You can find the PR here.

AGOS Engine finishing touches

In my previous post, I left it at the issue where in the game, when you pause the game, essentially it says, “press any key to continue”, I just wasn’t able to recreate it with Joy commands as the original code only triggered on keyboard input. But the mentors helped me identify that there was a way to access joy inputs and I was storing it in _joyaction and then that way I could record all inputs even if they were joy inputs.

And that is the last of AGOS Engine and here is the PR.

COMPOSER Engine

Composer engine is very unique in how it deals with keyboard inputs and doesn’t follow the conventional way to handle keyboard, maybe because the games can be completely played with the mouse and only requires keyboard for saving the game. Thus there was not much to add in the engine.

Here is the PR.

MADE Engine

MADE engine is more typical in its approach so I could relate it to previous engines to update. I was easily able to map the required inputs into the keymap but there was a small obstacle. As I was replacing EVENT_KEYDOWN with EVENT_CUSTOM_ENGINE_ACTION_START, I found out while testing that they work differently, so when the key is pressed EVENT_KEYDOWN is triggered in each loop and EVENT_CUSTOM_ENGINE_ACTION_START is triggered only once when key is pressed/held down, thus I had to introduce _action which would store the action then execute it each loop until EVENT_CUSTOM_ENGINE_ACTION_END(key is unpressed) is triggered, this way I was able to accommodate continuous input as key is held.

Here is the PR.

DISCLAIMER: I had my exams for a week, hence I could not make sufficient progress

After my previous commit my mentors had made me realize that I did not take into account the game controller players. My keymaps would not identify controller key binds. Below review shows that I had made these two major errors, rest were small like naming conventions etc.

I was able to insert the yes/no option easily into the keymap. But the issue arose on how could we check if any of the controller key binds have been pressed. First I tried to loop through the const HardwareInputTableEntry defaultJoystickButtons[] and add all button into the keyMap action but I was advised that it is not the right way as it would look too cluttered when keyMap is accessed by the user. As of Saturday I am still stuck at this and hopefully I will be able to come up with a solution by the end of the day as next week I have to focus on another engine.

PR: Github

The easiest way to start identifying where you need to replace the Enum values is to search the word “key” in that project. This way you can narrow down which files you have to go through.

Now in terms of how to define keymaps, there is initial documentation available in ScummVM website. But that won’t be enough to start, it is important to look through previous commits in ScummVM github to find similarities in the current engine in which keymap is being integrated. This is how I identified the keys and made initial keymap, I divided the keymaps into two, Engine(AGOS) Keymap and Game keymap. Engine Keymap contains key bindings which are same throughout the all the games of that engine and Game keymaps are specific to that engine.

There were two issues I faced, in the previous commits when they were adding custom key binds, they would usually customize or replace Event object based methods for example here. But AGOS engine in most places did not use event.type to identify key binds, rather it used _keyPressed.keycode, but there was a solution, I searched previous commits thoroughly and thankfully I found SKY engine commit which would track EnumAction _action and then make necessary changes to it.

Another issue I ran into was that after I had completed my keybind was that my method wouldn’t take continuous input when key was held down, The mistake I was doing was I would reset the –
   _action = kActionNone
each time after the keys were processed, instead I should’ve  reset it when
   event.type == EVENT_CUSTOM_ENGINE_ACTION_END.
Hence, that solved the problem.

My Commit: AGOS: Add keymapper support