brian151 Banned The administration (as well as a few users) have decided that you're creepy/weird enough that it's time to activate the sploded clause. Laters. Level: NaN Posts: 23/-249 EXP: NaN For next: 0 Since: 08-09-16 From: USA Since last post: 4.7 years Last activity: 4.7 years	Posted on 11-16-16 11:08:36 PM Link | Quote
	WIP Firstly, got reply from the person who uploaded the ULTRA.ief file... Their file, too, came from a legit CD-ROM. I decided to try contacting the moderator from vg-res that initially told me about finding 8BBP image data in the MMATH file, and I got a reply. Using the provided information, I was able to get THIS from TiledGGD:

brian151 Banned The administration (as well as a few users) have decided that you're creepy/weird enough that it's time to activate the sploded clause. Laters. Level: NaN Posts: 24/-249 EXP: NaN For next: 0 Since: 08-09-16 From: USA Since last post: 4.7 years Last activity: 4.7 years

Posted on 11-17-16 07:14:13 AM Link | Quote

WIP Alright, so... I've discovered a FEW things... 1. a given chunk/section seems to be identified with 8 characters 2. the offsets are relative to the offsets (so, if the offset is 0x0f, the data starts 0x0f bytes from the fourth byte in the offset) 3. definitely can confirm big-endian byte order in use here 4. there seems to be serialization, or some form of chaining stuff together 5. the only real indication for where something terminates is when an ID code is encountered, that, or a name. (which always seems to be a null-terminated string) id codes: INDXmeta = ??? INDX???? = ??? INDXvari = seems to point to another INDXvari, or a name DATApart = monster parts? DATAsprt = sprite? DATApixl = bitmap data of some nature? DATApltt = probably color palettes? DATAcblk = ??? DATAcomp = ??? DATAfram = frame? , not really sure what it's for, though DATAroom = room/map/area? DATAchar = probably byte or string character array? DATAblnd = blending mode(s) ? DATAtint = something to do with color tinting? DATAclst = ??? DATAsnip = ??? DATAtntR = tint red? DATAlayo = layout? DATAskip = ??? DATAxtra = ??? the 'DATA' ones seem to have versions that swap the first four and last four bytes ('DATApart' > 'partDATA') More research must be done about these. The bytes following these do not seem to be offsets or lengths. A significantly large portion of the results for searching for "DATA" returns these, instead of the ones starting with "DATA" At this time, I have yet to verify what for sure ANY of these mean, so I can only guess what a given ID code LIKELY would be an abbreviation/acronym for.

brian151 Banned The administration (as well as a few users) have decided that you're creepy/weird enough that it's time to activate the sploded clause. Laters. Level: NaN Posts: 25/-249 EXP: NaN For next: 0 Since: 08-09-16 From: USA Since last post: 4.7 years Last activity: 4.7 years

Posted on 11-22-16 06:27:21 AM Link | Quote

