Skip to main content
gamedev.net
🔒 Locked

File format between versions

Started by JY 2 replies 250+ views
Original Post
JY
JY
I''m just wondering how people manage the file formats for their applications. Object structures often change between versions of software and backwards compatibility is pretty important. It makes sense for each object to save itself to the file instead of having a central file loading class, but then it means that each object has to know about the version information. So, would you have a ''global'' version information structure that gets passed to the objects as you save and load to let the objects manage themselves - or would you go for the central management option whereby you would have a FileV1 class and a FileV2 class etc.?
"Absorb what is useful, reject what is useless, and add what is specifically your own." - Lee Jun Fan
Sneftel
Sneftel
quote:
backwards compatibility is pretty important.

Is it? This is only a problem if files meant for one version of a file format stand a good chance of needing to be loaded with another version. For read-only content/level/art/whatever files, there''s no reason at all to make them backwards compatible; just recompile for the new format. Saved-games might fix this criteria. If you want, though, you could just ship a converter from V1 files to V2 files.

If you want to maintain compatibility between versions, you have to think about a lot more than just data structures. If there are new members, what should the "default" values be? Are there any reasonable defaults? Of the members that are still there, do they really still mean the same thing, or do they need to be scaled or recomputed somehow?


How appropriate. You fight like a cow.
JY
JY
quote:
Is it?


Umm yeah - Imagine if you installed a new version of your 3D software and could no longer open any of your existing files or any files that other people sent to you or posted on web sites??

While conversion is an option, it''s not very practical if you have a new version of a piece of software and you are working with somebody who has an older version of that software and you want to share files.

Granted, there is a concern where new variables are concerned - default values etc. but I should imagine there would be an acceptable default.
For instance, if we are looking at a 3D editor - and we decide in a later version to save face normals in the file instead of computing them each time - if we want to save to an old format, we simply don''t save them and the old version of the software will compute them.

Question is, should this be object specific so that each object has to check the file version or not?
"Absorb what is useful, reject what is useless, and add what is specifically your own." - Lee Jun Fan
Sneftel
Sneftel
quote:
Original post by JY
quote:
Is it?


Umm yeah - Imagine if you installed a new version of your 3D software and could no longer open any of your existing files or any files that other people sent to you or posted on web sites??


Then you aren''t talking about games. Given that this is a game programming site, it''s probably a good idea to mention that, rather than leaving people to deduce it for themselves.

quote:
While conversion is an option, it''s not very practical if you have a new version of a piece of software and you are working with somebody who has an older version of that software and you want to share files.

That''s even worse, if you want the V1 app to be able to open V2 files. what if V2 has newer functionality? How are you supposed to emulate that, purely through the file format?

quote:
Granted, there is a concern where new variables are concerned - default values etc. but I should imagine there would be an acceptable default.
For instance, if we are looking at a 3D editor - and we decide in a later version to save face normals in the file instead of computing them each time - if we want to save to an old format, we simply don''t save them and the old version of the software will compute them.


There''s only a default in the special case, never in the general case. And there''s not necessarily a default for the special case. What if V2 has a field that stores the company name? Where does that default come from?

quote:
Question is, should this be object specific so that each object has to check the file version or not?
Well, it''d have to be. Otherwise you won''t be able to deal with these special cases.

It really depends on how your loader is organized in software. If your top-level loader dispatches object data to individual loaders, that''s ideal; just keep around the old object loaders, and have new-version objects listed with different "types" (or just make the dispatch argument be a combination of TypeID and VersionID). If your loader is flat, it might be better to have a separate loader for every app version (this will have some code repetition, since not every object format will change, of course). Above all, nail down your top-level format only after a lot of design work and thought, and make it a REALLY GOOD DESIGN; a change to the top-level design will be much harder to cope with than individual object loader changes.


How appropriate. You fight like a cow.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.