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.
- Multi-directory archives (e.g. zips) now support filtering lumps
depending on the loaded IWAD. The search rules are the same as for the
Autoload entries in the user's ini. For instance, if you are playing
Doom 2, the following filters will be applied:
* "filter/doom2/*"
* "filter/doom/*"
They will be renamed to strip out the "filter/doom2/" and "filter/doom/"
parts and will be ordered so they take precedence over any files not
inside a filter/ directory. Any files inside another filter/ directory
(e.g. "filter/hexen/*") will be ignored.
- Fixed: Using +set cvarname and +cvarname on the command line would not
work if cvarname was defined in CVARINFO. This should be the proper way to fix
it. Rather than move all command line execution after loading CVARINFO,
keep command line execution before wads are loaded. If an attempt is
made to set an unknown cvar or to run an unknown command (which could
potentially be shorthand for setting an unknown cvar), save it and try
running it again after all CVARINFOs have been handled.
Even when '+logfile' argument was omitted, the console would print 'Could not start log', because 'logfile != NULL' was used as a check for the presence of '+logfile' argument, but the internal buffer of FString is never NULL, so the right check is 'logfile.isNotEmpty()'.
While I'm at it, I fixed another bad check for 'pagename'.
- added version check for Windows 8. I also would have liked to add 8.1 but due to some incredibly stupid changes in the version API it's no longer possible to reliably retrieve the correct Windows version for later builds.
- Command-line console commands are executed before a level is entered, so
trying to use +warp to position yourself at a specific location will not
work. We now specially handle this command so that it does work.
- Fixed: You could not set any CVARINFO-defined cvars from the command line
because command line console commands were executed before wads were
even loaded. Off the top of my head, I can't think of anything that would\
break by having them get executed after wads are loaded.
