2010-09-16, 01:06 PM
I kind of assumed that when you change the resolution in the options menu and that causes the direc3d device interface to be recreated Som was just forgetting that it had to setup all the lights again on the new interface.
But that doesn't seem to be the problem (though they may also be going on -- have not run any tests) .... it seems like after changing the options (either device or resolution) the same bug that afflicts the debugger kicks in. Basically Som just quits managing the object lights period. If something causes the map to be re-opened, the lights will come back.
I think I've seen other stuff make this bug kick in as well.
There's nothing I can think of to work around this behavior in terms of fixing the bug. I would not want anyone to have to release a game with this bug on the loose.
However what I have planned in order to fix the debugger (som_db.exe) should be applicable. The idea there is to just ignore Som's flip switching and keep all applicable lights burning up to max lights.
It seems like Som turns on up to 3 lights per object. I figure it chooses the three by whatever light radii overlap with the best fit radius of the object (forming 3d spheres) ... I was going to turn on all the lights that were visible to the player, but now I'm thinking in order to better simulate the 3 light behavior the extents of the vertex buffers should be calculated. That will also probably be a lot easier to implement. The only caveat is in theory anyway for soft animation objects the contents of the vertex buffers can change, and I'm not actually sure how Som manages the map pieces. But this approach in theory will also be more efficient because only as many lights as necessary would ever be factored in, and that would make it possible to really have a lot of lights in your game. Even crazy firefights which magic balls of light flying all over the place. So the pros out weigh the cons I think (if there even are any cons)
If any of the soft objects do break out of their initial radius they could be altered by placing a degenerate triangle or two into the file. And the radius could probably have a fudge factor added to it just to be conservative without too much harm done.
I think I can implement this in not too much time. And the [Bugfix] section option can be equivalent to "do_lights = yes" with a maximum light number 3 or 4 (whatever it is)
It may be too early to say, but after the lights are fixed. If you just erased the "Elapsed Time" from the menu in the translation file, and restrict the aspect ratio to 4:3 (adding this option) if needed, your game might appear to be bug free, editing aside. Only other thing I can think of at the moment is the sound dropping out and continuing to play after going into the menu. I definitely want to do some more work with DirectSound at some point.
EDITED: There are also a number of graphical "bugs" I can think of which could be fixed by making sure there are no black holes in the textures. The shadow texture should be re-leveled so it tops out at pure white. And almost all of the mdl files seem to have their uv components off by about a texel, and I can't find a way to automatically fix that, so probably those would need to be corrected by hand (or some clever algorithm) eventually.
But that doesn't seem to be the problem (though they may also be going on -- have not run any tests) .... it seems like after changing the options (either device or resolution) the same bug that afflicts the debugger kicks in. Basically Som just quits managing the object lights period. If something causes the map to be re-opened, the lights will come back.
I think I've seen other stuff make this bug kick in as well.
There's nothing I can think of to work around this behavior in terms of fixing the bug. I would not want anyone to have to release a game with this bug on the loose.
However what I have planned in order to fix the debugger (som_db.exe) should be applicable. The idea there is to just ignore Som's flip switching and keep all applicable lights burning up to max lights.
It seems like Som turns on up to 3 lights per object. I figure it chooses the three by whatever light radii overlap with the best fit radius of the object (forming 3d spheres) ... I was going to turn on all the lights that were visible to the player, but now I'm thinking in order to better simulate the 3 light behavior the extents of the vertex buffers should be calculated. That will also probably be a lot easier to implement. The only caveat is in theory anyway for soft animation objects the contents of the vertex buffers can change, and I'm not actually sure how Som manages the map pieces. But this approach in theory will also be more efficient because only as many lights as necessary would ever be factored in, and that would make it possible to really have a lot of lights in your game. Even crazy firefights which magic balls of light flying all over the place. So the pros out weigh the cons I think (if there even are any cons)
If any of the soft objects do break out of their initial radius they could be altered by placing a degenerate triangle or two into the file. And the radius could probably have a fudge factor added to it just to be conservative without too much harm done.
I think I can implement this in not too much time. And the [Bugfix] section option can be equivalent to "do_lights = yes" with a maximum light number 3 or 4 (whatever it is)
It may be too early to say, but after the lights are fixed. If you just erased the "Elapsed Time" from the menu in the translation file, and restrict the aspect ratio to 4:3 (adding this option) if needed, your game might appear to be bug free, editing aside. Only other thing I can think of at the moment is the sound dropping out and continuing to play after going into the menu. I definitely want to do some more work with DirectSound at some point.
EDITED: There are also a number of graphical "bugs" I can think of which could be fixed by making sure there are no black holes in the textures. The shadow texture should be re-leveled so it tops out at pure white. And almost all of the mdl files seem to have their uv components off by about a texel, and I can't find a way to automatically fix that, so probably those would need to be corrected by hand (or some clever algorithm) eventually.