OniSplit/Change log: Difference between revisions

OniSplit/Change log (view source)

Revision as of 13:09, 10 January 2022

7,917 bytes removed , 10 January 2022

m

→‎v1.0 (WIP): moving to WIP subpage

Geyser

Administrators

5,389

edits

@@ Line 1: / Line 1: @@
 Here is a list of changes to some past versions of OniSplit, to the extent that these were documented by the developer.
 {{TOCfloat|numbers=no}}
-==v1.0 (WIP)==
-::Really? Yes, really. Get the nightly [http://geyser.oni2.net/OniSplit/1.0a2_2021.12.17/ HERE] (1.0a2, 2021/12/17)
-:0. '''''Possible introduction of aliases''''' for the notoriously confusing '''-export''' and '''-import''' (easily mistaken for the '''-extract'''/'''-create''' functionality).<br/>Historical synonyms for '''-export''' and '''-import''' are "unpack" and "pack", but I am leaning towards new aliases, most probably '''-split''' and '''-link'''.<br/>OniSplit itself may be rebranded as ''GameDataTool'', and a lightweight app (limited to the split/link functionality) may be dubbed ''(Oni)SpLink''.
-:1. '''''The required .NET framework''''' is changed back to .NET 2.0 (a few past versions of OniSplit were built for .NET 4.0 for some reason, but it appears that 2.0 is sufficient).
-:2. '''''A new packing format''''' called '''-import:onix''' was added, which is the same as '''-import:sep''' (PC demo-like) but suppresses template checksums and replaces them with a new versioning system.<br/>The produced .dat/.raw/.sep files are marked VR33 instead of VR31, only work with the OniX engine, and allow for new features in the game data format - provided that the OniX engine implements their support as well.
-:3. The misguided implementation of '''''32-bit transparent textures''''' has been remastered, with a distinction between "rgba" and "bgra32" import formats: "rgba" corresponds to TXMP type 11 (directly supported by all Oni engines); "bgra32" is TXMP type 7, mistakenly used by previous versions of OniSplit (and Daodan/Mac patches) as a substitute for the overlooked type 11.<br/>Old instances of type 7 TXMPs are automatically detected and repaired (replaced with type 11) at the first opportunity.<br/>New TXMPs created with '''-format:bgra32''' are stored as legitimate type 7, which will only be handled properly by the new OniX engine (or by an amended Daodan DLL).
-:4. '''''Sound conversion''''' is now (almost) fully featured, although with a strong bias towards the Windows platform (a.k.a. "PC") and MS ADPCM compression.<br/>In addition to the previously available stream copying, you can now '''-extract:wav''' from a Mac SNDD ('''-extract:aif''' from a PC SNDD may be added later).<br/>When using '''-extract:wav''', an additional option '''-pcm''' decompresses the waveform and produces a .wav file with raw PCM storage.<br/>Compressed ADPCM .wav-files (exported through '''-extract:wav''') are now standard-compliant, and the importing of a .wav preserves custom (AD)PCM settings fully as well, meaning that third-party WAV files can now be roundtripped in and out of Oni (PC retail) without any issues. (However, the validation of corrupt third-party WAVs has not been thoroughly implemented or tested.)<br/>In addition to the automatic creation of PC or Mac SNDDs through the '''-create''' command (depending on whether the input is a .wav or an .aif file), the '''-demo''' option can be used to generate a PC demo-like SNDD (short header, no custom sample rate or compression) both from a .wav and from an .aif file (useful when mass-converting sounds for VR33/OniX).<br/>By default all SNDDs made with '''-create''' are ADPCM-compressed SNDDs even if the input is an uncompressed .wav file. The '''-pcm''' option allows uncompressed/decompressed storage for PC SNDDs, but this is not recommended: PCM sounds take up 4 times as much space as ADPCM, and their playback is currently broken for the PC demo and OniX engines.<br/>Considering that, as of now, 18:55, 14 December 2021 (CET), all Oni engines play back SNDDs as 22.05 kHz waveforms (the PC retail engine only ''pretends'' to support custom sample rates, see [[OBD:SNDD#Known_engine_issues|HERE]]), it is now OniSplit's duty to report any waveforms that are ''not'' sampled at 22.05 kHz and to suggest the custom playback speed that should be used at [[OBD:OSBD/OSGr|OSGr]] level. 44.1 kHz sounds will automatically be downsampled to 22.05 kHz except when doing so would involve an additional round of decoding and reencoding; this potentially lossy operation must be explicitly requested with '''-forcestd'''.<br/>When creating short-header SNDDs for the PC demo/OniX (using the '''-demo''' tag), incoming MS ADPCM files are ultimately required to have a standard block size of 512 bytes per channel. Here too, a potentially lossy reencoding must be explicitly requested through '''-forcestd''', otherwise importing will fail with a report of the non-conformant block size.<br/>Uncompressed PCM sounds can be imported from .wav, with support for the following bit depths: 16-bit (CD-quality), 24-bit (overkill) and 32-bit (super-overkill). Bit depth reduction is straightforward, practically non-lossy and therefore automatic, with merely a warning printed after the conversion. 8-bit linear PCM input (unsigned) is also supported, but don't tell anyone.
-:5. '''''[[OBD:SUBT|Subtitle]] files now have a custom XML format''''' as requested by Script10k. You go from SUBT*.oni to XML using '''-extract:xml''', and you import using '''-create''' (both the old .txt subtitles and the new XML format are accepted as input). Vanilla English SUBTs roundtrip exactly both through TXT and through XML. Non-Vanilla SUBTs and other language versions not tested.
-:6. The '''-fullname''' option is available for '''-extract:dae''' operations, '''''prepending the 4-character template tag to the filename''''' (TRBS, ONCC, AKEV, etc).
-:7. '''Level creation works again.''' The <Import> feature of Physics.xml has been repaired (it is the feature that lets you import several OBOA entries and their OBANs from the same Collada file) and enhanced with a couple of options, like explicit script IDs for each animated object and custom prefixes/suffixes for animations. As a minor convenience, all _marker textures are now imported automatically.
-:8. '''Interaction with Blender has been consolidated''' through the '''-blender''' option, available both when '''-extract'''ing and '''-create'''ing.<br/>The primary use of '''-blender''' is to control the transition between Oni's and Blender's axis conventions, both in terms of scene orientation (Y-up for Oni, Z-up for Blender) and rotation order (X-then-Y-then-Z for Oni, Z-then-Y-then-X for Blender).<br/>Another effect of '''-blender''', exclusive to '''-extract''', is to replace all instance of <technique_common> with <technique sid="common"> in the exported Collada files. When importing a Collada file through '''-create''', both <technique_common> and <technique sid="common"> are accepted.
-:9. '''Characters/animations have been consolidated.''' Among minor improvements, quaternion math is more accurate (preventing "upside-down" pelvis animation and other artifacts), the identification of animation curves in Collada input is more robust, and OniSplit's internal animation buffer (for raw TRAM data) is no longer limited to 65535 bytes.<br/>A new '''-keepkeys''' option is available for TRAM operations: for '''-extract''' it preserves Oni's sparse animation data instead of keying every frame; for '''-create''' it bypasses the keyframe reduction pass and uses the same keys as in the Collada file.<br/>When '''-create'''ing a TRBS, non-standard skeleton hierarchy is still allowed (controlled by the node tree in the Collada file), but standard sibling order is enforced for "thigh" and "shoulder" bones (if detected).<br/>At this point there is still no proper skeletal setup (meaning it's still the same "nested" approach, with rigid body parts hinged to one another), and the rest pose is still the infamous "folded umbrella". A more intuitive rest pose may be implemented later.
-:At the time of writing, items (1) through (7) are done and ready for testing, whereas (8) and (9) are being finalized. The rebranding (0) is merely planned (subject to debate?). --[[User:Geyser|geyser]] ([[User talk:Geyser|talk]]) 13:11, 17 December 2021 (CET)
 ==v0.9.90==
 What's new: