Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
go negative
|
|
|
|
|
|
|
|
|
|
We no longer use SharedPtr
|
|
|
|
using getFrameData()
|
|
|
|
|
|
|
|
|
|
methods internally.
Rather than creating an instance of MouseEvent and passing argument around.
|
|
every process()
|
|
|
|
|
|
SharedPtrs
|
|
|
|
This is consistent with scanString(), and I have verified that the
included test cases still work.
|
|
|
|
|
|
|
|
As suggested by LordHoto.
|
|
|
|
This also fixes bug #3361925 - "SCI: HOYLE4: Crash in bridge"
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
replace magic values by constant
|
|
GUI: Various GUI Improvements
|
|
|
|
|
|
Formerly, the behavior between when a drawable area was specified and when not
was different in a sense which is not expected. For example, when an empty
textDrawableArea was passed and the text could be drawn outside the 'area'
specified. While when a textDrawableArea covering the whole screen was passed
the text was clipped inside 'area'. Now, the code does follow the latter logic
in both cases.
I am not sure whether this will cause any issues, but a quick check of the
launcher and options menu didn't reveal anything...
|
|
This removes the two additional copy steps for rendering when a drawable text
area is specified. Instead it uses Surface::getSubArea to draw directly onto
_activeSurface.
|