Hi everyone, At last I have located the cause of the blue screen. This morning i did a step by step debug of the ExitProgram code when the Visual C++ debugger began giving me the exact error codes we are seeing in the dump files. So obviously I know what the debugger is seeing and we have been experiencing is the same problem. Fortunately or unfortunately, depending on how you see it, the error is not in the game engine itself. So I'm not totally crazy and am not actually at fault here. The bug seams to be located in the SFML libraries themselves, the Windows SFML libraries to be more specific. With this in mind I think my alternatives are pretty clear. Since SFML appears to be the cause of the blue screen on Windows operating systems I'm going to have to create two different builds of the Genesis Engine. One designed for Windows operating systems using DirectX, Sapi, and other Windos specific APIs. The second using SFML, Speech-Dispatcher, and Linux specific APIs. Although I'm not exactly overly thrilled about this alternative I do see that this probably is the best option in the long run. For one thing I've known for quite a while now that developing a cross-platform game engine would be what I call a "lowest common denominator" approach. What I mean by that is that often times operating systems are so different from a programming standpoint that whatever I did I'd have to use only coding practices, development libraries, etc that all the operating systems have in common like SFML. Unfortunately, this doesn't always work out that well in practice. For example, Wwhile Microsoft Windows is written in C++ Windows applications written in C++ are far different from an application written in C++ for Linux. Thanks to Microsoft's Windows API, which is required for Windows applications, they have added a lot of pproprietary functions, data types, headers, etc that are totally different from those used by anyone else. That obviously makes it difficult to create cross-platform software because the developer constantly has to sidestep and avoid anything that is Windows, Linux, or Mac specific as much as humanly possible. To give a simple example here let's consider the main function. In most cases you can start a C++ program with the main function like this.
int main (int argc, char** argv) { // Add initialization code here return 0; } That is the most common way to start a C++ application. Most platforms supports this, but on Windows only commandline programs begin with the main function. For full blown Windows applications every C++ program begins with the WinMain() function which is naturally only supported on Microsoft Windows of course. It looks something like this. int APIENTRY _tWinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, LPTSTR lpCmdLine, int nCmdShow) { // Add initialization code here return 0; } Obviously right off the bat we have a problem with cross-platform compatibility. Windows and a Linux application don't even use the same main function which is something a cross-platform developer has to get around. Usually, the quickest way to solve this problem is to create a WinMain() function that calls the standard C++ main() function to perform program initialization. It isn't exactly hard to do, but is still a hastle because Windows requires something extra to properly initialize the program. The differences between Windows applications and Linux applications don't stop there. In terms of programming games this gets to be more complicated, because we are dealing with various APIs to handle graphics, input, audio, networking, etc. While cross-platform APIs like SFML and SDL do exist they are also built with the lowest common denominator in mind. They don't always offer the flashier features you might see in a platform specific API like DirectX. The best example I can think of is input handling. SFML and SDL use an event driven input system which means it polls the operating system for Windows events and acts upon a key press or key released event. This is often quite slow because it has to wait for the event message to be processed through the operating systems message queue, and the message queue was never designed for rapid key presses or to handle more than two or three key down events at a time. This is why in MOTA beta 15 it isn't possible to hold the arrow key down to walk and pres enter to pick up something. Contrary to common belief that isn't a bug, but the fault of the generic keyboard support SDL and SFMl uses to maintain cross-platform compatibility. On Windows Microsoft has created an API to resolve this problem. It is called DirectInput. DirectInput bypasses the message queue altogether and directly interfaces with the keyboard, joystick, and mouse. Being directly interfaced with the keyboard not only makes it faster to poll the state of the keyboard, but it can acquire the entire state of every key on the keyboard at once. It makes it possible to have multiple keys held down at once and handle more actions at once. Unfortunately, DirectInput is a Microsoft Windows specific technology, and if I'm running my game on Mac or Linux I really can't use it unless I run my games through an emulator like Wine. Which brings us to the second problem with developing cross-platform programs. Every operating system has proprietary APIs and technologies that are specific to that particular platform. As a result they are likely to be better than the cross-platform alternatives, but requires more effort to support. That's the problem I'm facing now. Take speech for an example here. On Linux speech can be accessed through an API called Speech-Dispatcher that gives me access to ESpeak, Festival, Eloquence, etc. That's all well and good, but on Windows speech is generally handled through Sapi. On Mac OS it uses Apple's own Speech API. One alternative is to use the lowest common denominator approach by including something like ESpeak in my engine, or I can go the extra mile and support all of these technologies on a per platform basis. For the moment I'm using prerecorded speech to resolve this sticky situation, but there may come a day when I will have to use some sort of Speech API directly. Enough said. Basically, by creating platform specific versions of the Genesis Engine I can remove most of the problems of cross-platform development. It is more work, but I can wrap each version of the engine around those proprietary and platform specific APIs for maximum effect. If I create a version for Windows I can use DirectX, Sapi, the Windows API, and all the other Windows stuff to make the engine operate at maximum performance on Windows platforms. On Linux I can continue using SFML for input, audio, networking support, etc but can also go ahead and use something like speech-dispatcher for speech output etc. Basically, just go ahead and make a completely Linux specific version of the engine without worrying about supporting Windows as well. This will make both versions of the engine run better because they will handle each operating system differently, and use whatever APIs etc are natively supported on that platform. So that's what I plan to do with MOTA beta 16. Over the next week or so I plan to revamp the Windows version of the Genesis Engine and try and make the Linux and Windows version as compatible as possible from a programming standpoint. What I mean by that is that the Genesis Engine is all object oriented anyway meaning most of the platform specific code will b hidden behind wrapper functions and classes that are there to make the game easy to recompile with wichever engine I'm using. If I call a function like Audio::SoundPlay (PLAYER_FIRE, false); it really doesn't make any difference to the game if I'm making a call to XAudio2, DirectSound, OpenAL, because Audio::SoundPlay() is a handy class method that wraps the audio API being used. In most cases this works fine, but it isn't always that easy. There are times where I have to pass a special parameter or a variable of a different data type that is not common between the two APIs. For example, on Linux the Speech-Dispatcher API takes a common ansi character string. On Windows Sapi takes a Unicode string for handling Unicode. I'm going to have to make sure my Speech::SayString() function takes the same string type, but converts it to Unicode behind the scenes before passing it on to Sapi in the Windos version of the engine. This is where the most difficult part of managing two engines lies. Deciding what parameters and data types each function will accept and then converting as needed to whatever the specific API requires. Over the following week I'm going to work on the game engines and attempt to make them as compatible as possible so I can just grab the MOTA source code and compile it with whatever engine I need to. If I'm successful I should be able to compile it with whatever engine I need to without having to do very much editing or messing around with a lot of cross-platform specific changes. 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/gam...@audyssey.org. If you have any questions or concerns regarding the management of the list, please send E-mail to gamers-ow...@audyssey.org.