No room for future backwards compatibility

[GoogleCodeExporter]

I noticed Hourglass seems to have no backwards compatibility.  The input file 
format doesn't have an input file version number in its header, nor an 
Hourglass engine version number.  Both of these should be remedied, and old 
versions of the Hourglass engine should be maintained with corresponding 
version numbers.  This way, new versions of Hourglass can maintain backwards 
compatibility with ALL Hourglass input files and desynchronization based on 
version will NEVER happen.  See Worms Armageddon (PC)'s backwards compatibility 
model for inspiration.

Rerecording emulators have always been far behind Worms Armageddon in this 
regard.  As a new project, Hourglass doesn't have to fall into the same old 
pattern of people saying "Doesn't sync with x; only with y".  Input files 
should always sync using the latest version of Hourglass (which automatically 
detects and uses the engine version from the file header).

Original issue reported on code.google.com by lexlexlex@gmail.com on 17 Jul 2011 at 12:08

[GoogleCodeExporter]

I meant to post this as an "Enhancement", but it could be seen as a "Defect" 
too, I guess.

Original comment by lexlexlex@gmail.com on 17 Jul 2011 at 12:11

[GoogleCodeExporter]

By the way, the Worms Armageddon model uses diffs to maintain engine versions 
somehow.  The exe hasn't increased in size with each new version, and there 
have been tons.

Original comment by lexlexlex@gmail.com on 17 Jul 2011 at 12:27

[GoogleCodeExporter]

Additions to the input file format are already being made in such a way that 
new versions can play previous versions and will upgrade them upon 
re-recording. So far an overall version number hasn't been needed to do that 
(because each part of the file is implicitly versioned), but it could easily be 
added if it is needed, and I guess it might as well be added now even if it 
isn't needed.

The engine itself is more difficult to maintain backward compatibility with. 
The idea of using (binary?) diffs is interesting, but infeasible for me to 
implement (not because diffs are involved, but because the engine isn't an 
isolated thing that can be swapped out wholesale with an older version, and 
because I don't think I would want to do that even if I could). I'm not worried 
about the DLL size increasing, and the nature of hooking functions makes it 
possible to switch a particular function or component to an older version with 
almost no runtime performance overhead, but maintaining compatibility would be 
a drag on development that I want to avoid for the time being.

Also, some cases are a little unclear what should happen. If an old version 
behaves inconsistently on its own, should newer versions maintain that 
inconsistent behavior when playing old movies even if doing so might actually 
cause more desync problems than doing otherwise? And I wouldn't want people to 
continue recording some movie in the new version only to get bitten by an 
already-fixed bug later on as a result of unknowingly having disabled the fix 
for that bug by not starting the recording from scratch.

All that being said, I think it's a good idea to start adding version numbers. 
Even if they don't get used yet, they could still simplify things in the future 
if backward compatibility starts to become more of a priority, and they can be 
used to improve the user experience by warning about version mismatches in 
cases where a backward compatibility issue hasn't been fixed but is known to 
exist.

Original comment by nitsuja-@hotmail.com on 17 Jul 2011 at 3:46

[GoogleCodeExporter]

Great points.  I agree with your big-picture assessment of the situation.

Original comment by lexlexlex@gmail.com on 17 Jul 2011 at 7:32

[GoogleCodeExporter]

Version number added in r57. Now movie files, the exe, and the DLL all 
know/contain the SVN revision number they were made with. I made it so any 
backward compatibility code is optional (according to your choice at a dialog 
that pops up when playing the movie... the default choice of Yes enables it).

Original comment by nitsuja-@hotmail.com on 18 Jul 2011 at 9:05

• Changed state: Fixed