Age | Commit message (Collapse) | Author |
|
forum post 29/7/10
svn-id: r51567
|
|
svn-id: r51558
|
|
svn-id: r51556
|
|
svn-id: r51555
|
|
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
|
|
svn-id: r51474
|
|
svn-id: r51473
|
|
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
|
|
svn-id: r51466
|
|
svn-id: r51465
|
|
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
|
|
This keeps ScummVM's own port from being included in the list of
available MIDI devices.
svn-id: r51378
|
|
Thanks to eriktorbjorn for some quick testing.
svn-id: r51366
|
|
the main ScummVM codebase thanks to fingolfin :)
svn-id: r51362
|
|
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
|
|
svn-id: r51203
|
|
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
|
|
svn-id: r51053
|
|
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
|
|
svn-id: r50989
|
|
svn-id: r50982
|
|
svn-id: r50981
|
|
svn-id: r50980
|
|
svn-id: r50964
|
|
ScummVM from crashing if, for instance, someone accidentally closes the driver
twice.
svn-id: r50870
|
|
svn-id: r50844
|
|
svn-id: r50835
|
|
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
|
|
clean'
svn-id: r50745
|
|
This parallels what I did in ds.mk
svn-id: r50744
|
|
svn-id: r50743
|
|
svn-id: r50742
|
|
* remove (S)RAM save code (it has not been in use for quite some time)
* remove the lz compressor (was only used by ram save code)
* OPT_SPEED was set incorrectly
* dsmain.cpp was misspelled as ds_main.cpp
* remove unsed arm9 libcartreset (the copy in the arm7 directory
still is around, though)
svn-id: r50741
|
|
svn-id: r50736
|
|
svn-id: r50729
|
|
svn-id: r50728
|
|
svn-id: r50727
|
|
svn-id: r50709
|
|
svn-id: r50708
|
|
svn-id: r50702
|
|
svn-id: r50701
|
|
svn-id: r50694
|
|
* Do not modify the strings passed to std_fopen anymore
* Correct signature of std_fread
* Do not cast away constness, nor perform unnecessary casts
svn-id: r50693
|
|
svn-id: r50692
|
|
svn-id: r50691
|