ps2homebrew / Open-PS2-Loader

Game and app loader for Sony PlayStation 2
https://ps2homebrew.github.io/Open-PS2-Loader/
Academic Free License v3.0
2.21k stars 279 forks source link

[FR] CFG backward compatibility #346

Open brainstream opened 3 years ago

brainstream commented 3 years ago

I am the author of OPL PC Tools. I am currently working on adding support for the game config. Two years ago (in 928d62e6) you removed "HDTV 1080p @ 60Hz" from the list of GSM modes. Thus, all values greater than 12 became invalid. This breaks backward compatibility and adds some problems to my application's implementation.

AKuHAK commented 3 years ago

It definitely isn't a bug. Some OPL releases come with the comment that you need to recreate your config file from scratch. You, as a third-party tool creator, can handle this specific case inside your app, but not the Open-PS2-Loader maintainers. Anyway, providing a fix for your specific case will break compatibility for all versions that were released in the past 2 years. I don't see a reason to do so. I understand that, maybe, you have a huge database with old configs, but it is still easier to convert it into a new format from yore side.

The only thing I can advise: to provide a fix for preventing such things in the future. 1) Comment a code - so developers see where are stored structures that should not be reordered. So if some features are removed, that this will affect only that particular feature, not the whole list. Just keep a dummy number that does not do anything. The same with adding - just add a new feature at the end of the list. But I don't like this system - after some time it will be full of removed features, and structure numbers became huge. So this can be implemented only temporarily - between 2 major releases. If a major release happens, the configuration should be clean and reordered. In other words, every big release won't be compatible with the configuration file used for the previous release. 2) To implement a completely new configuration system that will not be based upon a numbering system but will use parameter names. In fact, this will be simpler, and configuration files will become easier to read and maintain. But this also will lead to the bigger config file (not a big deal for me). But this will break compatibility with all previous versions :)

It is also possible to implement both systems at the same time, so you can use both values and the app will automatically define which one is used. So it is still will be compatible with old configs. The OPL can try to rewrite old configs into the new format upon the app start or something similiar.