Age | Commit message (Collapse) | Author |
|
* Rewrap comments to 80 columns
* Clarify comments where possible
* Use smart pointers where appropriate
* Change view/pic flags detection to always use word-size
(byte-size check for flag 0x80 was a compiler optimisation)
|
|
* Rewrap comments to 80 columns
* Clarify comments where possible
* Fix whitespace errors
|
|
|
|
* Rewrap comments to 80 columns
|
|
* Rewrap comments to 80 columns
* Clarify comments where possible
|
|
* Rewrap comments to 80 columns
* Clarify comments where possible
|
|
* Rewrap comments to 80 columns
* Clarify comments where possible
|
|
* Rewrap doxygen comments to 80 columns
* Swap public/private sections so public APIs come first
* Clarify comments where easily possible
|
|
* Rewrap comments to 80 columns
* Clarify comments where appropriate
|
|
* Rewrap doxygen comments to 80 columns
* Renamings for clarity
* Deduplicate copy/paint code
|
|
* 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
|
|
* Rewrap comments to 80 columns
* Clarify comments where possible
* Use smart pointers where appropriate
|
|
* Replace raw pointers with smart pointers
* Use references instead of const pointers where appropriate
* Tweak initialisation
* Tweak palette copies to the stack
|
|
screen items in last-ditch sort
Fixes Trac#10257. Fixes Trac#10261.
|
|
Fixes Trac#10252.
|
|
Fixes Trac#10251.
|
|
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.
|
|
|
|
Convert macros and vars to enums, rename keyboard events in
preparation for adding key up events, clean up unnecessary nested
conditionals, add TODOs for potential future work.
|
|
|
|
This code is currently untestable and is almost certainly at least
partly based on guesswork & not actual reverse-engineering (as was
the case for all other pre-2015 SCI32 code), so future developers
interested in adding SCI32 Mac support should use it only as an
intermediate reference rather than as known good code.
|
|
|
|
|
|
This is used by RAMA in room 6201, after eating the alien fruit.
|
|
In a couple of places, Lighthouse updates the renderer with screen
items for the next room before the room transition video plays.
This is normally fine when using the compositing video renderer
because the videos are drawn into new planes which occlude the
screen items, so the screen items are culled from the draw list
and do not submit their palettes. However, when in HQ video mode,
we currently force the overlay renderer, which was not blocking
screen items before forcing a frameOut, so the screen items'
palettes got submitted prematurely in this case and caused bad
rendering after the video finished playback.
Now, if we are forcing into the overlay code path, we still create
a blank plane behind the overlay before the forced frameOut in
order to correctly occlude screen items and keep them from
participating in rendering before they normally would.
Fixes Trac#10233, Trac#10235.
|
|
|
|
|
|
This improves the behaviour at the end of PQ4 when navigating the
warehouse with the flashlight by getting rid of mouse events that
may have been queued before the mouse warp to the other side of
the screen is performed. Without this, frequently, those extra
events would then be processed and cause the mouse to jump back to
the opposite side of the screen, triggering another navigation in
the opposite direction.
This patch really only helps when mouse capture is enabled in
ScummVM as well, but it does allow the sequence to be played
pretty much normally in that situation. Additional (pending)
patches to ScummVM itself are needed to move the mouse to the
correct place when mouse capture is off and the system mouse moves
outside of the game window.
Refs Trac#9689.
|
|
Now it says "BOTH", just what the button in SQ4 says as well.
|
|
Now those say "BOTH", just what the button in SQ4 says as well.
|
|
This fixes overlapping of the left arrow in all cases, but the
scroll delta and initial offset of inventory items will only be
fixed in new games because the affected objects are global objects
whose bad properties get persisted into save games.
Fixes Trac#10037.
|
|
OpenGL backends don't always support the pixel format that is
returned by the Indeo 3 decoder when playing the GK2A.AVI from the
GK2 demo. If this happens, use the backend's preferred pixel format
and convert in software.
If a backend doesn't support any 16-bit or 32-bit format, the
playback code will error out. This is probably fine, since there
are not really any of those any more.
Fixes Trac#9994.
|
|
|
|
|
|
|
|
|
|
This is needed for 8.VMD in Lighthouse (room 380, the credits
room), which is rendered partially off the bottom of the screen.
OSystem does not accept rects that are offscreen.
Technically this video probably should not have been doubled
vertically by game scripts, but there is not enough space to fix
the rendering with a regular script patch, and it is a very
unimportant video.
|
|
kCelLink exists in SSCI since 2.1mid, but it is only known to be
used in Lighthouse, during the weapon creation puzzle near the end
of the game.
|
|
All these fall through were marked as deliberate, so again I've only
changed the comment to silence GCC.
|
|
|
|
This was broken by 9f33f2b3df22a26314dbb74173f49bc930c7a1f9.
|
|
|
|
Refs Trac#9974, Trac#9975.
|
|
|
|
This should make things slightly more responsive and avoids
unnecessary rendering of frames that are just going to disappear
in a moment.
|
|
Calling through EventManager::getSciEvent to flush events is
pretty inefficient and created stalls that lead to dropped
frames during the chapter 7 chase in Phantasmagoria 1.
If necessary, performance could be improved further by extending
Common::EventManager to expose SDL_FlushEvents, but this seems to
finish in 0-1ms so should be OK for now.
Refs Trac#9974, Trac#9975.
|
|
|
|
|
|
|
|
|