Mouse Eventhandler - doesnt work correctly

[r5ive]

Code: Select all

if( event.EventType == EET_MOUSE_INPUT_EVENT ) {
	if( event.MouseInput.Event == EMIE_MOUSE_MOVED ) {
	//	printf("%d - %d\n", event.MouseInput.X, event.MouseInput.Y);
		MouseRotation = true;
	}
}

every frame event.MouseInput.Event is EMIE_MOUSE_MOVED. even if i dont move the mouse. how come?

is there any solution?

thanks

[randomMesh]

You need to return true if you handled an event, false if not.

[r5ive]

thank you!
i did:

Code: Select all

virtual bool OnEvent(const SEvent& event)
{
	if( KeyStateChanged ) {
		KeyStateChanged = false;
	}

	if( MouseRotation ) {
		MouseRotation = false;
	}

	if( event.EventType == EET_MOUSE_INPUT_EVENT ) {
		if( event.MouseInput.Event == EMIE_MOUSE_MOVED ) {
			printf("%d - %d\n", event.MouseInput.X, event.MouseInput.Y);
			MouseRotation = true;
		}

		return true;
	}

	if( event.EventType == EET_KEY_INPUT_EVENT ) {

		if( event.KeyInput.PressedDown != KeyIsDown[event.KeyInput.Key] ) {
			KeyStateChanged = true;
		}

		KeyIsDown[event.KeyInput.Key] = event.KeyInput.PressedDown;

		return true;
	}

	return false;
}

but still i get true every frame at if( event.MouseInput.Event == EMIE_MOUSE_MOVED )

[vitek]

That's just the way it happens to work. Why does it matter?

[r5ive]

i wanted to trigger an action, only when the mouse is being used. now i just compare the mouse co-ordinates every frame and it works.

but why is there an event EMIE_MOUSE_MOVED, though its useless? are there advantages irrlicht handles it that way? it makes no sense to me, it would be helpful to have such an event.

thanks!

[vitek]

The windowing system generates the mouse events. Irrlicht just forwards them to your event receiver as SEvent objects for portability and convenience. You may get different results on different platforms (Windows/Linux/MacOS), but I don't know for sure, I haven't tried. Technically this is a bug because the documentation says

EMIE_MOUSE_MOVED The mouse cursor changed its position

In the grand scheme of things it shouldn't really matter because most everything you could do when the cursor moves requires you to know the previous cursor position.

If you want to call this a bug, I suggest you write a simple testcase (take one of the examples and simplifiy it) and post it here, or create a new thread in the Bug Reports forum.

Travis

[CuteAlien]

I just tested it on Linux and at least there it only produces the event when the mouse is actually moved. I also just checked the MSDN docs and WM_MOUSEMOVE should also only be generated when the mouse actually moved so basically that's what should happen on Windows, but maybe there is a bug (didn't see anything suspicious on a quick view). Would need to test on Windows which I can't right now.

Also I might note that there is no need to return true in your event-handler if you handled events. Returning true is to prevent any further event-handling, so unless you have a good reason to prevent the engine from processing mouse-events you should actually return false (but here it simply doesn't matter).

[r5ive]

hi,

i wrote a test with the following event query:

Code: Select all

virtual bool OnEvent(const SEvent& event) {
	if( event.EventType == irr::EET_MOUSE_INPUT_EVENT ) {
		if( event.MouseInput.Event == irr::EMIE_MOUSE_MOVED ) {
			printf("Mouse Moved\n");
		}
	}
	return false;
}

now using addCameraSceneNode() everything seems fine. Mouse Moved is being printed only when the mouse is moved.

but when using addCameraSceneNodeFPS() its the original issue. the mouse seems to be moved permanently.

i think there is a bug indeed. not in my eventhandler, but in the eventhandler of the FPS-Camera. it seems every frame the cursor is being moved to the center of the device window. that triggers the eventhandler.

my test case:

Code: Select all

#include <irrlicht.h>

using namespace irr;

#ifdef _IRR_WINDOWS_
#pragma comment(lib, "Irrlicht.lib")
//#pragma comment(linker, "/subsystem:windows /ENTRY:mainCRTStartup")
#endif

class EventReceiver : public IEventReceiver
{
public:

	virtual bool OnEvent(const SEvent& event) {
		if( event.EventType == irr::EET_MOUSE_INPUT_EVENT ) {
			if( event.MouseInput.Event == irr::EMIE_MOUSE_MOVED ) {
				printf("Mouse Moved\n");
			}
		}
		return false;
	}
        
	EventReceiver() {
	}

private:
};

int main() {

	EventReceiver receiver;

	IrrlichtDevice *device = createDevice(video::EDT_OPENGL,
		core::dimension2d<s32>(640, 480), 16, false, false, false, &receiver);

	video::IVideoDriver* driver = device->getVideoDriver();
	scene::ISceneManager* smgr = device->getSceneManager();

	scene::ICameraSceneNode* camera = smgr->addCameraSceneNodeFPS();

	while(device->run()) {
		driver->beginScene();

		smgr->drawAll();

		driver->endScene();
	}

	device->drop();

	return 0;
}

[bitplane]

The FPS camera animator moves the cursor to the centre of the screen as this is how FPS games work.
I'm not sure if this should be considered a bug or not. On one hand I'm thinking yes, as Vitek said the mouse doesn't actually move in user land, on the other hand, the windows API to move the mouse was called, so as far as Windows is concerned a movement happened.
Should we track the mouse position and filter these non-movements out?

[r5ive]

i implemented a manual position-change query:

Code: Select all

if( event.EventType == EET_MOUSE_INPUT_EVENT ) {
	if( !mousePos.equals(core::vector2di(event.MouseInput.X, event.MouseInput.Y)) ) {
		MouseRotation = true;
	}

	mousePos.set(event.MouseInput.X, event.MouseInput.Y);

i think to handle it this way using a FPS-Camera is acceptable. but is it as efficient as it would be doingthe way irrlicht handles it acctually?

[CuteAlien]

On one hand I'm thinking yes, as Vitek said the mouse doesn't actually move in user land, on the other hand, the windows API to move the mouse was called, so as far as Windows is concerned a movement happened.
Should we track the mouse position and filter these non-movements out?

We could add a check before moving the mouse to the centre if it isn't already at the centre. It's probably cheap, and the events are still created each time the windows API is called. And maybe add a comment to the check that is is done to prevent unnecessary event creation.

edit (2009-11-10): Don't know when it was fixed, but I just checked current svn and someone seems to have added that check by now. So now events are only created when the mouse moves even with fps-cam.