jLevelBuilder 1.88 (june, 9th 2021)

[namida]

The 4x4 object thing is a limitation in Lemmings itself. While you can save any X coordinate in the file, when Lemmings loads it, it rounds it to the nearest 8. The same is true (in multiples of 4) for the trigger area's Y coordinate, although that only affects function - *graphically*, it can be at any Y coordinate (and all editors will allow you to place it as such).

With steel areas, it's not even a matter of the engine but the level format itself. The coordinates and size are divided by 4 before being stored in the file. For example, if it's 16 pixels wide, the file will save the width as "4". (Actually, it subtracts one from the final value before saving it, so it'd save it as 3, but you get the idea.)

Lemmix could most likely be recoded quite easily to avert the X-coordinate rounding and trigger area rounding. Positioning/sizing steel areas more finely, on the other hand, would require a modified level format. One possible way this could be done while retaining backwards compatibility would take advantage of the way steel is stored - it's stored as 4 bytes, the first which denotes the X coordinate, the second denotes the Y (well, the X spills over into it a little bit as well), and the third denotes both the width and height. The fourth one is always zero. The 8 bits of this could then possibly be used to signify slight offsets from that 4x4 grid; you'd have two bits per value, which allows you to shift it by up to 3 pixels, thus resulting in perfectly covering the gaps between the main 4x4 positions. Once an editor that supports this is developed, coding Lemmix to take advantage of this shouldn't be too hard.

Of course, this does depend on exactly how Lemmix processes the trigger areas - it may have to be recoded to consider each individual pixel rather than just each 4x4 region. I believe the original game works on 4x4 regions, and since Lemmix aims to emulate it as closely as possible, it's quite plausible Lemmix also works this way. That being said, it's equally plausible that it in fact does consider each pixel individually, and simply rounds to the 4x4 areas when manipulating them (like when placing blockers) - especially since the editor supports Lemmini format, which I believe is not subject to these restrictions?

I did once have a look at recoding it to load a custom, tidier format (ie: no values spilling over into each other, no hardcoded limits on number of objects/steel/terrain, a specific flag for fake objects rather than relying on index) obviously with such restrictions removed eventually, but I can't quite work out exactly how it's load level code works. Delphi isn't exactly one of my strong points...

[ccexplore]

Of course, this does depend on exactly how Lemmix processes the trigger areas - it may have to be recoded to consider each individual pixel rather than just each 4x4 region. I believe the original game works on 4x4 regions, and since Lemmix aims to emulate it as closely as possible, it's quite plausible Lemmix also works this way.  That being said, it's equally plausible that it in fact does consider each pixel individually, and simply rounds to the 4x4 areas when manipulating them (like when placing blockers) - especially since the editor supports Lemmini format, which I believe is not subject to these restrictions?

Don't get confused between Lemmix game emulation vs Lemmix level editor.  I don't know much about the editor's code but like you mentioned with supporting Lemmini format, the editor portion of the program should have little trouble handling non 4x4 alignments.

Game emulation is a somewhat different story.  As you said, accurate emulation of DOS game means trigger areas (which includes steel areas since they are represented the same way in the DOS game) are tracked in units of 4x4 regions rather than pixels.  In programming terms, think of representing the level area as a 2-dimensional array in a map-like fashion, except each array element is a 4x4 region rather than a pixel of the level area.  I refer to it as the "trigger map" when describing the DOS game mechanics to Erik.

The good news is that if I recall, the Lemmix programming has a specific function to read, and another to write, to this "trigger map" array.  Let's say those functions are named "ReadTriggerMap(x,y)" and "WriteTriggerMap(x,y)", with x and y being unaltered x and y values (the "rounding to multiples of 4" effectively always happens inside the functions rather than outside).  All the programming for the game mechanics, and I believe level loading as well (for the game emulation), call those functions to do their work rather than directly reading/writing the array.  So to change the game mechanics to track triggers by pixels, mostly you just need to modify ReadTriggerMap and WriteTriggerMap and change the dimensions of the trigger map array.

[namida]

Awesome.

Do you have any idea exactly how Lemmix handles loading levels? I couldn't really make sense of it... like, I could see where it defines the variables that values are loaded into, but not how it determines whether they're shorts or bytes to load etc, or how to add/remove from it, etc... I do understand the relevant general concepts, I'm just not sure how to go about breaking down and tracking down the bits of Delphi code specifically, so if you (or anyone else) could give a quick outline on how it works and where the relevant functions are...

[LJLPM]

I have uploaded the new version (beta 1.20): 3 new features added.

- 1) now, you can use the "Auto-Snap Settings" window (http://www.lemmingsforums.com/index.php?topic=794.msg17576#msg17576" class="bbc_link" target="_blank">http://www.lemmingsforums.com/index.php?topic=794.msg17576#msg17576) to force your items (Terrains, Objects, Steel, and Helpers) to snap on a multiple of "put-your-favorite-number-here" on X and Y axises.

By default, Objects auto-snap on 8/4, while Steel items snap on 4/4 (and no constraint for Terrains and Helpers).
You can freely edit this default config to meet your needs: just edit the "AutoSnap" values in the "config.ini" file (a value of "1" means "no_autosnap").

In the "Auto-Snap Settings" window, you'll also find checkboxes to enable/disable this auto-snap thing for each type of items.
And these checkboxes can be mapped to your own keyboard shortcuts if you want to quickly enter/quit "auto-snap" mode for Terrains, Objects, Steel and Helpers.
The "Auto-Snap Settings" window is available from "Options -> Auto-snap settings".

"And during a level-creation session, how can I know if "auto-snap" mode is activated for my Terrains, Objects, ... ?"
Well, simply refer to the little dots right to the "Selection" icons: first dot means "auto-snap activated on X", while second dot means "auto-snap activated on Y". Easy.
http://imageshack.us/photo/my-images/39/ano.png/" class="bbc_link" target="_blank">http://img39.imageshack.us/img39/6579/ano.png" alt="" class="bbc_img" />


- 2) the following new feature still concerns snapping stuff.
Additionally to the snapgrid (press 's') and the "Auto-Snap Settings" window for more permanent uses (see above), I have also added keyboard shortcuts to go even faster for enabling/disabling useful snapping settings on X and Y!
Press 'x' or 'y' to immediately activate some convenient and GLOBAL (= for every item) snapping settings: available values are 2, 4, 5, 8, 10, 12, 16, 24, 32, and 64.
Pressing 'x/y' will allow you to loop through these built-in handy settings http://www.lemmingsforums.com/Smileys/lemmings/cool.gif" alt="8)" title="Cool" class="smiley" />.
And when the job is done, simply press 'SHIFT+x/y' to cancel the snap mode in use.

