Are map tiles allowed more than one texture?

I'll be posting Rathmor screenshots here as i go along. Theres a few here to get started on.
Feel free to post your screenshots when you have the game.

Produce! The screenshot isnt 100% clear as its a jpg.


Look around for stems in the ground...



... They may yield mighty treasures!

Please state your vote folks! Question being... The weapon and armour models will be displayed outside of the shop menu.

Looking thru the DATA/ENEMY/ folder, I see TEXTURES.

In there there are .txr and .bmp files. Neither of which are necessary to .mdl files.

So I'm curious... when you re-skin a monster for example. Does it not create a new .mdl file? Or is there a new way to associate textures with .mdl files

If you can texture a .mdl file with a .txr file somehow, that would really open up some possibilities. The most basic of which is better colour depth.

Thoughts?

I noticed today Som wasn't producing the object lighting to match up with the lamps (with my drivers/Windows 7)

I knew that before if you changed your display settings in the options mid game the object lighting had a tendency to disappear, but this is new.

An example of why this sucks is if you have say a lamp near a false wall (secret door) the door object will have no lighting but the walls around it will. Of course the object lighting and map piece lighting have never meshed correctly so your secret door would still be pretty obvious either way but it kind of cramps the atmosphere for it to not be lit to at least match.

The lamp lights are never even created. The directional map lights are however. The ambient map light isn't actually a light, its a global render state I learned about only the other day while researching the Direct3D lighting model.

Anyway I know for certain these were working before, though it may've been a year since I last payed attention to them. I'm assuming there is some device capability that Som expects to be reported just so which is not.

I'm pretty confident it can be fixed (with Ex...) in fact in theory it definitely can be. I'd forgotten about the lights being lost after leaving the options screen. Hopefully that can also be remedied in the process, though there is a possibility that bug might present more trouble... or at the least require a less than eloquent approach.

I have been seeing on some SOM games this issue of transparent object.I realize my pc is E-Machine with intergrated graphics card and shared memory.So I dont expect very much out of it yet on Trismegistus,Diadem of Maunstraut both work perfect.I have no visual problems,no framerate issues,no black areas or bleed thru.not even an issue with the memory just a quick flicker at beginning.I have been drawn in as others to start working with SOM and my project has now just run into this issue.I had seen no sign of transpareancy till adding the sky after this no matter the settings (even option ie resolution,texture mode) no change.I have change every setting in map mode also alters appearance not situation any help here?Now to my question i realize if I wish to continue I will need a new PC I have gaming machine.i do not wish to put this on that to many hour of play time!So what would be the best set up for this ie:video card,memory. I be thankful for any help would really like to dig into SOM

I'm feeling game to start work on a Galth Fee set. I'm a little embarrassed though because I can't find the original files Todd gave me (which he had somehow ripped from the game disc)

I have all the files I'd derived from those files but not the originals... and I've looked everywhere

None of my derivative files have UV information. For me the original UV info is a must before getting started. I think the files you gave me were .lwo. I'm assuming those are the files produced by the ripper... otherwise it's important to be sure at no point along the way UV information was added, ie. by some generic projection mapping.

I will start by compiling the models/textures for the originals in the .blend format. And I'm hoping Som will accept those as MDL files so I can just use Assimp's Blender support / x2mdl so I don't have to subject myself to the unofficial Meta (sequoia) -> Som toolchain.

If I can't use x2mdl I will leave the Som import to others until I can setup a replacement x2mdo app. I don't think anyone will want to use the original graphics in a game at this point, but we could make sure everything lines up at least.

Ultimately going the txr/mdo route might yield superior colour depth, but that can be a last step.


PS: Was "Seath's" armor the Merril Ur equivalent to the Galth Fee set? Or did he have another set of armor not represented in Som?

For some reason I was thinking about dithering, and I remembered that Som seems to want to have dithering. I double checked this, and it's true.

