Using XML? My own binary system? A paint by number scheme?

Somehow, I have no idea how, I have to read structured data from a file. I've been pointed to XML, I can understand how this would work, but another poster suggested I make my own hierarchy, and stated:

Quote:

---

It could be as simple as assigning a number to each node, and then when you store the nodes in the file you reference pointers to children by using their number. Then when reading the nodes from the file, you restore all the pointers after the nodes are loaded.

---

This seems really easy to do, but that doesn't mean I even know where to begin code wise. I'd rather do this over xml because if I used xml then I'd need something like Tiny-XML to parse it and that I feel would be overdoing it. My questions seem simple, but really they are overly complex in my opinion.

1. What do my data files need to look like?
2. How do I create them?
3. How do I load them?

The key to making it simple and to avoid the pointer mess is to avoid the pointers all together.

Instead of maintaining pointers to objects on disk which is a mess, you can do this. When you create the BSP tree you will A) know how many objects are in the level/game, B) how many of those objects are in a node, and C) the ID of those objects.

So you have an object file which contains the objects. If you use the ID of the object as its location in the file, then object with ID of 0 will be the first object in the file. Now to store the BSP tree, simply store the object ID's. This will also work for the actual game engine too since every object is ran through some type of resource manager that's either based on ID's or some other identification system. Also give each node an ID in the tree, a way to store it's parent's ID, and a way to store it's children's ID. You can store the final information for the tree (how many nodes, children, etc, etc) in a structure and use that structure as a header for the file, followed by the actual BSP data.

For terrain quad-tree's you only need to store the world min,max bounds and the node type. The header of the file would store the cellsize for the given world, world width, depth, etc, etc. The pointers to children would be converted to ID's. As long as you use a depth-first method this should work. This means that in the file you go as deep as possible on one node until you reach a leaf node. Then you know the next item in the file belongs in another node. When you load this into memory you can now use your quadtree min,max and type information to construct the actual vertices.

Quote:

---

So you have an object file which contains the objects.

---

In what format? How do you accomplish this? Are you using XML? Are you using your own file types? If you are, how are you doing this?

If you're using XML, what do I need to learn to accomplish the task at hand, granted I don't want to learn an entire markup language to produce 300 lines of functional code, if that.

I remember not 3 months ago I was learning about stl containers... Now this?!

XML is always always a slow solution.
While it can be handy for creating configuration files I'd never use it to hold the actual data.

So you might have an XML file holding the index table to a binary file containing the actual data, but not the actual data itself.

I've decided against making my own binary file format due to my lack of, hmm, wanting to write my own binary file format? XML will be perfectly fine for my needs.

so instead of your own binary file format you are having to make your own DTD or XML Schema document.
Instead of code to read and write that binary format you have to write a parser and writer for that XML Schema or DTD.

And you're ending up with a solution that's slower and takes more memory in the process.

Parser is covered, TinyXML will handle that. And I'm pretty sure I don't need a schema or DTD as long as I'm not displaying the information in an html file.. Thats how I understood it..

you'll still need a means to interpret the data that your XML parser spits out...

that's the real parser, all TinyXML (or Xerces which I prefer) does is give it to you in more easily digestible bites.

A DTD will be crucial as documentation if nothing else, and also allows your parser to check whether input files are syntactically correct.
Prevents a lot of headbanging later when you spent 3 days debugging your code only to notice a typo in your XML file at 3:14:32 sunday morning (trust me, I've had it happen, though not necessarilly at that exact time and date).

So enlighten me oh enlightened one, how does one even begin to write a binary file system?

Binary is base 2, because a computer only needs two possible answers. Yes and no.

Normaly, people use base 10. Ten possible answers, 0-9.

So, the easiest way is to establish a different base. But I dont see why you want to make a new binary system.

Let me re word my statement

A binary file type, which holds a binary ized tree structure?

You mean like open a file for "binary writing" except your version of binary? I dont think you can without making your base computer understand the system. Dunno if I got the question, but I'd have to say its not possible without tons of work.

Nono! I don't wanna create my own binary version!

I just wanna create a binary file structure.. Like a .x file or something!

I need to figure out what I need and stuff...

I know how to do I/O in binary, I'm just unsure exactly what I need in my file to get my job done :D

so you figure out what you want to write to it.
Define how you're going to write and read that information, then possibly (advisable) define a file header containing information about the file (type, maybe a checksum, etc.).

If you don't know what information you need in the file, figuring that out is the first step :)

Binary file I/O is actually quite simple no matter what method you use.

You can use C block array-based/character-based I/O, C++ streams, Win32 file I/O, or a combination of them. Don't be fooled into thinking one is more elegant than the other. I've used them all and have found that good old fashioned _open,_read, and _write get the job done quite nicely.

There are newer versions of these in MSVC .NET but they do the same thing.

Array-based I/O is really what you need since you won't be looking for text strings, etc, etc.
Remember you cannot store pointers on disk because a pointer is just an address in memory that contains another address in memory. So the program would have to load at the exact same place in memory and the OS would have to stick all the data in the exact same place in order for the pointer to be valid. Not gonna happen. You could use offsets into the segment, but my advice is don't use pointers on disk. You can de-reference a pointer and write to disk what it points to (IE: a string, some data, vertices, etc, etc.) but writing the pointer won't accomplish anything. A pointer is just a DWORD or a 32-bit variable that contains an address in memory. When you de-reference the pointer, the compiler looks at the address of the pointer, reads the value at that address, and uses that value as an address to another portion of memory.

This is why I said use IDs in your tree's instead of pointers.

But here is how I normally use file I/O for my game code. The editor in MFC uses nearly the same process except it does so through CArchive and CFile. CArchive's know how to write CString's to disk correctly so no pointer problems. Quite handy.

This is only ONE of many, many methods available to you. Use what you like.
Open file in binary and write to it

Code:

---

struct TestStructure
{
  DWORD dwValue1;
  int iValue2;
  BYTE uValue3;
};

int handle=_open("MyFile.dat",_O_BINARY | O_CREAT, _S_IWRITE);
if (handle==-1)
{
  //error
}

//Read structure from file
TestStructure Object;
_write(handle,&Object,sizeof(TestStructure));

//close file
_close(handle);

---

Stream based I/O can also accomplish this because they also support array-based reading and writing using certain functions.

Take for instance this CArchive from MFC.

Code:

---


//Create CFile and CArchive
CFile theFile("MyFile.dat",CFile::modeCreate | CFile::modeWrite);
CArchive theArchive(theFile,CArchive::store);

//Set some variables for testing

//Integer
int iX=5;

//DWORD
DWORD dwY=0xFFFFFFFF;

//CString
CString testString;
testString.Format("Testing: %i %u",iX,dwY);

//DWORD array
DWORD *m_pData;
m_pData=new DWORD[dwY];
memset(m_pData,0xFFFFFFFF,dwY * sizeof(DWORD));

//Write integer and CString object to disk
theArchive << iX  << testString;

//Write literal string to disk
theArchive.WriteString("Hello");

//Write m_pData array to disk
theArchive.Write(m_pData,dwY*sizeof(DWORD));

//Close archive
theArchive.Close();

//Close the file
theFile.Close();

---

For more info concerning the extremely robust C/C++ I/O system, I recommend consulting a book on C/C++.

Also Win32 provides functions for this as well. So there are about a billion ways to do this.