These global snapping values only apply on items that don't have a specific "auto-snap" value activated (because of the "Auto-Snap Settings" window seen previously): therefore, this snapping feature actually concerns Terrains and Helpers only, by default.

In the upper-left corner of the GUI, you can see the currently activated global snap mode.
(in the screenshot below: snapX=8, while snapY=32)
http://imageshack.us/photo/my-images/32/xzcu.png/" class="bbc_link" target="_blank">http://img32.imageshack.us/img32/2861/xzcu.png" alt="" class="bbc_img" />


- 3) the last new feature is the addition of "Paste selection vertically".
The "Paste selection "horizontally" option already existed and it was convenient, but the "Paste selection vertically" option was missing. Now it's fixed http://www.lemmingsforums.com/Smileys/lemmings/laugh.gif" alt=":D" title="Laugh" class="smiley" />
Moreover, there were no button on the GUI for the "PSH" option: it was only available from the "CTRL+v" shortcut.
Now there are dedicated buttons for these options, and the "PSV" option is also available from the "CTRL+n" shortcut, by default.
Of course, all of these options can be freely assigned to your own keyboard shortcuts ("Options -> Key Configuration").

Clone-, H-, V- deselect source selection after operation, while Clone+ , H+, V+ keep source selection selected after operation.
http://imageshack.us/photo/my-images/713/v3m4.png/" class="bbc_link" target="_blank">http://img713.imageshack.us/img713/1654/v3m4.png" alt="" class="bbc_img" />

Because of all of these changes, you will need the new "config.ini" and "keyconfig.ini" files (not just the executable .jar file).

[namida]

I've begun editing terrain pieces in Lemmini so aligning things will be easier for your editor. I've put up with those stupidly placed boundary boxes for long enough  http://www.lemmingsforums.com/Smileys/lemmings/tongue.gif" alt=":P" title="Tongue" class="smiley" />

If I could code, I would change the the 4x4 object set-up...

One thing to be aware of - it could mess up the placement if you set them as upside down.

[namida]

The latest update seems to no longer be able to load a level I made in the first release. It misidentifies it as a special graphics level. I checked with a hex editor and the problem is not the level file itself.

Another level (which was made in LemEdit), it doesn't load all the steel areas correctly - some are missing.

[LJLPM]

1) What is the expected/normal theme of the level instead of "special"? (dirt, fire, snow, ...)

2) About the Steel issue, maybe it's because of the new "Auto-Snap" feature which is set to 4x4 for Steel items by default?
Go to "Options > Auto-Snap Settings", and uncheck snap for Steel on X and Y.
Reload your level, and see if the problem still occurs.
This same problem may appear for Objects too, since they are auto-snapped on 8x4, by default.
- you can easily get rid of these default settings and set your owns, by editing the "config.ini" file, and set a value of "1" for auto-snap options.

PS: in a general manner, if you could provide me a link where I can download the levels that don't work (as möbius previously did), it would be fastest way for me to fix those bugs (otherwise it will be difficult). Thanks! http://www.lemmingsforums.com/Smileys/lemmings/smiley.gif" alt=":)" title="Smiley" class="smiley" />

[Simon]

1) What is the expected/normal theme of the level instead of "special"? (dirt, fire, snow, ...)

Dirt.

All four vgaspec levels have the large single terrain piece, plus objects from the dirt set, recolored according to each vgaspec's palette. Any normal tileset should work with vgaspec.

-- Simon

[LJLPM]

Thanks for the info, Simon!

The latest update seems to no longer be able to load a level I made in the first release. It misidentifies it as a special graphics level. I checked with a hex editor and the problem is not the level file itself.

I found the reason: it is due to a bug in the first release, and it is now fixed.
- if your hex editor allows you to edit data, then just change the value of the byte located at address 0x001A from whatever-it-is to "02".
IMPORTANT: Make a backup of your level file before doing this!!!
- or if you prefer, I can handle this, if you tell me where I can download your level.

Another level (which was made in LemEdit), it doesn't load all the steel areas correctly - some are missing.

This one is strange... Be sure to have your keyboard's "numlock" key activated, and press "9" (numpad) to display all the Steel items in the foreground. Could you still confirm you're missing some Steel pieces?
If there's really a bug here, I definitively have to try/load your level to find the problem.

By the way, thanks to your message, I realized that default "Auto-Snap" settings needed to be scaled x2 because the level-editor uses hi-res sprites and a "x2" scale as in Lemmini (therefore, in the next version, Steel will auto-snap to 8x8 and Objects will snap to 16x8). This way, you'll be sure to design Lemmings1-fully-compliant levels!


EDIT: just a little teaser.
Tomorrow, I'll upload a new version with a VERY, VERY, VERY, COOL/USEFUL/POWERFUL new feature I've just finished!
I'm sure you'll love it, he, he http://www.lemmingsforums.com/Smileys/lemmings/cool.gif" alt="8)" title="Cool" class="smiley" />

[namida]

Thanks for the info, Simon!

The latest update seems to no longer be able to load a level I made in the first release. It misidentifies it as a special graphics level. I checked with a hex editor and the problem is not the level file itself.

I found the reason: it is due to a bug in the first release, and it is now fixed.
- if your hex editor allows you to edit data, then just change the value of the byte located at address 0x001A from whatever-it-is to "02".

0x001B actually. For some reason, 0x001A was set to 82, and 0x001B wasn't set. Anyway, I had thought I'd already tried this - but I'd been changing 1D, not 1B, which obviously isn't going to help my cause very much... xD

Another level (which was made in LemEdit), it doesn't load all the steel areas correctly - some are missing.

This one is strange... Be sure to have your keyboard's "numlock" key activated, and press "9" (numpad) to display all the Steel items in the foreground. Could you still confirm you're missing some Steel pieces?
If there's really a bug here, I definitively have to try/load your level to find the problem.

By the way, thanks to your message, I realized that default "Auto-Snap" settings needed to be scaled x2 because the level-editor uses hi-res sprites and a "x2" scale as in Lemmini (therefore, in the next version, Steel will auto-snap to 8x8 and Objects will snap to 16x8). This way, you'll be sure to design Lemmings1-fully-compliant levels!

I think I've identified the problem based on this and a closer look at my level. Namely - the size limit for a steel area in Lemmings is 64x64. However, your editor attempts to enforce this - but again, doesn't take into account it's own double resolution. I notice that steel areas that exceed 32x32 in size are cut down to that, but smaller ones remain perfectly fine.

1) What is the expected/normal theme of the level instead of "special"? (dirt, fire, snow, ...)

Dirt.

All four vgaspec levels have the large single terrain piece, plus objects from the dirt set, recolored according to each vgaspec's palette. Any normal tileset should work with vgaspec.

-- Simon

I think you misunderstood. We were talking about one of my levels being mistakenly identified by the editor as a special graphics level when it isn't one. The actual graphics set of the level in question is Marble.

[LJLPM]

0x001B actually. For some reason, 0x001A was set to 82, and 0x001B wasn't set. Anyway, I had thought I'd already tried this - but I'd been changing 1D, not 1B, which obviously isn't going to help my cause very much... xD

Yes, 0x001B. So 0x001A should be set to 0, while 0x001B should be set to 2 (and 1D won't help, yes).
Tell me if it works.
If it doesn't work, then you could provide me with the level, I'll make a tmp quick'n dirty fix in the editor to re-save your level in a good way, and I'll upload the fixed level on my website. It won't be a problem.

I think I've identified the problem based on this and a closer look at my level. Namely - the size limit for a steel area in Lemmings is 64x64. However, your editor attempts to enforce this - but again, doesn't take into account it's own double resolution. I notice that steel areas that exceed 32x32 in size are cut down to that, but smaller ones remain perfectly fine.

You're absolutely right. Fixed! http://www.lemmingsforums.com/Smileys/lemmings/laugh.gif" alt=":D" title="Laugh" class="smiley" />

[namida]

0x001B actually. For some reason, 0x001A was set to 82, and 0x001B wasn't set. Anyway, I had thought I'd already tried this - but I'd been changing 1D, not 1B, which obviously isn't going to help my cause very much... xD

Yes, 0x001B. So 0x001A should be set to 0, while 0x001B should be set to 2 (and 1D won't help, yes).
Tell me if it works.
If it doesn't work, then you could provide me with the level, I'll make a tmp quick'n dirty fix in the editor to re-save your level in a good way, and I'll upload the fixed level on my website. It won't be a problem.

No worries, this worked perfectly once I was changing the right offset.

By the way guys - after another read through ccexplore's documenting of the format, I actually managed to make sense of it this time. So, within the next few days I should be able to whip up a tool to extract the terrain/object graphics from the DOS datafiles to use with the editor, thus giving better accuracy (as well as bringing graphic set 9 to Lemmini, if no one's done that already).

[LJLPM]

@namida: nice to hear some news about a new tool http://www.lemmingsforums.com/Smileys/lemmings/laugh.gif" alt=":D" title="Laugh" class="smiley" />

New version uploaded (beta 1.30):
- fixed the bug with the bad size of Steel items found by namida (see above)
- 2 new features added (see below)

feature #1:
a new layer has arrived: the "Bounding Boxes" layer.
This layer allows you to easily see the actual dimension of any item (it may be useful for performing precise selections, or just to see the structure of a level http://www.lemmingsforums.com/Smileys/lemmings/smiley.gif" alt=":)" title="Smiley" class="smiley" />)

Remember, by default, layers are available by pressing "numpad 4" (backward move) and "numpad 6" (foreward move).
You can also switch back to the original layer by hitting "numpad 5".
Layers can be very useful for making specific selections!!! ... as well as using "numpad 7" and "numpad 8" (to loop through selection modes)!
note: using the numpad keys requires the "numlock" key to be activated, of course.

- showing the bounding-box layer on:
http://imageshack.us/a/img42/5627/5crw.png" alt="" class="bbc_img" />


feature #2:
This one is a very nice addition!!! It's the "snap-to-item" option!!! http://www.lemmingsforums.com/Smileys/lemmings/cool.gif" alt="8)" title="Cool" class="smiley" />

You already knew about the "snapgrid" feature (press 's').
Now, if you press 's' when some items are selected, you'll activate the "snap-to-item" feature (instead of the classic snapgrid).
Basically, the "snap-to-item" option will draw some handy snap-lines around your selected item(s): left, top, right and bottom snap-lines.

- one item selected, press 's' to make the snap-lines appear around the item:
http://imageshack.us/photo/my-images/31/t2au.png/" class="bbc_link" target="_blank">http://img31.imageshack.us/img31/923/t2au.png" alt="" class="bbc_img" />

Press 's' once, and you'll have the vertical snap-lines only.
Press 's' a second time, and you'll have the horizontal snap-lines only.
Press 's' a third time, and you'll have vertical+horizontal snap-lines.
Press 's' again to exit this "snap" mode.

Snapping items has never been easier: it's really a child play to build well-aligned stuff!

- showing the 3 snap modes with a multiple selection:
http://imageshack.us/photo/my-images/34/eh7s.png/" class="bbc_link" target="_blank">http://img34.imageshack.us/img34/7509/eh7s.png" alt="" class="bbc_img" />

[namida]

Okay, bit of a block in this tool... I don't understand the whole GIF format thing!
I've managed to make sense of the headers, color tables, etc, it's the image data itself I don't get.
Any chance anyone here can explain it or link me to a document that'll help? Otherwise, I'll have to resort to outputting in BMP, which (since it doesn't support transparency) leaves a bit of a cleanup job even if you use a tool to convert the format... or I could try and get my head around PNG if that's simpler (which since that does support transparency, it's just a matter of running them through a conversion tool after that).

I honestly don't give a crap about a compression algorithm - I'm fine to just have uncompressed data. Problem is, I don't even get exactly what I'm meant to do to store *that*.

If you need to use sample code to explain anything, then I can most easily make sense of BASIC or PHP, but I'm sure I'll manage to decode anything else as long as it's simple enough - however the problem isn't that I don't know how to write code to save to the format, but rather, I don't understand the format itself.


Or otherwise, LJLPM, what's the chance of you being able to add pallete-based BMP (16-color or 256-color) support to your app and just using color 0 as transparent (and if this can be done - can the same modification be made to Lemmini, if the author's still around or if the source is available)? (I would assume that you could just add a second entry for black to the pallete for, eg, the solid black in the crystal set). Or alternatively, loading the transparency mask from a second (monochrome) BMP file?


EDIT: Okay, I *think* I've got my head around it now. Once I'm finished translating it from Namida-mental-language to actual programming code, we'll see if I actually am understanding it or not...


EDIT: Well. It seems I'm at least somewhat on the right track. I can at least create an image file that all GIF-supporting programs will open rather than go "OMG BAD FILE *die*"... now, actually getting it to show anything is another matter... (Those that support transparency are displaying it as entirely transparent, while those that don't are displaying it as the first color in the pallete.)

EDIT: PROGRESS! I now have it outputting a GIF file with an image that, although not perfect, at least somewhat resembles the input. =D

EDIT: AND AT LAST, full-blown success, at least for a small image (which means everything's in one block and it doesn't even come close to having the code size change). I have written code to handle splitting the "compressed" data into 255-byte blocks (actually, as a precaution and since it won't really have any negative effects, it cuts off slightly sooner than 255), as well as to clear the table before the code size should increase (again, it errs a bit on the side of caution, and clears it slightly before it would be full). Attached is an image generated by my code. The actual image was hardcoded using DATA statements rather than loaded from any kind of file at this stage; as the focus was on the GIF-saving code.

EDIT: And a bit of further modification. Previously, the program was outputting 16-color images. Now, in practice, due to the duplication of custom 0 into default 7, Lemmings will only ever use 15 colors at a time, thus leaving one color free to use as transparent. However, especially if custom graphic sets get made at some point, there's no guarantee that all of them will make sure to use that one as transparent; we already have examples in the original game of black not being transparent (in the Crystal style) although it's quite possible that it defines an extra copy of black as a custom color (I haven't checked). So, I've made the program output 32-color images instead (with one of hte extra 16 being used as a transparent color, and the remainder of them being unused). Note that you can convert them to actual 16-color, 256-color or whatever else you want once extracted. I'm just working with what's convenient for me, to output a GIF that at least works.


EDIT AGAIN: Successfully decompresses all terrain pieces! It doesn't do objects yet, but that's coming. I've attached it, and included basic instructions.

Note that while it can extract the terrain from Graphic Set 9, since it doesn't yet extract the objects, there's not much point (except to look at for fun).

It'll automatically give them the right names "dirt" "marble" etc, though it doesn't organise them in folders. Set 9 will be labelled "xmas". When you run it, it'll create a text file where you can change the style names if you want to for any reason.

EDIT: It does the object graphics now. Doesn't yet do the trigger area graphic or the style properties INI file.


EDIT: Deleted, see seperate topic about extractor tool.

[LJLPM]

new version will be released tomorrow (beta 1.40).

new features:
- enabled selections and entity moves in zoomed views http://www.lemmingsforums.com/Smileys/lemmings/cool.gif" alt="8)" title="Cool" class="smiley" />
- added "Lock Moves On X/Y" option

Good news, I took time to handle the scale thing when dealing with mouse inputs: so now you can perform the same operations in the original 1:1 view and in the zoomed views (x2, x4, x8). Nice addition!
http://imageshack.us/photo/my-images/853/9181.png/" class="bbc_link" target="_blank">http://img853.imageshack.us/img853/9421/9181.png" alt="" class="bbc_img" />


The "Constraint moves on X or Y axis" feature, which is available by holding the SHIFT key when moving items, has now its own checkbox area (you can freely add your own keyboard shortcuts for these options by mapping the "LOCK_MOVES_ON_X/Y" entries in the "key-config" window).
(also notice that the "Borders on X/Y" option now stands on one line)
http://imageshack.us/photo/my-images/30/40k5.png/" class="bbc_link" target="_blank">http://img30.imageshack.us/img30/7194/40k5.png" alt="" class="bbc_img" />