Lemmini

[0xdeadbeef]

Ok, yeah well, then let's start anew.

Please note that there's a complete revision history on my site.

Fixes/changes 0.73 -> 0.74 (27.6.2006)
#  Fixed GIF extraction bug introduced with 0.72 that would make areas transparent if they had the
   same color as the transparent color (but a different palette index). This especially affected
   fire_16.gif and (due to strange level design) created garbage in levels 0061 and 0061b
   ("If only they could fly"/"Down, along, up. In that order").
#  Changed skill one text to "You finished all the <skill> levels!"
#  Drowning sound was missing in crystal set due to a typo.
#  For the last few bricks, builder uses "ting" sound (like unassigned skill) instead of "chink"
   (like hitting on steel).

[Mindless]

For anyone who doesn't know: http://lemmini.de/

Anyway, I'm still requesting 1) full-screen mode (if possible), 2) style-specified lemmings animations, 3) and a different method of handling the special levels.

1)  Is this possible in Java?
2)  For example, if I made a Lemmings 2 Beach style and I wanted the Lemmings to look like beach-bums.  Styles should be able to specify which lemmings animations to use just as levels specify which style to use.
3)  I realize this seems like a lot of work for nothing, but I think the special graphics should be specified by a "special=specialgraphicnamehere" instead of using a seperate style.  As of right now, it isn't possible to play special levels in CustLemm packs, whereas this would make it possible (in a roundabout sort of way).

[0xdeadbeef]

#1 - yep, this is completely possible and top of my "to do" list. But it needs some major rework and I didn't find the time to start this yet. Maybe end of july, when I get my vacation.

#2 - This is also on my list. Creating the right animations will have certain restrictions though. The question also arises who is willing/capable to redraw all hires lemmings to Summer/Xmas style.

#3 - I don't really get it. You can define our own styles. Define a special style and you can use it.

[Mindless]

#3 - I don't really get it. You can define our own styles. Define a special style and you can use it.

The special style contains a very limited number of object (and of only one style).

[0xdeadbeef]

Sure, because this "special" set is only used to implement the 4 special levels from the Amiga version missing in the Win95 version. There are not other objects in this style because there ARE not other objects.

If  someone whises to use a special styles with more object he can simply create his own style specialXXX and put any object in he wants to.

[0xdeadbeef]

Fixes/changes 0.74 -> 0.75
#  On MacOS, the screen menu bar is supported.
#  Red dots representing lemmings in the mini map didn't show on MacOS (probably gfx/image update issue of JVM).
   Fixed by drawing everything (also explosion particles) in the gracphics object and nothing in the image
#  When loading a level manually, the music track chosen is random.

[EricLang]

I still see that the framerate at the beginning of a level is too high. After a few seconds it slows down to the normal speed. I mentioned this earlier (on the dead forum).
Does anyone else see this? Or is this only on my machine?

[0xdeadbeef]

Did you have a look at the CPU load? Is it very high at the beginning of the level?

[EricLang]

Yes, it is about 100%.
After that it becomes about 35%

[Mindless]

CPU usage on my machine is deathly high on the intro screen(s)... everything is fine while playing levels.

[EricLang]

A bit off topic
But did anyone ever notice that the superlemming level is called
"Inroducing SUPERLEMMING" instead of "Introducing SUPERLEMMING".
Has anyone ever noticed this obvious typo?

[0xdeadbeef]

Yep, I did. Decided to keep it due to authenticity. I think it was also wrong on the Amiga, wasn't it?

[Proxima]

I noticed that when I first played the level on the Mac version  :cool:

[EricLang]

About this high resolution christmas-lemmings animations for Lemmini: I think I will be able to create them automatically, with some fancy-named scaling-algorithm.
But it will not be tomorrow

[0xdeadbeef]

There are some clever scaling algorithms like Eagle and derivates which smooth edges, but if you compare upscaled animations to animations designed to be hires, there will be a big difference.
Also there will be some manual work to do, especially determining the foot position for each animation and creating the descriptor file.

[EricLang]

I think there always will be difference between automated and human design
But at least it would be a beginning. The graphic scaling library I'm using for Lemmix has some scaling procedures, with which I will create the animations (after my holiday in France, before it I am trying to upgrade to Lemmix 0.0.4).
I'm already busy with Lemmini-support, so creating the descriptor file is easy.
Footpositions will be the same as your originals (afaik).

[Mindless]

I've noticed that in the latest version, if you try to assign the brick laying skill to a lemming that's already laying bricks, the "chink" sound is played.  In the Amiga version no sound is played at all when this happens.

[0xdeadbeef]

