i'd have just ignored cross platform really and just finish it up and release 
the game, since another year has gone without the full release of this title

On Oct 29, 2010, at 4:52 PM, Charles Rivard wrote:

> Sounds like this is going to be a time consuming, troublesome, pain in the 
> buns, mess that should work out in the long run.  It is good, though, that 
> you have found where that blue screen bug was.
> 
> ---
> Shepherds are the best beasts!
> ----- Original Message ----- From: "Thomas Ward" <thomasward1...@gmail.com>
> To: "Gamers Discussion list" <gamers@audyssey.org>
> Sent: Friday, October 29, 2010 9:19 AM
> Subject: [Audyssey] MOTA Beta 16 Changes
> 
> 
>> 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. 
> 
> 
> ---
> 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.


---
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.

Reply via email to