SuperLemmini 0.104a

[Tsyu]

I'm unable to reproduce any of the problems that you reported; your replays work fine for me, and the trap in Lemmings Companion Fun 4 (the level that I think your screenshot comes from) doesn't produce an error message.

It sounds to me like you installed SuperLemmini to an existing Lemmini installation. SuperLemmini is not fully compatible with Lemmini assets, save for levels (although some Lemmini levels don't work in SuperLemmini). I suggest deleting everything everything in your SuperLemmini folder with the exception of these files and folders:

• changelog.txt
• superlemmini.jar
• superlemmini_enhanced_music.lzp (if it exists)
• superlemmini_license.txt
• superlemmini_megadrive.lzp
• the "docs" folder
• the "lib" folder

Once you've done that, start SuperLemmini again. You should be asked to perform resource extraction again; go ahead and do it.

[UnrealGecko]

Thank you, that seems to have fixed it  Didn't think that I did not need Lemmini... my bad 

Sorry for bothering. Thank you again!

[Ben H]

Hi,

I'm trying to get Oskar's Lemmini pack to work in SuperLemmini, but it doesn't seem to work anymore.

Using SuperLemmini 0.103a
Pack here: http://www.lemmingsforums.net/index.php?topic=1723.msg43179

I can see the levels listed in the browser, but whenever I try to load one I only get a black screen.
I'm not sure where to put the levels properly after the format change? Or whether anything else needs altering too?

Thanks

[Tsyu]

The levels in that pack use a single massive graphic set, so give them time to load.

(If you're wondering why that graphic set is so huge, it's because it contains a full-level image for just about every level in the pack. It may be convenient for a level designer, but it's actually a bad idea because it results in every level image being loaded whenever any level using that set is loaded, resulting in long load times and hundreds of megabytes of memory being wasted.)

Even if the levels do load, don't expect them to work properly. The graphic set in that pack was designed for Lemmini, not SuperLemmini, and Lemmini graphic sets are not fully compatible with SuperLemmini due to differences in game mechanics, the most common problem being exits that require an extra builder.

[namida]

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.

[Ben H]

The levels in that pack use a single massive graphic set, so give them time to load

Hi,

Thanks for your reply, but I don't think that is it.

I have left a single level loading for 20 mins and it still does not show up.
Whereas the exact SAME level loads in SECONDS on Lemmini.

My system is:
i7 2600K
Windows 10 x64
16GB RAM

So not slow or underpowered by any means.

It used to work fine on older versions like 0.9.9 or whatever is was.

[Tsyu]

Those levels load for me. Are you able to load the built-in levels (i.e., those not from Oskar's pack)?

[Ben H]

Hi,

Yes, all the built-in levels play fine for me.

[namida]

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?

If you need ideas on how to implement this, feel free to take a look at the source code of recent experimental NeoLemmix versions (the way it loads pieces isn't really going to help here due to the very different graphic set structure it now uses, but the way it handles caching flipped / rotated pieces can be adapted to this) or just ask. In general, NeoLemmix and Lix have both benefitted greatly from ideas suggested by each other's authors; we'd be more than happy to help SuperLemmini out too.

[Tsyu]

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.

[Ben H]

It's working with the 64-bit java version. It's a little slow to load, but at least it's working now.
Oh, and ofc some of the exits need adjusting.

[namida]

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.

Interesting. Lix has had this feature since day one so it was never really a problem there, but NeoLemmix is currently going through such a change (the experimental version already supports it). So, if you need any suggestions on how to handle this, and in particular how to handle compatibility with older content, feel free to ask! Of course I can't help with actual code since I know next to nothing of Java, but I should be able to help with general concepts.

[zanzindorf]

I noticed the countdown for bombers was removed by default. Is there a way to enable it through a setting somewhere? It'd be nice to be able to disable/enable the countdown for certain level packs. I'm loving this launcher so far

[grams88]

Welcome to the forum Zanzindorf.

[zanzindorf]

Thanks Grams!