The first patch is a script patch for Ellinger's Tower Level 2
on the Dark Side. It fixes an incorrect index for a wall item
of a curtain that's meant to be removed
The original didn't allow loading during combat from it's
options dialog, and I'll leave that untouched, but the ability
to load out of a unwinnable combat is too convenient to not
allow in some form.
This first new option displays the effective cost of items
when viewing in the standard character inventory. This makes
it easier to compare the value (and thus relative power)
of items against either other
The later games stored them in resources, but Clouds of Xeen had
them hardcoded. So this adds them under the same resource names
as the later games, so the existing code can load them
The existing structure didn't make sense, as Sound only handled
sound files, but Music handled both music and short FX decoding.
I've merged Sound & MUsic into a single Sound class, and moved
the music driver to their own file, renamed to SoundDriver
Technically they do have voice samples, but the code for playing
them is indistinguishable from standard SFX. And given how few
they are, I feel it better for now to simply flag the detection
entries as no voice, rather than trying to separate them
Previously, I only had a single savefile, which maintains the
state of the party and mazes. But I've realised that I'll need
a separate archive for each side of Xeen. I'm still not entirely
happy with the cleanliness of the new structure, but it at least
is now functionally separating the sides.
Previously the game wasn't paying much attention to the access of
dark.cc vs xeen.cc, which was causing problems when trying to
travel to Dark Side. This is the beginnings of a refactoring
to more closely work like the original does
This flag is removed for a few reasons:
* Engines universally set this flag to true for widths > 320,
which made it redundant everywhere;
* This flag functioned primarily as a "force 1x scaler" flag,
since its behaviour was almost completely undocumented and users
would need to figure out that they'd need an explicit non-default
scaler set to get a scaler to operate at widths > 320;
* (Most importantly) engines should not be in the business of
deciding how the backend may choose to render its virtual screen.
The choice of rendering behaviour belongs to the user, and the
backend, in that order.
A nearby future commit restores the default1x scaler behaviour in
the SDL backend code for the moment, but in the future it is my
hope that there will be a better configuration UI to allow users
to specify how they want scaling to work for high resolutions.
Some strings are still in the base Resources, since they're referred
to by core dialogs. These may be able to be refactored in the future
as support is added for the other games