Hm, I didn't change this though lately. All actions that can't be assigned produce the "chink" sound.  The only thing that I changed lately regarding builder and sounds is that I exchanged the brick laying sound itself since some people complained it was the wrong one.

Anyway, I wonder which sense it makes to play a "denial" sound for almost every actions that can't be performed, just not for one. I tried to keep everything as general as possible.

[Mindless]

Actually, I don't think the Amiga version plays a sound for any denial.  :shocked:

Edit: Neither does the DOS version.

[Mr. K]

Only the Win95 version does to my knowledge...

[0xdeadbeef]

And is that so bad? I don't think it's a bad thing to be informed that something went wrong...

[Mindless]

In case you're interested in making Lemmini more Amiga-ish... I've ripped the Lemmings levels from the Amiga (so we get the lava under "All the 6's" for example).
http://it.travisbsd.org/lemmings/_misc/amiga_lemmings_levels.zip

I should have ripped the ONML levels too.   I'll see if they're in the same format, but it'll take a while to figure out how I ripped the files off the disk.

[Mindless]

I figured it out faster than I thought I would... http://it.travisbsd.org/lemmings/_misc/amiga_onml_levels.zip

Oh, and the 2-player levels are in both of the level sets.   Mayhaps ccexplore will enjoy those.

[0xdeadbeef]

Problem is that I extract the levels from the Windows version. If I would take the Amiga levels instead, this would make the whole idea of resource extraction a little pointless.

[Mindless]

Problem is that I extract the levels from the Windows version. If I would take the Amiga levels instead, this would make the whole idea of resource extraction a little pointless.

I thought the main reasons to extract the resources were a) a legal fallback and b) because extracting graphics saves a lot of bytes.

[covox]

