Of Mice and Men

The game isn't going to look very glamorous as I continue to work on the back end. Now that I'm in the program loop proper, I have to start giving the game the event queues it's expecting. First of which is the mouse queue. The rendering of the mouse pointer is handled by Allegro all automatically. It kind of makes me feel guilty when I have replacement code that looks like this.

void ShowCursor()
{
    al_show_mouse_cursor(DISPLAY);
}

This is a little more tricky when I have functions that rely on real mode interrupt vectors. Namely INT 33h (mouse)  and INT 16h (keyboard). This is pretty much the whole input system I will have to rewrite. The way that these interrupts work was like this;  In DOS is that there used to be a table in memory that pointed to useful routines that hung out in RAM and ROM. The table was numbered 00h to FFh (0 to 255 in decimal)  It's one of the reasons why the 8088 could only do 640k of memory, even though it had enough address lines for 1 megabyte. The BIOS took up that extra 384k with things like keyboard (INT 16h) and video control (INT 10h). That's why it's was the Basic Input and Output System. DOS hung out on INT 21h and other things, like the printers used 17h for it's own.

What made these interrupts so useful was it gave DOS pseudo-mutitaksing. All you had to do was fire off in interrupt, and the whole system would come to a screeching halt as that interrupt was serviced. After it was done, the program continued, never knowing what happened. In the case of the keyboard and mouse, these interrupts managed a queue.

Underscore function, we meet again!

In the case of the keyboard, every time a key is pressed, INT 09h was fired by a physical wire (IRQ1) This paused the system, took the key, and put it into a queue. Later on, you could read back the queue of keys by calling INT 16h to see what has been pressed, or see what was pressed right now.

The mouse was the same way. Every movement of the mouse was queued, and you could ask the driver later if something moved and what the status was, or what the status is now.

Allegro has the ability to create event queues and can hawk various channels for events. You can look over the queue later. Normally, you would make one event queue and just register everything to it. Keyboard, mouse, display, sound, really anything including your own stuff. What I decided to do was create two event queues because that's what ROE kind of expects. (One for keyboard and one for mouse, as they both come in on their own channels asynchronously.) It makes it easier because I can just have the original code pull from the queue as opposed to having to write my own queue manager.

As an example I  have posed the old and new mouse event handler. They both do the same thing and return the data. Because the old handler uses some older interrupt functions, I commented what each line does. In the new handler, the code is a little more self explanatory. Truthfully speaking, it's finding elegant solutions to each of these commands I find extremely satisfying. Even better when the game just tools along with the new code, not knowing that the underpinnings have changed at all.

The new hotness

Old Mouse Handler