WIP I used a hex editor to split the files into 10MB chunks, due to tiledGGD lagging/crashing a lot I have skimmed ULTRA.ief for the 8bpp pixel data of graphics with the dimensions 640 x 480 my list so far is: CANNOT FIND PALETTES AT ALL...... 0xa00000 - snip size (10 MB) [ULTRA] 32 32 from snippet test3 0x109 OUTDATED ENTRY 32 32 from snippet TEST 0x160 OUTDATED ENTRY {snip 01} 640 480 0x30ec5 640 480 0x9be88 640 480 0x12529b 640 480 ~0x17029b 640 480 ~0x25da9b ~0x2a8a9b ~0x2f629b 640 480 0x34afa1 640 480 0x39e328 ??? ??? ~0x904b28 EOF {snip 02} EOF {snip 03} EOF {snip 04} ??? ??? ~0x41000 ??? ??? ~0x8c000 ANAMOLY, WHY DO THESE HAVE A TILE-LIKE ARRANGEMENT? 640 480 0x465fa might not be perfectly aligned vertically ??? ??? ~0x4b04fa another weird spot 640 480 ~0x78286d EOF {snip 05} 640 480 0x381a60 640 480 0x6a848a EOF {snip 06} 640 480 0x1563be 640 480 0x1a190a 640 480 0x1ece56 640 480 0x2383a2 640 480 0x2838ee 640 480 0x2cee3a 640 480 0x31a386 640 480 0x3658d2 640 480 0x3b0e1e 640 480 0x3fc36a 640 ~0x444b6a ~0x48fb6a ~0x4dd36a ~0x52836a ~0x57336a ~0x5be36a ~0x60936a ~0x65436a ~0x6a1b6a ~0x6ecb6a ~0x737b6a ~0x782b6a ~0x7cdb6a ~0x818b6a ~0x863b6a ~0x8b136a ~0x8fc36a ~0x94736a ~0x99236a ~0x9dd36a [OVERFLOW] LOADING SCREENS, GOT TIRED OF ALIGNGING THEM EOF {snip 07} 640 480 ~0x28000 ~0x73000 ~0xbe000 ~0x109000 ~0x156800 ~0x1a1800 ~0x1ec800 ~0x237800 ~0x282800 ~0x2cd800 ~0x318800 ~0x366000 ~0x3b1000 ~0x3fc000 ~0x447000 ~0x492000 ~0x4dd000 ~0x528000 ~0x573000 ~0x5c0800 ~0x60b800 CONTINUE OF LOAD SCREENS... EOF {snip 08} EOF {snip 09} 640 480 ~0x28000 640 480 ~0x20d000 EOF {snip 10} EOF {snip 11} 640 480 ~0x5aa000 EOF {snip 12} 460 480 ~0x35c000 EOF {snip 13} 640 480 ~0x29e00 EOF {snip 14} 640 480 ~0x500000 ??? ??? ~0x546000 ANOTHER WEIRD TILING 640 480 ~0x974000 ??? ??? ~0x9c4000 ANOTHER... EOF {snip 15} 640 480 ~0x62c000 EOF [MMATH] I kinda got tired after a BOMBARDMENT of loading screens (I estimate somewhere close to 10 MB worth) , and quit precisely aligning the offsets... I did log the relative offsets so I or someone else can align these later. I have requested a tool for ripping just the raw color indexed pixel data (and later palettes) , but this tool is incompatible with win32, i guess... Hopefully it will be updated by tomorrow. I'll deal with mmath tomorrow. I skimmed a chunk of Mmath for 640 by 480 image data (simply to verify it exists in the first 10 MB, even. it is EXTREMELY prominent) , and for 32 by 32 images, also... those are turning no definitive results. I have already identified a few in ultra. I am concerned mmath almost certainly has compression or custom formats going on with some image data. Everything found thus far does follow a few rules: 8 bits per pixel dimensions are multiples of 16, observed so far are 32, 480, and 640 one final note, if anyone understands x86 assembly, I might have a use for that. getting frustrated with getting much from the .ief files, I disassembled mmath.exe a few days ago. Just got several thousand lines of x86 assembly to try and work-out (if cracking the format by trial and error proves unsuccessful) I need to sleep now...

brian151 Banned The administration (as well as a few users) have decided that you're creepy/weird enough that it's time to activate the sploded clause. Laters. Level: NaN Posts: 26/-249 EXP: NaN For next: 0 Since: 08-09-16 From: USA Since last post: 4.7 years Last activity: 4.7 years

Posted on 11-23-16 07:08:02 AM Link | Quote

