The TGL_TRIANLE_FAN was looping past the valid array size due to the way the
loop is written, relying on i and i+1 to draw the fan. Reducing iteration to
cnt - 1 fixes the access violation and the triangle fan draws properly.
Triangle fans need to use a vertex from the previous triangle to create the next
one. The original TGL code does this properly but it was edited at some time and
the iteration changed to move on to the next triangle rather than using the previous
vertex, causing the triangle fan to skip a triangle and render a weird rays thing.
The Cinepak decoder had an unweighted euclidean color distance calculation for palette matching. This was moved and rewritten to a color distance method on the palette class.
The original patch courtecy of IRC user grib. The original comment:
Try to coordinate using windows bitmap fonts in the MacFontManager needs to consider
pixels, points, and DPI
Font sizes are usually described in terms of "point" sizes, and rendered
as a number of pixels.
Windows fonts and Macintosh fonts used different DPI (dots per inch).
Bitmap fonts on Mac mostly used 72 dpi, so 72-point font would be about 72 pixels high.
Windows bitmap fonts mostly assumed 96 dpi, so a 72-point font would be 96 pixels high.
director:trektech loads a Windows bitmap font file that is nominally 12 point at 96 dpi. It is 14 pixels high.
Since we cache windows an mac fonts, this ensures that we check both caches
before attempting to generate substitutes, whuch affects greatly
performance in Windows Director games
We required version 110 for OpenGL backend shaders while we only checked
for version 100, although this version is not expected to work without
proper ARB extension support.
Increase minimum supported version to 1.10 which matches OpenGL 2.0
Disabled menus can still be opened. Menu items in disabled menus will
look and act as if they were individually disabled. Enabling the menu
will restore it to its pre-disabled state.
It was using the wrong parameter order to hLine(). This caused a
regression in drawing Macintosh menu bars (rounded rectangles), and
quite possibly other things as well.
This simply moves the new ColorQuantizer class out of the SCUMM engine
and into the Graphics namespace where I think it belongs. It reduces a
potentially large number of colors into a reasonable palette of the
desired size.
The SCUMM engine uses this so that the Mac versions can present the
thumbnail image (which is at least 16 bpp) stored in savegames.
The LucasArts SCUMM games need to know when this happens so that they
can turn the screen black. Polling the window manager for the menu
status probably wasn't good enough, because it seemed there were cases
where the menu was both activated and opened too quickly for the game to
have a chance to register it happening.
There is no callback for when the menu is deactivated. I could be wrong,
but I don't think this is quite as sensitive?
