Right, I couldn't get the original URL to work, but ... read this if you haven't before.

Don't ask me; you're the script guy I just make the pretty pictures ...

simplep: I've never used XML, but that's certianly not what I had in mind. Though I would not be adverse to someone demonstrating a good way to customize the file format (as I've no clue) ...

Surely XML is overhyped. But it is not entirely useless, in my opinion. The point of XML is:

1) as a text file, it can always be modified with a simple text editor like Notepad or vi

2) a generic XML tool like XmlSpy can be used

3) it is a structured format; allows very easy representation of trees

4) it is as human readable as much as the tags allow it. If the tags are obscure, then the whole XML document is obscure. If the tags are clear enough, then it is quite human readable

5) it is almost self-documented; you can come back a year later and remember just by reading the XML document what its data are; if you have binary format only, there should be documentation around

6) it carries itself around different architectures; no need to worry about little/big endian

7) since it is self-documented, new external tools can be easily programmed either by the original author or by others.

Your point is correct though that it takes too much space. Since it is text, it can be compressed quite well. It is also correct that it takes a while to be loaded and parsed. But, remember, it is for tools.

In the place that I work, we have successfully used XML over a variety of products. It have solved quite some problems, especially data exchange between different architectures.

That's true. You can't see how the level is from the file. But neither you can from the binary format. From my point of view, XML has more advantages than disadvantages. It is worthy enough to give it a try.

I forgot the biggest advantage of XML: flexibility. A small set of tags may be defined today; future tags will not break backwards compatibility; the XML files may specify additional information, but they will be still loaded from older applications. Imagine a situation where you would like to extend your tilemaps with new attributes. With a binary-only format, you would have to re-compile the tilemap editor in order to support the new format; by using XML though, you can specify additional attributes for each tile, and the tilemap will still be loadable by the tilemap editor. This makes a huge difference. And by making the tilemap editor expandable by plug-ins, you can always provide additional processing for the new attributes.

Of course all these can be done with binary only, but more difficult. I think XML makes my programming life quite a bit easier.

If you do it right, you can do a loader that would load binary data of future versions: for each chunk of data, store its size at the beginning. If a chunk in version 1.0 has 4 variables stored, with a size of 16 bytes, and, in version 2.0, you add 2 more variables, making a total of 24 bytes, an old version capable of loading only 1.0 files, would read the first 4 variables (16 bytes) and skip the two variables that doesn't recognize. It's some work, but may be worth it.

Compare .psd (photoshop's internal format) file sizes to .tga's, .bmp's or any other format. Compare .doc files to .txt, or even .rtf files.

The internal format of any editor is supposed to be large; it has all kinds of information that the "object" formats don't need.

We're talking about the tile editor's internal format, yes? If so, there's an entire undo-stack in that file (if there isn't, there should be), containing arbiturary information. Information that can change frequently as the tile editor is developed. And if the editor has plugins, their actions have to go there too.

Flexibility is important in the internal format of a plugin-able system.

In theory. In practice, using something like Xerces to write/read an .xml file is simplicity itself. It's not like you have to write an .xml parser or something.

Allegro's .dat files are "endian-independent", for formats that it understands. But storing and retrieving arbiturary data in them (as a block) isn't.

Considering that this debate is solely on the internal format of the tile editor (which I didn't realize at first), arguments about file size are irrelevant (unless they're extraordinarily huge). Thanks to freely-avalaible .xml parsers, arguments about the ease-of-use are equally irrelevant. The only real question is, "Can the text be parsed and loaded fast enough?" That's a non-trivial question, depending on how fast you would like your loading to work.

The point I was making is that saying, "A text file is larger than a binary file" is not a valid argument for not using .xml as an editor's internal format. The reason is that the internal format of most large programs is larger than the external format. As such, the file size of the internal format is irrelevant (unless it pertains to speed).

I think it was Max I saw doing that. I can't be certain, though. I know I used some program that went so far as to save the undo stack.

Those functions store a single word, not arbiturary data. Sure, you could put your data together into words and save/load them with these functions, but that's hardly "arbiturary data".

OpenOffice's gzipped XML files (its native file format) are significantly smaller than MS Office's .doc (on just about every document I converted). I don't believe the .doc contains any additional data that isn't present in the XML conversion.

I have a simple XML parser on my site, written in C. Uses callbacks to parse, and depends on well-formatted XML docs.

Who set that rule and how badly do I get punished? MapSlapper is 220KB and one of my files (which includes the tileset images) is 85KB. I expect that number to climb when I add animation, "stamps", etc.

I'll look at Bob's parser, but my file format considers all parts optional (like the palette in .bmp files), with a flag at the begining which details what's there and what's not (tileset, bitmasks, animation, etc). It won't save the tilemap in anyone's predetermined format, but it's versatile enough for me

How much more would you need? About the only thing that can't be handled is the combat engine, and depending how generic you want to be, even that's debatable.

It's a good idea if only because RPG's tend to be the hardest genre to program. A little help getting started would be nice. Alternatively, if someone were to write a tutorial and provide a lot of souce code with many different ways of doing things, that would be helpful as well ...

A library is not an engine. There's nothing wrong with helper functions. As for knowing exactly how it works, I'm all for fully documented source code. If you want an idea what I mean, read my third STL article on my site and see if you can easily follow what's goin on in the code (I write several pages outlining it). Assuming you know C++, of course A library would be documented even moreso; in fact, for those quibbling over tilemap file formats, I can tell you now it would be less than effort to modify the Save and Load functions in my editor. I've ben doing it quite often myself, actually

By code documentation, I include the notion of stand-alone docs (again, see my third STL article for a rough example). A readme outlining the files and what's in them. When you find the file with the functionality you want to alter, you open it and find the exact code, which is commented further. If you can imagine it being documented in some way, it will be; let's put it that way

So? My tilemap editor makes tilemaps I can use for my platformer, shooter and RPG. Doesn't get much more diverse than that. Remember; this is a library, not an engine

You'd need a versatile tilemap editor, a versatile scripting language (rip off Lua or something ) and some GUI/dialog functions. That's a big chunk of your RPG engine done for you, and doesn't rob you of a whit of "customization ability".