2010-08-19, 07:06 PM
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.
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.