Scissor operations happen in a 2d rectangle, but it used to take a buffer
offset as a parameter. As a result, it had to divide that value with its
width, which is an expensive operation, which has to be done for each
pixel candidate for display (even before z-buffer comparison when
applicable, in current implementatoin).
But callers actually generate the buffer offset from rectangular
coordinates, so propagate these instead.
This sadly increases API redundancy, but saves a lot of time in a very
frequent occurrence (especially when enabling dirty rect mechanism,
which is not yet enabled by default).
Very few material files define their own color maps:
DATA000.LAB/blue.mat
DATA000.LAB/orange.mat
DATA000.LAB/pink.mat
DATA000.LAB/white.mat
DATA001.LAB/bren_chest.mat
DATA001.LAB/bren_shin.mat
DATA001.LAB/bren_skin.mat
DATA001.LAB/bren_thigh.mat
DATA004.LAB/bren_chest.mat
DATA004.LAB/bren_shin.mat
DATA004.LAB/bren_skin.mat
DATA004.LAB/bren_thigh.mat
Also, walk (but ignore) downscaled mipmaps. Even fewer files contain them, and
they contain a single image each (with 3 mipmaps):
DATA000.LAB/dflt.mat
DATA000.LAB/shadow.mat
The EGA version of Gobliiins, similar to Little Red Riding Hood,
claims a few resources are larger than they actually are. The original
happily reads past the resource structure, but we'll instead fix
the size of the resource after loading.
This fixes bug #7162.
The delay occurred when trying to interrupt the animation while at
the start of the first scene with Igor. After the interruption (skipping
the intro, return to launcher or quitting ScummVM) it would continue
to play the animation for a bit longer than necessary.
GCC 6's -Wmisleading-indentation warns about the debugC() statement
being wrongly indented, as if belonging into the else's branch, which
it clearly doesn't.
I tried to cover most of the things that seem to be interesting
for the end user. I excluded the SCI32 stuff because a) it's not
officially supported and b) I don't have the slightest clue what
most of the changes to the SCI32 engine do. :)
Please excuse if you made a noteworthy contribution I missed
to mention in this NEWS update. It was not on purpose.
Avoid doing a lot of operations just to move 2 or 4 bytes around.
Inline these methods as they are hot-spots and do very little: call
overhead becomes significant.
drawLine was broken for dx = 0 lines.
Also, the split between fillLineGeneric and drawLine, along with the many
parameters exchanged (with obscure names with subtle differences), made
the code hard to understand.
This implementation should be easier to check.
There was no visible CPU usage change.
Fixes GRIM's ticket printer, which are composed of a lot of vertical
segments.