MODULE: BinaryFile v.1.0 - File class functionality extension

[Crimson Wizard]

This module adds a number of extender functions to AGS File class, allowing to read and write "precisely sized" integer values from/to the file (naturally).

For scripting weirdos only.

List of functions in the Version 1.0:

ReadInt8
ReadUInt8
ReadInt16
ReadUInt16
ReadInt32
ReadUInt32

SkipBytes
SkipInt8
SkipUInt8
SkipInt16
SkipUInt16
SkipInt32
SkipUInt32

WriteInt8
WriteUInt8
WriteInt16
WriteUInt16
WriteInt32
WriteUInt32


Supports both Little Endian and Big Endian byte order.

Requires AGS 3.0+

Download
Download mirror

[Monsieur OUXX]

That'll come handy for me. I started writing similar stuff, but didn't have time to polish the result, while working on everything else.

[Crimson Wizard]

That'll come handy for me. I started writing similar stuff, but didn't have time to polish the result, while working on everything else.

Why, it's good to know someone will need this make sure to report any bugs!

[Kweepa]

Interesting...
I'm not sure how useful the UInt32 functions are since you can't work with them in AGS. I suppose you could shuffle them around and write them back out, or convert them to an internal struct representation that can be operated on.
I would recommend having a global function to set the endianness, rather than having to pass an extra parameter in each function. You could have a separate reading endianness and writing endianness. Or perhaps you could set the endianness on each FILE - that would probably slow things down too much though, looking up the endianness inside each read/write function.
Nice work!

[Crimson Wizard]

Interesting...
I'm not sure how useful the UInt32 functions are since you can't work with them in AGS.

Yeah, that's true. I guess it was rather formal addition (same as various "skip" functions that skip same number of bytes, but may be used to simply help user distinguish which sorts of data he skips).

I would recommend having a global function to set the endianness, rather than having to pass an extra parameter in each function. You could have a separate reading endianness and writing endianness. Or perhaps you could set the endianness on each FILE - that would probably slow things down too much though, looking up the endianness inside each read/write function.

I am not sure it is wise to use global endianness setting here, because there's no guarantee that end-user will not open 2 or more files at a time, one of which would need little-endian reading order and another big-endian one. I know that the chance this will happen is quite low, but it is still possible.
It is also impossible to set endianess for FILE (unfortunately), at least with current implementation, since these functions are extender methods of internal File class. To do so I would need a custom struct, which would store File reference, endiannes setting and whatnot else. Will this be better way to implement this? I am not sure atm.

Anyway, you only need to pass this parameter explicitly if you need big endian order, becuase little endian is passed as a default value.



EDIT:  Regarding speed. These functions are obviously slower than common File.Read/WriteInt ones. But you will start to feel the difference when amount of data is really large.
I tested writing 1 million of 4 byte integers in the file. When using File.WriteInt it takes roughly 2 seconds, with File.WriteInt32 it takes 9 seconds.
Writing 100.000 integers takes <1 and about 1.5 sec correspondingly.
Writing 10.000 integers takes imperceptible amount of time in both cases.