Maxon Developers Maxon Developers
    • Documentation
      • Cinema 4D Python API
      • Cinema 4D C++ API
      • Cineware API
      • ZBrush Python API
      • ZBrush GoZ API
      • Code Examples on Github
    • Forum
    • Downloads
    • Support
      • Support Procedures
      • Registered Developer Program
      • Plugin IDs
      • Contact Us
    • Categories
      • Overview
      • News & Information
      • Cinema 4D SDK Support
      • Cineware SDK Support
      • ZBrush 4D SDK Support
      • Bugs
      • General Talk
    • Unread
    • Recent
    • Tags
    • Users
    • Login

    Example of using lSwap() etc.

    Scheduled Pinned Locked Moved SDK Help
    3 Posts 0 Posters 195 Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • H Offline
      Helper
      last edited by

      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:

      User Information:
      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?

      Thanks,

      Robert

      1 Reply Last reply Reply Quote 0
      • H Offline
        Helper
        last edited by

        THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

        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.

        Thanks,

        1 Reply Last reply Reply Quote 0
        • H Offline
          Helper
          last edited by

          THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

          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).

          Thanks,

          1 Reply Last reply Reply Quote 0
          • First post
            Last post