THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 07/08/2006 at 23:40, xxxxxxxx wrote:
Cinema 4D Version: 9.102
Platform: Windows ; Mac ; Mac OSX ;
Language(s) : C++ ;
My plugin object and tags have zlib compressed struct arrays that are saved/loaded with the C4D document via Read()/Write(). Currently I'm using WriteMemory()/ReadMemory() for the array. Obviously, these are no good if one wants to port their documents from Windows to MacOS and vice versa - leads to crashing on the other system.
Thanks to Per-Anders, I see that lSwap() or lMotor(),lIntel() may allow the data to be endian-corrected despite its original storage order. But this is a byte array (Bytef is typedef'd unsigned char in zlib). How would one use these to do the corrective ordering in this case?
On 07/08/2006 at 23:50, xxxxxxxx wrote:
I think that I may have my culprit here - maybe. This would explain why older versions of my plugin didn't have this problem although the zlib-compressed array was being stored. Since the zlib array is bytes, there should be no endian concerns.
But I am also storing a Polygon array in the same manner. This is a very likely candidate for endian issues. Let me see what can be done.
On 08/08/2006 at 03:56, xxxxxxxx wrote:
Hmmm. Well, I'll never use ReadMemory()/WriteMemory() again.
Although it took some work (compressing and decompressing the arrays when reading and writing), reading and writing the struct arrays uncompressed, including the Polygon array, using standard C4D HyperFile types has allowed perfect portability between Windows and MacOS.
The document size is slightly larger, but at least users can actually save a document from Windows C4D, move it a Mac, and open it within MacOS C4D (and vice versa).