Sounds like the best approach, although for your sake I hope this won't add
too much onto development time since I know how anxious you are to finally
get this project off! your back and take that nice long break I'm sure
you've been hankering for. And goodness knows you've more than earned it.
We are the Knights who saaaaay...Ni!
----- Original Message -----
From: "Thomas Ward" <thomasward1...@gmail.com>
To: "Gamers Discussion list" <gamers@audyssey.org>
Sent: Friday, October 29, 2010 8: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.
