kitylam9 / moveme

Automatically exported from code.google.com/p/moveme
0 stars 0 forks source link

MoveState struct in moveclient.h does not match data coming from move.me server #20

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
Turns out at least the latest move.me server is producing a MoveState portion 
of the data that is 8 bytes larger than the one defined in moveclient.h.  The 
symptom of this is that everything after the first controller's MoveData is 
garbage.  The size of the packet from the server is 32 bytes larger than the 
sizeof(MoveServerPacket).

The fix is to add an additional 64 bit element to the MoveState struct, it is 
possible that there is some useful data supplied there, I haven't checked.

typedef struct _MoveState {
    float4 pos;
    float4 vel;
    float4 accel;
    float4 quat;
    float4 angvel;
    float4 angaccel;
    float4 handle_pos;
    float4 handle_vel;
    float4 handle_accel;
    MovePadData pad;
    system_time_t timestamp;
    float temperature;
    float camera_pitch_angle;
    uint32_t tracking_flags;
        uint64_t reserved; // needed padding

} MoveState;  

Original issue reported on code.google.com by esse...@gmail.com on 14 Jun 2012 at 4:31

GoogleCodeExporter commented 8 years ago
Hi,

What compiler are you using?

John

Original comment by j...@johnmccutchan.com on 14 Jun 2012 at 5:00

GoogleCodeExporter commented 8 years ago
This is on iOS (both ARM and x86 simulator) using XCode 4.2 with LLVM 3.0.  The 
UDP network packet received from the server was 2132 bytes.  The 
sizeof(MoveServerPacket) (with 32bit compile) before my fix was 2100.

Further testing by building with different compilers and 32 vs. 64 bit shows 
even more issues.

/* main.c */
include "moveclient.h"
#include <stdio.h>

int main(int argc, char **argv)
{
    printf("Size is %lu\n", sizeof(MoveServerPacket));
    return 0;
}

========

Mac OS X 10.6.8

$ gcc --version
i686-apple-darwin10-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) 
(LLVM build 2336.1.00)

$ gcc -m32 -o main main.c 
$ ./main
Size is 2100

$ gcc -m64 -o main main.c 
$ ./main
Size is 2152

Non LLVM gcc, same results:
$ gcc-4.0  --version
i686-apple-darwin10-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5494)

$ gcc-4.0 -m32 -o main main.c 
$ ./main
Size is 2100

$ gcc-4.0 -m64 -o main main.c 
$ ./main
Size is 2152

Obviously, you don't want there to be any size differences in your struct when 
you are overlaying it on top of a fixed sized network packet without more 
fine-grained deserialization.

By applying __attribute__((packed)) to every struct and padding the 
MoveImageState with two additional unsigned chars to round that up, only then 
did the 32bit and 64bit compiles come up with the same number (2100 bytes).  

However,  I am receiving 2132 byte packets from the PS3 move.me server and only 
by adding the 8byte padding in the MoveState struct is the resulting data 
interpreted correctly.

What are other people seeing with different platforms with regards to the 
struct and recv'd packet sizes?

Original comment by esse...@gmail.com on 14 Jun 2012 at 5:33