|
| bool | matches (Bytes data, Bytes magic) |
| bool | matches (Bytes data, std::string_view magic) |
| bool | hasBytes (Bytes data, size_t off, size_t len) |
| constexpr uint32_t | fourccLE (char a, char b, char c, char d) |
| void | appendU32LE (std::vector< uint8_t > &out, uint32_t value) |
| void | appendU64LE (std::vector< uint8_t > &out, uint64_t value) |
| uint32_t | readU32LE (Bytes data, size_t off) |
| uint32_t | readU32BE (Bytes data, size_t off) |
| uint64_t | readU64LE (Bytes data, size_t off) |
| Result< std::vector< uint8_t > > | slice (Bytes data, size_t off, size_t len) |
byte level helpers shared by the codecs. every container haio reads or writes stores its integers little endian, which the names say out loud: ktx even carries an endianness marker that the decoder checks, so leaving it implicit was asking for a silent bug on a big endian host.
| uint32_t Haio::Util::fourccLE |
( |
char | a, |
|
|
char | b, |
|
|
char | c, |
|
|
char | d ) |
|
constexpr |
a four character code, the tag formats put at the front of a header. it is the same operation as readU32LE over a literal, and it carries the suffix for the same reason: riff and dds pack it little endian, iff and aiff pack it the other way round, so "fourcc" alone does not say which.
Definition at line 29 of file haio_util.hpp.