I'm hoping that some of you old-timers can help me out. A few of us are working on making the old Might and Magic games (specifically MM6, 7 and 8) editable. We have enough information to be able to display the graphics files, but there are still some unknown values, which will make it difficult to be able to import anything back in. These games were written in the mid-90's and I am hoping that if I give a description of the general layout, that one of you might recognize it as similar to something else. Each outdoor map is a simple 128 x 128 raw type map, with 512 units per grid and a factor of 30 on the heights. Anything at level 0 is always water. Each grid is mapped with a single terrain texture tile, which is referenced by index into another file which identifies the actual texture names. All the 3D objects on the map are defined beginning at a standard offset in the definition file (after the terrain information), as follows: word -> number of entries, followed by all the base entries sequentially. Each entry is B8 long and starts with the 'name' of the object repeated twice in 20 byte entries. The entry contains the number of vertices, the number of faces, the origin of the object on the map, a bounding box and some unknown information. After all the entries, begins the data for the first object, followed by the data for the second object, etc. Data for each object is vertices, which are each 3 signed words (not floats), followed by the 'face' definitions. All vertices are given in world coordinates, so that you have to subtract the origin in the main entry to get the local co-ordinates, and all vertices are in whole numbers. Each face has a normal for the face (as far as I can tell, every face lies entirely on one plane, regardless of how many vertices), followed by a list of of vertex indices (no triangles - more like a triangle strip), a maximum of 20, but more commonly 4 to 8. The space for all 20 entries is always there, whether they are used or not. This is followed by 20 shorts, which give the tex_s or u texture coordinates, followed by 20 more shorts which give the tex_t or v texture coordinates. This is followed, in each entry, by about x80 bytes of unknown data, followed by a short delta tex_s value and a short delta tex_t value, followed by min and max x, y and z values (also shorts), followed by some unknown but unchanging values, with the number of vertices in the midst of that. Each face entry totals x134 in length. Following that are all the texture names (one texture per face), each in 10 byte entries. If a texture is used on 6 faces, then it is listed 6 times. The only way to reference the texture name is by using the same sequence as the faces. Immediately following that is the entry for the next object, etc. etc. That's about it. If this looks familiar to anyone, I can supply additional details. Any help is greatly appreciated.

Quote:Original post by Name_Unknown
What is it you actually want help with? You only state what you already know..
Do you want to know how to reverse engineer them? The old skool way is to go in a hex editor and change stuff, load the game and see what happens. It is not brilliant but it worked ...

Yeah - that's pretty much the way we've been going about it, and we'll keep on that way if need be.

I know this was a shot in the dark, but my ultimate hope was that someone would look at it and say, "oh, that looks a lot like blah-blah format. Some of that unknown data might be...".

As I said, a shot in the dark, but just looking for any clues, hints or tips at this point, in hopes of shortening the curve.