Hi Dark,
No offense, but that's not quite right. Some of the things you said is
just not correct. Let me try and clarify here.

Dark wrote:
I may be wrong, but i do seem to remember you originally writing using direct X,
then changing your mind to include cross platform support.

My reply:
You are missing some of the facts here. When I began converting the
Genesis Engine from .NET to C++ I first did so by using the SDL
cross-platform libraries. I did a lot of the early testing of the new
engine on Linux rather than Windows. However, as I was having some
technical issues with the cross-platform engine I decided to create a
Windows specific version to market to Windows users until i could
resolve those technical issues. Once I discovered SFML and added it to
the cross-platform engine I decided to release the game using the new
So my point here is that my intentions were for a cross-platform
version of the game all along. Clear back when i was using .NET I had
been tinkering with a cross-platform engine using Mono 2.6 and SDL
.NET for Linux. I've always had this in mind. It is just that I was
focused on trying to target the Windows market which is my biggest
market, and have not released the Linux specific versions before now.

Dark wrote:
There then followed a period when you seemed to go through a number of
rewrites both
of mota and of the genesis engine generally.

My reply:
For the most part that is true. One of the down sides to being skilld
in several different programming languages is deciding on one to
actually use. I know Visual Basic .NET, C# .NET, C++, Java, Python,
etc. I wanted to know how the same game performed in each language and
which APIs would give me the best results. Plus I wanted to find the
right combonation that will work on Windows and Linux. I've learned a
lot, but to an outsider, someone who isn't a programmer, what I'm
doing must look like goofing off.
To put this in some perspective when I took over Montezuma's Revenge
and Raceway I had just started USA Games. I really hadn't decided on
what I'd use, but was pretty sure I'd use Managed DirectX and the .Net
Framework. Well, in 2007 Microsoft dropped Managed DirectX like a hot
potato and in 2008 had replaced DirectSound with XAudio2, etc.
Everything I had decided upon had just ben dropped by Microsoft and I
was litterally back at the drawing board. However, I forged on with
the .NET Framework and DirectX until I discovered wonder of wonders
that Managed DirectX is buggy. I had to go to C++to fix it, or adopt
something else like SlimDX. I chose just to use C++ and native DirectX

Dark wrote:
Now however, you state that you are rewriting the windows engine to
use direct X,
and then writing a separate lynux engine.

My responce:
I think you are confused what I'm talking about here. I don't have to
rewrite anything. I have a fully operational Windows engine that uses
DirectX, PB Streemway,  etc which MOTA beta 13 used. All I need to do
is upgrade or modify it with some of the changes the cross-platform
engine has, and recompile MOTA beta 16 using the Windows engine.
That's not as bad as it sounds. Although, it will take a week or so to
make the necessary updates.
As far as a Linux engine goes I've already got one. The cross-platform
engine beta 14, 15, and beta 16 currently uses works fine on Linux. So
there is no need to do anything to the cross-platform engine to make
it run on Linux. It already does just fine.

Dark wrote:
this is not intended to be rude or in any way be a personal attack,
however, ----
to put it bluntly, I wish youd just finish the game!

My reply:
Yeah, I'm sure you do. Believe me when I say I wish I was done with it
too. Problem is I thought for sure the engine was done around beta 15,
but now discovered this blasted bug in SFML that has caused me no end
to grief. If it weren't for that bug I'd be working on levels 3
through 12 right now.

Dark wrote:
While I understand more people are using lynux, I wonder if, from a
utilitarian perspective,
spending this amount of time and trouble on a lynux port was actually worth it.

My reply:
Yes, from my point of view it is worth it. It doesn't matter if there
is one Linux user or one million Linux users playing my games, because
all along I created the Linux version for purely personal reasons. in
fact, the only reason I create the games at all are for purely
personal reasons for that matter. That reason is for my own personal
pleasure. Without any personal satisfaction/pleasure I wouldn't bother
spending any time writing accessible games. If I weren't using Linux
personally I wouldn't have bothered creating a linux version in the
first place.
However, getting back to the point, you are speaking purely from a
Windows user point of view. Let's face it you have games like Tank
Commander,  Shades of Doom, Super Liam, and loads of other accessible
games all for Windows. If you went out and purchased a brand new
MacBook with Mac OS, or purchased a new Del notebook with Ubuntu Linux
10.04 on it you'd want to know what games are available. The sad
reality is there aren't that many to choose from that is accessible
for a blind gamer, and playing accessible games through an emulator
like Wine sucks.
For example, let's reverse the situation for a second. let's assume
that GMA, Draconis Entertainment, USA Games, and a couple of other
accessible game developers decided to go out and buy Macs and forget
about writing games for Windows. How would you feel if the developers
told you that in order to play their games you would need to buy a
copy of VMPlayer for Windows, purchase Mac OS, and then run it in
VMPlayer just to play their games?
Well, that is the way Linux gamers are being left out right now by
accessible game developers currently. The majority of game developers
don't own or use Linux personally so don't support it. If I want to
play GMA Tank Commander I have to run Windows through a virtual
machine or try and get it working with Wine, because Linux isn't
supported officially. I don't blame GMA for not supporting Linux, but
none-the-less I would really appreciate having a native Linux build
rather than trying to emulate Windows and DirectX in one way or
Since I am a game developer, I use Linux a lot, I have a personal
stake in seeing that a linux version of my game is available.
Obviously, no one else is going to do it for me, and it seams sort of
stupid to create a Windows only version I would have to run through an
emulator like Wine when I could create a native Linux version as well
as a Windows version. From a personal point of view I've got more of
an interest in a Linux version than I do a Windows version. Since I do
most of the development and testing from Linux the last six months has
been a case of porting MOTA from Linux to Windows. Not the other way

Dark wrote:
if the second rewrite with specifically lynux components is as
necessary a matter
if it is going to slow down developement even further.

My response:
I think you misunderstood my meaning. I already have the
cross-platform engine that runs on Linux. Therefore I don't need to
rewrite anything. I was merely thinking ahead, down the road, that
someday I could update that engine to use native Linux APIs like
Speech-Dispatcher for speech output rrather than recorded wav files. I
didn't mean to imply that any of those changes or updates would have
anything to do with MOTA beta 16. I was merely pointing out that by
using two different engines each could support native APIs better, and
each version of the engine would have more to offer me for each
specific platform. On Windows I could use Sapi 5 and on Linux
Speech-Dispatcher for speech output. However, not all of the changes
or updates discussed were necessarily planned for the near future. I
was thinking more long term rather than short term.


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
All messages are archived and can be searched and read at
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