This was done to ensure it can be properly overridden in scripts without causing problems when called during engine shutdown for the type and symbol objects the VM needs to work and to have the scripted version always run first.
Since the scripted OnDestroy method never calls the native version - the native one is run after the scripted one - this can be simply skipped over during shutdown.
The original implementation just printed a mostly information-free message and then went on as if nothing has happened, making it ridiculously easy to write broken code and release it. Changed it to:
* Any VMAbortException will now terminate the game session and go back to the console.
* It will also print a VM stack trace with all open functions, including source file and line numbers pointing to the problem spots. For this the relevant information had to be added to the VMScriptFunction class.
An interesting effect here was that just throwing the exception object increased the VM's Exec function's stack size from 900 bytes to 70kb, because the compiler allocates a separate local buffer for every single instance of the exception object.
The obvious solution was to put this part into a subfunction so that it won't pollute the Exec function's own stack frame. Interesting side effect of this: Exec's stack requirement went down from 900 bytes to 600 bytes. This is still on the high side but already a lot better.
- instead add a list of SpecialInits to VMScriptFunction so this can be done transparently when setting up and popping the stack frame. The only drawback is that this requires permanent allocation of stack objects for the entire lifetime of a function but this is a relatively small tradeoff for significantly reduced maintenance work throughout.
- removed most #include "vm.h", because nearly all files already pull this in through dobject.h.
* everything related to scripting is now placed in a subdirectory 'scripting', which itself is separated into DECORATE, ZSCRIPT, the VM and code generation.
* a few items have been moved to different headers so that the DECORATE parser definitions can mostly be kept local. The only exception at the moment is the flags interface on which 3 source files depend.
- _FPU_GETCW is defined for more than just x87. Don't use it if the
control word for the target architecture doesn't support _FPU_EXTENDED
or _FPU_DOUBLE defined, e.g. pretty much anything but x87. If I had been
using glibc on PowerPC instead of Apple's libc, I probably would have
noticed this sooner, since _FPU_GETCW is part of glibc.
- handle a 'restart' CCMD a bit more controlled. Instead of throwing an exception in the CCMD handler it now just flags D_DoomLoop to return.
If the exception is thrown within the CCMD this can easily happen deep inside the renderer when it calls NetUpdate. But since the software renderer with its use of global variables is not equipped to be yanked out of lile this it could leave broken data behind that caused glitches or even crashes on subsequently played maps.
This cuts down on as much message noise as possible, outputs everything to a file specified as a parameter and then quits immediately, allowing this to run from a batch that's supposed to check a larger list of files for errors.
Multiple outputs get appended if the file already exists.
- This isn't a real file or even a name, but the game would try and load
it, including running through various permutations, potentially resulting
in loading the current directory as an archive.
This requires quite a bit more thorough cleanup. I got it to the point where the titlepic appears after restarting, but it still crashes when starting the game so there's more data that needs to be cleaned up...
Conflicts:
src/p_mobj.cpp
(This stops right before moving the conversation IDs into MAPINFO because that feature is quite conflict-heavy and will have to merged by itself.)
Conflicts:
src/d_main.cpp
src/info.cpp
src/p_local.h
(Had to merge this all by itself because it was creating too many merge conflicts when combined with other stuff.
UpdateSounds will not be called during screen wipes and the entire setup of this function suggests that this is not advisable at all.
The OpenAL stream updates were done deep inside this function implicitly.
This caused music to stop while a wipe was in progress. So in order to allow uninterrupted music playback during screen wipes the music updates need to be handled separately from sound updates and be called both in the main loop and the wipe loop.
I think that the OpenAL music updating should be offloaded to a separate thread but at least it's working now without causing interruptions during wipes.
- Old mess:
* Execute autoexec files right away.
* Execute -exec files right away.
* Execute command line commands right away.
- If, during any of the above, an unknown command or a set of an
unknown variable is encountered, store it for later.
- Pullin commands are directly executed and add to the list of files
to load.
* Do a little setup, including parsing CVARINFOs.
* Retry saved commands in case CVARINFO added a cvar they refer to.
- New, less messy, mess:
* Parse autoexec files into an array.
* Parse -exec files.
* Parse command line commands.
- During all of the above, exec commands are also parsed into the
array immediately rather than being saved for execution later.
- Pullin commands are parsed into a different array. The pullin
command doesn't actually do anything directly anymore.
* Add all the pullin files to the list of files to load.
* Do a little setup, including parsing CVARINFOs.
* Execute every command that was parsed in the preceding steps.
This has an important implication:
Previously the config was loaded before IWADINFO so in order to allow the config to access the data this had to be switched around.
This means that zdoom.pk3 will not be looked for in the global IWAD search paths anymore, but since it shouldn't be there to begin with it should be an acceptable compromise.
As a result the old 'Group' property could be removed and all other means to get a section name were disabled.
As an example, if the code gets 'doom.doom2.commercial' it will use the following sections in this order:
global.autoload
doom.autoload
doom.doom2.autoload
doom.doom2.commercial.autoload.
