Handle padding for received data packets?

Yaazarai

Member
From the GMS2.x docs: async_load[? "buffer"]
  • "buffer": This is the unique "buffer ID" which is generated by the event. A "grow" type buffer, byte aligned to 1, is created to hold the ID should be stored in a variable and used for all further function calls to the buffer in this event. Just like the async_load map, the buffer created is automatically removed from memory at the end of this event. For more information on buffers, please see Reference - Buffers.
When you create buffer you can set it's byte alignment and then send the data over a TCP socket connection--which is my use case here. However when we actually receive a data packet back from our TCP connection we get the problem, where we receive say a packet with a 4 byte alignment, yet it's treated as 1 byte alignment. Is there a fix for this?

Or do I just need to create a 4 byte aligned buffer and copy the data over from the network event buffer?
 

PNelly

Member
we receive say a packet with a 4 byte alignment, yet it's treated as 1 byte alignment. Is there a fix for this?
I'm not sure there's anything to consider broken. AFAIK the byte alignment mechanism is only there to facilitate writes and not reads. Regardless of the alignment used to originally write the buffer in question, if you wish to read it as if it were 4-byte aligned, then you would do that by consuming and interpreting it in chunks of 4 bytes.

Even if you intend to modify the buffer you can respect it's original 4-byte alignment by multiplying your "data index" (for lack of better phrasing) position, by the alignment, and using that to set your seek position.
 
Top