«

[The Fifth Horseman]

<div class='quotetop'>QUOTE(laiocfar @ Jul 16 2007, 06:04 AM) [snapback]299590[/snapback]</div>

Someone will start the translation of other PM titles and/or PD?
[/b]

Try and convince some publisher to do it. <_<

[laiocfar]

You convince the publisher and i share credits and earning with you

[The Fifth Horseman]

OK, but we also share the resulting eternal damnation. LOL

i was just browsing the internet looking for something to do and i found this 1,ive been hearing a lot about this game and would love to play it i already feel like i already did :w00t: but sadly i havent can anyone tell me where to download for free wich will be good or buy it?please i cant wait any longer i really wanna play it

[Mighty Midget]

You cannot get links to downloads here. The game is protected, so any such links are big NOs.

Where to buy it? Have you tried Amazon or Ebay?

[The Fifth Horseman]

He won't find it there - the only version in existence is a leaked incomplete copy.
Which might be for download somewhere else, but I ain't telling nobody where.

So, I recently came across information that says one can turn on screen capture capabilities. Thing is, it does not write them to a common (or known by me) format.

I did use a hex editor and a webpage on the BMP format, to add a BMP header to the *A.B1, *A.G1, and *A.R1 files (the E1 files are mostly null with some non-null bytes strewn through out. No idea what kind of info might be in here.) The *B.?1 are all 7kb so too small to be a screenshot, and not sure what kind of info per channel it could be, yet.

Playing around with the height, width, and color depth bytes of the BMP header (and copying in a color table from a 8-bit grayscale BMP) has lead me to actually see an image. So I am confident that each file is just a raw dump with nothing extra (ie palette info, hieght, width info, etc.). I am guessing that this feature was just to help debug (?) and so the programmers knew what the palette was, what the size is (seems to be based on 320 by 200, but I'll get to that) etc so they just needed the raw data and their program took care of displaying it.

At 320 by 200, 4bit color (16 colors) I can see 2 side by side pics. Changing it to 160 by 400 makes it one image wide (but since the two lines are light and dark it looks interleaved) and has it look all squished (160 by 400 is too narrow and long looking). using Gimp to then scale to 320 by 200 makes it look nice. I suspect though, that each line is first the odd pixels then the even pixels (or vice versa) and the gimp's scaling was more of a lucky break (things getting blurred hiding the disrepencies). I might try, another time, just having gimp keep just the odd lines or even (at the 160 width) and play with that a bit. I been using the 320, 2 image side by side, to try to recompose the 3 bitmaps into a colored picture (instead of 3 greyscales that probably represent red, blue, and green) but the pictures don't look well colored (or just as nice in general as the in-game screens). I might need to play around with learning to program (Hmm, maybe I can find an old C++ compiler to run on dos-box) so I can try playing with that odd / even pixel idea to see if that helps resolution (basically a custom viewer where I can tweak on the fly height, width, non-sequential reading, etc). Also, I'll need to find or figure out the palette info for these files, maybe the main program has it built in, but that'll be alot of work. (Remember, that's 16 colors per channel, or 12bits total. Not exactly high-color but I don't thinkl there was very many 15/16 bit colors used in the early 90's. So, 4bit per channel instead of 8 probably does the job for storing a vga display. I think, not sure, that the game was 320 by 200, and maybe 256 colors? more? At best it would be 640 by 480 but that is too big for these files unless teh screen capture function lowered the resolution upon capture. Not like it's an official feature.)

Now, this is just an excersize for me, cause I find it a pleasing challenge to puzzle out. After all, Dos-box does have its own screen capture feature, so this is not really necessary if I really cared about getting a screen cap. I just notice people mentioning it's strange format and I wonder how much of it could be figured out with some plugging about. I was wondering if anyone else has looked into this and what you might have found. (Also, it's a pleasant diversion from using my hex editor to figure out how to hack the save games. Which is a fun puzzle in its own right.) But any helpful info would be nice. Color Tables, viewers, format specs, etc can be very useful.

I also wonder if anyone is working on things like Total Conversion (or at least having fun hacking the items, fashion, school, work, etc.) I know the LBX files are basically archives, and I can unpack them if I wanted, but the txt files are not ascii / plain text (must be in some format specific to the game, I'd try unicode but I don't know if it was around back then) and the pt1 files are confusing. I am guessing, regardless if it was a graphic, a music, or what, it all got called pt1 and the game engine knows which is which and how to read them, but I'm not going to go through all of them just to see if they could be image or sound raw data. Also, they could be compressed with RLE or LZW or something.) So, anyone else have luck figuring out how to work with all of that game data?

Thanks, and I hope none of this is too annoying to read.

Me again. Played around some more. The 'B' files are image data. I turned them into BMP and they fit nicely after the 'A' file (cutting and pasting in Paint), so the image is broken up into 2 A/B files (as well as the 4 B1/E1/G1/R1 files).

I use the Hex Editor to just paste the B onto the end of A and reset the height vaule to 240 and it comes out nice. The E1 files are also images (mostly black in my first test example) when I do the same to them. So the screen is broken into 4 parts, each 4 bits(?). Maybe its a hi-color (15/16bit) representation of the screen, and each file is suppose to be packed into it's repsective bits? No idea.

Hope my little experiments is amusing to you, hate to waste space here if no one is interested in the screen capture files this game makes. I might take a capture of a different screen to see if the E1 files are still mostly black ... could be a clue, like it represents the most significant values for 16 bit color data, maybe?

