Hi, Philip wrote:
I have looked into XInput, but it does not support neither keyboards nor mouse devices which makes it rather unatractive for me. The only reason then to use it would be for extended joystick and game pad support which is certainly an option, but not something I'm sure about just yet. my comments: Agreed. For the record when we decided to go ahead and rewrite the G3D engine in C++ we also looked at XInput rather than DirectInput, and discovered the same exact problems and issues. XInput is primarily designed as a cross-platform API for handling XInput compatible joysticks and game controllers such as those for the Microsoft XBox 360 and/or third-party PC game controllers like the Logitech f510 specifically designed for XInput. As a result if we use XInput for joysticks we still have to use something else for mice and keyboard like the Win32 API for polling mouse and keyboard events from the OS. Since polling the OS for keyboard and mouse events is less desirable than using DirectInput going with XInput has very little value for us. Especially, since our surveys seam to show most VI gamers prefer the keyboard over mice and joysticks in a large amount of cases. Philip wrote: Multithreading would indeed be nice, but let's take a look at some of the practicalities there. Let us assume that you have two loops running in two separate threads, and they both modify the same global variable. You have no way of knowing what value the variable may or may not have, at any given time. To prevent this, we would need something similar to a critical section or a mutex to lock access to some resource during a short amount of time while a thread accesses or modifies it. Here we are getting into quite advanced concepts of programming (e.g. thread synchronization), which is way beyond the simplisity goals of BGT. my comments: Again, I have to agree. Multithreading is a very advanced area of programming, and if people are having problems with BGT now throwing multithreading in the mix would make things a lot more complex and confusing for the average user of the product. Anyone who isn't an expert at multithreading can create some extremely nasty bugs, problems, and if they don't know what they are doing end up crashing the end user's entire system because of a stupid mistake. I have done it myself quite on accident. For example, in the G3D engine I use multithreading in order to process input in one thread, process/update the enemy AI in another thread, and so on. That is fine, but you really have to be careful what thread a certain process was started on in order to shut it down properly. Several months back when testers were exiting MOTA they got a nasty blue screen on exit. It took me a good long while to find/fix that bug. The problem turned out to be the fact I called the WindowDestroy() function from the input thread, when the window was created on the main thread. Since the window was actually created on the main thread that meant that the WindowDestroy() function has to also be called from the main thread. It is exactly this kind of mistake new and experienced BGT developers could make if they aren't careful of properly starting, stopping, updating, and locking threads. I don't think some of these new developers are aware of how easy it is to hang or lock up a computer using an improper thread safe design. Cheers! --- Gamers mailing list __ Gamers@audyssey.org If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org. You can make changes or update your subscription via the web, at http://audyssey.org/mailman/listinfo/gamers_audyssey.org. All messages are archived and can be searched and read at http://www.mail-archive.com/gamers@audyssey.org. If you have any questions or concerns regarding the management of the list, please send E-mail to gamers-ow...@audyssey.org.
