Re: Interview

[Philipp Gühring <p.guehring@enemy.org>]

Am Fre, 03 Sep 1999 hast Du wahrscheinlich geschrieben:
>"Philipp Gühring" wrote:
>
>> After having ported Würstelstand successfully to Linux, I want to
>> offer an interview, if anyone is interested.
>
>Ehm.. with who ??
With me.
Oh, I see, i said it in a confusing way. Sorry.

>An article on the encountered porting woes would be cool though :)
Is that the only question? (I thought an interview consists of
several questions) But ok:

The Dos version of Würstelstand was developed from 1996 to 1998, as
far as I remember. What we wanted to do now was to create a
Linux-binary of the game-engine, which is capable of playing all the
binary data from the Dos-Version. So we declared the binary data as
architecture-independet, and started to work on the Linux-client.
This is the reason, why we didn´t change the codepages of the texts
and sourcecodes (as some people suggested). We had our own fonts,
which used the codepage from Dos, so we left the data files
untouched. It was my idea to be able to install the Dos version from
the CD-Roms back from 1998, then install only the new binary, and play
the game right away.

There was only one problem with all the data files:
We used structs to store the information about the products,
telephone calls, customers, ... We just defined the struct, and used
an fread(Handle, struct,1, sizeof(struct)) to load them into the game.
But this didn´t work with the Linux version. I looked through the
code, and suddenly I rememberd the alignment, I knew from my AXP
machine. It turned out that all the integers in a struct are
2byte- aligned. So there were holes in the structs, which were
missing in our data-files. What to do? I decided to fread groups of
the members of the struct by hand, which is not a nice solution, but
the only practical, because I really wanted to reuse the old files.

We started by searching the web (especially LGDC) for Game-Developing
material, and we found PenguinPlay (not much more than some ideas),
SDL (there was not enogh information, or it didn´t looked good to
us), and GGI (which seemed to do what we wanted). We thought about
it, and decided that we need a graphics library, which gives us
320x200x256, and displays it whereever possible. We needed
DirectBuffer, because that´s the way, is was done in DOS (writing
directly to the memory of the graphiccard at 0xA0000). So voted for
GGI, and ported all the graphic routines to it. After it was done,
and it ran on an 8 Bit X-Server, I found the way to use the palemu
target from GGI (I forgot to export the GGI_DISPLAY, ...) But the
problem was then, that this palemu thing gives no DirectBuffer. So I
went through the whole code of the game, and inserted Put(); wherever
the screen needs to be updated. So Würstelstand is now able to use
Non-DirectBuffer targets.

For the sound ouput we found the libmikmod package, which seemed to
be the only library that is capable of playing .mod and .xm files.
The only problem with that library is that it "plays" to a file
called music.raw, of the other output devices are not accessible.
(Having a mp3 player in the background, which uses the soundcard)
And it fills the harddisk, until there is a harddisk overflow. So I
recogniced the raw-driver, and disabled the MikMod Soundsystem if
needed. But there is still the problem, how to play and control with
libmikmod in the background. I am currently forking, but it leads to
zombies, ... and the music is still playing, when Würstelstand gets
killed.

And the last big thing was the distribution. We wanted to make a
single CD-Rom, where everything is on it. So our customers should buy
the CD-Rom, and then be able to play it under Dos, Windows, Linux,
and even have the source of it. The Dos version was rather easy, we
just used copied the files from the old distribution. With the Linux
version, I decided to create .tar.gz archives, and .rpm ones, so that
everyone can use it. Creating .tar.gz files is very easy. But
creating .rpm files is just the opposite. I looked at
http://www.rpm.org , downloaded "Maximum RPM", and gave up, when I
saw that it consists of 400 pages! But then I read that 100 pages
about creating RPMs, and after 2 days, the first working .rpm was
born. Some words that might help Rpm-newbies: Do not delete
directories like /usr/src/packages/RPMS/i386 . RPM crashes, when it
wants to write the built RPM at the end of a 1 hour building session,
so you can do everything again! If you want to build a .rpm from
about 80 MB videos, then you must have 500 MB of free diskspace, and
a very fast machine (I suggest using an Alpha/AXP). Do not try to
fake the free diskspace by using symbolic links, and overwriting the
data again! RPM copies the whole data that you want to package about
4 times across the disk, and fails at the end, if just a single
directory is not available (instead of creating it, which can´t be
that big problem!?!). This is not what I call userfriendly. So be
prepared and invest a lot of time into RPM, before getting into
troubles with you deadline.

--------------
Any more questions?

Many greetings,
--
~ Philipp Gühring              p.guehring@poboxes.com
~ http://www.poboxes.com/p.guehring  ICQ UIN: 6588261
~ Please change p.guehring@xpoint.at to p.guehring@poboxes.com