FelipeFS wrote:
Talking about binary mode... No matter what you choose, between text-mode or binary-mode to write your files, it is always a double-edged sword.
Euhm, ok :) Luckily it makes absolutely no difference what-so-ever at a Unix system, both modes are equivalent :D
(Unix uses \n in text-files, which in text mode gets translated to .... \n :D )
FelipeFS wrote:
For example, in my data file, which I store maps, I have the following map 4x4:
Code:
[0.1, 0.0, 2.0, 3.0,
10.1, 0.20, 3.0, 3.0,
0.1, 0.0, 2.0, 3.0,
0.1, 0.0, 2.0, 3.0 ]
// the number before the dot is the Y of the tile, after the dot is the Y;
It is text mode, and it is good when the number of digits is small, "2" for example has 1 digit. This means that I'm using only 1 byte. But, if the number of digits is large, like "5435734", you will use 7 bytes for an integer, which could use only 4 bytes.
If that example is directly from your sources, there is a typo in it, the comment says both numbers are Y coordinates.
Other than that, I see 'text mode' as useful for files I want to be able to read, and usually edit with a text editor. Binary files are for reading by a computer. I don't want to examine them without additional tools, I use the latter as little as possible as it makes development harder. I don't really care about the size of files, 1GB disk goes for about 1 euro (at least it did several years back), so my time and convenience is more important than 3 bytes of data.
FelipeFS wrote:
XML has the "<![CDATA[", which allows you to put a binary code inside the structure. It is like a binary-mode inside a text-mode file. But, WHO guarantees that inside your binary-code will not have an sequence of "]]>"???
Where did you read you can put binary code in the CDATA block?
Afaik, an xml file is a unicode file, encoded in some char-set (usually utf-8). That means the entire file has to be valid utf-8. Arbitrary binary code is not going to play by that rule :D
The usual solution is to encode the binary data in a text-format, eg hexdigits, or base64 (as also said by cxzuk). That also takes case of your marker problem.
FelipeFS wrote:
Text-mode can be more expensive, but is more secure. BUT and idea to prevent the problem above is to put the size of the binary-code(inside the text-mode file) to read before start the reading.
Sorry, I don't understand "more secure". I do use such size prefixes, but only in binary files (adding anything binary in a file makes it a 'binary file' for me no matter how small the binary data is).
FelipeFS wrote:
Alberth wrote:
I have to create Python equivalents for each 'primtive' type in it. That cannot be right ;p
When you say that, you mean something like this:
XML to Python data structure (Python recipe)?
Oh, your reference looks like the elementtree module to me :)
It is however not what I mean.
Code:
====== ====== ==========================================================
Offset Length Description
====== ====== ==========================================================
0 4 Magic string 'ANSP'.
4 4 Version number of the block '1'.
8 4 Length of the block excluding magic string, version, and length.
12 2 Zoom-width of a tile.
14 1 Person type.
15 2 Animation type.
17 2 Frame count (called 'f').
19 f*4 Sprite for each frame.
? Variable length.
====== ====== ==========================================================
Above you see the data layout of the 'ANSP' block. Notice the word containing a count at offset 17.
This block in XML looks like
Code:
<block magic="ANSP" minversion="1" maxversion="1">
<field name="width" type="uint16">Zoom-width of a tile</field>
<field name="person_type" type="PersonType">Type of persons in the animation</field>
<field name="anim_type" type="AnimationType">Animation being defined</field>
<field name="frames" type="frame_images">Sprites of the animation for a single tile width</field>
</block>
As you can see, there is no count in this definition. Instead, there is a thing called 'frame_images'. I cannot express in XML that it has a count prefix, and it contains sprite blocks (which should be counted, and used as prefix value).
Instead, I have to code a data type called 'frame_images' in Python manually that knows all this.
Another example: Tomorrow I will need to define a number of bits from a set for defining possible colours. Obviously, you can state eg 0x'3E6', but I rather have 'blue, green, light-red'. The latter is currently also not expressable in the structdef.xml file.
In other words, I am already running into limits of the data format, and have not even started doing ride data which is much more complicated.