DataBuffer peekfloat little/big endian issue

Monkey Forums/Monkey Programming/DataBuffer peekfloat little/big endian issue

Timotron (Posted 2014) [#1]

Mark I ran into this issue today while writing a binary file loader for spine animation .skel files. The spine tool exports floats in the opposite endian order than monkey assumes, which means I had to add this in my code to fix the float reads for now. Snippet from my ReadFloat, file stream method. [code] floatBuffer.PokeByte(3, buffer.PeekByte(index)) floatBuffer.PokeByte(2, buffer.PeekByte(index + 1)) floatBuffer.PokeByte(1, buffer.PeekByte(index + 2)) floatBuffer.PokeByte(0, buffer.PeekByte(index + 3)) Local data:= floatBuffer.PeekFloat(0) [code] An option to read the floats bytes in the opposite order would be nice, as it would read much faster. Tim

ImmutableOctet(SKNG) (Posted 2014) [#2]

I haven't ever had this issue, but just in case you need them, here's my byte-order commands. The only reason for me making that module is networking, but it works for my needs. I may just make the floating-point endian code similar to yours at some point (Or at least have an option for it). EDIT: Just for the record, if your machine is big-endian, these commands will just 'pass-through' and work as expected. In other words, this will be consistent on targets which are big-endian. And, if you really want it, a while ago I wrote my own 'DataStream' class which ended up being pretty identical to 'DataStream', but it does have support for big-endian. EDIT: I just tested it, yeah, the 'Flash' target does weirdly use big-endian for floats.

Salmakis (Posted 2014) [#3]

i had this problem only with flash target, did you use flash or something else? if so, keep in mind that you maybe need to - not swap - the bits then on another target

Powelly (Posted 2014) [#4]

I've had the same problem with DataBuffer myself. It appears that Flash is Big Endian, but most (all?) of the other targets are Little Endian. At the moment I'm checking for the Flash target and only endian swapping if it is Flash. I'm hoping to get some Monkey code to compile on PowerPC Linux at some point, which will be GLFW and Big Endian, so the target check won't work for that case. I think that what Monkey needs is a IsBigEndian() function/property or maybe a #BIG_ENDIAN directive that checks both the target and the underlying architecture so that byte swap code can be executed only when needed.