Tuesday, December 17, 2013

Update and Preview - Input System

Hello again,

as some of you may know, I am focusing more on getting things done than on writing about them here. Since this tutorial is supposed to be at a harder level than most of those we already find over the web, it is indeed more complex and I, as expected, am making some mistakes on the process of engineering/coding it. But now, I am focusing on the input system part as I aim to create an article here explaining part of it. The article is supposed to go to gamedev.net as well.

For our input system, I'll be using an events (or messages) approach, where we capture events from our library (Allegro 5, in this case), morph them into one of our own events and then queue it for grabbing.

These are the base classes we'll be using:

InputEvent

First Phase Complete (80%)

  • A class that is simply a container for all desired information on any generated input event, such as its type and time of generation. Examples of child classes are:
    • KeyInputEvent;
    • MouseMovementInputEvent;
    • MouseKeyInputEvent; and so on.

Controller

Keyboard part Complete, mouse partially, and missing gamepads (30%)

  • A controller actually communicates with Allegro in order to create new InputEvent objects based on the events Allegro may spit at us at a given time. It has a local event queue that stores them until we check out on an event (or call a purge function or destroy the controller). Every controller should have an independent controller object and we can have as many as we need. This way, we'll be able to have more than one player on the same screen (one on the kb/mouse and two on two separate usb gamepad).

GestureInterpreter

Yet to be implemented (0%)

  • A gesture is an input behaviour. It is supposed to hold recognizable patterns to compare with the input events stored on a Controller object. Will hold all the translation necessary to go from a raw keycode to an internal input information (that can be a simple translated keycode). The code right now is using a temporary translation system where you can register the translations yourself.

The code


As of now, the code is all messy and full of test commands, not documented at all and completely untested. The memory cycle isn't complete, the events are being all forwarded but never deleted. This is stupid, I know, but I'll get to it when I get to it.


To summarize
  • The code has a functional event queue that hold on to these until you ask for them.
  • It will give you access to the events one by one, in order.
  • The time of generation is independent from the time you actually read them or update the controller; It marks the actual time of the generation.
  • The code lacks all memory management and documentation.
  • The Gesture Interpreter is still missing, and it will be the soul of this input system (and responsible for the memory cleaning, since it will be the last step of any events).
  • As of now, I am planning on a way to create the pattern recognition using a composite pattern registration approach. Will need some more thinking on that.
  • What the Gesture Interpreter will do when it recognize a pattern is yet to be decided. Possibilities are:
    • Call a callback registered along with the pattern.
    • Update a variable while the pattern is still valid for polling.
    • Generate an event and dispatch it somewhere.
    • Or, ideally, all three options, so anyone using this can choose what to do.

But if you're crazy enough to be interested in this, here's a link for the Code::blocks project:
Download

You'll need a working compiler and Allegro5 with TTF support to be able to compile and run the simple test program. It'll probably need some Build Options tweaks (sorry for that).  There's not much to see though, just it popping translated codes into the screen using a font I got from here. But I find it quite amusing to see how it captures input even during a Debug breakpoint.

But don't worry, things will fall in place; I hope!

Over and Out.