Previous Page | Next Page
- by Nisto at 7:15 AM EST on January 6, 2015
- It was due to a small bug (faulty reading of integers). My apologies. Please get this update:
https://dl.dropboxusercontent.com/u/48454461/misc/bio0/alzdec03.zip
- by shenghua8848 at 4:24 AM EST on January 7, 2015
- @Nisto£ºalzdec03 is perfect, not found any obvious problems, if the compression function can add it perfectly
- LZ compression by RangerRus at 12:03 AM EST on January 11, 2015
- Hi, Nisto.
Thanks for your work in this subject.
Don't you mind to explain in two words how work sliding window in this 'a'lz? bits meaning.
For example:
02 79 05 00 00 01 02 04 18 a6 1d 10 d1 5f d1 9f
{0x00} = 02 - type
{0x01-0x04} = 0x579 - decompressed size
{0x05-...} = {01,02,04,18...} - compressed data
How properly read bits in compressed data part?
edited 5:15 AM EST January 11, 2015
edited 5:41 AM EST January 11, 2015
- by Nisto at 9:52 AM EST on January 12, 2015
- @RangerRus: I have decided to open-source the program. Looking at the code should answer your question.
Version 0.4 and its source code are available here:
https://dl.dropboxusercontent.com/u/48454461/misc/bio0/alzdec04.zip
It compiles with at least GCC 4.8.1 (MinGW) on Windows. Haven't tried with other compilers as I only have GCC.
For those wondering, this version only adds some additional safety checks and messages.
Mark Grass hasn't responded in over a week and it seems like he's read my PM at this point, so I don't know, I guess he isn't up for trying to implement a compressor. I hope someone else will give it a try.
Also, I would appreciate any feedback on the source code as this is one of the first C programs I've written. If I am doing something wrong/redundant/whatever, I would love to know how I can improve it. Thanks!
- by RangerRus at 11:13 AM EST on January 12, 2015
- @Nisto: Thanks! will look into
- by Nisto at 3:08 PM EST on January 16, 2015
- I have updated the codepoint converter to support all characters in all versions. All versions changes the character mappings, so I've had to implement a table for each release (trial, JP, US), hence the now enormous script file size by the way. This has taken me a great amount of effort to compile as each character has required me to manually extract it "by eye" (naturally some automation and OCR was involved, but it has still added up to a lot of time due to proof reading among other things), since each codepoint just maps to a glyph and that's it (there's no consistency with standard encodings or anything). So here's to hoping it'll be put to good use.
Maybe in the future I'll add the ability to convert characters back to codepoints. If there's any requests for that...
https://dl.dropboxusercontent.com/u/48454461/misc/bio0/bio0text.py
edited 8:26 PM EST January 16, 2015
- by Nisto at 4:25 PM EST on January 17, 2015
- Terrible news (and good for some I guess)... The codepoints (at least in the JP release) changes for some reason at various places. For example, if you save at the first typewriter (cabin), you'll notice two characters are off in the converted text (列車2程個写) when comparing to what the actual game shows (列車2等個室). This is not an error in the character mappings in the converter (I have triple checked the two codepoints in question). So I have two theories:
1: the game loads the font textures needed (apparently it's only in the US release the codepoint textures aren't loaded) based on the characters in either each string or each file
2: the game loads the needed font textures for the option menu (which is where I've been iterating each codepoint) when the menu is loaded
So I figured, one way I might be able to figure it out is by replacing the codepoints in the actual game image... This made me remember that there is actually a way to replace compressed files with uncompressed data, for those who wants to mod this game. Just set the first byte to 0 and the integer (4 bytes) at 0x1 to the (uncompressed) size (remember that it's little-endian). Obviously you might be limited to what you can do with this method, but it's a start. Also, this is actually supported by the game, it actually does check if the data is uncompressed.
So anyway, I've manually replaced the codepoints within in the actual image and.. the game still shows the unexpected characters, so I guess it must must be somehow related to which "area" is currently loaded. So guess there's no accurate way to convert the codepoints without knowing which set of characters are to be used, or by guessing :shrug:
edited 9:39 PM EST January 17, 2015
- by Nisto at 7:50 PM EDT on June 25, 2016
- The last few days, I've been working on the original ALZ decompression tool I wrote, to also support compressing, since it's been requested once or twice. Now I truly understand the algorithm (and compression concepts in general) and have finally finished writing a successor with compression support. It can (de)compress any known ALZ type (0-2), and the word compression algorithm even seems to be more efficient.
https://github.com/Nisto/bio-tools/tree/master/bio0/alz-tool
edited 5:01 AM EDT June 26, 2016
- by jimbo1qaz at 8:55 PM EDT on June 25, 2016
- Yeah, there used to be an unclosed parenthesis in the above post. https://www.xkcd.com/859/
edited 2:31 PM EDT June 26, 2016
- by Nisto at 5:01 AM EDT on June 26, 2016
- Blargh. Now it's the first thing I see.. Having been awake for nearly 24 hours, I was quite tired last night though (<-[open] that's a legitimate excuse and not something I'm making up !! [close]->), so I hope it's forgiven.. :P
Previous Page | Next Page
Go to Page 0 1 2 3 4
Search this thread
Show all threads
Reply to this thread:
HCS Forum Index
Halley's Comet Software
forum source