This might help with bug #12182 where the comment suggests there is a problem
with loading the treasure data. To make sure it loads properly, added a lot
more error checking and error messages, and created unit tests for the same.
Large flat squares should get sorted below other flat things. In U8, the
definition of large is 128x128, but in Crusader they can also be larger than
that.
This fixes the paint order of hazard tape stripes in Crusader. It may also
improve paint order for Ultima 8 which has some big flat squares larger than
128x128 too (eg, shape 165 or 318 which are 256x256).
Also added tests for flat object sorting.
Try to use more of the built-in ScummVM rendering pipeline and remove redundant
types where possible. Unfortunately this is a bit of a mega-commit because all
the pieces were tied together, but the main changes are:
* Remove the Texture types, as they add little over ManagedSurface
* Remove the ScalerGump as we no longer use it - we should be using the
built-in ScummVM scalers
* Remove the Scaler types - the only remaining user after removing ScalerGump
was in hte AVI player. There we manually add the Crusader style interlaced
scaling, which was an outstanding TODO anyway.
* Remove now-unused functions from the RenderSurface family
* Remove the "default" mouse cursor as we never use it in ScummVM
* Remove the memset_n header which duplicates Common::Fill functions (fixes
#11969)
* Remove the fixed-width bitmap fonts which were used for the Pentagram
console.
I've tested the following things that this had the potential to break:
* U8 game, credits, movies, minimap, and ttf rendering
* Crusader game and movies
* Debug tools (shape viewer, touch-highlight)
The boundary conditions were reversed in Box.Inbox when compared with
Box.Overlaps. Since InBox is not being used and Overlaps is, I went with the
definitions from Overlaps. Also configured unit tests to exercise this
behavior.
I put scare quotes around "correctly" because I can't swear this is the
intended behaviour of the original interpreter.
I don't think accessing filenames that end with / in the .DCPs is even
defined behaviour, so this is a best guess.