Thanks Mindless!  These are really easy to patch over the DOS ones. There are a couple of boggling glitches (for instance, "We are now at LEMCON ONE" now has a giant vertical stack of drawOverTerrain'd water objects to the left of the entrance), but I suspect that's just my dodgy binary diff method being clever.

[Mindless]

Thanks Mindless!  These are really easy to patch over the DOS ones. There are a couple of boggling glitches (for instance, "We are now at LEMCON ONE" now has a giant vertical stack of drawOverTerrain'd water objects to the left of the entrance), but I suspect that's just my dodgy binary diff method being clever.

That is quite strange, it's a problem here too... either the Amiga version has a slightly different rendering engine or there's a problem with the ByteKiller decruncher.  I suspect the second... what I've seen of ByteKiller hasn't been very stable.  I'll see if I can figure this out.

[ccexplore]

Interesting.  How similar/different is ByteKiller compared with how DOS compresses the levels?

Also, if you can find Amiga's analog of "main.dat", see if you can find the mask for basher, which if I recall is slightly different from the one in DOS.

[Mindless]

Interesting.  How similar/different is ByteKiller compared with how DOS compresses the levels?

I don't really know since I'm using the decruncher on the Amiga to decrunch it.

Also, if you can find Amiga's analog of "main.dat", see if you can find the mask for basher, which if I recall is slightly different from the one in DOS.

There's a file simply called "main" - it wasn't crunched and it's 28kB.  I don't have time to do much of anything right now.

[Mindless]

Now that I've looked at "We are now at LEMCON ONE", it appears that it's either a problem with the emulator, a problem with the disk dumper, a mistake on DMA's part, or a purposeful addition to the level (it looks somewhat like liquid is flowing out of pipes.)  The level appears the exact same way in every disk image I've checked... it always has the water over on the left.

[ccexplore]

Now that I've looked at "We are now at LEMCON ONE", it appears that it's either a problem with the emulator, a problem with the disk dumper, a mistake on DMA's part, or a purposeful addition to the level (it looks somewhat like liquid is flowing out of pipes.)̆ The level appears the exact same way in every disk image I've checked... it always has the water over on the left.

Wow now I'm really intrigued.̆ So you are saying that on Lemmini/DOS Lemmings, you see the large stack of liquid, but there's none when playing the level in the Amiga emulator?

It could still be a rendering engine difference though, but I'd need to take a look at the extracted levels in DOS Lemmings to see.̆ Since it was mentioned that the acid is drawOnlyOverTerrain'd, if there are no terrain pixels where the acid stack is located, then in principle it could be correct that you won't see the acid at all.̆ DOS Lemming's rendering engine is somewhat different in this regard, as it doesn't quite check exactly for terrain pixels per se, but instead checks for pixels on the screen of a certain range of color (I think 8-15 if I recall correctly), and assume those are terrain pixels for the purpose of drawOverTerrain rendering.̆ Meaning if the acid objects overlap, you may see some of the overlapping pixels displayed, despite the flag.

We can check for the water's existence by attempting to reach it and see whether it affects any lemmings, although it's also possible that they may be "fake objects" like how in DOS Lemmings objects with index/z-order > 15 are fake and does not affect lemmings.̆ In any event, I definitely will look at this when I get home from work.

[Mindless]

Now that I've looked at "We are now at LEMCON ONE", it appears that it's either a problem with the emulator, a problem with the disk dumper, a mistake on DMA's part, or a purposeful addition to the level (it looks somewhat like liquid is flowing out of pipes.)  The level appears the exact same way in every disk image I've checked... it always has the water over on the left.

Wow now I'm really intrigued.  So you are saying that on Lemmini/DOS Lemmings, you see the large stack of liquid, but there's none when playing the level in the Amiga emulator?

On the Amiga emulator the water is there.  On Lemmini, when playing the Amiga levels, the water is there.  I've checked all the Amiga disk images to make sure it wasn't just a bad dump, but on every one, the water shows up.  This water is not in the DOS levels.

[ccexplore]

I'm finally home and so was able to check on my Amiga emulator, and now I know what you're talking about.  That is kinda neat.

I got confused because covox was calling it a glitch, so I kept thinking that it is showing up when playing the extracted Amiga level on DOS Lemmings or Lemmini, but that it doesn't show up on the Amiga emulator.

But looks like there's no glitch after all.  I haven't yet seen how DOS Lemmings (nor Lemmini) renders the extracted level, but I'm pretty sure it won't look correct--knowing how it renders, DOS Lemmings has either a bug or took a bit of shortcut in how it renders DrawOnlyOverTerrain'd objects, so the color will be wrong I think.

[covox]

Apologies for the confusion. I only assumed that it was a glitch because it seemed... well, horribly out of place in comparison with the DOS one. I didn't actually check the Amiga version, however The Lemmings Solution (which I always thought had shots of the Amiga version with the background changed) shows no liquid on the poles.

If this was intentional, I'm surprised they didn't at least flick the upsideDown modifyer to disguise all the bubbly bits.

[ccexplore]

If this was intentional, I'm surprised they didn't at least flick the upsideDown modifyer to disguise all the bubbly bits.

Well, if it's boiling acid and they are tubes, why wouldn't the bubbles be rising in the portion of acid that are in the "tubes"?

The bubbles I'd say actually makes the liquid inside the "tubes" look more like liquid rather than just a static, unanimated block of green.̆ I'll admit though that the bubbles are a bit big relative to the tube size, and since the stacking is so regular, the bubbles are spaced too evenly and thereby look a little artificial.

The whole thing does look kinda like the acid being partly sucked up the tubes via capillary action.̆ It's at least a good effort at a neat idea, even if it does end up looking slightly odd.

As for the Lemmings Solution screenshots, I believe people have said they come from the Windows version (I guess the low-res graphics if that's the case).

Anyway, for the benefit of those without an Amiga emulator, here's a screenshot of what we are talking about, using the WinUAE emulator on my computer:

[ccexplore]

I guess since Mike has started frequenting the forums again, maybe we can ask him whether the "acid in tubes" visual effect in Fun 20 is intended or not.

[covox]

I stand corrected. Of course, one could interpret it as the tubes ending at the middle actually depositing a stream of acid into the pond :p

Amiga lemmings seems to intentionally blit these in reverse (?) in order to hide the blue bit atop the acid, which looks pretty good (apart from the niggling wave at the top of the pipe).

[ccexplore]

I checked a few other versions.

The SNES version does not have that "acid in tubes" look on that level, even though in general the levels look similar to the Amiga version (or more accurately, like the Lemmings Solution screenshots).

The Genesis/Megadriver version of Lemcon is redesigned to take less space, so the entire part left of entrance is effectively removed and replaced with something simpler with no acid.

The Windows version, in general, apparently looks exactly like DOS Lemmings.

The Mac version is hi-res only, but to my surprise, it does have the same "acid in tubes" look:


(yes, they did botch it up a little, with the "wavy" parts in the stack still exposed)

So I'm not sure where exactly the screenshots for the Lemmings Solution came from.̆ I'd like to try out the Atari ST version but I'll have to download it from somewhere along with a suitable ST emulator. ̆It looks like the "acid in tubes" look is in a few selected versions but not many.

[covox]

Intriguing

In the end I just compromised and used the Lemmings Solution rendition in my patchfile. Hopefully it won't draw extensive criticism from trainspotters.

[ccexplore]

Ah I see, I forgot you're planning to make a clone of the game.

I for one have no problem at all with your choice of forgoing the Amiga look in that level.̆ The Amiga acid-in-tube is an interesting concept but I must say it is not totally successful to my eyes.

[wysiwyg]

Personally I'd quite like to see the amiga levels in Lemmini. I know the differences are purely aesthetic and have no affect on any solutions (as far as I know), but even just a row of lava is slightly more interesting than black space.

The game could still extract the levels that are identical to the amiga ones, and so the copyright method would still work.

I remember the effect in the tubes from Poles Apart from years ago playing it on the amiga and thinking it was a cool idea (even if it does look slightly dodgy), but there seems to be a problem loading the amiga level in Lemmini, as some of the water at the bottom doesn't appear  :huh:

Also because of the resized graphics, the water in Save Me doesn't quite reach the right hand side if loaded into Lemmini.

[ccexplore]

Well, now that Mindless made the Amiga levels available in LVL format, you can in principle get Amiga levels in Lemmini as follows:

1) make a copy of the WinLemm data
2) in the copy, replace all the WinLemm LVLs with Mindless's Amiga LVLs
3) force Lemmini to re-extract resources from the modified copy of WinLemm data

