Quasar
Moderator
Posts: 5237
Registered: 08-00 |
The Green Herring said:
As it turns out, it's caused by a very obscure bug — one that, hilariously enough, involves the player's starting position. If the player starts on a vertex on a two-sided line, and the sectors on either side can each be rendered as different visplanes (e.g. different heights, or, in this case, different light levels), then Doom performs an illegal memory read that DOS tolerates, but Windows 9x won't. It can be fixed by moving the player or removing the vertex (because there is no reason for it to be there). One of these will be done for the next version.
All I can figure out is that vanilla DOOM must install a handler that causes integer division by zero exceptions to be effectively ignored. Unfortunately it apparently leaves the value in edx:eax undefined after the idiv instruction, which then leads to out-of-bounds indexes into tantoangle and/or finesine. What happens from there's anybody's guess. You say visplanes seem to influence it; I cannot rule out or confirm that myself :)
BTW this was independently fixed by Jim Flynn in BOOM 2.02 and Lee Killough in MBF, in slightly different ways, so that R_PointToDist returns 0 if you are on the seg's v1 vertex instead of dividing by zero. BOOM once again proves 0/0 == 0 apparently :P
|
01-15-13 14:30 
