How Were the NeoLemmix Genesis Tilesets Originally Ripped/Produced?

[Dullstar]

With the new update to NeoLemmix allowing background colors, it was brought to my attention that, for gameplay reasons, the background color of the Crystal set should be changed to avoid things being the same color. Just to see how things were in the Genesis version itself, I loaded it up in an emulator and noticed the background was tinted in the Genesis version.

The colors appear different. The darkest color in the crystal set is still the same as the background color, but the background color is different. So at first I was like, oh, the background color doesn't need changing, since if the background is black and the darkest color is dark blue, we're fine! Then I looked at the set in NeoLemmix and noticed its darkest color is 0,0,0. The colors don't match each other.

So I checked more colors and noticed that none of the colors actually match. But I'm not sure if it's just the emulator being stupid. It doesn't appear to be, though, simply by logic of the fact that there is both 0,0,33 for the background and 0,0,0 on the interface itself (see screenshot)



Anyway, going through the rest of the colors in the screenshot I can see discrepancies between the colors within it and the colors in the NeoLemmix tilesets.

As a result, I'd like to know more about how the tilesets were first created and try to isolate whether the tilesets are wrong or my emulator's wrong (or if both are wrong!). I remember there being Genesis versions of the tilesets back in the Lemmix (not neo) days, so I would hazard a guess that these sets are probably descended from those, especially since the tilesets contained no NeoLemmix exclusive features before I updated them - but if that's the case, how were those created?


Upon a bit more research, I can quickly verify that the emulate-and-then-extract-colors-from-a-screenshot method is probably not the best way to go about doing things, since I was able to get different results simply by tweaking the emulator settings slightly.

I imagine that if the color data was ripped from the game directly, it's probably correct. (If we don't know, does anyone know how to extract this data so I can compare it with what I've got?).  The explanation I've come up with for the issues with the crystal set specifically would be that the palette was extracted then a palette switched performed involving the original pieces; and with black being in the orig_crystal set's palette twice, the switch didn't work correctly. I have no way of verifying this, however.



I want the coloration in these sets to be accurate as possible where it doesn't cause gameplay issues, so if there's a color problem, I want to fix it.

[namida]

but if that's the case, how were those created?

I believe it was ccexplore who created them. In fact, these only used a custom GROUNDxO.dat file (these files contained the metainfo - ie: trigger areas / types, animations, and indeed, the palette; while the VGAGR file contains the actual image data), which was used together with the usual VGAGRx.dat file.

I would assume the Genesis version probably doesn't use these files exactly. Most likely, they were made by hand, using data that was extracted from the Genesis version some other way. I wouldn't know what that "other way" was though.

[ccexplore]

TL;DR Considering that the styles were more accurately "DOS styles palette-swapped to imitate Genesis", feel free to adjust the colors as you see fit.

More background:

First, keep in mind that the so-called Genesis styles were not direct ports of the actual styles in Genesis at all.  (If they were, some of the terrain graphics would've been actually different besides color, as compare to DOS.)  In fact, had I been lazier I could've never bothered with them.  The primary goal at the time is to make the Genesis-specific levels accessible to users of DOS Lemmings, CustLemm and Lemmix, rather than them having to hunt down an emulator and ROM.  It is obviously not going to be the exact same experience as on the Genesis, since even the game physics already has minor differences (or in some cases not so minor, like the timer-speed difference affecting levels like "Just a Minute", or the fact that Genesis's level area is 512 pixels wide rather than DOS's ~1600).  So the idea is that the purists who wanted an absolutely authentic experience would've just used an emulator already, and for the rest, they would prefer just needing to get some level files in order to experience something very close to the Genesis levels, without having to set up anything else.  And so indeed, you can play my converted Genesis levels with DOS styles--the levels are basically set up for using the unmodified DOS styles that come with DOS Lemmings/CustLemm/Lemmix.

I did recognize however that even though the graphics and gameplay between DOS and Genesis are nearly (but not actually) identical, the Genesis version uses different shades of colors than DOS--a difference that is decidedly not minor in that it affects every visible element in every single level.  But since DOS styles uses a palette stored separately from the actual graphics to assign the actual colors used, it would take relatively little effort on my part to create basically palette-swapped versions of the DOS styles by simply modifying a few entries in the GROUNDxO.dat files while leaving the actual graphics in VGAGR files intact, and then you would get the Genesis colors on DOS styles.  And I figure seeing the Genesis colors may be compelling enough for some people that they would take the extra minor effort to setup those extra style files so the levels look "more like Genesis" in the most noticeable way.  And that was the origin of those "Genesis styles".  Perhaps a more accurate name would be "DOS styles palette-swapped to imitate Genesis" but that doesn't quite roll off the tongue as smoothly.

DOS Lemmings/Custlemm/Lemmix style data (ie. the GROUNDxO.dat files where actual color information are stored) do not support changing the background color at all.  So even though I can clearly see the Genesis uses a dark tint of blue for the background, there is nothing I can do to support that particular color change.  There is a possibility that at the time I considered it more preferable for Crystal's darkest non-background color to match the background color, like it was the case on the actual Genesis (perhaps so that things that were not readily visible don't suddenly become more visible, or something like that--keep in mind that the colors can potentially be used in interactive objects and animations as well).  So while I don't specifically remember doing so, it is conceivable that I purposely left the darkest terrain color black in order to match the immutable black background you are forced to use in DOS Lemmings/CustLemm/Lemmix.  The other explanation is a simple oversight on my part.

One other thing:  IIRC colors are stored as 18-bit values (6 bits per RGB component) in DOS/CustLemm/Lemmix GROUNDxO.dat files [because the actual hardware at the time of DOS Lemmings only support that many bits per RGB component for palette colors].  Most computers at the time of the "Genesis styles" (and nowadays) represent colors using 8 bits per RGB component.  I don't remember anymore, but do believe I simply used screenshots from the emulator to get the colors to use, but it will then still have to go through an 8-bit to 6-bit conversion in order to specify the color in the GROUNDxO.dat files.  So in terms of 8-bit RGB component values when those 6-bit values in GROUNDxO are eventually up-converted back by Lemmix/DOSBox etc. for display on PC, they may end up slightly off from the values you get from the emulator, but should be by no more than 3 per component (since 2 bits map to 4 distinct values).  This obviously cannot explain away the difference of 33 for the darkest non-background Crystal color, so for that particular difference, it was either intentional or an oversight as mentioned earlier.

With the new update to NeoLemmix allowing background colors, it was brought to my attention that, for gameplay reasons, the background color of the Crystal set should be changed to avoid things being the same color.

That's the thing, it was well-known that the Crystal set (both in DOS as well as Genesis) used identical color for the darkest terrain color and the background color, and I even seem to recall at least one actual custom DOS level (or if not, then at least proposal of such a level) explicitly making use of that fact to create evil invisible terrain, for better or worse.

I can perfectly understand the proposal to purposely deviate from actual DOS or Genesis in this regard.  But at least for the purposes involved at the time, there's a chance I might have specifically chosen to preserve this property of the Crystal set.

Upon a bit more research, I can quickly verify that the emulate-and-then-extract-colors-from-a-screenshot method is probably not the best way to go about doing things, since I was able to get different results simply by tweaking the emulator settings slightly.

That seems a little suspect.  Which settings are they exactly and what emulator are you using?  It is possible the settings were provided only as workarounds for certain games that they weren't able to perfectly emulate resulting in undesired colors.  I don't remember what emulator I used but I did not change any color-related settings from the default, and I think I also cross-verified a few colors with screenshots of Genesis levels on www.deveria.com (now defunct but you can use archive.org wayback machine to look it up).  Granted, the screenshots from www.deveria.com are likely taken from an emulator left at default settings as well.

Besides the background color and Crystal's darkest non-background color, what other color discrepencies did you find?  I would not have expected any other major color discrepencies (at least relative to an emulator running on a PC) besides those two.

[Dullstar]

Most of the color discrepancies are fairly minor, as they're all at least close, with the one exception.

Changing the video settings would have slight impacts on the color, but nothing huge. I imagine the default settings are probably the most accurate, but it has settings to increase things like brightness.

Based on what I can tell, the best course of action is probably to fix the one color in the one set and leave everything else as is.

I suspected they were originally made as palette swaps, since that'd probably be the most compatible way to do it.

[namida]

I believe there's a few differences in trigger areas and order of the pieces too. I don't know if the trigger area differences are replicated in the Lemmix versions; I'm pretty sure in the NeoLemmix versions (where the Genesis styles weren't converted until a bit later, IIRC) I explicitly made sure the standard and Genesis variants had the same trigger areas.

[ccexplore]

I believe there's a few differences in trigger areas and order of the pieces too.

I had a chance to review the original thread and apparently it was actually the trigger area differences that was the major motivating factor at the time for creating the Genesis styles, not merely because it was easy enough to make the colors look more Genesis-like.  The colors seemed almost an afterthought compared to dealing with the trigger areas.  That said, making the levels work reasonably on unmodified DOS styles was clearly an important enough goal that apparently on affected levels using the objects that have significantly different trigger areas, I actually created multiple versions of such levels, one for unmodified DOS styles and another for the Genesis styles.

I think the ordering of the pieces should be identical to DOS though, unless someone else changed it subsequently when ported into NeoLemmix.  At the time I made the sets, there was no reason pieces ordering need to differ when it can always be compensated in the level data itself.

[namida]

I think the ordering of the pieces should be identical to DOS though, unless someone else changed it subsequently when ported into NeoLemmix.  At the time I made the sets, there was no reason pieces ordering need to differ when it can always be compensated in the level data itself.

This is unchanged in the NeoLemmix version from the Lemmix ones.