I had a go at it, and got up to level 11 before Lemmini's lack of the fine control features Lemmix/NeoLemmix have got too annoying... xD

Definitely seems like a good pack! However, one thing I would point out - the background on level 7 (I think), "City Builders", makes it VERY hard to see the cursor...

The saving as "testmode1" (or "step1_1" when not in test mode) is a glitch in the current version; it'll be fixed in the next update.

Doing video tutorials is indeed a great idea, and probably a lot less tiresome than a written/image tutorial. I'll definitely consider that idea. I'm actually holding off on this for the moment, in case there's any major changes - any tutorials I do do at the moment will probably be relating only to basics and/or level editing (including how to use new features).

Okay, update is here. Do note that although it supports the new NeoLemmix graphic set format, the current version of NeoLemmix itself does not. (I've already implemented support of it for the next player update, though I still need to implement editor support.)

V0.8 Beta
>  Object graphics can now be imported and exported (in BMP or PNG) format as strips; ie: images
   that contain all frames of an object arranged horizontally or vertically. The buttons to do this
   are right below the single frame import/export buttons.
>  The new NeoLemmix graphic set format (supported in NeoLemmix from V1.31n onwards) is now
   supported. This format avoids many of the limitations associated with the old format, such as
   the maximum size of 248x255 per piece/frame, the requirement of widths divisible by 8, and so on.
>  Fixed a bug where all pixels were treated as non-transparent in imported Cheapo graphic sets.
>  Fixed a bug where the frame order of entrances in imported Cheapo graphic sets would remain in
   the Cheapo order (ie: first frame closed, middle frames opening sequence, last frame open) instead
   of being changed to the NeoLemmix order (ie: first frame open, second frame closed, remaining
   frames opening sequence).
>  Fixed a bug where the "black" background might be colors other than black (in particular, often
   it would be white) on graphics imported from PNG files.
>  Fixed a bug where if you alter the trigger areas while Display Trigger Areas is enabled, the
   displayed trigger area wouldn't update until you did something else that caused the image to
   be refreshed (such as viewing a different frame, or turning Display Trigger Areas off and on
   again).

Remember, this should still be treated with caution. Keep backups, don't overwrite files you can't afford to lose, save often, etc. Rather than creating a huge mess of files with the Export > INI / PNG > Full option, you can save as the new NeoLemmix format; it will save full 24-bit (+ 8-bit alpha) images without rounding off the width to the nearest multiple of 8.

https://www.dropbox.com/s/3pwu2pkky6npkxx/GSTool_0.8_Beta.zip

Just wondering, how different (in terms of capabilities, not format) are your graphic sets from Lemmings ones? If they're not too diferent, and there's enough interest, would you like me to add support for them to the NeoLemmix Graphic Set Tool?

I could probably recolor the black pixels to a dark gray instead; the main reason they're black at the moment is because that's how it was in the actual Master System version of Lemmings.

As for the blue dot; there's a few letters in the font actually that have odd things. That's not a player glitch but rather the actual graphic of the letters in MAIN.DAT; the letters haven't been altered in any way as far back as the very original DOS Lemmings (though it is possible that DOS had some code that modifies how they're drawn, that isn't reproduced in Lemmix).

Loading and saving images as strips is now supported. Loading supports both BMP and PNG, saving is currently PNG only. Obviously, when importing you have to manually tell the editor how many frames there are and whether they're arranged vertically or horizontally. Exporting currently always arranges them vertically (this is in line with both how LemSet worked by default, and what (Super)Lemmini expects in object images); if there's any major need for horizontal to be supported I can add it but it's not a high priority at the moment.

Currently BMP loading treats #FF00FF ("death" magenta) as the transparent color, but I plan to make this customizable before any update is released. PNG, of course, generally will contain a proper alpha channel if the image needs one, though it still has the option to use a transparent color again (but for this too, it's currently hardcoded to death magenta).
EDIT: Custom selection of a transparent color is now supported.

Just as a heads up, I've already prepared the first rounds for the next voteoff (once this one finishes), which will be a six-way voteoff between the four Xmas/Holiday games plus Covox and Prima. The decision to combine them comes from that the total number of levels they have combined is roughly comparable to the number of levels in any of the other voteoffs. So, if you need to refresh your memory of them, now's as good a time as any to start.

You can get them here:
http://www.neolemmix.com/old/lemmix.html

Or if you prefer NeoLemmix:
http://www.neolemmix.com/old/neolemmixplayers.html

In both cases X91 + X92 are in a single combined player, as are H93 + H94 (the former because even combined they only have 6 levels, the latter becuase in the original DOS versions too H94 contained all the H93 levels). If using the NeoLemmix version, please note that the voteoffs are based off the DOS versions while the NeoLemmix levels are based off the Amiga versions, which means Flurry 8 (H93) is an entirely different level. The regular Lemmix players are indeed based off the DOS versions.

Moving to SuperLemmini shouldn't be too difficult; all you'll have to do is move the trigger areas (on objects in custom styles) downwards by about half a lemming's height. This is because SuperLemmini (like Lemmix / NeoLemmix, and unlike Lemmini) checks for trigger areas at the lemming's foot.

Aside from that, Lemmini graphic sets and levels *should* work on SuperLemmini without any problems, as far as I'm aware.

Porting to NeoLemmix would be a bit tricker, but should still be doable. The main issue is that the graphic set tool can't open Lemmini graphic sets yet, though it will be able to in the future.



One other thing to be aware of (for both SuperLemmini and NeoLemmix) is that the glitch of creating a left-facing entrance by putting a piece of terrain behind it no longer works. However, you don't need to exploit glitches to get left-facing entrances anyway, as both of them natively support making left-facing entrances.

If GigaLems's level of quality was anything to go by, then these other packs should also be very good.

Qualifying levels are:

Crazy 10 "ROCKY VI"
Havoc 07 "Creature Discomforts"

Round 5 is now up.

Two glitches relating to Cheapo graphic set conversion have been identified; please don't use this tool to convert Cheapo graphic sets until it's updated. It seems to have no issues with all other supported formats.

EDIT: Another one, imported PNGs may not always have a *black* background when the black background option is enabled; it may be a different color instead. However, this has no impact on the output graphic sets (regardless of choice of format), so it's a purely graphical glitch. One workaround to solve it is to save to LemSet-compatible INI/PNG format, add "rgb_24=1" to the INI, then reimport it.

I'm not saying anything about what my plans for that set are, for now. All I'll say (and this is really nothing more than a pointless trivia detail) the name I've given to it is "Candy", and that that is an actual level I plan to use, not just a test / proof-of-concept one.


EDIT: NeoLemmix player can now load embedded graphic sets in this format. It only directly works with graphic sets that are named (rather than numbered), but there's also a workaround which will match known numbers to their files (eg: in the Orig player, if it detects a level that uses Graphic Set #0, it'll automatically attempt to match it to the Dirt set in the new format).

