I did some testing and found that 32-bit Java throws an out-of-memory error when SuperLemmini tries to load Oskar's graphic set. 64-bit Java doesn't throw this error (most likely because it has access to more RAM), but it still allocates 1.5 gigabytes(!) when loading that graphic set.
I don't really know why so much RAM is used, but I do know that SuperLemmini uses more RAM for images than Lemmini 1) to support full translucency, 2) to support separate terrain masks (applies only to terrain pieces, obviously), and 3) because images are first loaded as-is and then copied to a blank image of a more predictable format.
I'll do what I can to reduce memory usage and avoid 3) whenever possible.
Just wondering, how possible is it to detect whether a graphic set was made for SuperLemmini or not? I'm thinking whether it may be worthwhile automatically moving the trigger area if a Lemmini set is detected.
Perhaps one measure is - if no SuperLemmini-exclusive features are detected, then unless there's a line (perhaps something like SUPERLEMMINI=1) that specifically states it as one, the adjustment occurs? I think the problem here is, it should've been designed in such a way that these could be told apart from the beginning; this is something NeoLemmix also had a problem with early in its development, but was resolved with newer versions using entirely unique formats rather than derivative ones for most files.
I'll do something like this. At least there are a good number of SuperLemmini-exclusive features (PNG images and movable object trigger areas, for example).
It came up in chat, but I see no one posted here - is there any reason that SuperLemmini needs to load every piece, rather than simply loading the metainfo (which is relatively non-time-consuming) if even that up-front, and only loading the image if/when it's needed?
Not really. I plan to revamp the way that graphic sets are handled (mainly to support multiple sets in one level); I'll be sure to load only the graphics that are needed by the current level.