WIP skimmed mmath.ief for 640 x 480 pixel data, i found that the majority of this exists within the first 20 or so megabytes CANNOT FIND PALETTES AT ALL...... 0xa00000 - snip size (10 MB) [ULTRA] 32 32 from snippet test3 0x109 OUTDATED ENTRY 32 32 from snippet TEST 0x160 OUTDATED ENTRY {snip 01} 640 480 0x30ec5 640 480 0x9be88 640 480 0x12529b 640 480 ~0x17029b 640 480 ~0x25da9b ~0x2a8a9b ~0x2f629b 640 480 0x34afa1 640 480 0x39e328 ??? ??? ~0x904b28 EOF {snip 02} EOF {snip 03} EOF {snip 04} ??? ??? ~0x41000 ??? ??? ~0x8c000 ANAMOLY, WHY DO THESE HAVE A TILE-LIKE ARRANGEMENT? 640 480 0x465fa might not be perfectly aligned vertically ??? ??? ~0x4b04fa another weird spot 640 480 ~0x78286d EOF {snip 05} 640 480 0x381a60 640 480 0x6a848a EOF {snip 06} 640 480 0x1563be 640 480 0x1a190a 640 480 0x1ece56 640 480 0x2383a2 640 480 0x2838ee 640 480 0x2cee3a 640 480 0x31a386 640 480 0x3658d2 640 480 0x3b0e1e 640 480 0x3fc36a 640 ~0x444b6a ~0x48fb6a ~0x4dd36a ~0x52836a ~0x57336a ~0x5be36a ~0x60936a ~0x65436a ~0x6a1b6a ~0x6ecb6a ~0x737b6a ~0x782b6a ~0x7cdb6a ~0x818b6a ~0x863b6a ~0x8b136a ~0x8fc36a ~0x94736a ~0x99236a ~0x9dd36a [OVERFLOW] LOADING SCREENS, GOT TIRED OF ALIGNGING THEM EOF {snip 07} 640 480 ~0x28000 ~0x73000 ~0xbe000 ~0x109000 ~0x156800 ~0x1a1800 ~0x1ec800 ~0x237800 ~0x282800 ~0x2cd800 ~0x318800 ~0x366000 ~0x3b1000 ~0x3fc000 ~0x447000 ~0x492000 ~0x4dd000 ~0x528000 ~0x573000 ~0x5c0800 ~0x60b800 CONTINUE OF LOAD SCREENS... EOF {snip 08} EOF {snip 09} 640 480 ~0x28000 640 480 ~0x20d000 EOF {snip 10} EOF {snip 11} 640 480 ~0x5aa000 EOF {snip 12} 460 480 ~0x35c000 EOF {snip 13} 640 480 ~0x29e00 EOF {snip 14} 640 480 ~0x500000 ??? ??? ~0x546000 ANOTHER WEIRD TILING 640 480 ~0x974000 ??? ??? ~0x9c4000 ANOTHER... EOF {snip 15} 640 480 ~0x62c000 EOF {snip 16} EOF {snip 17} 640 480 ~0x370000 640 480 ~0x97e000 ~0x9c4000 [OVERFLOW] EOF {snip 18} EOF {snip 19} EOF {snip 20} EOF {snip 21} EOF {snip 22} EOF {snip 23} 640 480 ~0x712000 ~0x758000 EOF [MMATH] {snip 01} 640 480 ~0xd2000 ~0x1b8000 640 480 ~0x208000 640 480 ~0x2a8000 640 480 ~0x438000 640 480 ~0x49c000 640 480 ~0x4f6000 640 480 ~0x5d2000 640 480 ~0x64a000 640 480 ~0x6b8000 640 480 ~0x726000 640 480 ~0x776000 640 480 ~0x7da000 640 480 ~0x848000 640 480 ~0x8c0000 640 480 ~0x910000 640 480 ~0x956000 640 480 ~0x9a6000 EOF {snip 02} 640 480 ~0x0 [STARTS AT END OF PREVIOUS] 640 480 ~0x46000 640 480 ~0x96000 640 480 ~0xe6000 640 480 ~0x136000 640 480 ~0x186000 640 480 ~0x276000 640 480 ~0x2d0000 640 480 ~0x32a000 640 480 ~0x37a000 640 480 ~0x3e8000 640 480 ~0x44c000 640 480 ~0x4b0000 EOF {snip 03} 640 480 ~0x60e000 ~0x65e000 ~0x6a4000 {snip 04} EOF {snip 05} EOF {snip 06} EOF {snip 07} EOF {snip 08} EOF {snip 09} EOF {snip 10} EOF {snip 11} EOF {snip 12} EOF {snip 13} 640 480 ~0x6b8000 640 480 ~0x708000 640 480 ~0x74e000 640 480 ~0x79e000 640 480 ~0x7e4000 640 480 ~0x834000 640 480 ~0x884000 640 480 ~0x8ca000 640 480 ~0x942000 EOF {snip 14} EOF {snip 15} EOF {snip 16} EOF {snip 17} EOF Due to time constraints, I haven't tested the program I requested after it was updated... I just barely had enough time to split mmath and skim it. I have found a few things that are definitely copied from and/or remnants of Monster Maker Ultra... Next step will be to precision-align + identify as many of these as possible, and dump the pixel data. I also have reason to believe at least some images are not constrained to multiples of 16. In fact, many may not be. there have been a few things that I'm pretty sure are pixel data, but I haven't the faintest idea for what (or their exact dimensions)

brian151 Banned The administration (as well as a few users) have decided that you're creepy/weird enough that it's time to activate the sploded clause. Laters. Level: NaN Posts: 27/-249 EXP: NaN For next: 0 Since: 08-09-16 From: USA Since last post: 4.7 years Last activity: 4.7 years

Posted on 12-07-16 08:01:33 AM Link | Quote