Alright so, the tool has fully implemented the format, the NeoLemmix player can now load the format, and as such, and we now have 24-bit color graphic sets at last! Or 25 bit if you count the alpha channel. (The format actually stores a full 8-bit alpha channel, but NeoLemmix doesn't support this yet; all non-zero alpha values are treated as 255.) Still left to do is support loading the new format when embedded in the EXE; currently it can only be loaded from an external file, but this should be very easy to do.

Here's a screenshot showing it. And yes... you are right if you think you've never seen this graphic set before.

Not overly familiar with either Java or Lemmini, but my first guess would be that the level references a terrain piece (or object) number that doesn't exist in the corresponding graphic set?

As far as the possible new format goes - I've yet to write a loading routine, which also means as of yet it's a tad hard to tell whether the save routine saved the data accurately or completely botched it up; but in terms of filesize, it's showing a lot of promise. I've tested two graphic sets - the Horror set, and one other (which I can't reveal too much about at the moment but I will say it has a VERY large variety of colors in it), both of which are 18-bit graphic sets in existing format, and I have 24-bit source image files for. In the case of the Horror set, results for both the old and new format (both compiled with this tool, rather than going off the existing LemSet-made version) are roughly the same filesize; while for the other graphic set, it's actually ~15KB smaller despite the extra 6 pixels of image depth. And, the time taken (on my PC) from the point at which the "Save" button (on the file selector popup) is hit, to the time at which saving is complete, is about 1.1 seconds for the Horror set, and 0.7 second for the other one.

Indeed, this new format removes the limitation of piece widths having to be divisible by 8. It also theoretically allows an unlimited number of pieces (provided the graphics for them don't exceed 4GB in size after encoding but prior to DAT compression, which realistically, it's unlikely that limit will be hit by any reasonable graphic set), though in practice this would currently be limited to 256 terrains + 256 objects per graphic set due to the level format.

Now, here's hoping it's actually saving the accurate images and not a load of garbage... time to write a loading routine and find out!

EDIT: Although it works, it's not actually giving a significant filesize improvement over just storing a plain ol' ARGB bitmap image, so I'm going to change it to just use such, but with a shortcut of not storing the RGB values if the A value is zero. On the other hand, the metadata format is very nice.


(This indeed technically means that the graphic set format uses 32-bit images, although currently there are no plans for NeoLemmix to support partial transparency; the format's capacity for it is mainly just future-proofing.)