Aha! The answer was mipmapping,

[Holy_Diver]

I think I have a good theory as to why the graphics don't show up correctly in the editors.

Working with D3D9 I began to have doubts that the mipmap "autogen" feature was actually working. The roofs of the houses in DD were especially telling. So it turned out (under D3D9) autogen was not compatible with dynamic textures (at least with my drivers) which Som needs in order to interact with GDI which is what Som uses to copy its images into the DirectX textures.

So I let Som manage its own mipmaps and what I ended up with is the visual bug where most of the level appears invisible, which I'm sure plagues a lot of people, including myself the last time I tried to play a Som game on the XP machine I had originally been using to work with Som. I think this bug accounts probably for a lot of the instances where Som alone would just not work out for people. It turns out this bug pretty much happens whenever the DirectX 7 drivers let Som manage its own mipmaps. Many drivers when a mipmap surface is requested these days just return an error while silently managing mipmaps on behalf of the application. When the drivers do that Som seems to do fine in hardware mode.

But if Som goes and tries to make its own mipmaps something seems to go wrong, and they come back as all black images. SomEx can off course correct for this one way or another. Then in your game all the surfaces that sample a mipmap come back with an all black pixel (ie. transparent to Som)

Whether the original texture or a mipmap is sampled is based on the distance between the texels projected on screen which determines the mipmap level. So basically stuff further away gets a mipmap, but that can depend on the resolution of the texture also.

So in the map editor for example, since the view in either the piece preview window or the piece setup view the camera is always back a little ways the entire graphic is likely to be mipmapped or the front may not be but the back is, which pretty well describes what you see... on XP especially... Vista/7 may have some additional problems.

But anyway, the reason the editors always get stuck this way and the games don't is because I'm pretty sure the editors always display graphics in software mode so to be compatible with window modes on all computers.

And I'm pretty sure the reason I could use the editors without disabling my graphics acceleration on my XP computer was because I had either disabled or forced mipmapping. I think either way would fix the problem.

SO FOR THOSE OF YOU PAYING ATTENTION, you probably don't need to disable hardware acceleration in dxdiag if your advanced display settings section has an option to override mipmapping.

And the reason things probably work if you disable hardware acceleration is the software renderer appears to try to mimic the hardware onboard, so with it disabled there is no mipmapping support.

[dmpdesign]

Good find!

Now if only I had a machine that let me disable that specific feature ><

[Holy_Diver]

Good find!

Now if only I had a machine that let me disable that specific feature ><

Most cards I've ever had allow mipmap overrides. My current card (on this machine) lets me turn them off and even change the filter used when forced on. I will try disabling them just for the Som editors later / let everyone know if that helped on Windows 7.

UPDATE: Hells yeah, it did the trick!!

PS: For 7, still really slow/crashy, but you can see the graphics. I think on XP things would be perfect. Compatibility settings might help further (I did not expect this to fix all the Vista/7 probs)

[Holy_Diver]

Good find!

Now if only I had a machine that let me disable that specific feature ><

ALSO, you might try looking for alternative drivers. I know Nvidia drivers always have this sort of thing. Even for bottom of the line hardware. There might be other ways to override mipmapping. Might be worth websearching.

[Holy_Diver]

Well I spent most of the afternoon looking into this.

It seems that Som doesn't actually have mipmaps for every texture. The ones it does have are presumably embedded in the files (most likely .txr format) which I presumed because generating mipmaps at runtime for paletted images would be impractical. MDL based graphics never have mipmaps.

The mipmaps it does have seem to be really shitty. Or at least under DX7 and D3D9 the roofs in DD go from a very dense texture to a total bloom in one LOD with a sharp transition between the two. It seems that mipmaps are more likely to appear in newer user generated objects. At any rate, Som appears to be really shooting itself in the foot in the mipmap dept, so I intend to see what happens if they are short circuited / generated on the fly for it.

I think the reason I was seeing drivers returning errors when Som looks for mipmaps is because Som just blindly looks for mipmaps even when it did not request any. I don't think there is ever any auto generation by DX7 drivers (unless you turn that on in your display settings)

It was a good lead as to what's wrong with the editors. I have to backpedal a little on why exactly the mipmaps are boogered in the editors. I think only the assets with mipmaps might look bad under XP. Somehow the mipmaps must be requested but never filled. Perhaps it was a bug that slipped by From' because the software device implementation at the time did not do mipmapping.

I was also a little confused about how mipmaps were requested under DirectDraw. It seems like that was never clearly documented even at the the time.

[Holy_Diver]

Ah geez,

I've ended up really doing a lot with this stuff...

So it turns out Som's mipmaps were not setup crumby afterall. The thing I didn't realize is mipmapping actually takes into account shear when choosing which map to sample. So even if the polygon is right in front of your face, if its turned away from you, so it's just a sliver, an extremely low, even 2x2 mipmap can be chosen. I mean technically this is what mipmaps are for, but you really never want that. So like looking up on the roofs of the houses in DD from the ground end up texturing them with a 4x4 texture which is just hideous. So you really have no choice but to also deploy anisotropic filtering. If you force on anisotropic filtering via the control panel (for your video card) that might seriously help Som, but I have not seen any signs of Som deploying anisotropic filtering.

So then once I got the universal mipmapping setup (now with anisotropic filtering, which helps with shear surfaces in general) that created (as I'd expected) a lot of problems for the imitation colorkey setup. Basically because each mipmap is a texture half the size (down sampled) from the level before it. So you get your black pixels all blurred and what's black versus transparent gets very sketchy.

So for starters, it was obvious the 1bit transparency afforded by 16bpp textures was infeasible. So with mipmapping setup ("do_mipmaps = yes" under the [Option] section of your Ex.ini file) the 16bit textures are converted to 32bit. They look the same (on level zero at least) but you have 255 possible transparency values versus 1. Also once you start blending the colours in the mipmaps you get into true colour (24bit) values, which looks cleaner as things blur into the distance. But to really make things work I relaxed the colorkey tolerance so any black pixels up to (6,6,6) is transparent, which I think may be technically correct under some circumstances when converting between 32 and 16bit colour. But anyway without that kind of tolerance you end up with weirdness like the bottom pixels of a grass texture wrapping around so they get blend up on top of the texture (making a disembodied row of pixels floating in the air)

Everything combined makes things look a lot better. The mipmapping is undetectable. I also got rid of the lines in the menus at some resolutions a couple days ago, which only show up under D3D9 when you change up some of the filters. The fix should be backportable to DX7. Just need to adjust the font dimensions for widescreen to really spruce things up.


There are just a couple lingering things that don't translate so well to D3D9 (yet) which I'm aware of. All tied to specific objects which could just be removed from the game if necessary. Basically there is a plant in the central woods in DD that has black stalks which surely should be green. And the flashing green barriers seem really slow and black out for a long time so you can see thru them. On the other hand I've seen some objects that never seemed to show up correctly before which show up now. Like some mugs in the last map of DD that were always white, that now look like glass mugs with apple cider or something in them.