In 2.6.0 they will still be available for both encoding & decoding. However, they will be marked "deprecated" to discourage their use. I'm doing this two ways.
One : if you encode with them, they will log a warning through the new Oodle "UsageWarning" system. Decoding with them will not log a warning. This warning can be disabled by calling Oodle_SetUsageWarnings(false). (Of course in shipping you might also have set the Oodle log function to NULL via OodlePlugins_SetPrintf, which will also disable the warning log). (Also note that in MSVC builds of Oodle the default log function only goes to OutputDebugString so you will not see anything unless you either have a debugger attached, change the log function, or use OodleX to install the OodleX logger).
Two : the enum for the old compressor names will be hidden in oodle2.h by default. You must define OODLE_ALLOW_DEPRECATED_COMPRESSORS before including oodle2.h to enable their definition.
As noted, decoding with the old codecs will not log a usage warning, and can be done without setting OODLE_ALLOW_DEPRECATED_COMPRESSORS. That is, Oodle 2.6.0 requires no modifications to decode old codecs and will not log a warning. You only need to consider these steps if you want to *encode* with the old codecs.
In some future version the encoders for the old codecs will be removed completely. All decoders will continue to be shipped for the time being.
I'm intentionally make it difficult to encode with the old codecs so that you transition to one of the new codecs.
Long term support codecs :
Kraken, Mermaid, Selkie (and Hydra)
codecs being deprecated :
LZNA, BitKnit, LZA, LZH, LZHLW, LZNIB, LZB16, LZBLW
The new codecs simply obsolete the old codecs and they should not be used any more. The old codecs are also a mix of some fuzz safe, some not. The new codecs are all fuzz safe and we want to remove support for non-fuzz-safe decoding so that it's not possible to do by accident.
In pursuit of that last point, another change in 2.6.0 is removing the default argument value for OodleLZ_FuzzSafe in the OodleLZ_Decompress call.
Previously that argument had a default value of OodleLZ_FuzzSafe_No , so that it would allow all the codecs to decompress and was backwards compatible when it was introduced.
If you are not explicitly passing something there, you will get a compiler error and need to pass something.
If possible, you should pass OodleLZ_FuzzSafe_Yes. This will ensure the decode is fuzz safe (ie. won't crash if given invalid data to decode).
The only reason that you would not pass FuzzSafe_Yes is if you need to decode some of the older non-fuzz-safe
codecs. We recommend moving away from those codecs to the new post-Kraken codecs (which are all fuzz safe).
Fuzz safe codecs :
Kraken, Mermaid, Selkie (and Hydra)
BitKnit, LZB16, LZH, LZHLW
Non-fuzz-safe codecs :
LZNA, LZA, LZNIB, LZBLW
If you need to decode one of the non-fuzz-safe codecs, you must pass FuzzSafe_No. If you pass FuzzSafe_Yes, and
the decoder encounters data made by that codec, it will return failure.
Fuzz safety in Oodle means that unexpected data will not crash the decoder. It will not necessarilly be detected; the decode might still return success. For full safety, your systems that consume the data post decompression must all be fuzz safe.
Another semi-deprecation coming in Oodle is removing high-performance optimization for 32-bit builds (where 64-bit is available).
What I mean is, we will continue to support & work in 32-bit, but it will no longer be an optimization priority. We may allow it to get slower than it could be. (for example in some cases we just run the 64-bit code that requires two registers per qword; not the ideal way to write the 32-bit version, but it saves us from making yet more code paths to optimize and test).
We're not aware of any games that are still shipping in 32-bit. We have decided to focus our time budget on 64-bit performance. We recommend evaluating Oodle and always running your tools in 64-bit.
If you're a user who believes that 32-bit performance is important, please let us know by emailing your contact at RAD.
No comments:
Post a Comment