[2.1] sdlinputhandler and multithreading

[ikyle620]

I'm looking at the sdlinputhandler.cpp provided in the tutorials for Ogre 2.1. I'm using the multithreaded tutorial with the cube moving and resetting as my base for this little endeavor. I'm trying to find a way to allow for my logic game state to listen to or react to input.

I've noticed that the sdlinputhandler is already listening for effectively everything, and if a logicsystem has been given to it, it will queue a message from the graphics system to that logic system. For Example:

Code: Select all

	case SDL_KEYUP:
		{
			...
			if (mLogicSystem)
				mGraphicsSystem->queueSendMessage(mLogicSystem, Mq::SDL_EVENT, evt);
		}
		break;

Finally, in the logic system's processIncomingMessage(...), there is a case for an SDL_EVENT, and a //TODO.

Code: Select all

	void LogicSystem::processIncomingMessage(Mq::MessageId messageId, const void *data)
	{
		switch (messageId)
		{
		...
		case Mq::SDL_EVENT:
			//TODO..
			break;
		...
		}
	}

Ultimately, my question is one of design: should I continue this line of implementation? How I should get my logic system to get input events? I would have thought that I'd want all of my input to pipe into the logic system, let the logic translate the input into things the game needs to do, and then send appropriate messages out (whether those be GAME_ENTITY_ADDED-like or completely new cases for other reasons). I could move the SdlInputHandler from the graphicssystem constructor to the logicsystem constructor (although that would be messy due to the needing of the sdlwindow), or I could give the SdlInputHandler a different listener when it is constructed (give it the logic game state).

It looks like the planned implementation was to catch all of the input in the graphics side and pipe it over to the logic side, and I'm having trouble understanding why. While typing this, I feel like I need to point out that I don't mean that as a criticism, it is more of the fact that I'm barely confident in my own abilities, and not at all confident in my own design decisions. Are there valid reasons to listen to input from the graphics side? An I wrong in wanting the input to go solely to the logic side?

Thanks.

[dark_sylinc]

It looks like the planned implementation was to catch all of the input in the graphics side and pipe it over to the logic side, and I'm having trouble understanding why. (...). Are there valid reasons to listen to input from the graphics side? An I wrong in wanting the input to go solely to the logic side?

Because, to the best of my knowledge, if we want a (cross platform, cross API) compatible way of grabbing input, you have to grab the input in the thread that controls the window, which is the thread that controls graphics. It's an OS/API limitation. If you were to restrict to certain OS/API it could be possible.

I too wish it were the reverse: logic captures input and, if needed, pipe to the graphics system. But unless someone proves me wrong and finds a way, input capture has to be done from the graphics thread, and then piped to logic. That's simply the reason.

[ikyle620]

Awesome! thanks for the explanation.

[hyyou]

For other readers, here is a related thread.
https://discourse.libsdl.org/t/sdl-1-2- ... in/17855/3
It states that :-

Windows requires event polling to be performed by the “main” thread.

[dark_sylinc]

For other readers, here is a related thread.
https://discourse.libsdl.org/t/sdl-1-2- ... in/17855/3
It states that :-

Windows requires event polling to be performed by the “main” thread.

To add more info to that:
I recently became informed that it is possible to do D3D11 rendering in a different thread. i.e. Windows is created and event polling handled in "main thread", but D3D11 initialization and execution, including Swapchain's Present() happening in another thread.
However that is not exactly how Ogre has been wired up since the beginning (and 2.2 will not address that either).

Such setup would allow polling input from a different thread than Ogre's. Either have 2 threads (1 for logic which also handles window events + 1 for Ogre/graphics system) or have 3 threads (1 for window and event handling + 1 logic system + 1 graphic system) with the main thread being a simple pipe to the other threads.
Having the main thread exclusively handling window & event polling increases perceived responsiveness. Even if Ogre or your physics would get hang or stuck doing something very slow, your users would still be able to easily Alt+Tab, minimize and resize your windows.

But even if we were to fix Ogre's design issue, OpenGL will certainly give nightmares (assuming it's possible, it still might work in one driver, but break in a thousand other configurations). And then there's Linux (X11, Wayland), macOS, iOS and Android to worry about.

I do know that on Android the best way is to use 3 threads (main thread dedicated to handling window events, otherwise the phone becomes extremely unresponsive... like several bloated Android apps), but since that's currently our least supported platform, it's more anecdotal than anything. I did get previous versions of Ogre to work this way so once Ogre 2.x gets working Android support we'll get this sort of setup.

Because most games on Windows tie the graphics thread with the main window handling/event polling thread, that's the most tested codepath, not just for us, but also for drivers and even the OS itself.

The reality is that few people know how to handle event polling and render in two different threads; and it requires not only knowledge & experience but also good testing in many configurations.