-

[DFYX]

Mal nur zum Dateiformat: auf keinen Fall XML für die Layerdaten. Zumindest nicht so, wie du es oben beschreibst. Mit <tile sourcex="wert" sourcey="wert"></tile> hast du pro Tile ca. 40 Bytes Overhead nur für die XML Struktur (ohne Einrückungen). Nimm dafür lieber ein Binärformat, in dem einfach nacheinander die Tiledaten als short oder int abgelegt sind. Die Reihenfolge kannst du ja als gegeben annehmen, wenn nur deine eigenen Programme mit dem Format arbeiten. Damit braucht eine 20x15 Tiles große Map grade noch 600 bzw. 1200 Bytes statt ca. 13 kB. Das ist immerhin um einen Faktor 10 bis 20 kleiner und bei großen Maps rechnet sich das. Außerdem ist es wesentlich leichter einzulesen. Lukis Argument mit der Plattformabhängigkeit versteh ich jetzt nicht so ganz. Unterschiedliche Größen von Datentypen sind unwichtig, weil du beim Lesen aus Dateien auch einfach die Anzahl der zu lesenden Bytes angeben kannst und für unterschiedliche Endigkeiten gibt es auch eine recht einfache Methode. Schreibe an den Anfang der Dateien zwei bekannte Bytes, etwa 0xFF00 und mache dann folgendes:

Code (C):

 
// ...
short temp;
bool must_swap;
fread(&temp, 2, 1, file);
if(temp != 0xFF00)
{
    must_swap = true;
}
//...
 
for(i = 0; i < num_tiles; i++)
{
    fread(&tiles[i], 1, 4, file);
    if(must_swap)
    {
        tiles[i] = SWAP_SHORT(tiles[i]); // Oder wie auch immer du das Makro nennst
    }
}

Dann musst du nichtmal beim Schreiben auf die Endigkeit achten, nur beim Lesen. Alternativ kannst du auch alles grundsätzlich in Network Byte Order speichern. Funktionen zum Umwandeln sind htonl/ntohl, htons/ntohs, etc. liegen aber je nach Betriebssystem in unterschiedlichen Headern.