Re: Interview

[Pierre Phaneuf <pp@ludusdesign.com>]

"Philipp Gühring" wrote:

> 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 used structs in both (Win32 and Linux) versions of Quadra, and both
platforms do word alignment. There is a compiler pragma that works on
both Visual C++ and gcc/egcs, "#pragma pack(1)" to start packing and
"#pragma pack()" to stop.

Reading member by member is the right way to do it. But we are lazy
bums. :-)

> 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

Am I right or this hack ignores the GGI_DISPLAY environment variable if
it has to use palemu? I hope not...

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

If you have zombies, I think it may be that you have to handle the
SIGCHLD signal. See the signal section of a good book on Unix
programming for more information.

One problem we had between the Win32 and Linux versions of Quadra was
the values used for the keys read in raw mode. Between DirectInput and
Svgalib, they were only slightly different, with no conflict found
between keys, but X had keycodes completely different, we had to use a
lookup table that we populated with a lot testing.

Also, the input in the Win32 version was a bit schizophrenic: on one
side, it used DirectInput to get the raw scancodes of key pressed and
key released, and on the other side, it listened to the Win32 API
messages that contain translated key presses (we are french canadian, so
accented chars are important to us, and they are done with diacritic
keys on our keyboard (if you don't know what they are, just know you
don't want to implement that yourself)). This was no problem for X, as
each KeyPress event contain both the keycode and the translated stuff,
but for Svgalib, we had to add a "mode" to our input system, and make it
switch back and forth between raw and cooked input. Aww...

I think GII (the input counterpart to GGI) handles key presses in a way
similar to X, so all must be fine. Good library, I agree, just not what
I need.

It's almost definitive that we'll drop the Svgalib support in our future
titles at Ludus. But we also plan to have dynamically loadable plugins
for the various modules (like video and input), so a plugin adding GGI
support to our games is not out of the question, far from it. But it is
possible that our next games use multiple windows, so it might be a long
time before I get to do that GGI plugin.

-- 
Pierre Phaneuf
Ludus Design, http://ludusdesign.com/
"First they ignore you. Then they laugh at you.
Then they fight you. Then you win." -- Gandhi