I've never really looked up to see if java interprets values in little endian or big endian format. Since it runs on an Intel architecture, I assumed it would follow little endian format (least significant byte first) (Which i found out is incorrect, it use Big Endian order)
[URL] Go there, it explains, and it has code for reading little endian values
ie:
the value 12 as a 32 bit integer is logically: 00 00 00 0B
but in memory and in files, because x86 is a little endian architecture, that value is represented as: 0B 00 00 00
That is why the first 4 bytes in the map files are like that, despite the value being logically 00 00 00 0B, its actually 0B 00 00 00
That is NOT a delphi thing, it's a processor thing.
lets consider an array of 4 32 bit integers: {1, 17, 14, 8}
these are logically:
00 00 00 01
00 00 00 11
00 00 00 0E
00 00 00 08
in memory they are represented as:
01 00 00 00
11 00 00 00
0E 00 00 00
08 00 00 00
if these are written to a file (in order), the file would contain:
01 00 00 00 11 00 00 00 0E 00 00 00 08 00 00 00
Signing of integers is done the exact same in java as it is in any other language (to my knowledge): 2s compliment
a negative number is just the positive version NOTed, with 1 added after
lets examine the value -6.
6 (without sign) is represented as:
00000000 00000000 00000000 00000110 as binary
or as hex:
00 00 00 06
-6 is:
11111111 11111111 11111111 11111010 as binary
or as hex:
FF FF FF FA
but then, it is switched around like noted above, so it is actually
11111010 11111111 11111111 11111111 in memory and in files
or, as hex:
FA FF FF FF
Strings in delphi are odd, yes.
The first byte is the length, subsequent bytes are the characters, and then because the strings are fixed length, delphi pads the rest with garbage characters.