As we don't reconfigure all shaders without shadows when we disable them
indoors (as it'd probably add a hitch to transitioning in and out) we
need to set up dummy state so the shaders don't do anything illegal.
This hadn't had symptoms for most objects as when indoors, nearly
everything would be drawn first in one of the water RTTs, which had
dummy state to disable shadows already. This wasn't true of the water
plane itself, though, yet somehow it took until just now for anyone to
report that.
This resolves vtastek's issue where the water would be invisible indoors
This should fix the issue where Windows Release builds (compiled as
/SUBSYSTEM:WINDOWS instead of /SUBSYSTEM:CONSOLE) can't have their
output redirected.
Basically, a console application creates a console if not given one, so
you get a console window behind OpenMW while it's running. It was
decided that this was ugly, so we set Release builds to be windows
applications, which don't get an automatic console and don't
automatically connect to a console if given one anyway.
Of course, we still wanted to actually be able to print to a console if
given one, so we manually attach to the parent process' console if it
exists, then reopen the standard streams connected to CON, the Windows
pseudo-file representing the current console.
This is a little like connecting a second wire into a dumb terminal in
that you're pumping characters into the display rather than onto a
pipeline, so output can't be redirected.
It turns out, though, that if a /SUBSYSTEM:WINDOWS application has its
standard streams redirected by the calling process, it still gets its
handles as normal, so everything starts off connected just how we want
it and we were clobbering this good setup with the straight-to-console
fix.
All we need to do to fix that is check if we've got valid standard
handles and that they go somewhere useful, and if so, avoid reopening
them once the console is attached. Simples.
This resolves a regression where the local openmw.cfg doesn't exist, so
we fall back to the global openmw.cfg, but because we've not loaded
anything from the local openmw.cfg, there are no variables with which to
merge.
These would only take their value from the highest priority source, so
specifying `openmw --content anExtraEsp.esp` would override all the
content files in the user cfg file, and the user cfg file would override
any in the global/local one.
Before movement calculation, the main thread prepare a
vector of ActorFrameData, which contains all data necessary to perform
the simulation, and feed it to the solver. At the same time it fetches
the result from the previous background simulation, which in turn is
used by the game mechanics.
Other functions of the physics system (weapon hit for instance)
interrupt the background simulation, with some exceptions described
below.
The number of threads is controlled by the numeric setting
[Physics]
async num threads
In case 'async num threads' > 1 and Bullet doesn't support multiple threads,
1 async thread will be used. 0 means synchronous solver.
Additional settings (will be silently switched off if async num threads = 0)
[Physics]
defer aabb update
Update AABBs of actors and objects in the background thread(s). It is not an especially
costly operation, but it needs exclusive access to the collision world, which blocks
other operations. Since AABB needs to be updated for collision detection, one can queue
them to defer update before start of the movement solver. Extensive tests on as much
as one installation (mine) show no drawback having that switched on.
[Physics]
lineofsight keep inactive cache
Control for how long (how many frames) the line of sight (LOS) request will be kept updated.
When a request for LOS is made for the first time, the background threads are stopped to
service it. From now on, the LOS will be refreshed preemptively as part of the background
routine until it is not required for lineofsight keep inactive cache frames. This mean
that subsequent request will not interrupt the background computation.
