[Troll] This Endian Up

["Kenneth W. Flynn" <flynnk@astro.umd.edu>]

At 09:02 PM 7/19/00 -0400, you wrote:
>[Don't know if Kenn meant to send this directly to me or not but
>figured I put my answers here anyway.]

Sure, it's as good as any forum.

> > The file formats are little endian.  Without doing all of the bit
> > manipulation myself, there is no way for me to read them in Java.  Java
> > assumes all data is big endian (network order).

Well, I've written code to read the palette's and sprites from a file, and 
I'm just doing the bit manipulations explicitly.  It works, and it isn't 
all that difficult (I just wrote a routine to read two unsigned bytes, bit 
shift one and then or them together.  It's not too terrible, but still...

>I was actually thinking of making Troll Bridge not care.  By putting a
>16-bit number of a known value first, you can easily determine if the
>file is the same endianess and compensate.  (And perhaps automactically
>save a convert file.)  Granted that doesn't help you're situation.

It still would be a good idea, because I intend to write a Java map editor 
and such.  I am unlikely to save my maps as little endian, so...  :)  You 
did mention you want improved design tools.  This is a problem that Java 
can solve pretty easily.

>Java should of put in a flag or something that allows you read as little
>endian.  A lot of old file formats are little endian.

Agreed.  I was actually surprised they did unsigned.  But then again, I 
discovered some bugs in their tutorial on this information.  I was looking 
at the section on bit manipulators to do the above (to be sure they work 
the same as C) and discovered a long discussion on how you can do 12 & 13 
and get 12.  They then had 12 written as 1100.  Which is definitely not the 
case, since there are no unsigned integers in Java; everything is 2's 
complement.  Bad, bad, bad....

>Big endian doesn't have as many advantages as you list.  Converting Troll
>Bridge to a big endian machine would take all of two seconds to implement
>BinaryReadFile and BinaryWriteFile.  Portability isn't helped because
>someone has to do the conversion.  It also doesn't help network play
>because the data in memory is going to have been converted to native mode
>and translated again.  Besides I could just declare the network protocol

In Java, everything is big endian.  It makes the port to Java a lot 
easier.  I'm not sure that's a big deal for you, but you might consider 
that one of your platforms.

>as little endian.  (Many windows games don't even have a protocol and
>instead simply dump memory structure to the wire.)

Just because Windows sucks...  Besides, this is primarily a Linux game.  It 
will fail on other platforms than Intel (Mac, etc.).

>Oops... Scratch that about only implementing BinaryReadFile and
>BinaryWriteFile.  Secrets makes some assumations about the data.  (Plus
>the misalignment bus error which I had intended this paragraph to be
>about.)  Should do something about that.
>
>I'm not too inclined to modify Troll Bridge to be big endian.

I could allow my fixes to allow me to read the little endian files, but I 
would strongly lobby for having the code do an autodetect by reading an 
unsigned short value of 1 from the start of each file.  It's two bytes, and 
it allows my tools to do things the way I prefer, and allows you to do 
things the way you prefer.

A couple other notes.  Your code to decipher the sprite files needs some 
more documentation describing the purpose of each variable.  I gave up 
trying to decipher it, and just implemented it from the specs.

BTW, you should mention in the specs that all data is unsigned.  You don't 
say that anywhere actually say that anywhere in the file format specs 
(although it is obvious from the code).

If I were to be really a Java lobbiest, I would argue against unsigned 
values at all, but I doubt I'll win that one.  :)

Finally, what's with the poor penguin?

Later,
Kenn

------------------------------+-------------------------------
Kenneth W. Flynn              | Graduate Fellow
flynnk@astro.umd.edu          | Department of Astronomy
www.astro.umd.edu/~flynnk     | University of Maryland
------------------------------+-------------------------------