Elemental: War of Magic



  • So, any thoughts on the alleged spiritual successor to Master of Magic?

    As for me, I just noticed that the CEO / lead designer/programmer kept going on and on about XML in the devblog, which gave me a bit of a chuckle...

    Google: +xml +elemental site:frogboy.joeuser.com

    http://frogboy.joeuser.com/article/390558/



  • Using XML is not a bad idea. It is human-editable and if you have a serializer you can read data and save games pretty easily using just the objects in your code.

    However one thing that I thought was strange was the fact that loading 11 MB of XML is slow. They must be doing something wrong.



  • @some guy trying to be helpful said:

    Would it help if you combined more of the XML files into bigger XML files only have less of them? Not sure if reading individual smaller files takes longer than reading less but larger files. Maybe be an option though?
    Oh yes, that oughta help..

     

    I like how someone suggested putting a game of pong on the loading screen. Reminded me of the Broken Sword installation process.



  • I could understand using XML files for the development process (easier to update stuff, don't need to recompile) but releasing it with it is kinda stupid and I really don't see why they use this method. For me, an XML file is only really useful for a setup/param file.



  • @TheMugs said:

    I could understand using XML files for the development process (easier to update stuff, don't need to recompile) but releasing it with it is kinda stupid and I really don't see why they use this method. For me, an XML file is only really useful for a setup/param file.
     

    Agreed. In my opinion it's probably worth the development time and money to create binary formats for the game data. Then your 11 MB of XML becomes 1 or 2 MB of binary that doesn't have to go through a text-parsing engine to use. Anything that makes the app faster (or seem faster) is a good thing.



  •  It's mainly to support user modding from what I have understood but they really shoud use binary files generated from the xmls for endusers, modders could then just flip a switch to use xmls instead of binary and then once they are done flip another switch to generate the binaries.



  • @u2892 said:

    So, any thoughts on the alleged spiritual successor to Master of Magic?
    Wow, Master of Magic, as in the 1994 Microprose still-lives-on-in-DOSBox-and-gets-more-playtime-than-Civ-IV classic TBS? Now... if only Elemental: War of Magic didn't suck.



  • XML wouldn't be so bad except that XML has so much redundant data...I wonder out of that 11MB how much is real data and how much is tags?

    There's something seriously wrong in my mind with any data management format where the metadata takes up more space than the useful data.

    (Now, I realize this is perhaps not an inherent limitation of XML so much as a statement on common utilization of XML).



  • @Zecc said:

    I like how someone suggested putting a game of pong on the loading screen. Reminded me of the Broken Sword installation process.
    It was Strike Commander that actually had a game of pong on every in-game loading screen. Best part of the entire game.

     



  • @too_many_usernames said:

    (Now, I realize this is perhaps not an inherent limitation of XML so much as a statement on common utilization of XML).

    It does require you to duplicate the tag name in the closing tag, and if you want your tags to have sensible names, they're bound to be more than two or three characters long. It's better to use attibutes for singular data, but they too can waste space due to requiring a name and quotation. Of course, you could pack multiple data items in the text inside a tag, but then you'll have to implement your own parser for it (which can be as simple as split-by-spaces).

    I'll illustrate with a few examples:

    <position><x>1.5</x><y>0.7</y><z>-2.2</z></position>

    This is horribly verbose, having 42 characters of tags for 10 characters worth of data. Still, it's proper XML and some people seem to prefer this sort of usage.

    <position x="1.5" y="0.7" z="-2.2" />

    A lot better, with only 27 characters of metadata for the same 10 characters of data. Also proper XML.

    <position>1.5 0.7 -2.2</position>

    Now it's 21 characters of metadata, plus the two spaces separating the items. This usage is questionable due to the contents requiring further parsing (aside from data type conversion).

    position 1.5 0.7 -2.2;

    A non-XML format can achieve the same with only 12 non-data characters, while still clearly labeling the data. The parsing library can take care of separating the parameters.



  • Is it just me, or when he's emphasizing the whopping (at least it is to him) "3.31 MEGABYTES of XML", I'm thinking "That's tiny!" - Our office PCs process more than that in one go (upto 20Mb) doing credit reference searches on individual customers (and simultaneously deciding whether or not to give a loan to the given customer), and a lot of the PCs in question are crappy single core efforts, but it's still nice and quick even on them!!


    What's he parsing it with to complain about speed? A Commodore 64?!



  • @MeesterTurner said:

    Our office PCs process more than that in one go (upto 20Mb)
     

    That still doesn't sound like sth you want to do with XML - that sounds like database stuff. Just because it can be done, doesn't mean it's right.

    Of course, I don't know anything about the situation, so I could be completely wrong here - just a gut feeling.



  • @too_many_usernames said:

    XML wouldn't be so bad except that XML has so much redundant data...I wonder out of that 11MB how much is real data and how much is tags?

    There's something seriously wrong in my mind with any data management format where the metadata takes up more space than the useful data.

    (Now, I realize this is perhaps not an inherent limitation of XML so much as a statement on common utilization of XML).

    If you can get by with loose typing, JSON is much, much better.



  • @b-redeker said:

    @MeesterTurner said:
    Our office PCs process more than that in one go (upto 20Mb)
     

    That still doesn't sound like sth you want to do with XML - that sounds like database stuff. Just because it can be done, doesn't mean it's right.

    Of course, I don't know anything about the situation, so I could be completely wrong here - just a gut feeling.

     

     Agreed.  If you have XML in any quantity measured in units larger than KB, you're doing something very wrong.



  • @tdb said:

    A non-XML format can achieve the same with only 12 non-data characters, while still clearly labeling the data. The parsing library can take care of separating the parameters.
    Doesn't sound right to me. In your example, your "position 1.5 0.7 -2.2;" format needs to have the meaning defined for it to tell you anything. Might as well strip out the 'position' identifier entirely. "<position x="1.5" y="0.7" z="-2.2" />" is the shortest format that contains all the information. I would note, though, that using 'Pos' for 'Position' would save a fair few characters.

    @Mason Wheeler said:

    Agreed.  If you have XML in any quantity measured in units larger than KB, you're doing something very wrong.

    Not entirely true. If you're regularly processing or transferring the data, then it's true, but XML is often a good way to store data. The whole point is to mix metadata with data, and that's appropriate in some contexts and inappropriate in others. The obvious penalty is the size increase, but that's only an issue if you have to send the data via a slow connection at some point, or have absolutely immense data sets and insufficient hardware to deal with them.



  • There is a data format class that most people seem to have forgotten exists, binary data. It can be formed in countless ways, but basically it is very easy to use. Every programming language capable of file handling has these neat commands, typically named something like readint, writeint, writeint64, writestring, readstring. All one has to do is use the corresponding sequence of read commands when reading the file, as was used for writing it. It is way faster than all the text data formats.

    Anyone programmer who think of binary data as clumsy, weird, hard to use or "only for the pros", really ought to get to know their computer better. A binary format should be the default choice, and then XML might be chosen in a few cases where a normal binary file format lacks a feature that XML has.



  • @eBusiness said:

    There is a data format class that most people seem to have forgotten exists, binary data. It can be formed in countless ways, but basically it is very easy to use. Every programming language capable of file handling has these neat commands, typically named something like readint, writeint, writeint64, writestring, readstring. All one has to do is use the corresponding sequence of read commands when reading the file, as was used for writing it. It is way faster than all the text data formats.

    Anyone programmer who think of binary data as clumsy, weird, hard to use or "only for the pros", really ought to get to know their computer better. A binary format should be the default choice, and then XML might be chosen in a few cases where a normal binary file format lacks a feature that XML has.

    I'm an old Mac OS programmer, so I'm still gunshy about Endian issues. Honestly, I'd still prefer an ASCII-based file format to anything binary, for exactly that reason-- who knows whether your binary files will still be good when you switch CPUs? Or we have quantum trinary computers? Or we store data in crystals, like HAL-9000? ASCII you know is good forever.

    (That said, ASCII != XML. You can write much faster parsers if you ignore the XML fluff and only include what you absolutely need.)



  • @blakeyrat said:

    ASCII you know is good forever.
     

    Though text-based documents aren't always ASCII, and confusion involving UTF-8, ISO-8859-1, WINDOWS-1252, and other encodings and proprietary code pages, and attempts by ignorant users/developers to shove characters (like curly quotes) in documents encoded in a format that doesn't technically support them, can cause problems.



  • @dtobias said:

    @blakeyrat said:

    ASCII you know is good forever.
     

    Though text-based documents aren't always ASCII, and confusion involving UTF-8, ISO-8859-1, WINDOWS-1252, and other encodings and proprietary code pages, and attempts by ignorant users/developers to shove characters (like curly quotes) in documents encoded in a format that doesn't technically support them, can cause problems.

    All of that is NOTHING compared to endian errors.



  • @dtobias said:

    @blakeyrat said:

    ASCII you know is good forever.
     

    Though text-based documents aren't always ASCII, and confusion involving UTF-8, ISO-8859-1, WINDOWS-1252, and other encodings and proprietary code pages, and attempts by ignorant users/developers to shove characters (like curly quotes) in documents encoded in a format that doesn't technically support them, can cause problems.

    Looks like both YAML and JSON assume a file is encoded in UTF-8, and accept others Unicode encodings when appropriately identified by a BOM. Sounds like a good policy to me.


  • @blakeyrat said:

    I'm an old Mac OS programmer, so I'm still gunshy about Endian issues. Honestly, I'd still prefer an ASCII-based file format to anything binary, for exactly that reason-- who knows whether your binary files will still be good when you switch CPUs? Or we have quantum trinary computers? Or we store data in crystals, like HAL-9000? ASCII you know is good forever.

    (That said, ASCII != XML. You can write much faster parsers if you ignore the XML fluff and only include what you absolutely need.)

    ASCII is built on binary data, if you for some silly reason ever get hold of a computer that can't handle binary data in the 8b/B form then your beloved ASCII is gone too. As for endianness, it used to be a problem because people ignored it and simply implemented whatever was native on their platform, the true problem was a lack of standards for a lot of file formats, different endianness is just one of many ways in which implementations differed.

    In case anyone should be in doubt, no, it is not hard to read and write little endian on big endian systems and vice versa. It takes a little extra effort, but less that of reading and writing ASCII decimal numbers.



  • @eBusiness said:

    In case anyone should be in doubt, no, it is not hard to read and write little endian on big endian systems and vice versa. It takes a little extra effort, but less that of reading and writing ASCII decimal numbers.
    I don't think that's the problem blakeyrat was talking about. The problem is detecting endianess in the first place.

    At least with ASCII you know the characters/bytes are read from the file in order.

    Eg. <font face="courier new,courier">0x0080</font> could be 128 or 32768 depending on your endianess, but <font face="courier new,courier">0x31 0x32 0x38</font> is always "128".



  • @Zecc said:

    @eBusiness said:
    In case anyone should be in doubt, no, it is not hard to read and write little endian on big endian systems and vice versa. It takes a little extra effort, but less that of reading and writing ASCII decimal numbers.
    I don't think that's the problem blakeyrat was talking about. The problem is detecting endianess in the first place.
    That was really just bonus info in order to avoid nontechies making nonproblems of endianness. (I have seen too many cases where people with minute knowledge of IT spoil a debate by making up technical problems and discussing them, so I tend to clarify whenever I see potential for misinterpretation.)

    As for endianness, that goes into the documentation, which is needed for any serious file format anyway. Old disasters like TIFF grow no worse or better from overhead added in modern file formats.



  • @Zecc said:

    @eBusiness said:

    In case anyone should be in doubt, no, it is not hard to read and write little endian on big endian systems and vice versa. It takes a little extra effort, but less that of reading and writing ASCII decimal numbers.
    I don't think that's the problem blakeyrat was talking about. The problem is detecting endianess in the first place.

    At least with ASCII you know the characters/bytes are read from the file in order.

    Eg. <font face="courier new,courier">0x0080</font> could be 128 or 32768 depending on your endianess, but <font face="courier new,courier">0x31 0x32 0x38</font> is always "128".

    Bingo. Anybody who's written software for Classic Mac would understand. The ASCII->data translation is already in the language, no matter how low-level. I'd much rather be using fscanf() on that "128" string than counting on the "luck" (that computers all use Intel-based CPUs) for the 0x0080 to mean the right thing.



  • @blakeyrat said:

    counting on the "luck" (that computers all use Intel-based CPUs) for the 0x0080 to mean the right thing.
    If you are a dumbwit who can't reverse the order of 4 bytes then it is luck. For the rest of us it takes 5 minutes to write a generic read and reverse function.



  • @eBusiness said:

    @blakeyrat said:

    counting on the "luck" (that computers all use Intel-based CPUs) for the 0x0080 to mean the right thing.
    If you are a dumbwit who can't reverse the order of 4 bytes then it is luck. For the rest of us it takes 5 minutes to write a generic read and reverse function.

    Wow! All thousands of bugs in hundreds of programs, and you could have fixed them all with a snap of your fingers! You truly are the Greatest American Hero. I guess I forgot that everybody in the 90s was a total retard and would never have come up with that on their own!

    You win all.



  • The problem is legacy, I can do it right, but I can't revert it where it has already been done wrong. And that pretty much sums up why using binary for a new data format does not cause said problems. (Unless of course if you really strive for them.)

    What is an American hero anyway? Seems not to describe anything but what we in the rest of the world would simply call a hero, but in Gods Own Country that word apparently must have a hint of nationalistic fanaticism.



  • @eBusiness said:

    The problem is legacy, I can do it right, but I can't revert it where it has already been done wrong. And that pretty much sums up why using binary for a new data format does not cause said problems. (Unless of course if you really strive for them.)

    Mostly I'm making fun of you assuming every single human being writing software in the 90s was so stupid that this "non-issue" (in your opinion) was actually an issue. Gee, maybe there's more to it than you think? Guess what, you're not as smart as you think you are.

    The fact is, it was an huge problem on 68k and PPC platforms when porting software. Is it an issue now? Kind of, there are still PPC machines that default to big-endian (The Xbox 360, for example, and probably the Cell chip inside PS3s), but that's a special case because PPC chips can be switched to operate in little-endian mode. So presumably those machines switch themselves to little-endian after they boot.

    BTW, look at this article. WTF! Someone shat out "citation needed" on every single fucking sentence, it's a completely unreadable mess. Some Wikipedia editors need a boot in the ass.

    @eBusiness said:

    What is an American hero anyway?

    The Greatest American Hero:

    @eBusiness said:

    Seems not to describe anything but what we in the rest of the world would simply call a hero, but in Gods Own Country that word apparently must have a hint of nationalistic fanaticism.

    Or maybe you're reading waaay too much into a stupid throwaway pop-culture joke.



  • @blakeyrat said:

    Mostly I'm making fun of you
    I hadn't noticed, thanks for telling.

    Never said it was a non-issue, but it is the kind of issues that arise only because they are ignored, and in this case probably also because of the endianness war.

    @blakeyrat said:

    Guess what, you're not as smart as you think you are.
    Or perhaps I simply assume that other people are smarter than they actually are.

    @blakeyrat said:

    The fact is, it was an huge problem on 68k and PPC platforms when porting software.
    Really? So if the source code compiles on a different platform to read data the wrong way, wouldn't simply exchanging all the read and write commands with their inverse counterparts do the trick? On top of all the other porting stuff of course. In any case, that is a problem with the programming language not being defined uniformly across compilers and platforms.

    As for the term American hero, I wasn't asking about that idol of yours, I meant the term in general. (I presume the term precede the TV series?)



  • @eBusiness said:

    As for the term American hero, I wasn't asking about that idol of yours, I meant the term in general. (I presume the term precede the TV series?)

    Shockingly, it's a combination of "American" and "hero." As in, "a hero who is American."

    What nationality are you? Jackass?



  • @blakeyrat said:

    @dtobias said:
    Though text-based documents aren't always ASCII, and confusion involving UTF-8, ISO-8859-1, WINDOWS-1252, and other encodings and proprietary code pages, and attempts by ignorant users/developers to shove characters (like curly quotes) in documents encoded in a format that doesn't technically support them, can cause problems.
    All of that is NOTHING compared to endian errors.
    ...because as long as you get the encoding right, the endianness doesn't matter, right?


  • It just seems odd that you always have to attach the nationality whenever talking about heroes, I get the point when you talk about warheroes, since in those cases heroism is relative depending on ones alignment, but in most other cases the act of heroism is not related to the nationality, so it seems odd to prefix the nationality.

    I'm from Denmark if you must know, your closest and dearest allies in the war against muslims terror. I guess that is not a lot better than the country of Jackass, but at least it is not the states.



  • @eBusiness said:

    It just seems odd that you always have to attach the nationality whenever talking about heroes, I get the point when you talk about warheroes, since in those cases heroism is relative depending on ones alignment, but in most other cases the act of heroism is not related to the nationality, so it seems odd to prefix the nationality.

    IT'S THE NAME OF A STUPID 1980s ACTION/COMEDY SHOW YOU IDIOT! I wasn't "attaching the nationality whenever talking about heroes", I was dropping the title of a TV show.

    I already fucking explained it's a joke! I even provided a visual aid! Fuck, it's like explaining it to the Thermians in Galaxy Quest. (Note to Danish people: Galaxy Quest is a fake Hollywood movie. Tim Allen is not real, only an expensive special effect.)

    @eBusiness said:

    I'm from Denmark if you must know,

    You have all kinds of crazy-ass heroes. What the fuck are you on about? How about Knut the Great?

    @eBusiness said:

    I guess that is not a lot better than the country of Jackass, but at least it is not the states.

    I was making a clever subtle reference that you were being a jackass. Since you're still being a jackass, I'm afraid you didn't get it. But good job, you've single-handedly brought my opinion of Denmark from "where?" to "oh that jackass eBusiness lives there".



  • @blakeyrat said:

    @eBusiness said:
    It just seems odd that you always have to attach the nationality whenever talking about heroes, I get the point when you talk about warheroes, since in those cases heroism is relative depending on ones alignment, but in most other cases the act of heroism is not related to the nationality, so it seems odd to prefix the nationality.

    IT'S THE NAME OF A STUPID 1980s ACTION/COMEDY SHOW YOU IDIOT! I wasn't "attaching the nationality whenever talking about heroes", I was dropping the title of a TV show.

    I already fucking explained it's a joke! I even provided a visual aid! Fuck, it's like explaining it to the Thermians in Galaxy Quest. (Note to Danish people: Galaxy Quest is a fake Hollywood movie. Tim Allen is not real, only an expensive special effect.)

    @eBusiness said:

    I'm from Denmark if you must know,

    You have all kinds of crazy-ass heroes. What the fuck are you on about? How about Knut the Great?

    @eBusiness said:

    I guess that is not a lot better than the country of Jackass, but at least it is not the states.

    I was making a clever subtle reference that you were being a jackass. Since you're still being a jackass, I'm afraid you didn't get it. But good job, you've single-handedly brought my opinion of Denmark from "where?" to "oh that jackass eBusiness lives there".

    I think the confusion here is arising because the 'American Hero' is better known in Europe as a literary characterisation than a crappy tv show, so that's probably the idiom that eBusiness was thinking of. It refers to hero in the sense of a protagonist, not some bloke with more muscles than brains. Robert de Niro's character in Taxi Driver is generally considered to be an American Hero, as is Huck Finn.

    P.S. Has it occurred to you that he might have been trolling you as well?



  • @davedavenotdavemaybedave said:

    P.S. Has it occurred to you that he might have been trolling you as well?

    Unpossible. Other nations have not yet invented trolling!



  • @blakeyrat said:

    I wasn't "attaching the nationality whenever talking about heroes"
    Actually that is the first time in this debate where you have written hero without also writing American, and that seems to be solely because it is part of a quote.

    @blakeyrat said:

    I already fucking explained it's a joke! I even provided a visual aid! Fuck, it's like explaining it to the Thermians in Galaxy Quest. (Note to Danish people: Galaxy Quest is a fake Hollywood movie. Tim Allen is not real, only an expensive special effect.)
    Do you ever make a cultural reference to anything without lame alien plots?

    @blakeyrat said:

    I was making a clever subtle reference that you were being a jackass.
    Sank you veri much for explanin, me englis not so gut, so me not understand you pathetic insult.

    @blakeyrat said:

    But good job, you've single-handedly brought my opinion of Denmark from "where?" to "oh that jackass eBusiness lives there".
    You have truly been enlightened, now you can tell your fellow USAnians about this disgusting place, and next time you all decide to bomb something you will pick Denmark. (Provided that you manage to get hold of a map displaying the world beyond North America, otherwise you will just have to make a random pick like you usually do.)

    @blakeyrat said:

    Unpossible. Other nations have not yet invented trolling!
    We just call it "Diskutere ting med USAnere over internettet", it is not that we don't know the art.



  • @eBusiness said:

    Actually that is the first time in this debate where you have written hero without also writing American, and that seems to be solely because it is part of a quote.

    And?

    @eBusiness said:

    Do you ever make a cultural reference to anything without lame alien plots?

    Yeah, one time I made a great reference to Highlander 2. That one was amazing.

    @eBusiness said:

    You have truly been enlightened, now you can tell your fellow USAnians about this disgusting place, and next time you all decide to bomb something you will pick Denmark.

    No we won't, because Denmark doesn't have oil! Oooo buuuurn.

    @eBusiness said:

    We just call it "Diskutere ting med USAnere over internettet", it is not that we don't know the art.

    Internet-tit?



  • @blakeyrat said:

    Yeah, one time I made a great reference to Highlander 2. That one was *amazing*.
    Good call, and except for the part where immortals turn out to be aliens the plot is not at all lame. You must be almost as smart as a conehead.

    @blakeyrat said:

    Internet-tit?
    You seem kind of desperate.



  • @eBusiness said:

    @blakeyrat said:
    Yeah, one time I made a great reference to Highlander 2. That one was amazing.
    Good call, and except for the part where immortals turn out to be aliens the plot is not at all lame. You must be almost as smart as a conehead.

    Yeah and you're about as charming as that movie where it has Hulk Hogan and that dude from Back to the Future and he's like taking care of the kids and there's that weird scene where he loses drag races because he stops at yellow lights!



  • May be, but you think the phone booth you live in is a space ship.



  • @eBusiness said:

    There is a data format class that most people seem to have forgotten exists, binary data. It can be formed in countless ways, but basically it is very easy to use. Every programming language capable of file handling has these neat commands, typically named something like readint, writeint, writeint64, writestring, readstring. All one has to do is use the corresponding sequence of read commands when reading the file, as was used for writing it. It is way faster than all the text data formats.

    Anyone programmer who think of binary data as clumsy, weird, hard to use or "only for the pros", really ought to get to know their computer better. A binary format should be the default choice, and then XML might be chosen in a few cases where a normal binary file format lacks a feature that XML has.

     

     TopCod3r is that you?



  • @eBusiness said:

    @Zecc said:

    @eBusiness said:
    In case anyone should be in doubt, no, it is not hard to read and write little endian on big endian systems and vice versa. It takes a little extra effort, but less that of reading and writing ASCII decimal numbers.
    I don't think that's the problem blakeyrat was talking about. The problem is detecting endianess in the first place.
    That was really just bonus info in order to avoid nontechies making nonproblems of endianness. (I have seen too many cases where people with minute knowledge of IT spoil a debate by making up technical problems and discussing them, so I tend to clarify whenever I see potential for misinterpretation.)

    As for endianness, that goes into the documentation, which is needed for any serious file format anyway. Old disasters like TIFF grow no worse or better from overhead added in modern file formats.

    It IS you! Welcome back.



  • You believe that there exist only one person in this world with a sensible opinion about XML and file formats in general?



  • @eBusiness said:

    You believe that there exist only one person in this world with a sensible opinion about XML and file formats in general?

    Protip: whenever you express an opinion on this board, people react to it as if you had ended your post with:

    And you will follow my advice or you will DIE LIKE THE DOG YOU ARE!

    Because God-forbid people have different opinions.



  • @blakeyrat said:

    Because God-forbid people have different opinions, and you will follow my advice or you will DIE LIKE THE DOG YOU ARE!

     

    FTFY



  • The reason I pick XML (/JSON/YAML/RELOAD) over a binary format is very simple.

    struct DataItem {
        unsigned short something;
        unsigned short somethingelse;
    };
    
    struct DataFile {
        unsigned short numItems;
        DataItem[] items;
    }

    Programmer 1: "This should be good enough for our needs."

    18 Months later...

    Programmer 2: "We need to store someotherthing, and it turns out that we somethingelse needs to be 32 bits."

    Programmer 1: "Shit. All our existing data doesn't have room for this."



  • @pkmnfrk said:

    The reason I pick XML (/JSON/YAML/RELOAD) over a binary format is very simple.

    struct DataItem {
        unsigned short something;
        unsigned short somethingelse;
    };
    
    struct DataFile {
        unsigned short numItems;
        DataItem[ items;
    }

    Programmer 1: "This should be good enough for our needs."

    18 Months later...

    Programmer 2: "We need to store someotherthing, and it turns out that we somethingelse needs to be 32 bits."

    Programmer 1: "Shit. All our existing data doesn't have room for this."

    FYI, RELOAD is a binary format, and a fine example that a file doesn't need to include human-readable overhead to implement key-value and tree structured storage.


  • @eBusiness said:

    FYI, RELOAD is a binary format, and a fine example that a file doesn't need to include human-readable overhead to implement key-value and tree structured storage.

    Yeah, I know, as I designed it.



  • @pkmnfrk said:

    @eBusiness said:
    FYI, RELOAD is a binary format, and a fine example that a file doesn't need to include human-readable overhead to implement key-value and tree structured storage.

    Yeah, I know, as I designed it.

    OH SNAP!



  • classic snap.

     

    Nonetheless,

    @pkmnfrk said:

    I pick [RELOAD] over a binary format

    Wait what?

     


Log in to reply