I'm definitely able to send ints and on other structures using OpenPlay
on Windows to and from OpenPlay on the Mac.
I suspect that the problem you are encountering is endianness of the
two platforms. The x86 architecture is little endian, the PowerPC and
most other processors are big endian (or can run either way). That
means that on Windows, if you look at how a long is stored in memory,
it is the reverse of how you see it written normally. Consider this
for the hex value 0x01520080
address 0 1 2 3
data 80 00 52 01 (little endian) - big endian machine would read as
data 01 52 00 80 (big endian) - little endian machine would read
By convention, Network Byte Order is big endian. So if you are going to
send back and forth between different platforms, you should make sure
your data is in network byte order before sending. Keep in mind that
anything that is a single byte wide doesn't suffer from this, nor do
char strings (wide char strings do have byte order issues). So by
sending things as a string, you are dodging the problem. Likewise, if
you find that the values you are sending will fit into a byte (signed
or unsigned char) then you are also fine.
The odd part about your problem is "it just doesn't seem to send
anything at all". I would expect you to get the data but to get it
reversed. Are you sure you are not receiving any data? If you are
sending a structure and it's size, then the size might be suffering the
same problem, making it seem as if some data isn't coming across.
This is also an issue for disk files, so if you want to share saved
games/map files/game data files between platforms you will want to
apply the same techniques.
Here are some convenient macros you can use to swap byte order. you
have to #define PLATFORM_LITTLE_ENDIAN 1 on Windows and any other
little endian targets.
#define BigEndian16_ToNative(n) Endian16_Swizzle(n)
#define BigEndian32_ToNative(n) Endian32_Swizzle(n)
#define Native_ToBigEndian16(n) Endian16_Swizzle(n)
#define Native_ToBigEndian32(n) Endian32_Swizzle(n)
#define LittleEndian16_ToNative(n) n
#define LittleEndian32_toNative(n) n
#define Native_ToLittleEndian16(n) n
#define Native_ToLittleEndian32(n) n
#define BigEndian16_ToNative(n) n
#define BigEndian32_ToNative(n) n
#define Native_ToBigEndian16(n) n
#define Native_ToBigEndian32(n) n
#define LittleEndian16_ToNative(n) Endian16_Swizzle(n)
#define LittleEndian32_toNative(n) Endian32_Swizzle(n)
#define Native_ToLittleEndian16(n) Endian16_Swizzle(n)
#define Native_ToLittleEndian32(n) Endian32_Swizzle(n)
To use these, just copy the data into them in network byte order before
you send -- be careful to swap back the data if you then pass the data
on to other parts of your code before sending. For example:
// send the player login info to the client to tell the client
which player they are and how many are playing
packet.loginInfo.playerNum = playerNum;
packet.loginInfo.playerCount = mGame.getNumPlayers();
sendPacket(player->getID(), packet, packet_Login);
Hope this helps,
On Dec 7, 2004, at 6:47 AM, Trevor Agnitti wrote:
An odd issue maybe someone else has seen...
I have been having some odd problems sending integers (and a few other
types) from mac to windows and (vice versa). I can send chars and
strings of chars, but when I send an integer to a windows build of my
program, it just doesn't seem to send anything at all. I can send
integers from mac to mac builds, but they just don't appear to send to
windows versions. I have found ways around this, like by casting
small ints as chars, sending them, and then casting them back to ints
upon arrival. I have even converted larger ints to strings of text,
sending them, and then convert a text "123456" to an integer 123456.
The whole thing seems kinda screwy.
I thought perhaps it might be because windows and macs have different
ways of storing integers on some level that gets confused in openplay
Did anyone else ever notice this/know a way to fix it?
Is there a bug in some netsprocket code or something?
Do not post admin requests to the list. They will be ignored.
Openplay-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden