This is guesswork, but it seems like the first channel always contains a
complete rendition of the music. I think that's intended for low-end
Macs, while the other voices (four, but the last one never seems to be
used) is the standard version of the music.
It doesn't sound particularly good, and also not quite as with Mini vMac
(I'm not fully prepared to rule out emulation problems), but it seems
reasonably close.
Before, ScummVM would only play ROL music if a MIDI-capable driver had
been selected. I have AdLib as default, which made it pick ADL music
instead and the Mac music player doesn't support that. So this is not a
new feature, it's just an old feature that's now applied consistently.
This fixes some missing music that might otherwise be missing in MI2,
most noticeably near the very end of the game. The ROL music is an
acceptable substitute, because the Mac instruments are close enough to
a subset of MT-32. I haven't seen any resources with both MAC and ROL
versions, so MAC should still be used when available.
Note that this doesn't seem to have been a ScummVM bug. The music was
missing when I tried the game in a Mac emulator too!
If another Mac version of MI2 is ever discovered, and its boot script
doesn't match any of the known ones, we can't know what the "skip copy
protection" boot param will do. Safer, then, to use the default boot
param. ScummVM may still skip the copy protection, but if so it will do
it the old-fashioned way.
There's still the matter of exactly when the text box should be created
(sometimes text is drawn to it in several steps, and we don't want to
erase the old text), and when/how to remove the box.
This is one of the players that has had problems with deadlocks
recently. I'm not very well versed in threaded programming, but arthxx
has promised to fix up some more players later. This one was used as
proof of concept because it deadlocks a lot.
The engine now measures whether it can perform one screen update within a 60Hz tick. Unfortunately the calls to OSystem::updateScreen() may take very long, depending on the backend and the filter setting. In this case the engine will start to catch up to the current frame. It should still look fine, unless the platform is way too slow for the selected filter setting (with the wrong settings it is not too difficult to achieve OSystem::updateScreen() durations of over 100ms).
("drawing" in this case means the data conversion and transfer from the gfx layers to the screen buffer)
From my measuring experiments in the MSVC debugger this speeds up the drawing 2 - 3 times. Not sure about release builds, whether these profit even more.
I have made the scrolling more smooth and still hopefully managed not to break the sync with the engine (which really is a bit tricky).
I've tested playing the ZAK and LOOM intros and also walking around in ZAK and MI2, since there are some good test cases there. I've also compared all these side by side with the UNZ emulator.
The main purpose of this set of changes is to refactor the code to make
it easier to pass the name of the Macintosh resource file to other parts
of the engine (it used to be hard-coded in the music players), and to
scale-up the graphics by 2.
The actual font rendering is almost completely broken.
This is mostly based on ZAK and MI2 disasm (and a bit LOOM). For MI1 and INDY4 I have at least checked with the FM-Towns UNZ emulator to ensure that they actually have the smooth scrolling.
The smooth scrolling is a bit tricky with regard to the timing. The scrolling tends to be a bit too slow for the engine, since it happens at a speed of 1 pixel per 60Hz tick, while the engine sometimes writes one or more new 8 pixel strips at the same time. So the scrolling often has to catch up to the engine. The original has a compensation mechanism which I tried to adapt. We'll see if it needs more fine tuning...
The Loom intro even glitches in the UNZ FM-Towns emulator due overflowing the scrolling surface (and causing a wraparound). But I made a fix for that.
Since we do have a bug report about the speed of the ZAK intro (and the new scrolling code does affect the timing) I have run the ZAK intro in ScummVM and in the FM-Towns UNZ emulator (with i80386DX, 16 MHz setting) side by side and they seem totally in sync. If I reduce the MHz setting in the emulator to 10 MHz on the emulator the intro will play slower, but still not play through the whole song. With 8 MHz I get close to finishing the song, but this seems to be almost to slow to run the game properly. So I'll leave that bug ticket open...
For each engine:
- Make a new folder detection
- Move detection-related files inside the folder
- Add a new module "enginename/detection"
- Add DETECT_OBJS here
- Adjust the normal engine module to remove detect_objs
- Adjust every file for the new changes.
- Move detection code used by createInstance & MetaEngine to a common header - detection_internal.h
- Move steam-related method & table to detection_steam.h
- More info in comments.
- Common: add wordWrap function to ustr.cpp
- Bladerunner: Explicitly state we have a U32String in subs (same as Subtitles::loadOuttakeSubsText)
- Don't use translations for engine specific "put strings", because they might not support.
- SCI: Use const references for showScummVMDialog
- SCUMM:
-- Don't use translation in md5 warning. left comments with the translated version.
-- Remove some redundant headers in help.cpp
-- Don't use translation in handleSaveload when printing to console
-- Also, display success transaction correctly via u32::format
- TESTBED: Use fake constructor when setting label of button
- SKY: Correctly use translation when using SaveStateDescription
- ULTIMA: Don't use translations when display_string
- ENGINES:
-- GenerateUnknownGameReport correctly, with proper translations.
-- There was an error, where a function had been declared twice, in a header file. Correct this.
Up until last commit, everything was working fine but the amount of files changed was too large. This commit tries to reduce the changes.
- Add a fake constructor to Keymap, text-to-speech, setDescription (save-state)
- Redirecting functions for PopUpWidget::appendEntry, ButtonWidget::setLabel, GUIErrorMessage
- Use the above functions and constructors to reduce changes in Engines
- Fix warnings being in unicode. Only output english text in - Warnings, Errors, etc.
- Mark some strings as "translation" strings. (Not yet added to POTFILES)
- Remove some CP related things from po/modules.mk
- Previously used some Common::convertToU32 where it was not necessary, replace this with u32constructor
- Revert accidentally put translations in mt32.cpp
- Use U32::format in some places earlier missed
- Add %u and %i for u32::format
- Add support for GUIErrorMsgFormat to use u32::format internally
- Use the above whereever needed
- Improve linux tts by removing redundant code
- Some places I had changed nullptr -> "". Revert this
After the initial changes just to scummvm/gui for u32, this commit includes the whole project
- Widget creations now always have u32 descriptions, labels, or tooltips
- Message dialogs make use of default arguments instead of providing the same argument explicitly
- encode String::format properly before passing on as argument where necessary
- Modify hugo utils (yesNoBox and notify box) to use u32
- Also provide fake constructors for the above which redirect to the u32 constructor
- Convert all keymap descriptions to u32 across all engines
- showConfirmationDialog in mohawk now uses u32
- showScummVMDialog also uses u32
- Scumm engine has dialogs now which use u32
- General fixes and wrapping convertToU32String for setLabels and related functions
- Add a fake constructor to MesssageDialog which redirects to the u32 constructor
- move mac, pc speaker and fm-towns ims sound drivers into separate directory
(AdLib and MT32/GM drivers are still too entangled with common code to be moved so easily, especially MT32/GM. It would require lots of changes to the common code and possibly to all engines using the MidiDriver class. So I leave that for now.)
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.
v5+ scripts can request saving/loading of savegames, this type of
savegame is internally called a "temporary" savegame
(_saveStateTemporary == true) which is invisible to the user (I'm not
sure whether this is by design or not).
Currently the savegame handling in scummLoop_handleSaveLoad() doesn't
distinguish between such temporary savegames and normal autosaves and
unconditionally resets _lastSaveTime (even after loading).
This has the unwanted side effect of potentially delaying the creation
of normal autosaves which are supposed to be created in accordance with
the autosave period setting in the GUI.
This commit makes sure that _lastSaveTime only gets updated if and only
if saving a (non-temporary) autosave.
