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:
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:

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...

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.

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.

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:

User Name Tags:

bold: [b]bold[/b]
italics: [i]italics[/i]
emphasis: [em]emphasis[/em]
underline: [u]underline[/u]
small: [small]small[/small]
Link: [url=]Link[/url]


HCS Forum Index
Halley's Comet Software
forum source