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.
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.
