| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
This is the solution discussed in bug #10568 ("SCI: PHANT1: Crash
on startup"). I believe that it's the correct solution, and that
ScummVM will do the right thing, but I'm not 100% sure.
|
|
Fixes Trac#10568.
|
|
SCI: High-quality "LarryScale" cel scaler for LSL7
|
|
The new approach is to delay kAnimate briefly (with an 68ms timeout)
while there is a zero-tick PalVary running, so that it has time to
trigger.
The previous workaround would immediately process a zero-tick
PalVaryInit/PalVaryReverse. This caused problems in QfG3 (bug #10304)
where it interfered with PalVaryPause.
The previous workaround could also be modified to handle pause/resume,
but this new approach should be closer to SSCI's behaviour, which used a
timer for a zero-tick PalVary too.
This fixes bug #10304, and keeps #5298 fixed too.
|
|
|
|
All other SCI games continue using the default scaler.
|
|
|
|
|
|
This is needed so that the system cursor can be appropriately
hidden outside the game's draw area, to match the normal behaviour
of ScummVM.
|
|
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.
|
|
This removes the unnecessary Buffer subclass and stops most places
where the output buffer was being interrogated about dimensions
instead of GfxFrameout.
|
|
|
|
* 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.
|
|
|
|
|
|
|
|
|
