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
- 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 was particularly an issue when the game had been saved in
chapter 1 as in this case the load would happen too early and
the game would crash. In other cases it was working but was
not optimal (the gane loop was run once before it succeeded
to load the game).
This fixes bug #10959.
This reverts commit bf69b25e33189581848412e77624865aa55ba234.
The original game had slight differences between the code for each
chapter. Part of these changes was to simplify the code and unify
some of these differences, particularly in the checks for clickable
areas, where the code is using Common::Rects with contains() now.
I have play tested the whole game with these changes, there are no
visible regressions, and the game is still completable. Thus, I'm
restoring the changes to the engine.
This reverts
1f1d8607 DRASCULA: Merge the floor coordinates into _walkRect
1e1b6f7c DRASCULA: Rename gotoObject() to walkToPoint() and simplify it
2bf05c2a DRASCULA: Clean up room variables, and simplify some related checks
Reverting due to unanswered questions about why the changes in behaviour
in 2bf05c2a746065f373ac136c994714dae376cdbc are correct.
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.
I don't see any purpose to this delays and they were not present in
the original engine. It works fine without those and the interface
seems more responsive.
This fixes bug #7121 DRASCULA: Delay and freeze when pressing
right mouse click on game
Also move a delay when left clicking to after performing the action.
With the delay between the left click and the action, the mouse
position could have moved when performing the action, resulting
in the wrong action being performed (e.g. activating the wrong verb
or picking the wrong object in the inventory). But removing the
delay altogether causes flickering when picking objects from the
inventory.
The delay, since it updates the mouse position, resulted in a
different verb being selected than the one we clicked on when
moving the mouse quickly after the clic. This was quite confusing
and frustrating. I can't see any reason for this delay and it seems
to work well without it. The initial commit adding it indicates this
was "for better mouse response", but it added a lot of other delays
at the same time, and removing this one doesn't see to impact the
mouse response (on the contrary, we get the new cursor quicker).
To time animations the original engine uses interrupt to get the
Real Time Clock and divides the number of clock ticks by 0.182.
Since there is approximately 18.2 ticks per second, this means
it uses values in 1/100th of a second. In ScummVM we were using
getMillis() / 20, so the animations was two times slower than in
the original.
This might fix bug #7115 Drascula: FPS are incorrect or some
frames are dropped.
Note that for the walk animation we are still not exactly using the
timing of the original. The original engines keeps each walk frames
for 5.7 times 1/100th of a second (i.e. 17.54 FPS). In ScummVM
getTime returns an integer value and as a result each walk frame is
now kept for 6 times 1/100th of a second (i.e. 16.67 FPS, which i
better than the 8.33 FPS we were getting before this commit).
as our getTime returns integer values and thus we use
frames for 6 of 1/100th of a second while the original is slightly
faster as it kept frames for 5.7 times 1/100th of a second.
This was a regression from commit fa3d3e3 and this fixes part of
bug #7113 DRASCULA: Serious sprite glitches.
The original uses extraSurface to draw text in draw_abc() in the
Spanish version while other languages use tableSurface. But in
ScummVM this was changed to use tableSurface for all languages.
However this caused an issue in chapter 6 when displaying the
inventory has it is also using tableSurface, as it was for all languages
in the original. While using the same surface works for other
languages, in the Spanish version we get the wrong background in
the inventory.
Rather than revert to using extraSurface for drawing text which is
a big change and impact all the chapters, I have opted to simply
swap the usage of the tableSurface and extraSurface in chapter 6
for the Spanish version compared to the original engine. The
changes therefore only impact chapter 6 and only the Spanish
version. I played the chapter in full to check that it indeed works
without causing adverse effects.
The previous fix only fixed the incomplete state when loading from
the launcher. Now this is fixed when loading from the game as well.
It also fixes loading a savegame from the first stage of the pendulum
scene (when the protagonist is not visible) to any other scene in
chapter 6. The protagonist was not made visible again when loading
the savegame.
Room 102 has two states. The first one has an animation of a
pendulum while the protagonist is chained to a table beneath it.
The second state is after the protagonist free himself. In the second
state the pendulum has stopped. When saving in the first state,
loading the save game did not properly setup the pendulum
animation causing graphic glitches.
This fixes bug #7113 DRASCULA: Serious sprite glitches
Engines should only have to call one set of functions and not decide between the two. In fact, the 'emulation' API was documented to just call the 'real CD' API.
The music add-on packs we provide have the audio files in an "audio"
folder, but without clear indication that its contents should be
copied inside the game data folder. Since this can lead to confusion
from users, we just add support for this case
