This is necessary because texts and shapes, in particular, come already
colourized and we need to adjust the colourization to match the ink style before
we get to the blitting step. This seems faster than copying the surface or just
keeping the text as a mask and colourizing the chunks as we go.
This is for mask and matte inks. Now, rather than a bitmap sprite requiring a
flood fill every time (for mask ink) the matte is created and cached when matte
ink is first requested on that cast. Mask ink does not require a new surface to
be created, but it uses the same new channel interface.
Some functionality may be lost here, as the old drawReverseSprite seems to have
dealt with more edge cases, but these can be reimplemented as they are needed.
With my bitwise method, reverse ink issues in Warlock and our colour testing
movie are fixed.
This commit introduces several changes to the rendering pipeline.
- Rather than having a window for each score that is played, there is a Stage
in g_director that is only cleared when the upcoming stage has a different
size. This permits transitions still clean transitions between movies.
- Rather than relying upon general surface blitting functions, there is
progress toward a custom blitter than makes working with inks much easier. A
pixelwise function, inkDrawPixel, has been introduced.
- The mask-based approach to incremental rendering has been abandoned, as it
caused performance issues and strange rendering bugs. Now the renderer
operates on a traditional list of dirty rects that must be redrawn.
- QuickDraw shapes are more closely integrated with the renderer, and they do
not require a temporary surface to draw.
The palettes are reversed by default. This is useful when rendering
sprites, as they use reversed ids as well.
When a color is read directly as an int, it is in the original
unreversed order.
So, reverse it by hand when it's coming from lingo or other sources.
This was done in multiple places by subtracting the color id from 255.
The function transformColor handles this now.
Reversing the color means: 255 - color_id.
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.