The only snag right now is that the Amiga LVLs are named differently than the WinLemm LVLs, so step 2 would be quite tedious to do manually.  Though I guess I can write a program to map them from one to the other.

Oh, and I forgot how to do step 3, but 0xdeadbeef should be able to help out there.

[EricLang]

Why not make a new levelpack for Lemmini, keeping the "old" one intact?
Lemmini is very flexible in this respect.
Lemmix will support this kind of "batch-conversions" in the future.
So another option now is the manual one:
Open each level in Lemmix and do a "Save As Lemmini".
After that you have to create one or two inifiles two let Lemmini know how two handle the order etc.

[0xdeadbeef]

If the differences between the Amiga version and Windows version are minor e.g. a few block added and/or drawing order changed in a few levels, I could also let my patching algorithm handle this. However my "real life" job cost me all the time and attention lately, so I didn't really follow the discussion.
If the changes are bigger, I support the idea of creating a level pack.

[wysiwyg]

Well I've checked a few of the levels and there doesn't seem to be any differences in the drawing orders. There were a few less Terrain pieces in Poles Apart in the amiga version which I think were from the 'island' on the right and are probably covered in water

The only other differences so far are the extra objects forming rows of water across the bottom of some of the levels, and the 'acid in the tubes' effect in Poles Apart (which doesn't seem to work properly in Lemmini).

I'll check some more if I get time.

[finlay]

Do you really not get the water effect on the DOS version? :huh2:

I was quite disappointed when I went from playing on the mac to playing on the Playstation, where it didn't have the water effects in that level (and in fact, most levels which should have water right across the bottom of the level didn't in that version, annoyingly; I seem to remember something similar with the Windows version but my mind might be playing tricks on me).

Also, do you definitely need to buy Windows Lemmings? I'd love to try this out...

[ccexplore]

Do you really not get the water effect on the DOS version? :huh2:

You don't, but that's not too surprising since there's a lot of missing water/lava/acid on the DOS version anyway throughout all the levels.̆ I think it's probably mainly a performance or memory issue.

I was quite disappointed when I went from playing on the mac to playing on the Playstation, where it didn't have the water effects in that level (and in fact, most levels which should have water right across the bottom of the level didn't in that version, annoyingly; I seem to remember something similar with the Windows version but my mind might be playing tricks on me).

No you remember correctly, the Windows version is also missing water like the DOS version.̆ I also agree that the PlayStation and Windows version have no excuse to have missing water, since performance and memory concerns are unlikely to apply at that point in time.

Also, do you definitely need to buy Windows Lemmings? I'd love to try this out...

Well, I don't really want to parade this, but I think I mentioned this on the forums some time ago anyway so:

http://it.travisbsd.org/lemmings/lemmingswelt/index.php?cmd=get&file=/winlemm_data.zip
(This is in the "Root" directory of Mindless's file portal.)

This only contains the data files for Windows Lemmings, which is all you need for Lemmini.

[finlay]

OK.... but what about the screenshots on "The Lemmings Solution" website? Are they from the Amiga or something? Most of them have water in all the right places.

[wysiwyg]

It might be the Atari St Version thats used on the lemmings solution site.

You can see the acid effect on Poles Apart if you look on the planet lemmings website:

http://www.deveria.com/alexis/lemmings/lemmings/amigacodes.html

[0xdeadbeef]

Long time no see...

Fixes/changes 0.76 -> 0.77
# Fixed long overlooked timing bug in sleep mechanism.
# Added new comments for level lost but 50-95% saved and 95-100% saved (of the
   ones needed)
