ripped Mac Lemmings graphics

[ccexplore]

This was originally a private request from Leo, but since PMs here don't allow attachments, and conceivably some other people may also want the graphics in the future, I'm posting them here as attachment.

[EricLang]

Ah great. I think I already got these from you a long time ago.
I have some questions on the colors.
The "transparent black parts" all seem to be RGB = 0,0,17.
The "non-transparent black parts" all seem to be RGB = 1,1,1.
How did you convert these colors?

[Leo]

Thank you very much for Mac graphics. If you can rip (at least) 'Xmass Lemmings' sprites from Mac version, will be great (no hurry).

[Mikex62]

I've been looking for these for months! Thanks! BTW, the Hell theme goal is HIDEOUS! 

[ccexplore]

I have some questions on the colors.
The "transparent black parts" all seem to be RGB = 0,0,17.
The "non-transparent black parts" all seem to be RGB = 1,1,1.
How did you convert these colors?

It's been a while since I did the conversion so I don't remember for sure.  But I believe the bitmaps in the game were all 8-bit indexed, meaning each pixel is one of 256 colors selected from a fixed palette.  So the 0,0,17 and 1,1,1 comes from whatever the palette says.  I believe in the bitmap the transparent pixel would have value 0 (ie. palette entry #0, which I guess apparently has color (0,0,17)).

Likewise the "non-transparent black" is some other entry in the palette.  Actually, now I think of it, it is possible that the palette may originally have the RGB as (0,0,0) for non-transparent black, and my conversion program purposely make it (1,1,1) instead to make it easier on other programs that may consume these bitmaps treating (0,0,0) as transparent.

I do think that if you run the actual Mac game, they really do use RGB (0,0,17) to paint the background (in other words, the background is not exactly (0,0,0) pure black like on the PC version, but rather this shade of very dark blue as the RGB value suggests).  So in that aspect the (0,0,17) is accurate as well.

I should be able to modify my conversion program to output in other ways.  For example, I can make the bitmaps be 32-bit ARGB and just encode the transparent/non-transparent information as alpha.

[EricLang]

The transparency is a bit of a problem when reading other styles. I believe the gifs of Lemmini where problematic as well.
In the crystal set there is also pure black which is really terrain.
Dos lemmings are not a problem because all bitmaps are palette-based.
I'm still not sure if I am going to use the alpha channel (all drawing is done with 32 bits bgra bitmaps) or just setting terrain-black to RGB 0,0,1.
I think the latter one is more clear for a user who edits pictures.

I can do the conversion easily if ALL bitmaps use the same coding which I mentioned. And I believe this is the case.

The problem in the near future with my program will be how to interpret things when a user drags 40 bitmaps into the program and says: "here you have some new terrains" for the Mac-style.

[ccexplore]

Well, there are a number of considerations to take into account:

- There's a difference between how you represent the graphics internally in the database and game engine, vs which file formats you may support for purpose of importing/exporting graphics to/from the database.  It wouldn't be a bad idea to have a design where graphics outside the database can be in various different formats (so users don't have to do their own conversions or be stuck with the same format internally used by the game which may not be fully supported by whatever favorite graphics editor they use), and conversions happen whenever graphics go in and out of the database.  Conversions may be supported with a plug-in architecture that allows more file formats to be supported in the future.

- alpha transparency (if fully supported) can also be used for anti-aliasing purposes to smooth out edges of bitmaps.  So if there's a concept of supporting that usage of transparency, you might want to consider having a separate mask bitmap that explicitly specifies which pixels are transparent (as in no terrain), rather than strictly based on the alpha value.  Although one may argue that since the Lemmings game physics is inherently pixel-based, maybe it's better for the player to avoid transparency-for-anti-aliasing, to minimize ambiguity (in terms of terrain vs no terrain) with what they see.  Anti-aliasing may also be less of an issue with the higher-resolutions supported in today's displays.

If you don't plan to make full use of the alpha channel, it should be acceptable to go internally with a simple convention such as RGB 0,0,0 is transparent while all terrain-black will be made RGB (0,0,1).  For import/export, note that there is an informal convention to use other "color key" such as magenta to represent transparent pixels, or in other cases the color key for transparency is the color used in the top-left pixel of the bitmap.  It would be a good idea to support such variations for importing and exporting graphics, even if we (say) initially stick to just supporting one file format for import/export like BMPs.

===========

As a further note, rips from other ports (eg. Mac Lemmings) will invariably involve the user writing or using some sort of conversion program in the first place.  So I think it is of lower importance compare to the case of user manually creating graphics (or creation through means such as starting from screenshoots).  At least that's my guess.

[Leo]

May I say something about background color on the Amiga?
It's not black, it's dark blue. This picture is captured from the emulator, so I don't know is it 100% correct (here is 8,12,57), but certainly it's dark blue on the Amiga also (I remember).



Screen resolution is really interesting. It's not 320x200 as most people think. It's separated in two parts:

Play area 640x320 (on this picture) or in fact 320x160 on the Amiga (dark blue background)
and
Control area 640x80 (black background)

Pointer is (probably) hardware sprite (not really in the chip RAM).

And control area is probably also divided in two parts

Counter area 640x32
and
Skills/map area 640x48

As conclusion, screen consist of 3 parts:
Play area 320x160 (4 bitplanes, 16 colors)
Counter area 640x32 (3 bitpanes, 8 colors)
Skills/Map area 640x48 (4 bitplanes, 16 colors)
 and hardware sprite pointer (3 colors + transparency)

[EricLang]

Yes that is interesting as well.
I am going to try to implement correct game-mechanics for higher resolution as well (because having data is nice, but we want to play of course).
Wondering how and where to retrieve / store screensizes and/or aspectratio's. For dos I know it is designed for 320x200...
I could just double this for higher resolutions.