Idea for cracking SoM's animation format...

[Holy_Diver]

Thats sounds very interesting, can you extract and alter the events?? Or just simply insert prebuilt events into anymap??

It copies events from one map to another. Basically it knows how to parse/synthesize a valid evt file, but cares nothing of what the events do or if they themselves are valid. I had to do this, because I have huge global events with hundreds of instructions which are just impossible/insane to try to input into the map editor on an individual basis. There is a post about the process, including my beginnings of my trying to transpose evt files by hand. It works good enough for my purposes, but I don't feel it's ready to be put on the website anywhere, and I kinda stopped after I succeeded in copying my global events into the maps where I wanted them.

I might want to break the command line app into two or more before I'm done. My next such project will be to shift map tiles around (so to free up space around them, like if you feel you started your map on the wrong tile or want to move a section to make room for another)

If anyone feels they need the evtcat program for their project I will try to sink more time into it / help them use what is there.

[HwitVlf]

"Reverse engineer" the game.exe what?? I don't know where people get off tossing shit out there like that... I could probably unravel the animated model format with some coffee and good looking over. You're not going to get anywhere by disassembling an executable etc, but you're welcome to prove me wrong. There isn't much point in "reverse engineering" other than to get some insight into the files (by whatever necromancy you propose) ...it's not like programming it from scratch would be too much trouble. The real value in SoM is license and assets that come with it. The tools themselves only slightly more impressive than the quickly thrown together runtimes.

Would you have been more comfortable with the term 'tracing code' than 'reverse engineering'? I avoid computer geekims and acronyms whenever possible because I'd actually like everybody to be able to grasp the concept of what I am saying. I simply meant that it would be probably be easier to decipher the animation format by tracing the code that processes the MDL files in the exe as opposed to my subject-line suggestion 'to decipher animation by looking at the MDL files themselves'. Translation projects have to 'reverse engineer' programs without the source code all the time; it's usually not that hard, and there are a tremendous number good tools available for doing so on the PC.

In spite of what you say, it is hard to program a functioning game engine from scratch. Feel free to prove me wrong by providing a link to a functioning SoM remake.

The 'assets' that come with SoM have almost no value to me. ‎  A lot of them aren't even King's Field related and they are all easy to replicate in well-documented formats for other game engines. My work on SoM is simply a hobby because I like to figure things out, and (in spite of everyone's complaints) SoM is far easier to use, and more feature-filled than any other game-maker program I've seen.

And as far as the license, I suggest you read SoM's EULA before you decide that it grants any license to distribute SoM material- I can almost guarantee you that it doesn't.

So why don't you have that cup of coffee and I'll look for your in-depth report on SoM's animation format in the morning.

[Holy_Diver]

Well it's not like me to make an unqualified declarative statement, but when I hear reverse engineering I imagine disassembling the binary then trying to make heads or tails of the diassembler's output over time. I have no experience with what/how people go about deciphering some translation/etc projects. Usually it seems like a fairly straight forward task, but it seems some types of platforms/programs may handle text etc in very strange ways. I guess I was being facetious (and hoped that was very obvious)

By tracing, I'm thinking you mean debugging the diassembled or assembly code. Still that is something that just makes my eyes roll back into the nether regions of my head. And in my imagination I just don't know when you'd decide you're looking at the MDL handling code. But this is stuff I suck at, so~

I plan to unravel the MDL format of course. But I should start with the MDO files first. If you know how 3d animation works and how files are generally organized, looking at a file can be fairly intuitive. What sections are what fairly obvious. Its something I can't say for sure how long it would take me to work out, but probably not very long. However it's not like I can just drop everything and obsessively broach some task just because someone dared me. I'll get to it when I get to it. I've a long laundry list of crap to do like everyone else. Just like when I got fed up with the Event limitations I sat down and programmed something to work around it in a few hours. I'll do the same with the graphics in my own sweet time. It's easier to do graphics though if you have something visual to test your hypotheses against, or just to comb data in general. So I'm working on finishing up a very sophisticated graphics project of mine I'd prefer to use for doing that, rather than wasting my time/cluttering my space coding something from scratch that would have no other function.


PS: I know how long it takes me to program a game engine like SOM because I've done it before. SOM is nothing sophisticated, it's really like "my first game project" for kids these days. All the art you get with SOM on the otherhand, that would take a while, no matter how you approach it. About SOM's EULA maybe you should translate it for us, but people seem to be sharing SOM games quite freely. Plus in Japan there is a long tradition of selling IP infringing amateur art like anything else. Japan is not a litigating society, so I take SOM at face value.

[Holy_Diver]

!!I did just have an amazing thought however...

If you could disassemble the binary, so we can recompile it. Then we can recompile a debug build (for "code tracing") and that would let me debug my ddraw.dll proxy, which is a serious problem I'm having right now.

Basically I've never been in a situation where I had to debug a dll via a release build executable. There is probably a way. Come to think of it, I've never had to debug a dll from an executable I didn't have sources for. It probably would not hurt me to figure out how to do this (there must be a way and I plan to soon) ...but disassembling and recompiling would definitely work.

So let me know if you do disassemble it/send me the sources.


I could be wrong, but I think a while back you mentioned disassembly for some reason??? And I couldn't find any C/C++ disassemblers up to the task. I can't imagine why we were thinking about that though. I'd rather not mess with the SoM runtimes however. Though injecting new code for certain purposes might not be so bad. I think if we changed anything other than text it wouldn't be SOM anymore.

I'm like a white wizard when it comes to software engineering... I know nothing of the black arts / shutter to think of it.

[Holy_Diver]

I think one thing to bear in mind,

The move object animations are really just simple transformations (translation/rotation) ...the animation of monsters/npcs is much more involved whatever techniques are utilized. There are a number of different ways models are animated in this fashion.

The two major ways are either just interpolating between beginning and ending states (basically unique geometries within themselves) with possible intermediate frames (again unique geometries) ...usually this interpolation is linear, but it need not be, and individual curves can even be applied to each vertex. This animation can be global or local to groups of vertices.

The other approach is to have a kind of skeleton, which can either be pivot points or vertex groups. Individual transformations (translation/rotation/scaling) are applied to these groups. This can be very simple with skeletal like figures, or more complex with "skinned" figures. Probably the most common modern approach for real-time applications is to assign weights to each vertex and compute the final position of the vertex based on the weighted sum of usually up to four such pivots (transformation matrices)

It's very possible SOM incorporates both basic approaches. I think modern weighted skinning might've been a little much for the time / hardware / general level of technology demonstrated by SOM. But I would not rule it out or anything else.

[darchangel]

After figuring out how to make new weapons for use in SOM, I started looking into the MDL files.

What I got from the little info available is that MDL is much like a gif where it stores the animation frames into a single file. However, I failed at finding a good MDL decompiler/program so I could open the available mdl files and be certain of what they were.

The one program I found was a Microsoft flight simulator which converts files into mdls but it was for airplane models only and not compatible with som.

[Holy_Diver]

You definitely shouldn't assume if you see a mdl file extension somewhere it has any relation at all to SOM. Som's internal formats appear to all be "proprietary" meaning they were not taken from anywhere and are tailored just for SOM's needs. That said it's very likely parts of the files (large parts even) would be identical/similar to popular formats of the day (almost definitely with odd SOM stuff tacked on)

Mod, Txr, Mdl, Prt, Map, Evt, all of this stuff, there is almost definitely no relation to any files with the same extensions you might find elsewhere.