# Fixed number of lemmings from 80 to 100 in Tricky 25 (checked with Amiga version)
# Added 3 select types, selectable using cursor keys:
   cursor left:  only lemmings headed left are selectable
   cursor right: only lemmings headed right are selectable
   cursor up:    only walkers are selectable

[Mindless]

woot, glad to see you're still working on this even though the community has all but died <_<

[0xdeadbeef]

Well, I just spent a few hours this weekend to complete the cursor thing that I started some months ago but then lost interest. This doesn't neccessarily mean that there will be more updates soon though
Indeed, I think that Lemmini's pretty much complete. There are some minor issues I'm aware of, but as all levels are playable at the moment, I'm not so keen on changing the game mechanics and risk making levels unplayable again.
There are things like fullscreen mode or two player mode over internet that I may or may not add sometime in the future.
Anyway, Lemmini is by far more complete then I ever hoped it would be, so chances are that there will be only minor updates and bug fixes and no major improvements.

[WNivek]

I've been messing around, using Lemmix to convert various levels to Lemmini's file format, and appear to have found a small flaw in the latter. The maxFallDistance setting in my levelpack.ini doesn't appear to function.  I have a level here that relies on the slightly extended drop-height available in certain versions, but no matter what I set that variable to, they still splat just the same.

Also, and this is VERY minor, but on the between-level screens, during the fade-out after selecting an option, you can click again to restart the fade.

[0xdeadbeef]

I've been messing around, using Lemmix to convert various levels to Lemmini's file format, and appear to have found a small flaw in the latter. The maxFallDistance setting in my levelpack.ini doesn't appear to function.  I have a level here that relies on the slightly extended drop-height available in certain versions, but no matter what I set that variable to, they still splat just the same.

True. Indeed it works if you put the maxFallDistance into the level file instead of the levelpack.ini. But as far as I remember, that's not what I indended to do.
Since you're probably more or less the only person to make Levelpacks for Lemmini: would you prefer to set the fall distance on a level or levelpack basis?
Maybe it would be a good idea to read a default value from the level pack but still be able to set it for each level.

Also, and this is VERY minor, but on the between-level screens, during the fade-out after selecting an option, you can click again to restart the fade.

Funny, never noticed this. Probably a quirk in my fading state machine...

I'm a little tired and lazy right now, but I'll have a look on both issues the next days...

[WNivek]

I like that idea about specifying a standard splat-height in the pack, with the option of setting different distances for specific levels.

Out of curiosity, is there any way to effect the level passwords beyond just setting the initial key? I've converted Martin Zurlinden's Lemmings - a 30-level pack which originally resided in 'Tricky'. I want to keep it authentic by retaining its original codes, but as far as I can tell, the only way I can do that is by preceding the actual levels with dummy level-entries. Any chance of a sort of 'initial level number' option? If not, it's not that big a deal... with the various player ini files keeping track of levels unlocked, the passwords are somewhat depreciated.

Oh, that reminds me. It's possible to crash Lemmini by entering codes for level 1 of any difficulty.

[0xdeadbeef]

I like that idea about specifying a standard splat-height in the pack, with the option of setting different distances for specific levels.

Ok, I think I'll go that way then.

Out of curiosity, is there any way to effect the level passwords beyond just setting the initial key? I've converted Martin Zurlinden's Lemmings - a 30-level pack which originally resided in 'Tricky'. I want to keep it authentic by retaining its original codes, but as far as I can tell, the only way I can do that is by preceding the actual levels with dummy level-entries. Any chance of a sort of 'initial level number' option? If not, it's not that big a deal... with the various player ini files keeping track of levels unlocked, the passwords are somewhat depreciated.

Hm, I understand Martin's levels started with Tricky 1, so the first level code would be "HCEONONPDX"? I guess it would be possible to handle this by adding an offset parameter to the levelpack.ini. Something like this:
    codeOffset = 30
By default, it would be 0. Probably I'll implement this for the next version if I don't find any drawbacks.
Note though that this reduces the maximum number of levels in the levelpack.  The maximum number is 127, so for an offset of 30, the maximum number would be decreased to 97.

Oh, that reminds me. It's possible to crash Lemmini by entering codes for level 1 of any difficulty.

Damn, you're right. A bug in the decoding the absolute level number to difficulty level and relative level number. I already fixed this locally, so it will be ok in the next version. Thanks for telling me.

[WNivek]

