LOADIFF to open its own screen based on IFF header, if no screen is open

[ByteProject]

For my game Ghosts of Blackwood Manor I've been working on adding a loading screen to the game via LOADIFF.

I found out that the compatibility of LOADIFF is very low, many images which are considered "valid" are not supported. The problem seems to be that it fails to properly render images with less than 256 colours, which is odd. It could be that LOADIFF does not properly handle the palette defined in the image. I was trying to convert an Atari ST screen, wich had 16 colors and it did not work. As soon as I used an image with more colors, reducing the palette to 256 colors, it works. It also seems not being able to open files generated with Grafx2 and Multipaint, my guess is this has to do with the palette handling as well. A palette of e.g. 16 colors or 63 colors etc. is perfectly valid for IFF-LBM.

[johnwayner]

If you have the rights to provide examples of non-working images that would expedite the investigation of this issue.

[ByteProject]

Here is an archive with an example. I've also attached a PNG version of the image as a reference. It has only 16 colors. The IFF-LBM has been created using Grafx2 and runs perfectly fine on Amiga and can be opened / edited with any software that supports IFF. Rendering via LOADIFF does not work.

example.zip

[snoopy-f64]

16 colors are 2⁴ colors, so you have to open a screen with SCREEN 320,200,4

Your example screen works fine, see attached screen shots (with Xemu):

[ByteProject]

Ah I see. So LOADIFF requires to define the colour depth. That's unfortunate as my work is for a set of build tools for adventure authors. The template provides a loader but it cannot know in advance which color depth the author's image provides. A suitable enhancement would be LOADIFF auto-detecting the image properties and then applying the right mode.

[dansanderson]

See also #55 which notes that LOADIFF only supports type-1 compressed images and not type-0 uncompressed images. It is possible to make images that work with LOADIFF with ImageMagick, it just has to be specific to its limited support.

LOADIFF expects the screen to already be allocated, and just draws onto the existing screen (and updates its palette). A workaround is for a BASIC program to open the file and scan the header for the bit depth, close the file, allocate a screen with the appropriate resolution and color depth, then LOADIFF onto that screen.

One possibility might be for LOADIFF to allocate its own screen based on the file header if and only if there isn't an open graphics screen. This would cover common cases of "just show this image full screen" without over-complicating the existing API. LOADIFF would fail in the same way SCREEN does if there isn't enough memory.

I'll make this issue that feature request. Please let me know if there's something else needed that I missed.