Depending on how complex your maps are, I would say you should just write it out in binary so you don't have a lot of bloat (unless of course you want to edit your map files by hand). Then you could just write the width and height of your map, and then use that information to read in the correct dimensions.

XML is another possible solution, but would be more programmatically difficult. Since I don't know your skill level, nor the amount/types of data your map format will entail, I would just suggest my aforementioned solution.

Well using xml makes spotting errors a lot easier.

Unless you are going to export a lot of nonsense data.
By nonesense I mean data that have no place in xml, 3d geometry, images
and so on. *This is my personal meening, If you are one of those who
use xml for everything, then please continue to do so..*


Then I would sugguest that you take a quick look on xml.
As binary formats have a way of getting out of hand when you
start to add lot of new stuff, and harder to debug.

I can recomand tinyxml
as its tiny, easy to use and great for beginning with xml.

*cough cough*...
Shutup all you xml freaks he's storing a large data array for goodness sakes, not a hierarchical structure!

Sorry, you'll have to excuse that lot. You mention certain buzzwords like xml & somehow the actual problem seems to completely bypass their brains & they go into automatic lets-post-as-many-links-to-our-favourite-library-as-possible mode

Erm no. xml is certainly no good for storing tilemaps
It's use is for object based data
It might be usefull for storing entities within your map like characters or points of interaction
But the map itself is probally just gonna be a giant array of values so you'd be better off storing it the way you are, or using a binary format
The article Simple File I/O Using C++ covers binary input & output briefly, but I'm afraid you'll have to look yourself to find more indepth articles as I am tight for time atm
It should be noted that the method used there (dumping whole structs & classes @ a time) is safe for "simple" structures
That means no values stored remotely by pointers (like std::string etc)
Also the data would need to be solid state since any constructors would be bypassed upon reloading
However if you just want to chuck a simple int array into it via binary then it would work something like this:

unsigned int map_width=512;unsigned int map_height=512;int *map=new int[map_width*map_height]; //runtime allocated size, don't forget to free//saveofstream file("filename",ios::binary);file.write((char*)&width,sizeof(unsigned int));file.write((char*)&height,sizeof(unsigned int));file.write((char*)&map,sizeof(int)*width*height);file.close();//load//free any old map that has been allocated with the 'delete' keyword before entering hereifstream file("filename",ios::binary);file.read((char*)&width,sizeof(unsigned int));file.read((char*)&height,sizeof(unsigned int));map=new int[width*height];file.read((char*)&map,sizeof(int)*width*height);file.close();

That is a very simple example
(I delibrately avoided classes to keep it simple)
But that's the basics of how binary works
The data is dumped in raw form & as long as you reload exactly the same sizes of memory (or marked earlier in the file any sizes which change) then it should reread exactly as it was saved

Damnit gtg, sorry I couldn't of been more help

No, he asked the best way of doing it & weather xml was a good answer
The best way of storing map arrays is in a binary form & xml is certainly not in any means a sensible answer to this

However, he may want to somehow append an xml block to the end of the file or prehaps use a second file for storing any object based data in the map (like entities), but that will probally come later

edit: hmm actually appending an xml block to the end would be kinda silly as you couldn't edit it by hand (isn't that the whole point of xml?)

Quote:Original post by walle
Is XML really as great and useful as they say?

No, but it is probably still well suited for your task, especially since that will likely not be your final map format, and XML allows for changing/expanding the format easily. If anything, XML should be the quickest to get working, so you can actually make stuff and worry about dumb stuff like map formats later.

And for those nay-sayers... What happens when there's actually objects in the tilemap hrrrm? No hierarchical structure now, but what happens when "map data" becomes "save game"?