Hm, I understand Martin's levels started with Tricky 1, so the first level code would be "HCEONONPDX"? I guess it would be possible to handle this by adding an offset parameter to the levelpack.ini. Something like this:
    codeOffset = 30
By default, it would be 0. Probably I'll implement this for the next version if I don't find any drawbacks.
Note though that this reduces the maximum number of levels in the levelpack.  The maximum number is 127, so for an offset of 30, the maximum number would be decreased to 97.

I made a slight mistake in my post - it's actually 'Taxing', not 'Tricky'. But yeah, a codeOffset setting would do the trick.
As for reducing the number of levels... I honestly don't know much about the Lemmings level code format, but would it be possible to 'wrap' the codes, so if you're on an offset of, say, 60, once you get past the max level of 67 (with code 127), level 68's code would wrap to 0 with subsequent codes counting up to 59?
Again, it's not that big a deal. I don't intend to use this offset option terribly often - only reason for it here is to preserve a converted pack's existing codes, and since such packs would have similar limitations, you'd never get one trying to go higher anyway.

Out of curiosity, what would happen if I assembled a pack with more than 128 levels? I've started converting various people's levels, with intention to keep them grouped together by creator, but some people have made more than 128 levels. I wouldn't wanna break those up, but it's starting to sound like I may have to.

[0xdeadbeef]

I made a slight mistake in my post - it's actually 'Taxing', not 'Tricky'. But yeah, a codeOffset setting would do the trick.

Just another offset then.

As for reducing the number of levels... I honestly don't know much about the Lemmings level code format, but would it be possible to 'wrap' the codes, so if you're on an offset of, say, 60, once you get past the max level of 67 (with code 127), level 68's code would wrap to 0 with subsequent codes counting up to 59?
Again, it's not that big a deal. I don't intend to use this offset option terribly often - only reason for it here is to preserve a converted pack's existing codes, and since such packs would have similar limitations, you'd never get one trying to go higher anyway.

Sure, you're right, I could use "level % 128" to wrap around.

Out of curiosity, what would happen if I assembled a pack with more than 128 levels? I've started converting various people's levels, with intention to keep them grouped together by creator, but some people have made more than 128 levels. I wouldn't wanna break those up, but it's starting to sound like I may have to.

Well, from what I've re-learned by quickly looking into the levelcode algorithm, I'd say that the absolute level number can only be a value of 0..127 (7bits). This is not restriction of Lemmini though. Also, while I didn't really think about it, I guess it would be possible to extend the algorithm for larger level numbers if you need that. E.g. using 11 or 12 characters instead of 10.
What would happen at the moment is another questions. I'd guess that the game itself would work ok, but the level codes for levels beyond the 128th would be wrong and you couldn't select them. I would assume that e.g. beating the 130th level, you would get the level code of the 2nd level and if entering this code, you would start with the 3nd level as well. Then again, I didn't investigate further, maybe the level code would also get corrupted or maybe even I check the number for overflow and throw an exception. Anyway: it wouldn't work correctly right now since the default algorithm can't handle it.

[0xdeadbeef]

This can be considered a WNivek release

Fixes/changes 0.77 -> 0.78
#  Fixed embarrasing bug that would crash Lemmini if a levelcode for any first level
    of a diffculty level was entered.
#  Fixed bug in fade in/out code that would restart fading again and again each time
     the left mouse button was clicked.
#  Parameter "maxFallDistance" in levelpack.ini was ignored. Now it can be set in
     the levelpack and additionally for each single level. Default if omitted is 126.
#  Implemented parameter "codeOffset" of levelpack.ini to give the first level a
     higher levelcode. Untested and experimental.

@WNivek: please have a look at the maxFallDistance and CodeOffset features. I just hacked it in, but didn't test it.

I also checked the level number restricitions again. Looks like Lemmini would currently  throw a null pointer excpection in case you win a level with a number > 128 since the algorithm can't handle it and returns a null pointer instead of a string.

[WNivek]

I haven't done extensive testing, but Martin's pack now has Taxing passwords, matching the level codes file he included with the original download, and If I want, I can bundle my experimental mFD=1 level in with a set of mFD=132 levels.
maxFallDistance and codeOffset appear to function as advertised.

[0xdeadbeef]

Ok, nice to hear.
About that >128 level issue: I put it on my "todo" list, but don't promise anything, since there are lots of things on the list which might never be done.
Then again: If you really need it, just drop me a note and I'll reconsider.

[WNivek]

