* the sight checking code needs to be as precise as possible and should not depend on some old semi-broken routines. (This is more a precision issue of these routines - P_PointOnDivlineSide removes the lower 8 bits of each value - than having an issue with returning the wrong side in some cases.)
* for slope creations it is flat out wrong to use the old routines at all.
* also ignore this in the modern (box-shaped) case of FPathTraverse::AddLineIntercepts. This functionality is new to ZDoom and therefore not subject to compatibility concerns.
* the line-to-line teleporter. It seems the hideous fudging code was just there to work around the design issues of these functions, so let's better not ever call them here in the first place.
* A_PainShootSkull: Its usage here does not depend on these issues.
* P_ExplodeMissile: New code exclusive to ZDoom.
* FPolyObj::CheckMobjBlocking
All occurences in p_map.cpp have been left alone although most of them probably won't need the compatibility option either.
- Envelope data needed to be converted to SF2 values.
- Fine tuning was ignored which made pretty much every instrument off tune.
- Despite this, it still sounds like shit compared to FMOD or Microsoft's
wavetable synth. There are lots of missing notes and some instruments
are still off tune. I'm not sure it's worth trying to salvage it. It'd
probably be better to scrap it, since Timidity is very much oriented
toward GF1 patches, which it handles perfectly fine.
- The missing comma on the first line of dBm_pan_volume's definition
looked suspicious, so I checked the MIDI specification at
http://www.midi.org/techspecs/rp36.php and found the equations
there gave different dB values than were in the table. So I
rebuilt it using the equation given there:
20*log (sin (Pi /2* max(0,CC#10 – 1)/126))
'ceilingterrain' is needed because the top of 3D-floors refers to the model sector's ceiling, so in order to give a 3D floor a terrain it must be assignable to the sector's ceiling.
Note that although it is basically the same property, its actual function bears no relevance to its use in Eternity.
Issues with the old code:
* when calculating friction for a 3D-floor - swimmable or not - the 3D floor's top texture must be used. The previous version always checked the sector's floor texture, even though the top might as well come from the sector's ceiling.
* 3D floors never checked for the SECF_FRICTION flag at all. According to Boom specs, sector-based friction must be ignored if this is the case.
* Terrain based friction had a higher priority than the sector's own value.
Changed the rules as follows:
* if the sector's SECF_FRICTION flag is set (i.e. something explicitly changed the sector's friction), this value is used regardless of terrain settings.
* if this flag is not set, the terrain's friction is used, if defined, using the proper plane for 3D-floors.
* otherwise the default is used.
