* added tests/iconwriter.js, which writes icons with formats 0-7.
Authors notes: I am aware that texture format 1 may work the same as texture format 3.
I am waiting on the tests provided by iconwriter.js to verify the functionality.
Reminder of TODOs:
Animation parsing, parsing animation data into visible data. ->
* Render animations in HTML client.
* Write animations to glTF2 exporter.
Considered ideas:
* Multi-format file input box (auto-detect format based off first bytes)
the icons that Gauntlet: Dark Legacy uses for it's save games are rarely even worth being compressed, considering that it only saves around 2900 bytes from just leaving it uncompressed. However, the fact that it's still compressed while still parsing properly ONLY with this change makes me think many others have had this constant wrong for a while. Could it be lower? needs research.
* changed a space for a no-break space in a file input description to make it flow better when text is split.
I was considering making this 0.8.0+u1, but eeh, nah.
I think this is it. The last major format for icondumper2.
It's been a fun ride while it lasted.
See you on the flip-side! Thanks for the pineapples.
+ Now supports MAX files
+ Added an LZARI implementation to the repository.
* Now considering icondumper2 feature-complete.
* [HTML] Fixed no-webgl fallback mode.
* Reworked modules object to not clobber one that already exists
- Dropped "goes here" terminology from file input boxes.
Ending comments: There's still a few bugs involving the HTML client...
Ambient lighting is quite jank. Needs better support...
Feature: Do interpolated animations of models
For now though... I want to do something else... for a bit, at least.
* changed inline-grid to table-cell, I like it better, and older browsers like it better since its not technically flex-width
- removed inflator-installed id from inflator script, as it was unused
* changed pako version to es5 version, since it works with the absolute minimum version browsers that we technically target, and performance isn't the most important thing when you only need to decompress the data once per export file.
Author's comments: Wondering how LZARI works. Not much I can add to that part of the conversation. Once it's done, it's done. Until then, progress may be stale...
+ Now including support for CodeBreaker Save (CBS) format.
* CBS Parser function requires a function parameter that inflates data (zlib-style) given to it.
- Removed enabling/disabling strict mode from the reference client.
* Made timestamp objects consistant with every file format.
+ Added Pako to as a semi-optional dependancy to the HTML reference client.
* Disabling Pako will also disable CBS support in the HTML reference client.
Internals:
+ Now includes the RC4 cipherkey for deciphering CBS files.
+ Implemented an RC4 cipher function for deciphering CBS files.
Author comments:
One of the big five. Only one remains, and it's not going to be easy.
The road to an LZARI implementation spans a long distance, and the road there is bumpy.
- yellows
No, this isn't a late 'Fool's joke, I was just having fun and now I can target pure ES6/ES2015 if I wanted to.
…except Chakra ('Edge <= 44), that thing never implemented `TextDecoder`/`TextEncoder` for some reason. We'll never know why...
I'm researching what makes over-bright happen... give me time!
fix sps/xps parser crash: apparently those 4 bytes were for a third part of metadata for those files. HTML client now shows this information if available.
example icon: id2_example_001 (12 vertices, 4 triangles)
I've saved and included this icon in the .PSU and .SPS formats. .PSV is a bit more complicated for a valid export.
Example icon shows vertex colours with no animation nor includes a texture (texture type 3).
was considering adding new formats, but its not one of the big five (translation: not MAX/PWS or CBS), and I can barely find any examples to test with. Oh well. adding them to gitignore already. If the demand comes up, I've made the related hexpat's for them anyway.
.xpo and .spo (assuming they're like .xpo files) files are out of scope for this project, if anyone asks. Reason being is that they usually exclude icon data, and even icon.sys. This makes it rather useless to me.
It's a bit nasty, however. Don't really know what else to do-
with this code other than attempt to support animations.
aeiou, I'm not really sure... again.
Minor updates to versioning, and added raw icon file support to both node clients.
And that's it from me. Other than using GLB instead of .glTF triplets, I don't know what to do with the exporter. Would update the HTML client, yet I'm not sure on the implementation details yet.
comment: "was going to update icon.js to use more for of loops, but didn't actually see a good use for them, oh well."
all intentional console.logs are now console.info or console.debug depending on use.
enabled back-face culling on HTML client, as a few models depended on it for certain effects (VJ2, Okami 2).
---
Likely my last commit for a while, again.
pretty much makes it faster, and buffer is now clumped together with all vertex data, since the other bytes from the normals, uv and colour information adds up, and since they don't change, this makes sense, at least to me.
Now that I've used the reference client to generate some glTF files, I've learned what I was doing wrong.
to be honest, rotating on X wasn't my first thought either.
Turns out the whole colour thing was because of colour spaces. I feel like I'm going to have a distaste for those in the future.
Has a few bugs, however:
* Doesn't support textures.
* Exports upside down, and attempting to fix it inverts geometry.
This is probably my last commit to this project from amaryllis.
At least for a while.
Also add helpers to exports (uncompress and bgr2rgb functions)
Still stuck on the whole oversaturation thing.
Considering writing something to convert icon objects to a more usable model format.
caveat: some icons aren't meant to do this and will be over-saturated. Some icons are meant to over-saturate, but I don't mind that as much as the one's that aren't. The criteria that allows this is unknown to me.
Long version:
Putting an SPS|XPS into the PSU input would read as if the file was very long, so added a 127-file limit (I think this is reasonable) to prevent prolonged stalling.
Added SPS|XPS support to the library, which is the third most common contained format besides PSU and PSV.
Updated demos.
Technical changes:
removed unused u16le definition from readEntryBlock(), since permissions are better read as a u32 instead
added PSV and SPS|XPS reader functions to c6 exports, since I forgot in 0.3.4
moved some stuff around in HTML demo, especially the old raw icon.sys and icon input boxes, since I'm finding parsing a collection of files more useful then the actual standalone files themselves.
HTML-demo: added an "show advanced options" checkbox that unhides features deemed too niche for conventional use
yellows111
yellows111
yellows111