Code for 2 mice (aka lemmings) in C

[Calgor]

Anyone know how the best way to make it so that you can have 2 mice working together in gameports 1 and 2. I have heard it was done in lemmings for 2 player mode.

I reckon i know how to get a second hardware sprite for use and movement by a mouse/joystick in gameport 2, and also know the location of this second sprite.

But how do I get it so that when the user clicks using the mouse in gameport 2, that it triggers an event of clicking on the gadget (so that my idcmp gadget routines can pick it up) ?

I think i may need to create an event on input.device for the left/middle/right mouse button clicks on the given x,y coordinates.

Any help or ideas appreciated!

[Calgor]

Anyone? Seems like more asm coders around than C here!

[Toni Wilen]

Games normally don't use OS routines to read the mouse.

But yes, you need to create "fake" input events if you want to support two mice simultaneously and also be OS-compatible.

[Calgor]

Thanks for confirming that it should be at least possible and I am not missing something obvious

I should find out if it will be satisfactory (also for speed) within the next week when I code this part up. Obviously it will not be able to use menus if I do it like this but that's okay.

Interestingly, I came across some code which switches the mouse to the other gameport (but then the original mouse would not work).

[ppill]

XAtoms, a logical game from aminet includes a small utility called TwoMouses which:

allows to control your mouse pointer with two mouses (the second one is connected to the second game port). It's very useful for playing games controlled by two users with the mouse (e.g. Exploding Atoms).
[..]
Known bugs: Eats a lot of CPU time when you're using the second mouse

Send comments and bug-reports to mjsoft@k332.feld.cvut.cz

no source code but might be of some help.

[Calgor]

@ppill: Thanks, but I wanted to code it myself.

Ok, I got my code to be able to use a joystick to control the mouse cursor and do left mouse button clicks (ala Dragons Breath)

Then once I had done that, I have used a second sprite as a second mouse cursor, and I can get this to move around with the joystick.

BUT, when I try to simulate the mouse clicks with input.device with this second sprite, the location of the mouse click always ends up being in the location of the actual mouse, not the location of the second sprite!

I cannot seem to get it to set the x,y position of the simulated click to what I want, say x=100, y= 100. It always uses the position of the mouse cursor.

Here is code snippet for ppl who understand C (seems to be ignoring my x,y overrides):
case IECODE_LBUTTON:
logMsg(" FIRE BUTTON PRESSED \n");

input_io_msg->io_Data = (APTR)&input_event;
input_io_msg->io_Length = sizeof(struct InputEvent);
input_io_msg->io_Command = IND_WRITEEVENT;

/* BUTTON DOWN */
input_event.ie_NextEvent = NULL;
input_event.ie_Qualifier = NULL;
input_event.ie_X = sprite_mouse1.x;
input_event.ie_Y = sprite_mouse1.y;
input_event.ie_EventAddress = NULL;
input_event.ie_Class = IECLASS_RAWMOUSE;
input_event.ie_Code = IECODE_LBUTTON;
DoIO((struct IORequest *)input_io_msg);

/* BUTTON UP */
input_event.ie_Code = IECODE_LBUTTON|IECODE_UP_PREFIX;
DoIO((struct IORequest *)input_io_msg);

break;

[thor]

My guess is that you should set the ie_SubClass member to the appropriate value (0 for the left port; 1 for the right port). But it's only a guess (as I haven't done anything similiar), so I don't know if it helps.

[Calgor]

The ie_SubClass field only appears to be used when moving the actual mouse pointer (with the NEW/POINTERPOS classes).

I have tried everything else I can think of with input.device, but can't get it to work

Even tried to simulate a GADGETDOWN/GADGETUP input event as an alternative, but couldn't get that to work either.

[thor]

Do you set the x/y pos to the input stream with IECLASS_POINTERPOS before the click event? Can you post your code?

[Calgor]

I have used the IECLASS_POINTERPOS and IECLASS_NEWPOINTERPOS, but they move the actual mouse cursor which is not what I want.

A hack could be to move the mouse cursor, click, then move it back to the original position. This could be done I think using the NextEvent field for 4 total events (POINTERPOS new position, BUTTON down, BUTTON up, POINTERPOS back to old position). BUT, this is too much of a hack and could stuff up the actual mouse cursor if it was being used for anything.

Here is the code to set the pointer position anyway (could use SetPointer() for this):
input_event.ie_NextEvent = NULL;
input_event.ie_EventAddress = NULL;
input_event.ie_Qualifier = NULL;
input_event.ie_Class = IECLASS_POINTERPOS;
input_event.ie_SubClass = 0;
input_event.ie_Code = 0;
input_event.ie_X = sprite_mouse1.x;
input_event.ie_Y = sprite_mouse1.y;

input_io_msg->io_Data = (APTR)&input_event;
input_io_msg->io_Length = sizeof(struct InputEvent);
input_io_msg->io_Command = IND_WRITEEVENT;

/* SET MOUSE CURSOR POSITION */
DoIO((struct IORequest *)input_io_msg);

[Calgor]

Doing the 4 events in a row as I suggested above works, but I could not get NextEvent to be recognised, so I had to do 4 separate calls to DoIO(), instead of just the one using the NextEvent parameter.

This could cause a problem for out of order events if there are other events for the actual mouse in between.

[rgen]

Originally Posted by Calgor

I have used the IECLASS_POINTERPOS and IECLASS_NEWPOINTERPOS, but they move the actual mouse cursor which is not what I want.

A hack could be to move the mouse cursor, click, then move it back to the original position. This could be done I think using the NextEvent field for 4 total events (POINTERPOS new position, BUTTON down, BUTTON up, POINTERPOS back to old position). BUT, this is too much of a hack and could stuff up the actual mouse cursor if it was being used for anything.

But the system have only ONE mouse, there are no structures for a second mouse, so everything you feed into the system is for its only mouse and I think the hack above is the best you can do.
Try the hack and see if it is recognizable for a human as the input.device has the highest task priority (20) in a normal system and try to set your task to pri 19 or 21 to prevent interrupting your hack by another task.
Maybe another possibility is to switch the mice when a mouse button is pressed.

[thor]

Originally Posted by Calgor

Doing the 4 events in a row as I suggested above works, but I could not get NextEvent to be recognised, so I had to do 4 separate calls to DoIO(), instead of just the one using the NextEvent parameter.

This could cause a problem for out of order events if there are other events for the actual mouse in between.

ie_NextEvent was never used, so it's normal.

This function was documented in V34 and earlier to allow
chaining of events via ie_NextEvent. The implementation
never allowed that. The documentation now reflects this.

[Calgor]

@Thread

Thanks for all the help and suggestions.

Seems like there is no optimal O/S friendly way. I will try as rgen suggested to change the mouse port (making it a total of 6 DoIO calls! edit: okay, maybe less than that).

I thought about doing it via commodities or an input handler, but figured if I can't get it to work in a program, that wouldn't work either (someone can correct me, as I haven't written either yet).

@thor

Where did you get that quote about NextEvent from? I couldn't find it in the include files (K/S 3.1) or the RKRM (K/S 2.x). I found it on a webpage, but unsure of the doco source:
http://www.ummon.org/En/Amiga/API/Am...RITEEVENT.html

[thor]

The quote about NextEvent is from the NDK Autodocs from version 2.0 onwards. In input.doc at section input.device/IND_WRITEEVENT.

[Calgor]

Thanks! Stupid MSWindoze explorer search function couldn't find it - and still can't (I know for a fact that it misses things in its "intelligence", windoze 98 didn't have this problem. Apparently the intelligence can be removed by editing the registry.....).