«

[The Fifth Horseman]

Chrono Quest is practically guaranteed to use a completely different method of storing data - it would have to be reverse-engineered from scratch.
And then someone would have to translate the text portion of the game anyhow.

[Ohne Mitleid]

Originally Posted by The Fifth Horseman

This is a functional algorithm for the compression process. http://5thhorseman.pastebin.com/14cVLejD
There's two things I'm somewhat unclear on, though: how the original format handles repeat sequences spaced more than 127 pixels apart, and palette indexes above the 127th. If those situations never happen, we're good. Otherwise I'll be going back to the drawing board as soon as we find an example in the original data.

The interleaving is next on my list.

I looked at your algorithm and while parts of it make sense to me, I cannot figure it out as a whole. So this post would probably be more clear to understand if I could speak in C++, but since I cannot, I'll try my best to explain.
I was unable to find a sequence that was spaced more than 127 pixels apart, but that is a very good question. The full screen graphics for this program all have a 3 color rectangular border around the edge. If this were combined with the interleaving, odds are it would probably cause a break in any sequence larger than 127, so maybe the graphics were planned this way to avoid having to code around those situations. If that isn't the explanation, my theory would be that the byte indicating the next repeat sequence location would be FF and the byte at current location plus FF would be FF (or the next repeat sequence location number) until the sequence longer than 127 pixels apart was broken.
The original format handles all palette indexes over 127 as the correct palette index except for the first byte of the graphic. If the first byte is larger than 00, it is handled as the indicator for the number of pixels to be repeated. My logic fails when it comes to figuring out what happens to the second byte when the first byte is 00, but it does not matter, at least for this program, since all of the graphics that need to be converted have the first line of on screen pixels set to be a sequence of three or more.

[The Fifth Horseman]

Okay, I've changed it so that it should work within the limitations.
If the program processes 126 single pixels and encounters another one without finding a sequence, it sets the 127th as a one-length repeated sequence. This should work as a fail-safe.

Originally Posted by Ohne Mitleid

The original format handles all palette indexes over 127 as the correct palette index except for the first byte of the graphic. If the first byte is larger than 00, it is handled as the indicator for the number of pixels to be repeated. My logic fails when it comes to figuring out what happens to the second byte when the first byte is 00, but it does not matter, at least for this program, since all of the graphics that need to be converted have the first line of on screen pixels set to be a sequence of three or more.

The thing is that from your previous explanation, everything above 7F is treated as a sequence start indicator. So either it does the same thing as RLE - ie places a sequence with a length of one - or it uses a flag you haven't documented yet.

For the time being, I've added a failsafe that assumes it will mimic RLE's behavior. We'll see how that works out.

Will it be okay with you if the utility uses PCX images as input?

[Ohne Mitleid]

I was not clear enough, sorry. The repeat sequence consists of at least three bytes: a repeat sequence count, a palette index and a stop current sequence / next sequence start byte. Outside of these repeat sequences, and even inside with the palette index byte, the values can be anywhere from 00 to FF. Within the repeat sequence, between the palette index and the stop current sequence / next start byte can be another byte with a value in excess of 7F which would allow the current repeat sequence to keep repeating with the new information of repeat count and new palette index. I am not sure if that is any clearer or if it makes things more confusing.

PCX formatting would be great. In fact, when I was looking at the graphic files in hex and searching on the internet, I was almost sure the format used by the game was a PCX. I only have access to versions 0, 2 and 5 to convert the files to though, so the utility either needs to identify one of those versions, or I need to find another program, maybe.

[The Fifth Horseman]

This actually clears things up.

My logic fails when it comes to figuring out what happens to the second byte when the first byte is 00

Offset to the beginning of first sequence, perhaps?

PCX formats 2 and 5 (v2.8 with palette and v3.0, respectively) will do just fine.

[Ohne Mitleid]

Originally Posted by The Fifth Horseman

This actually clears things up.
Offset to the beginning of first sequence, perhaps?

I had checked the 00 start, and it is not an offset. It appears only on one full screen graphic in the German version, but not the English shareware version. While poking around, trying to figure things out, there are a lot of things that were manipulated throughout the two versions so that files / graphics were not easily exchanged between versions without some drawback. This may be one of them, who knows.

The graphic for the game ending I finished last night.

Thank you again for all of your help with this, otherwise it would be a long, long time before I could even attempt to complete it.

[The Fifth Horseman]

Ripping out raw palette indexes from the PCXes works now. All that's left is the interlacing and we're done.

[Ohne Mitleid]

Awesome! That is fantastic! Hopefully, I didn't overlook anything else...

[The Fifth Horseman]

This should do the trick. Let me know if there are any problems.

[Ohne Mitleid]

Originally Posted by The Fifth Horseman

This should do the trick. Let me know if there are any problems.

Okay, just letting you know there are problems. I get this error message "This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information." I thought it might be a DOSBox application....no. So I looked at the CPP file, downloaded cstdio.h and cstdlib.h which, of course did nothing. After looking at those two files, I get another reference to STLport which if I understand it, stands for "Standard Template Library". I am under the impression this is not a standalone executable file and I don't know what to do from here. I do not have any type of compiler, programming libraries or things of that nature. I am also running Windows 7, as if that matters.
Any suggestions?