This commit is just preparation for upcoming changes to completely encapsulate the coordinate info in AActor because I'm going to have to work with an altered version of actor.h that cannot be committed without breaking the engine.
With this file present in the repo before work is started the changes can be committed piece by piece.
There is no need to close (and thus deallocate) console window explicitly
This will be done by autorelease pool in application controller event loop
OS X with GC and/or ARC was not affected by this issue
Older versions like 10.4 or 10.5 crashed because of double deallocation
Because frac variable has fixed_t type it must be compared with fixed one
Test case: try to break stained glass windows or open door at the beginning of Hexen's MAP01
* since we can trivially decide whether a line crosses the trace behind the end point from checking the return value of P_InterceptVector, there is no need to add those to the list of intercepts as they get discarded anyway in t
* maxfrac is always FRACUNIT so there's no need to waste some variable for a constant value.
* 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.
- Disconnect scripts were previously run at some point after the player
left. Now they are run immediately before destroying the player. Since
the player hasn't actually been destroyed yet, the player also gets to
be the script's activator. This gives you a chance to scrape whatever data
you want from the player before they're history. Note that if you do
anything to make the script wait, the script's activator will become the
world, as it was before.
- The old algorithm is something I threw together that produced decent,
but not spectacular results since it had a tendency to waste space by
forcing everything onto "shelves".
The new packer is the Skyline-MinWaste-WasteMap-BestFirstFit algorithm
described by Jukka Jylanki in his paper *A Thousand Ways to Pack the Bin - A
Practical Approach to Two-Dimensional Rectangle Bin Packing*, which can
currently be read at http://clb.demon.fi/files/RectangleBinPack.pdf
This is minus the optimization to rotate rectangles to make better fits.
The old method had a problem with missing order numbers and aborted the level load and made many assumptions that no longer apply with BSP based polyobject rendering.
- NODISTANCE: Disables distance checking.
- CHECKSIGHT: The qualifying actor must be in sight in order to count.
- SET<TARGET/MASTER/TRACER>: Gets the first qualifying actor and sets the calling actor's specified pointer to it.
- SETONPTR: If the function is being aimed at another actor other than the caller, sets that actor's pointers instead. Requires a SET* flag to work.
- FARTHEST: The actor farthest from the checking actor is set as the pointer. Requires a SET* flag to work.
- CLOSEST: The closest qualifying actor is set as the pointer. Requires a SET* flag to work.
- major overhaul of the static sector damage system:
* consolidated special based damage, Sector_SetDamage and UDMF properties into one set of damage properties. The parallel handling that could lead to double damage infliction was removed. This also means that damage through sector specials can be retroactively changed through Sector_SetDamage.
* all special cases were turned into flags. The new system can switch between Strife's delayed damage and regular damage, and it can also set whether terrain splashes are used or not. It also has access to the special properties of the end-level type (i.e. switching off god mode and ending the level.)
* the damage related flags are accessible through Sector_ChangeFlags, not the damage functions themselves.
Since Eternity got this it's a good candidate for a potential Super-Boom standard, and it's also useful for silencing a sector temporarily without removing the sound sequence.
- moved sector secret information from sector_t::special and secretsector to two flag bits in sector_t::Flags.
This is to get rid of the bit masking madness in the floor/ceiling thinkers which need to preserve this bit when they change a sector's type.
- fixed: Sector_SetPortal's Eternity translation was not correct.
The ZDoom variant allows specifying the plane as part of the portal, Eternity does not. Added a new 'plane' type 3 which just means 'any'.
Native OS X backed didn't center mouse cursor in fullscreen mode with Retina/HiDPI support enabled
Incorrect size of content view led to placement of cursor in upper right corner of the screen upon releasing of mouse capture
When some action is assigned to this corner using system Hot Corners feature, the given action was triggered on acquiring mouse capture
* OPL: specify the core to use for playing this song
* FluidSynth: specify a soundfont that should be used for playing the song.
* WildMidi: specify a config file that should be used for playing the song.
* Timidity++: specify an executable that should be used for playing the song. At least under Windows this allows using Timidity++ with different configs if the executable and each single config are placed in different directories.
* GUS: currently not operational, but should later also specify the config. This will need some work, because right now this is initialized only when the sound system is initialized.
* all other: no function.
These options should mainly be for end users who want to fine-tune how to play the music.
- increased the valid range of patch values for MUS. According to the original MIDI2MUS code it can handle numbers up to 188, not 181, and at least one track from Eternal Doom uses #183.
According to blzut3, it looks like it is a byte followed by a variable length field. It can be any value 0-15 and will be followed by that many bytes one for each bank used. If the bank count is 0 then it is shorthand for using one bank (bank 0).
Based on evidence from several songs in Eternal Doom the description in all known documents is wrong. The instruments are not stored in a 16-bit word but in an 8-bit byte, followed by some variable size data.
Known variations are:
* second byte is 0 - no additional data follows
* second byte is 1 - a third byte for the 'bank' value follows.
The resize indicator overlapped with progress bar and Quit/Cancel button on 10.6 and older versions
OS X 10.7 and newer don't have this indicator at all
- Did anybody actually use this? Use WildMidi instead if you want
something that sounds more like Timidity++ without actually being
Timidity++, since not even the old Timidity manages that.
-- errno.h is required for 'errno';
-- don't use str(n)casecmp and rely on ZDoom CMake handling;
-- add a missing parenthesis around a 'signed char' cast;
-- remove an unneeded GNU_SOURCE redefinition;
-- the non-MSVC side of snd_mididevice was not adapted to the new code, making wildmidi unavailable through the menu.
- Besides being little-endian centric, this bit shifting madness
was unneccessary since the values were already clamped to a 16-bit
range, so all we need to do is cast them to a short.
- In order to use ZDoom's own MIDI sequencer event handling must be
completely separate from mixing, but WildMidi had them intertwined
because it wasn't designed for external sequencers.
- Also remove all 'long's defining the output buffers to avoid having
something that's 32 bits wide on Windows and 64 bits wide on Linux.
The pointless error message in WildMidi_Shutdown was removed to keep the rest of the code simple and allowing to call this even when the device never was used.
Unused high resolution font lumps broke composite font logic
Small font had doubled height because of that, at least alternate HUD and inter-hub text messages had noticeable visual issues
The code assumed that it had access to the texture manager but that gets initialized after MAPINFO, which means that MAPINFO can only store the texture names and let the precaching code resolve the actual textures.
- Checks to see if a certain actor class, in numbers, is close to the actor/pointer via distance, based upon count. Can check for ancestry, disable Z searching, perform less than or equal to instead of greater or equal to, exact counts, check a pointer instead of itself and differentiate between live monsters and dead.
As a side effect this will now allow using custom messages with this function as well by using the arg2 parameter as part of the message's name (arg2=0 will use TXT_COMM0, arg1 TXT_COMM1 and so on.)
- Now includes anglelimit and pitchlimit.
- Anglelimit and pitchlimit only allows the actor to turn this much, similar to A_FaceTarget's limit. FVF_RESETPITCH also respects the pitch limit.
- (offset, anglelimit, pitchlimit, flags, ptr)
- Changes the caller's angle and pitch according to the direction of velocity they're travelling.
- FVF_NOPITCH and FVF_NOANGLE disable changing of pitch/angle respectively and should be counted as mutually exclusive, or the function does nothing.
- FVF_INTERPOLATE - Interpolate's the angle and pitch changes.
- FVF_RESETPITCH will, if there's no z velocity, reset the pitch to 0. Otherwise, the pitch remains unchanged.
The previous version didn't detect some real mistakes in code which used operator& with the wrong flagset (for now 'converted' to the correcly equivalent counterpart, waiting for the proper fix).
...\src\g_shared\a_randomspawner.cpp(32): warning C4800: 'DWORD' : forcing value to bool 'true' or 'false' (performance warning)
See http://forum.zdoom.org/viewtopic.php?t=49737
