I am finding anonymous additional bytes in several SDL event structures that
do not match the SDL_Event definitions in the headers.
An example is the SDL_ResizeEvent. The struct as defined in SDL_Event.h is:
typedef struct {
Uint8 type; /* SDL_VIDEORESIZE /
int w; / New width /
int h; / New height */
} SDL_ResizeEvent;
However SDL returns the following sequence of bytes when an SDL_ResizeEvent
is generated…
16 127 177 9 150 0 0 0 91 0 0 0
Breaking this down:
16 : Uint8 type : Event identifier
127 : ???
177 : ???
9 : ???
150, 0 0 0 : int w : window is 150 pixels wide
91, 0 0 0 : int h : window is 91 pixels high
Which basically means that the ResizeEvent struct looks something like this:
typedef struct {
Uint8 type; /* SDL_VIDEORESIZE /
Uint8 buffer1;
Uint8 buffer2;
Uint8 buffer3;
int w; / New width /
int h; / New height */
} SDL_ResizeEvent;
I am also getting much the same from the SDL_MouseMotionEvent event. The
struct as defined in SDL_Event.h is:
typedef struct {
Uint8 type; /* SDL_MOUSEMOTION /
Uint8 which; / The mouse device index /
Uint8 state; / The current button state /
Uint16 x;
Uint16 y; / The X/Y coordinates of the mouse /
Sint16 xrel; / The relative motion in the X direction /
Sint16 yrel; / The relative motion in the Y direction */
} SDL_MouseMotionEvent;
I get the following byte sequence when a SDL_MouseMotionEvent is generated:
4 0 0 0 159 0 3 0 1 0 254 255
Breaking this down:
4 : Uint8 type : Event identifier
0 : Uint8 which
0 : Uint8 state
0 : ???
159, 0 : Uint16 x : horizontal position of the mouse
3, 0 : Uint16 y : vertical position of the mouse
1, 0 : Sint16 xrel : relative motion in the horizontal
254, 255 : Sint16 yrel : relative motion in the vertical
Which basically means that the ResizeEvent struct looks something like this:
typedef struct {
Uint8 type; /* SDL_MOUSEMOTION /
Uint8 which; / The mouse device index /
Uint8 state; / The current button state /
Uint8 buffer;
Uint16 x;
Uint16 y; / The X/Y coordinates of the mouse /
Sint16 xrel; / The relative motion in the X direction /
Sint16 yrel; / The relative motion in the Y direction */
} SDL_MouseMotionEvent;
The SDL_MouseButtonEvent is fine however, the byte sequence matches the
SDL_Event.h header. I have not had a chance to test any other events.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1On Wednesday 23 April 2003 10:11, Luke J Crook wrote:
I am finding anonymous additional bytes in several SDL event structures
that do not match the SDL_Event definitions in the headers.
An example is the SDL_ResizeEvent. The struct as defined in SDL_Event.h
is:
typedef struct {
Uint8 type; /* SDL_VIDEORESIZE /
int w; / New width /
int h; / New height */
} SDL_ResizeEvent;
However SDL returns the following sequence of bytes when an
SDL_ResizeEvent is generated…
16 127 177 9 150 0 0 0 91 0 0 0
Breaking this down:
16 : Uint8 type : Event identifier
127 : ???
177 : ???
9 : ???
150, 0 0 0 : int w : window is 150 pixels wide
91, 0 0 0 : int h : window is 91 pixels high
Which basically means that the ResizeEvent struct looks something like
this:
typedef struct {
Uint8 type; /* SDL_VIDEORESIZE /
Uint8 buffer1;
Uint8 buffer2;
Uint8 buffer3;
int w; / New width /
int h; / New height */
} SDL_ResizeEvent;
[snip rest]
This is due to the compiler’s alignment of the structure’s member variables.
Access of data types bigger than one byte (i.e. int) are usually faster
when they’re aligned on their natural boundary. On a 32-bit machine, where
an int is 4 bytes long, this means that accessing an int is fastest when
its address can be divided by four.
The compiler automatically adds pad bytes to ensure this alignment for
faster execution speed. This is done in a machine and often even compiler
dependant way. In other words, don’t mess with the actual byte layout of
structures in portable programs.
you can tell the compiler not to do this though if you ever have a struct
you want to send over the network or write to a file raw or something…
depending on the compiler the syntax is a little different but it should be
something like this…
#pragma pack 1 //set it to 1 byte alignment (no padding) #pragma pack 0 //set it back to whatever alignment it was at> ----- Original Message -----
From: prefect_@gmx.net (Nicolai Haehnle)
To:
Sent: Wednesday, April 23, 2003 1:58 AM
Subject: Re: [SDL] Anonymous bytes in SDL Events
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wednesday 23 April 2003 10:11, Luke J Crook wrote:
I am finding anonymous additional bytes in several SDL event structures
that do not match the SDL_Event definitions in the headers.
An example is the SDL_ResizeEvent. The struct as defined in SDL_Event.h
is:
typedef struct {
Uint8 type; /* SDL_VIDEORESIZE /
int w; / New width /
int h; / New height */
} SDL_ResizeEvent;
However SDL returns the following sequence of bytes when an
SDL_ResizeEvent is generated…
16 127 177 9 150 0 0 0 91 0 0 0
Breaking this down:
16 : Uint8 type : Event identifier
127 : ???
177 : ???
9 : ???
150, 0 0 0 : int w : window is 150 pixels wide
91, 0 0 0 : int h : window is 91 pixels high
Which basically means that the ResizeEvent struct looks something like
this:
typedef struct {
Uint8 type; /* SDL_VIDEORESIZE /
Uint8 buffer1;
Uint8 buffer2;
Uint8 buffer3;
int w; / New width /
int h; / New height */
} SDL_ResizeEvent;
[snip rest]
This is due to the compiler’s alignment of the structure’s member variables.
Access of data types bigger than one byte (i.e. int) are usually faster
when they’re aligned on their natural boundary. On a 32-bit machine, where
an int is 4 bytes long, this means that accessing an int is fastest when
its address can be divided by four.
The compiler automatically adds pad bytes to ensure this alignment for
faster execution speed. This is done in a machine and often even compiler
dependant way. In other words, don’t mess with the actual byte layout of
structures in portable programs.
I am finding anonymous additional bytes in several SDL event structures
that
do not match the SDL_Event definitions in the headers.
Is it perhaps 32 bit aligned? so there’s just noise between the bits that
are used and the next variables? That’s certainly what it looks like to me -
I’m pretty sure by default most compilers default to dword structure member
alignment…
An example is the SDL_ResizeEvent. The struct as defined in SDL_Event.h
is:
typedef struct {
Uint8 type; /* SDL_VIDEORESIZE /
int w; / New width /
int h; / New height */
} SDL_ResizeEvent;
However SDL returns the following sequence of bytes when an
SDL_ResizeEvent
is generated…
16 127 177 9 150 0 0 0 91 0 0 0
Breaking this down:
16 : Uint8 type : Event identifier
127 : ???
177 : ???
9 : ???
150, 0 0 0 : int w : window is 150 pixels wide
91, 0 0 0 : int h : window is 91 pixels high
Which basically means that the ResizeEvent struct looks something like
this:
typedef struct {
Uint8 type; /* SDL_VIDEORESIZE /
Uint8 buffer1;
Uint8 buffer2;
Uint8 buffer3;
int w; / New width /
int h; / New height */
} SDL_ResizeEvent;
I am also getting much the same from the SDL_MouseMotionEvent event. The
struct as defined in SDL_Event.h is:
typedef struct {
Uint8 type; /* SDL_MOUSEMOTION /
Uint8 which; / The mouse device index /
Uint8 state; / The current button state /
Uint16 x;
Uint16 y; / The X/Y coordinates of the mouse /
Sint16 xrel; / The relative motion in the X direction /
Sint16 yrel; / The relative motion in the Y direction */
} SDL_MouseMotionEvent;
I get the following byte sequence when a SDL_MouseMotionEvent is
generated:
4 0 0 0 159 0 3 0 1 0 254 255
Breaking this down:
4 : Uint8 type : Event identifier
0 : Uint8 which
0 : Uint8 state
0 : ???
159, 0 : Uint16 x : horizontal position of the mouse
3, 0 : Uint16 y : vertical position of the mouse
1, 0 : Sint16 xrel : relative motion in the horizontal
254, 255 : Sint16 yrel : relative motion in the vertical
Which basically means that the ResizeEvent struct looks something like
this:>
typedef struct {
Uint8 type; /* SDL_MOUSEMOTION /
Uint8 which; / The mouse device index /
Uint8 state; / The current button state /
Uint8 buffer;
Uint16 x;
Uint16 y; / The X/Y coordinates of the mouse /
Sint16 xrel; / The relative motion in the X direction /
Sint16 yrel; / The relative motion in the Y direction */
} SDL_MouseMotionEvent;
The SDL_MouseButtonEvent is fine however, the byte sequence matches the
SDL_Event.h header. I have not had a chance to test any other events.
I’m interfacing to SDL using Lisp so I have had to manually pad the event
structures to compensate for byte alignment.
-Luke> ----- Original Message -----
From: atrix2@cox.net (atrix2)
To:
Sent: Wednesday, April 23, 2003 2:58 AM
Subject: Re: [SDL] Anonymous bytes in SDL Events
you can tell the compiler not to do this though if you ever have a struct
you want to send over the network or write to a file raw or something…
depending on the compiler the syntax is a little different but it should
be
something like this…
#pragma pack 1 //set it to 1 byte alignment (no padding) #pragma pack 0 //set it back to whatever alignment it was at
----- Original Message -----
From: “Nicolai Haehnle” <prefect_ at gmx.net>
To:
Sent: Wednesday, April 23, 2003 1:58 AM
Subject: Re: [SDL] Anonymous bytes in SDL Events
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wednesday 23 April 2003 10:11, Luke J Crook wrote:
I am finding anonymous additional bytes in several SDL event structures
that do not match the SDL_Event definitions in the headers.
This is due to the compiler’s alignment of the structure’s member
variables.
Access of data types bigger than one byte (i.e. int) are usually faster
when they’re aligned on their natural boundary. On a 32-bit machine, where
an int is 4 bytes long, this means that accessing an int is fastest when
its address can be divided by four.
The compiler automatically adds pad bytes to ensure this alignment for
faster execution speed. This is done in a machine and often even compiler
dependant way. In other words, don’t mess with the actual byte layout of
structures in portable programs.
From: jim@fortunet.com (Jim)
To:
Sent: Wednesday, April 23, 2003 3:08 AM
Subject: Re: [SDL] Anonymous bytes in SDL Events
I am finding anonymous additional bytes in several SDL event structures
that
do not match the SDL_Event definitions in the headers.
Is it perhaps 32 bit aligned? so there’s just noise between the bits that
are used and the next variables? That’s certainly what it looks like to
me -
I’m pretty sure by default most compilers default to dword structure
member
alignment…