I've come across a mildly bothersome little quirk: Any time the game doesn't find a resource it was expecting (a graphic in a style, a level in a pack...), it demands a re-extraction of the WinLemm data. Under typical circumstances (only Lemmings and Oh No! More Lemmings), this makes sense. However, as soon as user-generated material enters the picture, the reasoning gets a bit shaky as that response remains the same even is the missing file isn't one that gets created in the WinLemm extraction process.
It's not a major concern, though - at most, it's a minor inconvenience during testing of new content. But since it came up recently, I thought I'd mention it.

[0xdeadbeef]

Dunno if this helps, but there is a (manual) workaround for this. If Lemmini (for any reason) decides to force extracing the data again, it sets the "revision"-Parameter in Lemmings.ini to "invalid".
Before e.g.:
     revision=0.77
After
     revision=invalid

Note that the revision is the revision of the resources, not neccessarily that of the program. E.g. 0.78 didn't need new resources, so its resource revision ist still 0.77, while the program is at 0.78.

The Lemming.ini file can be found either in the same directory as the JAR (in case you're using a local JAR) or in your home directory (e.g. Windows: My Documents).
If you just copy a valid backup over Lemmings.ini each time you start Lemmini, you don't have to extract the resources again.

[ccexplore]

I just managed to extract the graphics for the 4 special levels on the Mac version, which uses hi-res graphics:

http://it.travisbsd.org/lemmings/lemmingswelt/index.php?cmd=get&file=/macspecials.zip

Now to be fair, they are nearly the same as the lo-res versions from DOS; the Mac people only did hi-res touch-ups either on small isolated areas, or simply apply some dithering.  Still, take a look and see which ones you want to use for Lemmini in place of the current "lo"-res versions.

[The Mac emulator I was using had a serious bug in displaying special graphics levels, which is why I couldn't simply take screenshots of them and be done with it months ago.]

[WNivek]

Hmm... the 'high res' versions of Beast and BeastII seem to only have added a sort of hap-hazard dithering, which appears to be compensating for not having quite the right colors available, and honestly doesn't look too good on close inspection.  Menace avoids that pointless dither, and actually cleans up a few lines. Awesome's palette has been significantly altered - the alien things look more more red than brown - but the heads of the things appear to have been meticulously redrawn.

In my humble opinion, while there's no point in borrowing the Mac versions of Beast and Beast2, It would be an improvement (albeit a small one) to use that version of Menace, and Awesome too if someone can 'correct' the palette to more closely match the original. (I may do that myself...)

[ccexplore]

Hmm... the 'high res' versions of Beast and BeastII seem to only have added a sort of hap-hazard dithering, which appears to be compensating for not having quite the right colors available, and honestly doesn't look too good on close inspection.

I don't see any difference in the color set used, maybe it's the dithering that makes you think they don't have "quite" the right colors.  But regardless, I agree that the dithering stands out too much and just doesn't really work.

Awesome's palette has been significantly altered - the alien things look more more red than brown<snip>
It would be an improvement (albeit a small one) to use that version of Menace, and Awesome too if someone can 'correct' the palette to more closely match the original.

Hmm, I actually kinda like the palette used on the Mac version a little better, but I guess it's a personal preference.  With the right software it should be easy enough to change the colors, there should only be maybe 7-8 colors used.

[WNivek]

Well that was easy. It may not be an exact palette match, but it's close.

You're probably right about the Beast/Beast2 dithering. I'm just too used to seeing that style of dithering used in situations where the colors available almost match what's needed, but not quite.

[0xdeadbeef]

Maybe you didn't notice, but the versions in Lemmini are upscaled to make them look smoother. I did something similar to the Mac's Awesome and Menace levels:

http://lemmini.de/special_0.gif
http://lemmini.de/special_3.gif

Since these versions IMHO look better than the versions I'm currently using, I think I'll include them in the next version.
Note that black is the transparency color, but in the browser, it's displayed white (transparent). It will of course be black (or dark blue) in Lemmini.
Any opinions?

[ccexplore]

Well the Mac versions only did smoothing on isolated areas, so one possibility would be to manually cut and paste the parts on the Mac versions that were enhanced and paste them over the existing Lemmini graphics.  That way you get general smoothing for the parts that the Mac versions didn't do anything on.

[0xdeadbeef]

I thought of it, but I think the method I used is less pain in the ass

[ccexplore]

Oh nevermind, I misread.  I thought you were showing the PC versions upscaled.

[ccexplore]

Hmm, now that I compare the un-smoothed and smoothed versions, I find the smoothed versions to have a bit too much of a blurred look and actually like the unblurred versions better.  I think the problem is that with your smoothing, it tends to simply smooth the "edges" around the individual lo-res pixels.

Let me think about this a little more, maybe I can come up with a better smoothing algorithm that works better.

[WNivek]

What about Hq2x?
beast-hq2x.gif
awesome-hq2x.gif
menace-hq2x.gif
beast2-hq2x.gif

[0xdeadbeef]

Well, I dunno, but I like my versions better. The Hq2x algorithm seems to create artefacts on the edges. Also look e.g. at the monster's eyes in Awesome: there's a low red color sweep added between eyes and face.

[ccexplore]

Hmm, looks like Awesome is simply tricky to scale right.  The problem is that the dragons' bodies are essentially texture but with lo-res and lo color-depth pixels.  Lemmini's scaling ends up blurring the individual pixels, and hq2x ends up over-detecting false edges within the texture.

I think a dithering approach might work better, but I won't know until I write a program and try it out.  I have a feeling I won't do much better than what we have.

[0xdeadbeef]

What makes Awesome so frustrating is the fact that it's only one body part which is just scaled and replicated. However not even the artists of the Mac version seem to have had access to this piece as they only exchanged the head and left the rest in lowres.

[WNivek]

Hmm, I wonder... Any chance someone has access to a copy of the game Awesome, and is able to extract the original sprites from there?

[0xdeadbeef]

Good idea!
Actually, I was able to rip the graphics from Awesome running on WinUAE:
http://lemmini.de/Awesome_tile.gif

Surprisingly, at least the version used in the Mac graphics seems to be a little improved (the "horns" look better).

A manually improved (but still lowres) variant:
http://lemmini.de/Awesome_tile2.gif

[WNivek]

I'm no expert, but it looks like the image you have there is slightly stretched, with certain individual rows and columns repeated to fill the gaps. It'll look better if you can snag an 'original size' version. Or gimme a while and I could probably manually cut out the doubled lines. I'd get right on it, but I'm sorta busy at the moment.

[ccexplore]

Surprisingly, at least the version used in the Mac graphics seems to be a little improved (the "horns" look better).

It's not surprising at all; it's not like DMA downgraded from the original Awesome graphics; if the Lemmings level is indeed an exact screenshot of a level from Awesome, the tile should be near identical to what you'd see in the Lemmings level.

The only use of the tile is if you want to manually touch-up a hi-res version of it, and then manually replace each instance of it in the level graphics with a hi-res version of the tile.

[0xdeadbeef]

It's not surprising at all; it's not like DMA downgraded from the original Awesome graphics; if the Lemmings level is indeed an exact screenshot of a level from Awesome, the tile should be near identical to what you'd see in the Lemmings level.

Yeah sure, I just wondered why they improved only a few pixels here and there and then gave up on it. Indeed the changes are so minor that first you'd think they only exhanged the two big heads.

The only use of the tile is if you want to manually touch-up a hi-res version of it, and then manually replace each instance of it in the level graphics with a hi-res version of the tile.

That's the idea. Indeed when also extracting the heads (and the star), one could create a program that creates the graphics from x,y positions and scales of the three object types. I'd think the downscaled body parts would look a lot better if they were downscaled using a proper algorithm and in the high resolution.

A lores head btw:
http://lemmini.de/head_lores.gif

Note that the left jaw has much more detail than the Mac mock up.

[WNivek]

I finally got around to cleaning up that body-piece tile. It's still small but I've cut out all the duplicated rows and columns, so it looks much better.


Not only does it look cleaner, it also overlays perfectly on the largest copies of the body tile on Awesome Level. So now someone just needs to produce a nice 2x version of it.

Also, between your rip, the Lemmings level, and screenshots from the Atari ST version* of Awesome, I've managed to piece together a good copy of the head sprite.


(* I couldn't get the Amiga one working, but the graphics of that guy seem to be pretty much the same between the two - only the colors changed, and I edited my work to match the palette of your Amiga sprite.)

I should probably note that the top two rows of pixels did not show up in the screenshots I was getting, nor do they appear in the Lemmings level, but I put them in 'cause you had them in the Amiga rip.

Anyone know for sure what that dark bit over the eyes is supposed to be? Is it perhaps a reflection of the player's ship?

[WNivek]

Sorry to double-post, but I've found a bit of a bug regarding the top of the Lemmini's playfield. Specifically, if a lemming is somewhat off the top of the screen and the player tells that lemming to bash, Lemmini crashes.

Additionally, under certain circumstances it's possible to make a lemming build past the top of the level, causing a crash. I have seen this happen before, but have thus-far been incapable of reproducing it. It may be worth noting, though, that the one time it happened, it was caused by a lemming who had previously managed to climb up through a ceiling by way of repeated building.