Hello, the problem with the 4 bytes not being written is now solved, thanks! Turned out to be a problem with my program, of course. :-)
Kind regards, Kai 2014-12-05 23:19 GMT+01:00 Kai Burjack <kburj...@googlemail.com>: > Hello, > > I just subscribed to this mailing list, so a friendly "hello" first. :-) > > Currently, I am building a Java tool that produces .blend files for > consumption by the Blender application. > Looking at the C code and the struct definitions and the file > "writefile.c" it really is a straightforward process. > > But, at one point I came to a halt, and that's when I want to write the > FileGlobal struct, which the Blender source does with the function > 'write_global' in the source 'writefile.c'. > > This struct, as defined in 'DNA_fileglobal_types.h', defines at its very > beginning a char[4] followed by two short's. > My tool writes data according to this exact struct definition, but somehow > the .blend files written by the Blender application are exactly 4 bytes > shorter (two times 2 bytes) there. Looking in with a hex editor it is > exactly at that very beginning where that 'char subvstr[4];' and the 'short > subversion, pads;' should be written. > > So, these are 8 bytes. 4 for the char array and 2 times 2 for the shorts. > Now, the Blender-written .blend file here has only 4 bytes written, instead > of the expected 8. > > I assume this is due to the fact, that compiler optimization kicks in, > resulting in the char-array member being simply erased from the struct > definition, because it is actually never read anywhere in the code. > > Only the char array is read, namely in the function 'read_file_version' > defined in 'readfile.c'. > > Is this right? > Otherwise I would not know how Blender falls short of writing the 4 > additional bytes there. > > Best regards, > Kai > _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers