Thanks for the reply. While you are right, I have very limited free time for that kind of incremental investigation, so I just threw it out there in case the community had some knowledge to share. The video in your signature, for example, shows one unexpected quirk of the engine.

Most likely I will release the editor at some point, once I build a more usable gui on top of my code, and let interested parties work with me cataloguing what the actual game will allow and not.

Greetings,
A couple of weeks ago I started working on a modding tool for Lemmings 2 - a combined level and style file editor. While I have made a lot of progress with my code interfaces, the game seems to enforce some limitations that I have not seen documented anywhere. Attached is an edited style and level file, which works for a while - but at some point it either:

soft locks the game
or
exits the level counting all lemmings as dead.

The edits to the style file seem fairly safe to me; I just injected some custom tile graphics (and corresponding previews), presets and changed the tiles used by some object tilemap animations.

I was hoping someone with more experience of the game and l2 tech could help point me in which direction to look to find out which limitations I am exceeding.

The files replace polar level 1, and I ran the game using the l2-fix executable.

The sprite decoding algorithm I described above is correct, I just had a bug in my concrete implementation that made it "almost" work. I have decoded all the sprites successfully, and to answer my own questions - the answers are no and no.

Incidentally, all the styles have at least one sprite associated with them - but the styles that only have one sprite have this image, in different palettes:

I can recommend Quake on Steam which received a major update recently. If you already own it, you get the update for free as well. Been enjoying playing online coop/deathmatches with friends, and the new episode is amazing.

https://www.reddit.com/r/mildlyinteresting/comments/phm731/found_my_first_game_while_cleaning_out_my_old/

Quote from: EricLang on January 08, 2014, 11:54:26 AM
Yep, same system I thought too. Only the low and high palettes are 128 in size now.
I''ll first scan through all tribes files to check if there is some gui palette hidden inside there.

Since the topic is not locked, I will take my chances reviving an old thread.

I have injected a tile of palette entries 128-255 into the styles files, and used it in one level of each style - which allowed me to extract the rgb-values for the high palettes of each. An interesting find is that palette entries 145, 146 and 147 cycle in all styles; red, red, yellow. (at different modes - so you can use it to make some kind of monochrome animation) Palette entries 164 and up are black in all styles.

The attached file contains the styles and levels (need to be used in combination) that i used, as well as screenshots of each palette, plus a text file with rgb-values for each entry. Note that these colors are according to dosbox on my system. Those who are interested can load up the files on their own systems and compare. (I used the l2-fix executable to run the game)

---

I also want to point out that the formula used in the original post for creating bitmaps from the 4-layer encoded graphics only works if the width of the image is a multiple of 4. Otherwise the 4 layers will have different sizes, the first being the biggest. For example if the width is 43, layer 1,2 and 3 will have widths 11, while layer 4 has width 10. (at least this is how it seems to be)

This is important for the run-length encoded sprite data (L2SS section) in the style-files which I have trouble decoding in some cases. For Medieval I have no problems, for Classic there is supposed to be one sprite which I cannot decode, and for Circus the 7th sprite cannot be decoded by my implementation.
EDIT: After loading in the extracted palettes and redrawing the sprites, they are all little off especially near the bottom. I think my sprite decoding algorithm is not 100%.

For those who can answer, I have 2 questions (which I will investigate myself if I have to, but if someone can tell me it will save me some time):

• Is it possible for the run length encoding to spill over from one line to the next (meaning I need to check the x-index for each pixel copied/skipped and "manually" do a line shift)?
• Can there be garbage data in this section if it is not used by any sprite animation? Say if the animations only use sprites #0, #1 and #2 - there is no use trying to decode sprite #3 even if the L2SS header tells me there are 4 sprites?

My implementation for decoding one layer is roughly as follows (I have the correct layer width parameter I believe, as I know they will vary for sprites where (width mod 4) !=0);


decode_sprite_layer(int layer_width, int layer_height, const std::vector<byte>& input) {
std::vector<byte> result(layer_width* layer_height, 0); // initialize with all zeroes
int x{ 0 }, y{ 0 };
        int stream_index {0};

while (true) {
    int high_nibble = (input.at(stream_index ) & 0xf0) >> 4;
    int low_nibble = input.at(stream_index ) & 0x0f;

    ++stream_index ;

if (x == 0 && high_nibbe == 0xf)
return result;

// perform copy/skip for high nibble
bool copy_mode = (high_nibble >> 3) == 0;
int count = high_nibble & 0b0111;
   
if(copy_mode) {
  // copy all bytes between input[stream_index] to input[stream_index + count - 1] inclusive, to result, starting at result[y*layer_width+x]
  // increase x and the stream_index by count
  } else {
  // only increase x by count, but do not touch the stream index
}

// HERE: perform copy/skip for low nibble
// logic the same as for the high nibble

if(low_nibble==0) {
x=0;
++y;
}

}

}