This greatly simplifies the display options and makes them more practical. Original resolution will try to fit the game to the screen pixel-to-pixel, and will revert to full screen if it fails. Keep AR maximizes height and adjusts the width accordingly. This works very well with 320x200 games (AR of 1.6) which is close to the PSP's 1.7, but not so well with 320x240/640x480 (AR of 1.3). Full Screen is still default.
svn-id: r52138
Found that the particular implementation was producing messy assembly for misaligned copies. Improved it and also fixed up wrapping the memcpy, which would cause endless prints in case memcpy testing is asked for.
svn-id: r51503
If a game CD has a scummvm.ini file with at least one game domain in
it, the normal autodetection is now bypassed and a menu of only the
games in the .ini file is presented instead. The descriptions of the
games are taken from the .ini file, but icons are still scanned for
in the old fashion.
Note that previously ScummVM would read global options from the
scummvm.ini file on the boot disc (if present), but now global options
are instead taken from the scummvm.ini on the game disc (in case of
a disc swap).
svn-id: r51480
Implement platform-specific variants of createConfigReadStream()
and createConfigWriteStream(), instead of inheriting the BaseBackend
definitions. Nonstandard behavious is as follows:
* createConfigWriteStream() always returns 0 (read-only filesystem)
* createConfigReadStream() returns an empty MemoryReadStream instead
of NULL if scummvm.ini does not exist. This is to make sure that
loadDefaultConfigFile() always clears out any old config data, as
I'll want to restart config parsing from scratch after a disc
swap.
svn-id: r51478
This should help avoid situations where MODULE_DIRS is not set to a
complete list of build dirs (which causes troubles with the automatic
header dependency detection logic).
On the long run, we should replace the relevant code by a macro or also
use rules.mk for this (with yet another if/else case add to it).
svn-id: r51467
Often, a client has more than one available port. Pick the first one
that isn't already in use. For instance, on my computer client 17 is
the "Emu10k1 WaveTable", and it has four available ports. If, say,
aplaymidi is already playing on port 17:0, ScummVM will use port 17:1
instead. Otherwise the two programs will mess up each others
instruments and controller settings.
Of course, in reality I doubt that anyone will run two different MIDI
playing applications at once.
svn-id: r51380
Bug #3025258: "Cursor Leaves Trail in GUI when Screen is Shaking". Based
on patch provided by eriktorbjorn but extended with another edge case.
svn-id: r51212
An #include was missing, causing the driver to never be built. Also fixed what
looked like a cut-and-paste error in generating the features string.
svn-id: r51056
* Added a yes/no variable _unix to configure, which controls when
-DUNIX is added to DEFINES
* Enable SEQ MIDI via _seq_midi by default on UNIX type systems,
except for those which override that.
* Switch SEQ MIDI code to check #define USE_SEQ_MIDI
(alternatively, we could compile it only conditionally...)
svn-id: r51055
This is also an attempt to make the transition from the old settings to the
new ones a little less rough, by trying to put something sensible into the
first device, which is what's used by default. Currently it prefers 17:x
and 65:x since they're the old defaults, followed by 128:x since that's
probably TiMidity.
The old SCUMMVM_PORT environment variable still overrides any config
settings. I haven't made up my mind whether or not that's a good idea, but
at least it prints a warning message.
TODO: The old 'alsa_port' setting is not handled. It should probably be
used to set sensible defaults for the new settings, but I'm not sure where
this should be done.
TODO: The documentation will need to be updated, once everything is working
the way it should.
svn-id: r51019
We should probably open the sequencer the exact same way, both when
opening the driver and when asking it for available MIDI devices. Not
that I've been able to figure out the difference between "hw" and
"default" from the fine ALSA manual...
And I'm not sure we really need to try and keep compatibility with
ancient (pre-0.9.0?) ALSA any longer...
svn-id: r51014
Previously, the code in OSystem_SDL::detectSupportedFormats
assumed that the arrays RGBList and BGRList had the exact
same length, and that the entries in each mirrored those in
the other 100%. Instead of relying on that, the code now
simply iterates over both lists separately. This changes the
resulting order a bit, but since we never gave any
guarantees on that, this should not matter.
svn-id: r50833
* Do not use global constructor for the RGBList and BGRList
tables anymore, by moving them inside a function.
* Update the list of supported formats if the hardware
screen surface changes. Previously, the list of supported
pixel formats (and its order) was computed only once and
then never changed.
svn-id: r50832
Andre Heider
Yotam Barnoy
Max Horn
Lars Persson
Fabio Battaglia
Marcus Comstedt
Torbjörn Andersson
Johannes Schickel
Angus Lees
Eugene Sandulenko
Willem Jan Palenstijn