Recent GCC versions complain if you memset() a class or struct that
contain non-POD data types. Get around that by either initializing
the object when created, or by adding a reset() method.
These were broken by the last PR merge which included a cpp file in a
way which will not build reliably. This splits the Accolade MIDI driver
structure definitions into headers allowing these to be included
instead.
Also, minor cleanup by removal of unused header includes.
Since 'filename' is 'baseName', plus a file extension, make the
'filename' buffer larger than the 'baseName' buffer. Even though
this almost certainly means that the 'filename' buffer is now
quite a bit larger than it needs to be, I don't think there's any
reason to quibble about it.
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.
In commit f0581bab4a4b1b4102a7fbdd4a3d54d4397e00e9 the index value
for the array was changed from a constant to a variable, but uint8
is too small to contain 293, so this value was ending up as 37.
Added it into hasFeature() of all engines which returned `true` in
simpleSaveNames() before.
As mentioned in #788, SCI is not always using simple names, so it
doesn't have such feature now.
Engines with "simple" savenames would support "Run in background" in
save/load dialog and gradual save slots unlocking. Other engines
save/load feature would be locked until save sync is over.
GCC 6's -Wmisleading-indentation warns about the debugC() statement
being wrongly indented, as if belonging into the else's branch, which
it clearly doesn't.
Engines should only have to call one set of functions and not decide between the two. In fact, the 'emulation' API was documented to just call the 'real CD' API.
Some backends like GCW0 do no support graphics >320x240 due to
the hardware limitation (downscaling is possible but it will ruin
the pixel hunting which is often part of the gameplay).
Instead of manually updating the list of engines, we now introduce
a new dependency.
I marked all relevant engines, but some, like tinsel, require more
work with putting their relevant high-res games under USE_HIGHRES
define.
