   Binary / compresed XML (tinyXML)
  XML is very easy to use but has the problems that it's bloated and very easy to change by stupid customers thinking "I know XML".Is it possible that libraries like TinyXML can understand XML files saved in binary format? I suppose one option is to have the files in binary mode and at run-time, make an ascii version (or maybe an in-memory version)?Anyone done this?   
  there are free zip libraries so you can zip/unzip the xml at run time. I think there is a tutorial on this site about such a zip library.Ofcourse the stupid user can figure out its a zip file, open it with winzip and edit the xml...   ;  www.icculus.org and  there  search for physfsits a virtual file system that can be plugged into your application easily and it supports reading of several compressed fileformats like zip ...   ;  The 0ad project uses XML to store most text data. Loading plain XML is slow (especially when it drags in Xerces, ugh), so we decided to go with a binary variant.At time of evaluation, there was no existing library for this; we implemented our own version that runs to about 1000 LOC. This could be made available, but some project-specific code needs to be stripped out first.Some details on how it works: code uses only the XMB interface to read in data. Both the XML and XMB are on disk; at runtime, XMB is created anew if the XML has changed (the aim here is the opposite of yours - encouraging moddability).Currently - due to use of UTF16 - XMB files can sometimes be larger than XML, but this would be reversed if using UTF8, to which we will switch at some point. Main advantage of XMB is reduction in load time due to less string parsing.   ;  I wasn't so much thinking of a different file-format, just having the data stored in a file on which you'd need fopen(path,"rb") - I wonder if I could do a very simple tweak to TinyXML to support this - all the C library functions work on both text/binary files I think?   ;  I think you misunderstand the point of text vs. binary files. They are the exact same thing, with the only difference that "binary" files do not attempt to do any CR/LF <-> '\n' newline translation when reading/writing.As to the problem of XML files being user-legible or slow to load, fopen(fn, "r") vs fopen(fn, "rb") makes no difference.   ;  If you're worried about users modifying the files, then why don't you just use some basic form of encryption? Just scramble the data a little.   ;  If the data in the file CAN be modified by users without breaking your program or, stop trying to control the world and trust them.  Their desires are in fact the reasons the game exists in the first place.  You should never take customization away from the user for no valid reason.  If you are worried about them making changes which don't work well together simply do 2 things - 1 change the file extension of the data files, so only users who actually KNOW they are taking a risk will be doing so (anyone who digs into unknown / undocumented files and makes changes realizes they might screw something up).  Or, simply provide 2 copies of the file, one labeled something like "original" or "default" that only gets used if the first copy doesn't exist.  This way users can experiment and then back out if they mess it all up.If there are in fact things in the file you don't want them to change for fairness reasons, then you really need to encrypt the file or at least add a checksum type item to it.   ;Quote:Original post by Jan WassenbergI think you misunderstand the point of text vs. binary files. They are the exact same thing, with the only difference that "binary" files do not attempt to do any CR/LF <-> '\n' newline translation when reading/writing.As to the problem of XML files being user-legible or slow to load, fopen(fn, "r") vs fopen(fn, "rb") makes no difference.You try writing 1000000 characters to a file in text mode and to binary mode. The binary file will be a lot smaller.;Quote:Original post by d000hgQuote:Original post by Jan WassenbergI think you misunderstand the point of text vs. binary files. They are the exact same thing, with the only difference that "binary" files do not attempt to do any CR/LF <-> '\n' newline translation when reading/writing.As to the problem of XML files being user-legible or slow to load, fopen(fn, "r") vs fopen(fn, "rb") makes no difference.You try writing 1000000 characters to a file in text mode and to binary mode. The binary file will be a lot smaller.Heh. Uh, okay.[bsunshin@Monster ~]$ cat > filemaker.c#include <stdio.h>int main(){    FILE* a = fopen("text.fil", "w");    FILE* b = fopen("binary.fil", "wb");    int i;    for(i=0; i<1000000; i++)    {   fprintf(a, "Z");   fprintf(b, "Z");    }}[bsunshin@Monster ~]$ make filemakerccfilemaker.c   -o filemaker[bsunshin@Monster ~]$ ./filemaker[bsunshin@Monster ~]$ ls -l text.fil binary.fil -rw-r--r--  1 bsunshin grads 1000000 Jun  4 13:16 binary.fil-rw-r--r--  1 bsunshin grads 1000000 Jun  4 13:16 text.fil[bsunshin@Monster ~]$ Convinced yet, or do you want to try it yourself?   