For the adventurous type, I'll paste below the BMP file header with the color table for 16 colors. The Red Green and Blue values are equal in the table so it makes gray. Once I figure out what the proper palette could be, I could change that later. Just stick the header up front, then the content of the A file then the B file for each B1, E1, G1, R1. That is for XX00000A.B1 and XX00000B.B1 you need to make 1 file with a bmp header and the 2 concatenated. Repeat for XX00000A.G1, XX00000B.G1, etc etc until all of the XX00000? are processed. Also, BMP are funny in that the image is stored upside down in it normally, so a right side up image like this one will display upside down. Just flip it in an image editor or photo editing program. Also, you should get 2 side by side images. I suspect the even and odd fields for each line are seperate adn non-sequential (ie all odd pixels for the line, followed by all the even pixels). Anyone know of a common graphic format that does this?

I still wonder how the 4 files encode the color information. Any ideas?

Okay, here's the hex code for displaying the A + B raw data as a grayscale bmp. This needs to be the very first thing in your file (as far as I know). (If you don't put the B after the A, then change the first F0 into C8 to display the A file alone or 28 to display the B file alone.) If this seems confusing, just play around with it. Also note, this is displayed Little Endian, so you should have your hex editor in little endian mode.

42 4D 30 9A 00 00 00 00 00 00 76 00 00 00 28 00
00 00 40 01 00 00 F0 00 00 00 01 00 04 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 11 11 11 00 22 22
22 00 33 33 33 00 44 44 44 00 55 55 55 00 66 66
66 00 77 77 77 00 88 88 88 00 99 99 99 00 AA AA
AA 00 BB BB BB 00 CC CC CC 00 DD DD DD 00 EE EE
EE 00 FF FF FF 00

Ahh, tired of me yet? I recently examineded a screen capture from Dos-Box (Ctrl-F5). It was 640 by 480 and 16 colors. The data in each of the files (When A and B are chained together) is enough for 640 by 480 at 1bit color depth. The 4 files would be enough to reconstitute 16 colors if 1bit from each are used to make the 4bits for the 16 colors (in other words, 4 bitplanes of data.) Maybe you all knew that already. Also, from looking at the dos-box screen capture, I know what the 16 diffferent colors are, now.

So, I guess all that is left is for me to learn enough c programing to make a little utility to reshuffle the bits back together again, and write a more common image file. It would be nice to know which bits originally went where, and the original ordering of the colors, but since combining them in any fashion will make 16 unique numbers, I just might at first make a greyscale version. Then comparing to an identical dos-box capture, figure out which number should be which color and make a color table that works. (in other words, being willing enough to make a new color map, I should not be hindered by not knowing any original details. Doing one thing with one (which bit where) is offset by compensating with another (changing the colormap)). Figureing that out, will be easy. Writing a program to automate the process, well I don't know if I can. But I am willing to share what I find. I'm thinking of using EBGR as the order of bits in the nibble (most significant bit being E). Right now, all I'm going to do is change the bmp header to make it 640 by 480 by 1bit, and have the 2 colors in the colortable be black (00 00 00) and some kind of grey (for the R file (10 10 10), G(20 20 20), B(40 40 40), and E(80 80 80)) so that I can use gimp to put them all as layers in an RGB mode image with addition (all layers add up). Then convert that image to 16 color indexed, and save as a bmp, just to see what kind of image I get, and have something to try to map the 16 colors to. Probably will work, but I don't think its what most people want to do by hand each time they take a screen capture (though dos-box has a nice screen capture so this is all moot anyways, but a fun project.)

Anyone try to figure out how to access the data files, like the music, to play with? Not unlike how people like to edit their Quake data and change things up in the game.

Ok, I tried that. I made the E layer most significant (bits were either 0 or 80). Then G (40), R(20), and finally B(10) was least significant.

I opened all 4 bitmaps in GIMP. I made a new image, 640 x 480 and RGB mode. I made new layers, so I had 4 in total. All were set to addition (instead of normal). I copy and pasted each bmp image into the new window. I flattened the image, and then saved it as a 16 color bitmap.

Then a long story in a nutshell, colors from a dos-box screenshot was extracted, applied to the greyscale image, and rearranged as neccesary. The new pallet, when applied to the image, works great and I get the original screen back. Next, I just need to figure out a way (got some ideas) and write a C program to automate this. Take the 4 bitplanes (EGRB order most significant first), convert into chunks and write a run of the mill BMP and use the pallet I just worked out for the color map. For those who are interested I'll list the RGB values of the pallet in the order I have them in.

R G B
00 00 00
FC EC DC
FC CC B8
EC 98 84
A8 50 50
84 24 24
50 00 00
64 64 64
C8 C8 C8
00 34 DC
FC 00 00
FC 98 AC
00 C8 00
44 CC EC
FC EC 00
FC FC FC

That's about it. I think I found all the info I can, and listed what a person needs for looking at the strange screen captures PM2 makes. That said, I instead advise just using Dos-Box to take screenshots. Press Ctrl-F5 to take a capture. All images are stored in the Capture folder in your Dos-Box folder in the Program Files where it gets installed. I probably won't get started on learning to code right away (I know a little already), but maybe some day I'll try to make a little DOS utility to process those 8 files. I hope you found all of these info to be of some use. (If you are confused about BMP files, a web search will turn up what you need to know.)