feat: move to big endian for network communications

[nadenislamarre]

No description provided.

[mkalkbrenner]

I think the counterpart is missing. Don't we need to ensure big endian when sending data?

libdmdutil/src/DMD.cpp

Line 339 in fc29cd7

m_pDMDServerConnector->write_n(&streamHeader, sizeof(StreamHeader));

[mkalkbrenner]

The Update struct contains "bigger" data types as well. So I think a conversion would be required here, too:

libdmdutil/include/DMDUtil/DMD.h

Lines 84 to 100 in fc29cd7

	struct Update
	{
	Mode mode;
	AlphaNumericLayout layout;
	int depth;
	uint8_t data[256 * 64 * 3];
	uint16_t segData[256 * 64]; // RGB16 or segment data
	uint16_t segData2[128];
	bool hasData;
	bool hasSegData;
	bool hasSegData2;
	uint8_t r;
	uint8_t g;
	uint8_t b;
	uint16_t width;
	uint16_t height;
	};

But not all fields are used for all modes. So maybe we can optimize the conversion per mode.

[francisdb]

There's no PR description, what is the reasoning behind the move?

[mkalkbrenner]

There's no PR description, what is the reasoning behind the move?

As commented in the code I didn't care about endianess. The assumption was that dmdserver runs as a service on the same machine as the clients. So endianess should not be an issue.
Now @nadenislamarre tries to send data to dmdserver running on a different host.

[mkalkbrenner]

@nadenislamarre uses dmd-play as client. Therefore, the current state of the PR seems to be sufficient. But if the client uses libdmdutil (VPX, PPUC, etc), I assume that big endian should be ensured as well when sending data.
Do you agree?

[francisdb]

@mkalkbrenner just wanted to know why, don't want to be involved in decision making as an observer.