adonthell-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Adonthell-devel] Endianness (Adonthell and Solaris)


From: Kai Sterker
Subject: Re: [Adonthell-devel] Endianness (Adonthell and Solaris)
Date: Tue, 19 Feb 2002 11:23:33 +0100

On Tuesday 19 February 2002 11:09, you wrote:

> Where is this output placed? the image class, or the pnm one?

The image class on my other box, sorry. Just after loading length and height, 
it prints them with cout.

I have by the way a theory new, and I also revise my opinion about the 
endian-independence of zlib ;)

If you look at the last line, which is loading of the jewelbag_open.img, the 
Solaris box prints:  

    Loading image (16385x61440) ...Abort - core dumped

The first line of the decompressed image is
    40 01 f0 00 25 17 10 1d 11 0e 1a 10 0e 23 16 0f

And if you reverse the byteorder of the first 2 16bit values (4001, f000), 
you get exactly the above.

I am not sure how to explain the 255x255 size of the font file though.
The only position to read those 2 values (00ff) is 5 bytes after the 
beginning. That's the first line in the decompressed font file:

    00 ff 59 02 0d 00 ff 00 ff ff 00 ff ff 00 ff ff 
                   ^   

So what happens with the first 5 bytes? The first is defined as boolean and 
the second as 8bit int. So I think that the boolean might be read as 32bit 
value. Then the first 5 bytes would be read when initialising mask and alpha, 
and the next 4 bytes that are used to init the size are 255 each.


What might be a prove of above theory: when I first added the byteorder 
change, even the font loading did not work. And if you do the maths, then 
you'll see that 00ff is 65280 in little endian. Meaning it's trying to load a 
pic of size (65280x65280) although it is only 601x13 - no wonder it wasn't 
working.

Kai 
Kai



reply via email to

[Prev in Thread] Current Thread [Next in Thread]