Consolidated kSetShowStyle version/argument checks and updated them to
handle SCI2.1 Mac games and PC demos. (The demos where the wrong
arguments were being applied happened to work anyway.)
Fixes LSL7 Mac pixel dissolve at the start of the game between the
postcard and the boat (rooms 120 and 130)
- 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.
- Where necessary as in, where translated messages are used.
- GUIErrorMessage now takes in U32String
- error messages across some engines use U32Strings. they are changed because they show a message dialog.
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
This avoids an issue with MSVC where if (non-SCI) "graphics/font.h" is
included through another include file from the SCI engine root, it finds
"sci/graphics/font.h" first and uses that instead.
Implements kInputText, which displays a black and white utility dialog
with a title and a text box in a fixed position using the system font.
The only known game that uses this is Phantasmagoria 2 for several
easter eggs, which now work. This was probably used by internal scripts
during game development.
kEditText and kInputText share a function in Sierra's interpreter for
processing events, so that code has been factored out and placed in
GfxControls32::processEditEvent().
GfxText32 can now measure text pixel height as SSCI did by identifying
the tallest character height in the current text, which the newly added
titled font bitmap code requires.
Fixes bug #10570
This removes the unnecessary Buffer subclass and stops most places
where the output buffer was being interrogated about dimensions
instead of GfxFrameout.
* Use containers where appropriate
* Re-wrap doxygen comments to 80 columns
* Clarify comments for parts of the engine that are understood now
but were not understood at the time of the initial
implementation
In SCI3, Sierra removed the ability of the main renderer to
automatically scale CelObjs with different source resolutions.
Instead, in SCI3, all CelObjs are treated as having the same
resolution as the screen (i.e. 640x480).
In all SCI3 games other than RAMA, keeping the code paths for
resolution-dependent scaling is not a problem because all the
assets and game code are correctly designed to use the same
640x480 resolution throughout. RAMA, on the other hand, was
written with the text subsystem set to a resolution of 630x450
(Phant1's screen resolution), and in SSCI, resolution-dependent
scaling code was not removed from the *text* subsystem. As a
result, RAMA's game scripts rely on the slightly larger scaled
dimensions coming out of the text system when determining the size
of screen items for rendering, and then also rely on the main
renderer ignoring the 630x450 resolution baked into the bitmaps
generated by the text subsystem when drawing them to the screen.
In SSCI, mouse events are received through a hardware interrupt
and the cursor is drawn directly to the graphics card by the
interrupt handler. This allows game scripts to omit calls to
kFrameOut without stopping the mouse cursor from being redrawn
in response to mouse movement.
ScummVM, in contrast, needs to poll for events and submit screen
updates explicitly from the main thread. Submitting screen updates
may block on vsync, which means that this call should really only
be made once per frame, just after the game has finished updating
its back buffer. The closest signal in SCI32 for having completed
drawing a frame is the kFrameOut call, so this is where the
update is submitted (by calling OSystem::updateScreen).
The problem with the approach in ScummVM is that, even though the
mouse position is being updated (by calls to kGetEvent) and drawn
to the backend's back buffer (by GfxCursor32::drawToHardware),
OSystem::updateScreen is never called during game loops that omit
calls to kFrameOut.
This commit introduces a workaround that looks at the number of
times kGetEvent is called between calls to kFrameOut. If the
number of kGetEvent calls is higher than usual (where "usual"
seems to be 0 or 1), we assume that the game is running one of
these tight event loops, and kGetEvent starts calling
OSystem::updateScreen until the next kFrameOut call. We also
then start throttling the calls to kGetEvent to keep CPU usage
down. This fixes at least two such known loops:
1. When interacting with the menu bar at the top of the screen
in LSL6hires;
2. When restoring a game in Phant2 and sitting on the "click mouse"
screen.
A similar workaround may also be needed for kGetTime, though loops
around kGetTime should preferably be replaced using a script patch
to call kWait instead.
Sometime during SCI2.1mid, the palette manager was changed to
save and restore the source palette, and to add in-game gamma
correction. Previously, only the vary start and target palettes
were saved, and gamma correction was only configurable in SSCI by
editing RESOURCE.CFG.
In GK2, restoring a save game causes the segment manager to reset
in the middle of a kListFirstTrue call, which invalidates all
pointers and reg_ts to stored data. This means that when
kListFirstTrue tries to decrement the list recursion counter at
the end of iteration, it is writing to freed memory, potentially
resulting in heap corruption.
SCI3 added checks to prevent this from happening, but these checks
seem like they should have also been applied to some SCI2.1 games
as well (like GK2).
Since there should be no negative side-effect to this check, it
is applied universally to all SCI32 games.
Game scripts pass an extra argument which is never used in SSCI.
This happens e.g. when warping from room 620 to room 860 in
LSL6hires.
Adding a signature for kPalVarySetVary for SCI2.1early games only
does not work because KQ7 1.51 is detected as SCI2.1early but the
interpreter includes kPalVary code that matches SCI2.1mid.
Fixes Trac#9611.
This change invalidates earlier SCI32 save games, which separated
arrays and strings in an incompatible manner. Old save games
contain invalid references to a string segment which no longer
exists, and contain incompatible array structures that lack
critical type information.
These were introduced in SCI3, and are used by RAMA. We don't preload
videos, so we don't really need kPlayVMDSetPreload, but
kPaletteSetGamma may need an implementation.
With these two stubs, the main menu of RAMA is working again
On at least DC platform, the ShowStyleType enum is fit to a 4-bit
data size, so the 16-bit input value needs to be checked for
validity *before* it is cast to a 4-bit ShowStyleType.
This may come back in the future to deduplicate some gfx code,
but SCI32 had two different inlined ways of doing coordinate
conversions with different rounding methods, so CoordAdjuster32
didn't get used when the graphics system was rewritten.
At the moment, SCI32 code uses the mulru/mulinc methods from
helper.h for scaling up/down coordinates.
KQ7 2.00b, PQ:SWAT, Phant1, GK2, and Torin are all verified as
using the 'ignore' variant; SQ6 and QFG4CD are verified as using
the 'fail' variant. MGDX and Shivers could not be checked as they
have only Phar Lap Win16 executables, so took a guess based on
their release dates.