«

[The Fifth Horseman]

Originally Posted by Ohne Mitleid

I think I would be able to work things out though, if I could only find some way to capture the screen without a full 15,999,744 to try and eliminate and then attempt to assign proper indexes to the other 256.

Captures straight from my copy of DOSBox 0.74.
http://img577.imageshack.us/img577/7728/atlantis001.png
http://img824.imageshack.us/img824/1738/atlantis003.png
Custom builds should also have PNG support if compiled with libpng.

The compression you've encountered might possibly be some variant of RLE. It's fast, cheap and was somewhat popular back in the day.

[Ohne Mitleid]

Awesome, thanks once again Fifth Horseman! In the mean time, I had found out how to screen capture in 256 color indexed by accident. It seems DOSBox will not do it for me, but launching from D-Box will. But that is not for this post.

Your pics provided me with further information, letting me know the colors don't match up with RGB values across systems, much less trying to translate what they mean into bytes or however. The indexes helped a lot though.

I now have a definitive set of goals to accomplish instead of just poking around. Hopefully, I will move forward faster. I get too distracted by "ooo...what does this do?" though.

New things:
- I found out by accidentally changing something, how to become an air-fish. I can "swim" through the air.
- I discovered the SW version does not allow you to "creep" swim, like you can tip-toe using ALT while you walk. Couple this with:
- I have meshed the palette from 1.LBM with level one text, a big step. Palettes within the LBM file are chopped up, shared by game elements AND scattered, meaning 1 comes before two when comparing palette 1 and 3, etc. However, this leads to slow your swimming turning you into the Human Torch while performing the side crawl. Something Reed Richards probably would not approve of.
- I have pinpointed one of the sprites in START.LBM. It only proves I cannot use this info to find other sprites within the file based on the same information, I can adjust the horizontal location of the sprites appearance but have no idea where the vertical is determined and the compression is beyond my level. It appears to chunk out in segments horizontally...not even contiguously based on color sequencing
- Last point: I usually don't give up, I love learning new things and I post way too much info in this forum

Man, I love this!

[EDIT: I forgot. The Lost City opening screen rock formation on the right bears a striking resemblance to Augustine Rodin's "Thinking Man" IMHO]

[Ohne Mitleid]

Update of completion to English: I have the Full working Executable. Opening intro movie plays, Skill level selection screen and the Beginner / Master status bar, all in English.

The only problem now is I cannot figure out the compression for the "shop" graphics. I have the English versions edited for display and ready to swap out but since I cannot figure out the compression, those graphics won't work with the current program. I would also have to have the FINISH to the game translated, but it does make any sense to me at this time since I wouldn't be able to swap out the graphics, even if it were to be translated then created.

I figured out the compression for the graphics which involved editing 4,624 bytes manually, but I really have no intent of doing this with the four - 320 x 200 byte screens that remain. One pixel out of place while editing and the whole thing becomes a real mess. All I need is some way to save it in whatever format it is in, swap out the body (the content in the game does not include dimensions, attributes or a stored palette).

Help?

[The Fifth Horseman]

Describe the compression. I'll see what can be done for an automated decompressor/compressor.

[Ohne Mitleid]

Thank you, that would be great!


Hopefully this will help. I've come a long way, I would hate to fail now

[The Fifth Horseman]

Can you show me the raw data for the master icon before and after the conversion process you applied?
I think I understand the procedure, but I'll need an example entry and output to test my program on.

The compression/decompression procedure itself will be fairly easy to code.

[Ohne Mitleid]

This should do it. The file is at the bottom of the same page.

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

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

[arete]

Could we perhaps apply this process to Chrono Quest if you guys perfect it? Frodo's been bugging me for ages.