WIP I have made a lot of progress on this recently... Sill nothing overly useful, but I have managed to find some palettes that are at least compatible with the monster parts can't find ANY data explaining what size they are, or where they are, i just have used trial-and-error the whole way Taking a bit of a break cuz of ludum dare 37, starting this week...gotta prepare, even though I only plan on doing graphics this time around

brian151 Banned The administration (as well as a few users) have decided that you're creepy/weird enough that it's time to activate the sploded clause. Laters. Level: NaN Posts: 30/-249 EXP: NaN For next: 0 Since: 08-09-16 From: USA Since last post: 4.7 years Last activity: 4.7 years

Posted on 12-08-16 06:40:27 PM Link | Quote

WIP Something was bothering me during a previous graphics location attempt: image data followed by unknown bytes containing the same values... Really hope that's not what I think it is... the... special type of sprite/graphics optimization technique that reduces redundancies by breaking the image into x_sized chunks/tiles... Those really suck to try piecing together, and raw data extraction won't be much better... That's probably all progress I'll make until Sunday or Monday...

Ehm Member Level: 49 Posts: 524/533 EXP: 844123 For next: 39760 Since: 06-13-09 From: Canada Since last post: 4.0 years Last activity: 4.0 years	Posted on 12-26-16 08:56:44 PM Link | Quote
	Operation (1998) also uses IEF. I don't know what to do with it, I just attempted to view the graphics through TileGGD. In-game vs. viewer:

Cuber456 Fuzzy Don't mind me. Just passing through. Level: 56 Posts: 708/776 EXP: 1319410 For next: 78766 Since: 02-19-12 From: Everywhere at once. Since last post: 4.2 years Last activity: 130 days

Posted on 12-26-16 11:40:24 PM (last edited by Cuber456 at 12-27-16 12:27:14 AM) Link | Quote

Ehm, it looks you can display the IEF files. You just appear to be missing the palette. I don't know the file structure of IEF files. My guess is that they are some sort of variation on 256 color bitmap images. Look at the second viewer image you posted. The bottom of the image which looks like "random/scrambled/garbage" data might contain the palette. I'd see if you can get the correct palette out of that section of the image. I know how to do that in Crystal Tile 2 but not in TilesGGD. ____________________ Zero Time Dilemma is Out!!!

Ehm Member Level: 49 Posts: 525/533 EXP: 844123 For next: 39760 Since: 06-13-09 From: Canada Since last post: 4.0 years Last activity: 4.0 years	Posted on 12-26-16 11:43:12 PM Link | Quote
	IEF is a single large uncompressed archive that contains all the game data. These graphics are towards the top of the IEF, I haven't looked much further. I also wouldn't know how to locate/ID palette data :x I think the next step for me is to see if I can find a common header or something for each image so I can batch rip the core image data.

brian151 Banned The administration (as well as a few users) have decided that you're creepy/weird enough that it's time to activate the sploded clause. Laters. Level: NaN Posts: 44/-249 EXP: NaN For next: 0 Since: 08-09-16 From: USA Since last post: 4.7 years Last activity: 4.7 years

Posted on 12-27-16 05:50:05 AM Link | Quote

WIP Do these IEF files have the INDXmeta header thingy? So, all I have found-out about the monster maker files is they're at least PARTIALLY a container format... I THINK... some of the meta-data from mmath.exe has references to a cpp source file that has the code for decoding ImaginEngine files (which is probably what IEF means) now, colors... I found the palettes in monster maker because i successfully dir-opened the actual director movie from the demo for monster maker (and had someone open the .dir, cuz my current situation leaves me without director). the colors are 4 bytes each. tilledGGD is setup to read them as four bytes per pixel/color big-endian with alpha at the start, but ignored. unless you could even get some idea what the color palettes are like when loaded (monster maker demo even varies slightly from release, and this confused me at first), not sure... in-file, the colors are four bytes RGB + A? I am sure other IEF files exist, but I don't know if they will be of any use for finding-out more about this format. I also have a couple ten megabytes of various attempts at decompiling mmath.exe, if anyone wants to look at that? The MOST reliable part is probably the disassembly, since it *theoretically* didn't change much from the "original" form, thus might at least be somewhat valid. honestly, for my purposes, i'd want the sprites extracted with the pixel data remaining paletted, probably not unlike its current form, but more organized. monster maker uses a LOT of color-swapping for the monster parts. Compression, I have no idea about. Pretty much confirmed the audio is some form of uncompressed PCM, but just like graphics and other data, without all the information that tells WHERE stuff is, what size, etc... not much luck extracting that, either... Sorry I really can't help much more, this project is reaching the point I've probably done all I can do... /: