   Keyboard/Mouse input & Multithreading
  I'm pretty much a noob when it comes to game programming but it's always been something that I looked into.... then encountered a problem I couldn't figure out. Then it sat on the side for a while. Rinse and repeat. Due to recent happenings in my life I'm picking it up again and found a solution to the problem I'm having. My question is is there a better way?One of my weaknesses is trying to do something "like the professionals" instead of just getting a working version finished.I think the easy way of handling input is processing Window's messages and adjusting the camera, changing state, etc accordingly. I decided not to do that but instead used DirectX 8. (The code is older than I'd like to admit)The code at the end is what I wrote in VC++ 6 and the solution I found said to insert the DirectX functions to read KB/mouse state inside the else block. I guess the thing that stopped me so many years ago was that everything was in multiple threads (that and I thought this project was getting too big for me). So I thought that was the way to go.My question is in the "high end" engines how is input handled? I basically wanted to complete an engine that I could use in a variety of projects with close to zero tweaking in the end as far as the more low level things go.... such as reading in input.Thanksint CGameEngineApp::Run() {// TODO: Add your specialized code here and/or call the base classMSG  msg;do {if(::PeekMessage(&msg,NULL,0,0,PM_REMOVE)) {if(!PreTranslateMessage(&msg))::DispatchMessage(&msg);}/***ENTER GAME LOGIC***/} while( msg.message != WM_QUIT);return msg.wParam;//return CWinApp::Run();}Edit [05/13/09 16:13]: Changed code to actually work as game loop. Removed else block which never got executed.[Edited by - Robione on May 13, 2009 3:00:02 PM]
  The code you listed there is pretty much the best way to handle messages that come from the windows message pump. Basically, the message pump is a queue of messages that arrive at your doorstep. You grab one each iteration of that loop and process it. I don't think it can get any simpler then that. There is very little overhead. Your problem might get complicated when you add in DirectInput processing. I'm not an expert with DirectInput, but I have dabbled in it and know the basics of polling it for Joystick values. The idea is the same as the message pump, but with added complexity of setting up DirectInput.What I get form your question is that you want to put this on to another thread. Well, I see where your coming from, and I want to discourage you from doing it. Firstly, in order to pass data from the main process to/from your input thread, it requires Critical sections, events, or possible mutexes. Although, they can be a fast way to share information, it is still overhead and can add precious milliseconds between key press and event reaction. Alternatively, you can skip all that and have the input directly wired to objects in 3D space. This causes overwriting issues and will become a headache.So, what I do know about professional game engines is that they still use the message pump for basic input. Some do use DirectInput for faster access, but this can be difficult to set up properly. If you are going to redesign your engine to use DirectInput, design it well so that the next time you look at your code, it won't scream to be fixed up. There is no such thing as an ultimate design, just your design. And if it ain't broke, don't fix it.   ;Quote:Original post by RealMarkPWhat I get form your question is that you want to put this on to another thread. Well, I see where your coming from, and I want to discourage you from doing it. Firstly, in order to pass data from the main process to/from your input thread, it requires Critical sections, events, or possible mutexes. Although, they can be a fast way to share information, it is still overhead and can add precious milliseconds between key press and event reaction. Alternatively, you can skip all that and have the input directly wired to objects in 3D space. This causes overwriting issues and will become a headache.Yeah that's basically how I was thinking about it... separate thread. When I was putting this together initially I had these grandiose ideas. Now I'm going for something I can do in a reasonable amount of time and that's realistic for my game programming level... which is 0. So I'm going to make an asteroids clone as a starter but I figured I'd get my old code working and use that as a base.The whole idea from separate threads came from two sources... some book I picked up in B&N years ago that said every game consisted of "modules"... i.e. video, sound, ai, networking, etc. The second source was one of the earlier Game Programming Gems books which discussed micro threads which significantly cuts down on thread switching time. I just combined the two together in my head.... not sure why. My brain just likes to complicate things.In your opinion (anyone really who wants to chime in) .... eventually duties need to be split up into threads I would think, especially with multiple core processors.... what would be the duties you give the threads?In a single threaded app I guess a basic game loop would look something like:-Read input-Process input-AI-Physics-Networking (output)-Render Video-Play SoundFeel free to adjust that loop if I missed something. Things that use to be on the CPU are being offloaded (graphics as we all know, and recently physics) does this change how the threads would be organized?I'm just going to put everything in the else block I have above for the moment so I can get this working but I'm curious as to your views when I improve this down the line.   ;  Well my game currently has the following threads (that I created, windows and some directx components seem to create there own interal ones, last check I think I have 4 such threads).-Window Thread: This is the thread that create the window and handles the windows messages. It stores important events into buffers which is then moved into the "game buffers" at the start of a game update. For example I have a buttonsPressedBuffer[256] which stores if any button (includeing mouse) was pressed since the last update.The reason I broke this into its own thread is I found that this thread seems to get lost inside windows whiel certain things happen, resulting in my code not getting run. For example moving the window. Not only does it pause the game, but it also doesn't redraw the scene which doesnt look good if part of the window was hidden last time the scene was rendered. Also when I started playing with networking stuff I ran into problems with this causeing the app not to respond, eg when testing on just my comp I minimsed the server so I could have 4 clients up for testing, then wondered why the game seemed to freeze cause windows had decided to look after the main thread on the server...-Game Thread: This does all the updating and rendering. With a fair bit of work I could split updates and rendering apart, although I see no need too.