Needless to say, this is simply too volatile and would require constant active maintenance, not to mention a huge amount of work up front to get going.
It also hid a nasty problem with the Destroy method. Due to the way the garbage collector works, Destroy cannot be exposed to scripts as-is. It may be called from scripts but it may not be overridden from scripts because the garbage collector can call this function after all data needed for calling a scripted override has already been destroyed because if that data is also being collected there is no guarantee that proper order of destruction is observed. So for now Destroy is just a normal native method to scripted classes
- allow recursive linking of $random definitions (as long as they do not link back, see above.)
- fixed the sound precaching which did not handle $alias inside $random. Normally this went undetected but in cases where the random sound index was the same as a sound index in the current link chain this could hang the function.
The only reason this even existed was that ZDoom's original VC projects used __fastcall. The CMake generated project do not, they stick to __cdecl.
Since no performance gain can be seen by using __fastcall the best course of action is to just remove all traces of it from the source and forget that it ever existed.
* 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.
- Move MUSINFO change request out of FLevelLocals and into player_t. This
allows the MusicChanger actors to change music for each player
independantly. This is similar to PrBoom+, which switches depending on
the displayplayer. The difference being, we don't actually track the
music other players are listening to. (Which might not be a bad idea to
implement at some point.)
- Moved a few fields in player_t for better packing.
- move D_LoadWadSettings to keysections.cpp.
- made some more data reloadable.
- data structures filled by P_SetupLevel should be cleared before loading the level. They can remain non-empty in case of an error. There's probably more to fix here...
- fixed: MidiDevices and MusicAliases were not cleared before reloading local SNDINFOs.
- fixed signed/unsigned warnings in AddSwitchPair for real (GCC really allows -1u? MSVC prints a warning for that.)
SVN r3036 (trunk)
* savegames stored an index in the switch table and performed no validation when loading a savegame.
* setting of a random switch animation duration was broken.
* separated the 2 values stored in the Time variable into 2 separate variables.
* defining a switch with one texture already belonging to another switch could leave broken definitions in the switch table.
- added function for serializing switch and door animation pointers.
- bumped min. savegame versions due to changes to DButtonThinker and removed all current savegame compatibility code.
SVN r3030 (trunk)
- changed all parsers that check for the current game to use the same function for the game check.
- fixed: The TEAMINFO parser handled 'game Any' incorrectly.
SVN r2934 (trunk)
- Was there any reason why the MIDI_GUS device was so well hidden from the user? It sure does not sound broken. Added it to MIDI menu and $mididevice.
SVN r2862 (trunk)
way MP3 obfuscates custom tags. Vorbis and FLAC are fine. (I could make it work with MP3,
but you should be using Vorbis instead.) They are:
* LOOP_START: Start time for the loop. If omitted, the song repeats from the beginning.
* LOOP_END: End time for the loop. If omitted, the song loops at the end. (If you need to specify this, why aren't you using a shorter song.)
You only need to specify one of these tags to set the custom loop. Naturally, you can set
them both, as well. The format for each tag is the same:
* If it contains a colon (:), it specifies by time. This may be of the form 00:00:00.00
(HH:MM:SS.ss) to specify by play. Various parts may be left off. e.g. To start the loop
at 20 seconds in, you can use ":20", 0:20", "00:00:20", ":20.0", etc. Values after the
decimal are fractions of a second and accurate to one millisecond.
* If you don't include a colon but just have a raw number, then it's the number of PCM
samples at which to loop.
* Any characters other than digits (0-9), colons (:), or a single decimal point for the
seconds portion will result in the tag being ignored.
SVN r2424 (trunk)
