* Changed from -1 - based constants to 0 - based constants;
* These were purely internal values, therefore no API would be harmed;
* Removed necessity of converting from internal mouse button code to script and back all the time;
* On a side note, this fixes a bug where WaitMouse etc were returning incorrect values on mouse skip, because we forgot to convert from internal to script code.
From upstream 471098d239b076c494beb2d554572ccb69372667
In order to specify that they should be treated as signed
Some ports may treat an (unspecified) "char" as unsigned by default. Android does this for its ARM architectures and while we did fix this by enforcing -fsigned-char to its compiler, the issue may come up for other ports. Also it should be better to clarify in the engine when a variable is not actually storing string characters.
I've spotted and changed the most "safe" cases I could find for this. As far as I can tell, out of these, only the Outline field and fontoutline array could potentially be assigned valid negative values which would cause bugs for ports treating chars as unsigned.
We now use a U32String for the savegame descriptions, but
the code was calling c_str() directly on it, and the uint32 pointer
was casted to a char pointer along the way. This resulted in only
the first character of the description being displayed on little
endian systems (and probably none on big endian systems since the
first byte would be 0 for ASCII characters).
This fixes bug #12869
From upstream 9d65a68c61d0503e05e2cbe80447af0d619161e4
Note that ScummVM doesn't have a TEXT_INPUT event, so this change and following
ones will be mostly to keep in sync with the standalone codebase even if they're
not directly used
The original interpreter sorts the savegame from the most recent
to the oldest. We don't have the savegame date in ScummVM, but
sorting by decreasing slot number should approximate this better
than using increasing slot numbers.
One of the issue was that we were listing the restart point
savegame (in slot 999), and it should not have been listed.
This caused a crash in the ags savegamedialog as it tried
to use the next slot, 1000, which is out of bound.
Changing this fixes bug #12386.
Another issue is that we could do out of bound writes due
to the AGS engine having to MAXSAVEGAMES define, one set to 20
and the other to 50. And in one place we were using the wrong
one.
Also specify a maximum save slot of 99. This is what the
original uses as it reserves higher slots for special purposes.
And finally do not use slot 999 for autosaves as it conflicts
with the slot used bu AGS for the restart point.