Hey everyone, I want to make a 2D level editor using C#. The C# program will save the file using serialization and will throw all the map objects into the file. Now the game I want to make that will use this data will be written in C++. Is there a way to take that object from the file directly as in:

//psuedocode
Level mylevel;

mylevel = (Level)stream.read(Csharpobject, whereveritslocatedinthefile);


If you don't understand what I mean I'll try to make it clearer.

Thanks.

We have that all the time. Many tools are in C#, game code is in C++.

As mentioned you can use XML, which is certainly fine if you don't mind the load time.

Generally we write our tools to output the final data structure as used in memory. Rather than writing out a file format that needs to be parsed and memory allocated, you can write out exactly the memory format needed in the game; that allows us to just load the data directly into the final location and use it without any unpacking or extra load time. You can just read it from disk and continue.

We have that all the time.  Many tools are in C#, game code is in C++.  

As mentioned you can use XML, which is certainly fine if you don't mind the load time.

Generally we write our tools to output the final data structure as used in memory.  Rather than writing out a file format that needs to be parsed and memory allocated, you can write out exactly the memory format needed in the game; that allows us to just load the data directly into the final location and use it without any unpacking or extra load time.  You can just read it from disk and continue.

Is there a link or name for this way of saving/loading that I can look up? For this small project I could use xml but your method seems like it would be easier/faster. Easier in the sense of loading and saving.

We have that all the time.  Many tools are in C#, game code is in C++.  

As mentioned you can use XML, which is certainly fine if you don't mind the load time.

Generally we write our tools to output the final data structure as used in memory.  Rather than writing out a file format that needs to be parsed and memory allocated, you can write out exactly the memory format needed in the game; that allows us to just load the data directly into the final location and use it without any unpacking or extra load time.  You can just read it from disk and continue.

Is there a link or name for this way of saving/loading that I can look up? For this small project I could use xml but your method seems like it would be easier/faster. Easier in the sense of loading and saving.

Is there a link or name for this way of saving/loading that I can look up? For this small project I could use xml but your method seems like it would be easier/faster. Easier in the sense of loading and saving.

A name for it? Yes, it is called a file format. The process is called serialization (as your topic title already suggests).

Using raw data was the way things used to work before XML and similar unified file formats came along. You wrote actual data instead of writing huge plaintext name/value pair trees. Today you still write raw data for most complex stuff, and use XML for more lightweight data because it causes the file size to explode.

No specific tutorials that I know of but I'm sure Google can find tons of them. Serialization is a basic task for programmers, something you will probably spend a few thousand hours on over your programming career. You'll spend even more than that if you are working on tools or data loaders for graphics and similar systems.

If you need help understand it, sites like wotsit can help you learn about file formats.

For example, one of the file format pages for BMP says:

[font=courier new,courier,monospace]The BITMAPFILEHEADER:
start size name stdvalue purpose
1 2 bfType 19778 must always be set to 'BM' to declare that this is a .bmp-file.
3 4 bfSize ?? specifies the size of the file in bytes.
7 2 bfReserved1 0 must always be set to zero.
9 2 bfReserved2 0 must always be set to zero.
11 4 bfOffBits 1078 specifies the offset from the beginning of the file to the bitmap data.

The BITMAPINFOHEADER:

start size name stdvalue purpose
15 4 biSize 40 specifies the size of the BITMAPINFOHEADER structure, in bytes.
19 4 biWidth 100 specifies the width of the image, in pixels.
23 4 biHeight 100 specifies the height of the image, in pixels.
27 2 biPlanes 1 specifies the number of planes of the target device, must be set to zero.
29 2 biBitCount 8 specifies the number of bits per pixel.
... (some formatting not displayed correctly, of course)[/font]

That should give you an example of what file formats actually look like.

You will need to develop your own file formats, write the data in that format, and read that data back up in that format, storing it where you feel best. They are something that grows dynamically with your system, you end up adding a field here and there as you discover the need. That's why it is often best to start it off with a keyword or version number so you know you've got a matching edition.

Thank you for the advice and website. I'll be bookmarking that. I decided to go with an XML file format for now since it does what I was trying to do in the first place AND it's in a file format that can be easily read by a C++ program. I have to see how it handles saving an array though. Thanks again.

EDIT: Just noticed XMLSerialization won't write private variables. I'm searching for another way again.

EDIT2: If I were to use binary formatter in C# to create my save file, would I be able to load it in C++ somehow? And if I need to make changes to that save file in my C++ program, is there a way I can do that and still have the C# program understand it?

[quote name='frob' timestamp='1325479542' post='4898855']
We have that all the time. Many tools are in C#, game code is in C++.

As mentioned you can use XML, which is certainly fine if you don't mind the load time.

Generally we write our tools to output the final data structure as used in memory. Rather than writing out a file format that needs to be parsed and memory allocated, you can write out exactly the memory format needed in the game; that allows us to just load the data directly into the final location and use it without any unpacking or extra load time. You can just read it from disk and continue.

Isn't this a giant pain in the ass? Wouldn't it invalidate all of your files the second an objects (code) signature changed, meaning you would have to rebuild your asset for every corresponding code change?[/quote]

Um, yeah, what he said:

You do not change the formats very often if you think well about them first.

... file format that contains a version number which makes it easier to support older versions and convert them on the fly...

I specifically commented about the version number in the post above.

It is rarely an issue in practice.

Another thing that really helps is that you never turn manually-saved files into the final assets. Always use an intermediate format, or have your tool able to extract the data without any human interaction.

One set of tools manually generates intermediate files when the designers or artists make changes. For example, the raw photoshop files turn to DDS files as an intermediate. Then another set of tools is automated to run periodically that rebuilds those assets into the final resources. Those final resources are the ones in the machine-specific format.

Alternatively, you have a tool that opens the raw manually-saved files (such as the photoshop files), extract the data without human intervention (such as a layer with a specific name) and save the result directly.

Either way you do it, in the rare event that the format changes it needs to change both in the tool and in the game. The server's build cache gets invalidated because the tool is newer than the output; the machine-specific format of the data is regenerated with the next build. The only people who potentially miss a cycle are the programmers who sync code after you submit but before you pull data. A simple email solves that problem. Everyone else only sees finished builds so they notice anything except that a build takes slightly longer to run.