Brief Summary:
- LLS and MS patches are in the works. They will be released When They Are Done(TM), or in other words when all parties involved have time to sit down and finish the tasks of game hacking, image editing, text translation (there are still some pages on the wiki related to the PC-98 games that actually still lack a translation!), length editing and insertion, etc. Patch making is not a quick task, not to mention this is a bad time time-wise for most of us
1. Anything with the extension starting with .b* in the files is a graphics file. (I think, I didn't check them all, but I'm pretty sure.)
I
believe those were 16-colour raw bitmaps in a weird aspect ratio - shouldn't be too hard to check, just open them up in Irfanview or imagemagick's commandline imageviewer app or whatnot.
2. .M and .M2 are music files. (Well, .M is for sure, and .M2 has matching file names as .M)
FM Synth operator commands/data stored in the .M format for PMD files: the .M files are for the original OPN series which has 3 FM operators (as well as 3 "SSG" channels - short looped sample channels, typically used for percussion), whereas the .M2 files are for the PMDB2/PMD86 boards which use a later version of the OPN which increases the number of FM operators from 3 to 6. IIRC, most of the .M and the .M2 files were near-identical if not outright identical from a pure file data perspective, and I couldn't hear any difference between the two when listening to them on FMPMDE, so I wouldn't be surprised if they actually
are the same file, except renamed for some obscure compatibility reasons relating to PMDB2.COM/PMD86.COM or whatever. Who knows, really. Japanese programming has some really
weird idiosyncracies at times (there's that one time mauve found out that stock IaMP was ""compressing"" images using 64-bit RLE...with a 64-bit int as the runlength variable for each run. Said images wound up being considerably
larger ""compressed"" than uncompressed. lol.)
3. .PI files are either text, or how the game processes most of its data.
One of no less than
three imageformats used in LLS/MS, and by far the weirdest. It's compressed, and actually manages to pull off
remarkably good compression on 16-colour bitmaps, far better than PNG, while similarly being lossless. The disadvantages are that it goes from awesome to horrible as soon as you increase the bitdepth per pixel even to 256-colours, let alone something sane. It's fairly arcane, mauve wrote a dumper and I wrote a recompressor for it using that as a base, we were scratching our heads over the damn thing until I found an ancient implementation of this algorithm (predictably, this stuff hasn't been used since the DOS days: it came with an image display program which had the distinct appearance of a typical Windows 3.11 program (i.e. Comctl16.dll-style directory trees/open/save/etc dialogues, among other things)), which then simply reduced the problem to "read this fairly nasty x86 asm with a bunch of horrible macro tricks" or "read this fairly cryptic algorithm spec which is available only in Japanese" (and as both of us knew x86 asm and neither of us knew Japanese, the choice was obvious
).
Now that there's a dumper and a recompressor for these files, this has been taken care of and now the impetus is on the folks doing image editing to take care of that (among other things, ending images are stored as .PI files, principally because they are otherwise very large and compress
extremely well when compressed using this algorithm)
If this was already known, please don't beat me. I just wanted to help.
No problem.
EDIT: 4. .TX2 files have someone's script in them, actually, it might have everyone's for that stage... Those might be the ones to edit. But it might be hard to hex edit them because all of the characters use the "Windows: Japanese" character set and I don't know whether or not it's possible to change it to US and make them still work on the emulators...
The charset is SJIS, yes. Despite this being SJIS, lower-set ASCII characters (i.e. 0-127)
should display perfectly fine regardless of system codepage, this is kind of by design and for very good reasons (and besides, you typically can see some random lines of English text from PMD.COM/PMDB2.COM/PMD86.COM (whichever one of those 3 actually recognises Anex86's emulation layer as a valid OPN and stays resident, iirc PMDB2.COM) before the main game is loaded via ZUN.COM in the startup script on the default .HUD set that seems to be circling around the internet these days.
