Fix for CLI processing of very large sprites (>64MB)
When the output sprite is calculated to be too big to fit in the upper limit of dynamic area size, ChangeFSI would attempt to create the output to disc in smaller chunks. However, the size required by the sprite header was not accounted for, eg. a 5000x4000 32bpp image would come out as 80000000 exactly. Fix this by flushing the sprite header (and palette) before spooling out the image. Tested with a nobbled dynamic area size of 128k, used 8bpp 2000x1000 sprite as test and processed this to S32,90,90 S16,90,90 28d 28 27 to exercise true colour, 256 palette, and bpp < 8. Note, the desktop front end isn't helped by this as it requires the image to all be in memory at once for the display step, but the CLI version can now output practically unlimited sprite files. Deleted call to PROCflushoutput in the JPEG/JPEGMONO code path, since addr% is never incremented it never gets called and the file that is being written to in o% is set type to FF9 at the end anyway. Tested with JPEG75 JPEGMONO75 Made Wimp version check consistent with 2 other occurences elsewhere in the source for the same template-related feature. Version 1.54. Tagged as 'ChangeFSI-1_54'
Showing with 18 additions and 18 deletions