Now I don't think dithering was ever supported by ddraw/d3d in 32bpp modes. But in the 16bpp mode presumably there is supposed to be dithering. You may also notice in the various Objedit like tools there is dithering going on. The thing is apparently graphics hardware manufacturers at some point stopped supporting (hardware) dithering. Apparently this was bad for a lot of older 16bpp games because without dithering the rainbow banding effect is more plain to see and these games were never intended to be displayed without dithering, so that's a shame. The reason there is dithering in Objedit and friends is presumably because they are in software rendering mode.

I've added a variable that overrides Som's dither setting to turn off dithering for starters. The reason why is just because I figure games should be consistent across hardware and dithering really changes the look of the game and by default authors probably want their games to be consistent (even though there probably isn't many contemporary chips that implement dithering if any)

That said apparently dithering is how Som was meant to be seen... in 16bpp mode at least anyway. I know KF2 (Melanat) has dithering. In fact you all playing KF2 on emulators are not getting the full experience very likely because there probably is no dithering happening. I checked epsxe and my plugin was not dithering KF2 anyway.

Probably I was thinking about KF2's visuals when my mind found it's way to dithering this morning... speaking of which I completely forgot about my coffee...

I figure if one of you lot ever get an urge to make a game with the KF2 graphics it might look a lot better with a dithering effect for that matter. So I reckon I will try to implement some form of dithering in the D3D9 shaders... probably right before the gamma correction stuff.

The dithering I see in Objedit is not the same I think as what I plan to do (https://en.wikipedia.org/wiki/Ordered_dithering) but I think the kind of dithering I will try to achieve will be better in some ways because the DirectX dithering can cause problems when there are transparent pixels, because they get dithered with the non transparent ones and end up creating a kind of unnatural fog where every other pixel is transparent. It may in fact be Objedit is just dithering the textures, because otherwise I think there would be that kind of fog around every open edge of a polygon.

This (https://en.wikipedia.org/wiki/Ordered_dithering) kind of dithering just dithers the colour of each pixel depending on where it falls on the screen, which I'm pretty is how PSOne dithering works. In fact the PSOne dithering can be somewhat annoying on a non-standard-def-tube-display because the dithering mask is fixed even while moving so it seems like you're wearing a kind of veil. I think if I get that far probably the pattern can be swapped out whenever the view changes (kind of like how the stars change in KF2) to alleviate that.

EDITED: The dithering in Objedit seems to be something about how colorkey is implemented. It only happens within textures anyway. I don't know if it's better or worse than just knocking out the whole unfiltered (square) texel. I wonder what makes it work that way though.

Just posting to see if you pop on here, havent heard from you in about a month.

Anyone hear from Madison Lastrega?

Here (attached) is a new tool for working with .MDL files. It's called x2mdl basically in the spirit of the x2mdo tool that From' released. X2mdo converts .x files to .mdo files from what I understand, and that's what x2mdl does. However you can also try other types of files in place of .x. If that format includes all the features a MDL file requires and is supported by the Assimp library it will also work. If it doesn't include all of the features it will still probably net you a static graphic but might not be useful for animation etc.

As is I think you could get started making new doors and treasure chests etc, and even NPCs and monsters. However Som has two different kinds of animations, and only one kind is supported right now. With the supported kind you can make wooden puppets basically, like most of Som's NPCs but not make one piece rag doll puppets, slugs etc. The animation method you choose must also reflect that or the Assimp library will interpret the animations as the wrong kind and they won't be exportable (yet)

In this release textures will be converted to 16bit and be down sampled to 256x256 if necessary. Afaik as far as we know this is as good as any existing .MDL files, but it may be the format can do better. Just need to setup some experiments.

X2mdl only facilitates .mdl files... you will have to figure out the .prf files and others for yourselves. In some cases you can just overwrite the string of characters in the .prf file that stores the name of the mdo/mdl file. Edited: also I still have to develop another app for generating .cp files (more about that later...)

When you name your animations there are 3 ways x2mdl will recognize them. If the last letter is a closing parenthesis, x2mdl will look backwards for the first opening parenthesis, and if that is followed by the # character, the next characters must be the number, eg. Walking (#1) ...otherwise, the first character must be a number, eg. 1 ...otherwise the actual order of the animations will be used, so first animation is 0, the next is 1, and the next is 2, and so on. If your file format of choice does not let you name animations in any way, you will have to somehow make dummy animations to fill in the animation IDs you don't want/need.

Below is a list of animation IDs used by Som:

if(id<2)
{
switch(id)
{
case 0: set = "Idle (default)"; break;
case 1: set = "Walking (#1)"; break;
}
}
else if(anims<5) //! guessing object
{
switch(id)
{
case 4: set = "Opening (#4)"; break;
case 5: set = "Closing (#5)"; break;
}
}
else if(anims<12) //! guessing enemy
{
switch(id)
{
case 4: ‎ set = "Dying (#4)"; ‎  ‎  ‎ break;
case 6: ‎ set = "Evading (#6)"; ‎  ‎ break;
case 9: ‎ set = "Trigger (#9)"; ‎  ‎ break;
case 10: set = "Attack A (#10)"; ‎ break;
case 11: set = "Attack B (#11)"; ‎ break;
case 12: set = "Attack C (#12)"; ‎ break;
case 13: set = "Attack D (#13)"; ‎ break;
case 14: set = "Attack E (#14)"; ‎ break;
case 15: set = "Attack F (#15)"; ‎ break;
case 16: set = "Defending (#16)"; break;
case 20: set = "Hitting (#20)"; ‎  break;
}
}
else switch(id) //! guessing npc
{
case 2: ‎ set = "Hitting (#2)"; ‎  ‎  ‎  ‎  ‎ break;
case 3: ‎ set = "Dying (#3)"; ‎  ‎  ‎  ‎  ‎  ‎ break;
case 4: ‎ set = "To Left (#4)"; ‎  ‎  ‎  ‎  ‎ break;
case 5: ‎ set = "To Right (#5)"; ‎  ‎  ‎  ‎  break;
case 6: ‎ set = "To Face (#6)"; ‎  ‎  ‎  ‎  ‎ break;
case 16: set = "Seated (#16)"; ‎  ‎  ‎  ‎  ‎ break;
case 17: set = "Standing (#17)"; ‎  ‎  ‎  ‎ break;
case 18: set = "Hitting Seated (#18)"; ‎ break;
case 19: set = "Dying Seated (#19)"; ‎  ‎ break;
case 20: set = "To Left Seated (#20)"; ‎ break;
case 21: set = "To Right Seated (#21)"; break;
case 22: set = "To Face Seated (#22)"; ‎ break;
}

If you want to replace the arm, animation IDs 0, 1, and 2 are used for each swing animation, not sure which is which.

Control points are supported by x2mdl, but x2mdl won't generate the .cp file. In order to create a control point your format needs to support per vertex or per triangle colours. Setting the material won't do. Any triangle that is the same colour on all vertices and that colour is not pure white will be treated as a control point. I'm assuming pure white means the equivalent of no coloration... if that is not so for your format I will add an option to specify what is the neutral colour.

If your model has no control points, and you're impatient, then you can probably get it in game by using the wooden treasure chest's .cp file.

Beyond the scope of the .mdl file I don't really understand control points myself at this point. I'm assuming they are referenced by number in the .prf file. For example a control point at the tip of a sword damages the player when it touches the player during an attack and might be the point where a magic spell originates for example.

The way the program works is very simple at this point. And there are few frills in the case that something goes wrong. Just drop a file on top of it, and if it works it will make a file of the same name with .mdl appended to the end. Alternatively you can evoke the program via a command prompt and pass along the name of the input file as the only argument.

It's a standalone application, but requires Direct3D 9 and the D3DX9 libraries to be installed on the system. The kinds of external images supported are currently limited to the ones supported by the D3DX9 interfaces (.bmp, .dds, .dib, .hdr, .jpg, .pfm, .png, .ppm, and .tga)

Attached Files

  x2mdl.exe (Size: 1.84 MB / Downloads: 181)
  Somimp_view.zip (Size: 976.51 KB / Downloads: 166)
  cpgen.exe (Size: 164 KB / Downloads: 179)