[OLD] Player Bugs / Suggestions

[namida]

From some quick testing, it appears you're right. I'll look into this in more detail later on.

[namida]

Okay, I looked more into this, and thanks to your suggestion as to the cause, was able to fix it.

On a side note, I've also added an option in custom-made Flexi packs to unlock all levels by default. This means you now have three choices of how you make your packs - forcing sequential play completely; suggesting sequential play but allowing skipping via a cheat code; or outright just opening up all levels right from the start.

(Still need to make a seperate option to exclude secret levels from that, though.)

[namida]

Couple of new features I've added for the next update; they aren't too visible in a screenshot so we'll have to wait until a video (or an LPIV demo) using them surfaces...

> Constantly-animating objects can now be set to start from a pseudorandom frame; this will avoid the effect of all of the same object within a level animating perfecty in sync with each other. (Of course, this behaviour could be desired for certain object types (such as one-way arrows), hence why it's an option.)
> Added a new type of object, "moving background piece". These are like usual no-effect constant-animation objects, except they can move! Their maximum movement speed is 255 pixels per direction per 17 frames of gameplay, and they can move in a straight line, or diagonally at a 22.5 degree or 45 degree angle. Their speed/angle of movement is defined by the level, not by the object itself, so you can even have a sort of "parallax" movement if you want.

(Eeep, posted this in the Editor topic by accident earlier.)


Also, I'm finally getting around to replacing some of the kludgier parts of NeoLemmix (written back when I had very little idea what I was actually doing) with more well-written code. This probably won't have much effect on the average user, but will make the source code a lot tidier. It's possible it may result in very slight performance increases.

[mobius]

Couple of new features I've added for the next update; they aren't too visible in a screenshot so we'll have to wait until a video (or an LPIV demo) using them surfaces...

> Constantly-animating objects can now be set to start from a pseudorandom frame; this will avoid the effect of all of the same object within a level animating perfecty in sync with each other. (Of course, this behaviour could be desired for certain object types (such as one-way arrows), hence why it's an option.)
> Added a new type of object, "moving background piece". These are like usual no-effect constant-animation objects, except they can move! Their maximum movement speed is 255 pixels per direction per 17 frames of gameplay, and they can move in a straight line, or diagonally at a 22.5 degree or 45 degree angle. Their speed/angle of movement is defined by the level, not by the object itself, so you can even have a sort of "parallax" movement if you want.

(Eeep, posted this in the Editor topic by accident earlier.)


Also, I'm finally getting around to replacing some of the kludgier parts of NeoLemmix (written back when I had very little idea what I was actually doing) with more well-written code. This probably won't have much effect on the average user, but will make the source code a lot tidier. It's possible it may result in very slight performance increases.

this all sounds really cool. [will be easier to see in action ]
the parallax thing sounds interesting. It's something that was used effectively in one of the mario games I don't remember which. It was also, I felt, used poorly in several other games but it depends on how it's implemented. As long as a background image is sufficiently different or of different brightness than the foreground it won't be confusing. And it shouldn't be too cluttered or busy.

great work with the whole project so far btw.

[namida]

So far, I've only made use of the background thing to have stars and planets floating around in the background in the space graphic set; although there's no reason it couldn't be used for full-scale background images. With that being said, currently the movement of them is constant, not relative to how much you scroll the screen.

[namida]

Well, it appears Cheapo itself only supported 5-bit color depth (or 6-bit for the Green channel), so upgrading Copycat Lemmings to use the new format isn't as much of a big deal - it won't give any improvement in graphics quality, as the old 18-bit color format could still support the entire color range that Cheapo could.

Still, it goes without saying that they should be updated to the new format for consistency's sake, so it's still on the todo list; just not as important a matter.

[PIGSgrame]

I found 2 level bugs in the Original Lemmings Neo player v 1.32

Fun 9 / Tricky 26
The Lemmings die as soon as they touch the pillar. Looks like either there's something wrong with the Y position of the trap on top of the pillar, or something is marked deadly in the tileset which shouldn't.

Taxing 27
This level if cut off at the right and left. You don't actually need the structures that are missing because of that, but the original Amiga level uses the whole level space.
(cf. http://tle.vaarties.nl/images/solutions/lemmings/amiga/taxing/27%20-%20Call%20in%20the%20bomb%20squad.gif)

[namida]

Fun 9 / Tricky 26, I'll look into.

Taxing 27, this is simply because it's "more NeoLemmix-y". DOS/Amiga used a fixed level size, so many levels filled in the empty space with decoration. NeoLemmix supports resizable levels, so a lot of the non-functional decorative elements have been cut out.

[namida]

Sorry about the delay with the Fun 9 / Tricky 26 bug. I've just now confirmed that I can reproduce this bug, and will look into the cause of it within the next few hours and release an update to fix it.

I'd guess it wouldn't be a matter of the level design, but rather an engine bug; as I had a similar problem with an LPIV level prior to the V1.32n release but thought I had fixed it. In this case, the trigger area was shifted to the right as well as downwards, but the downwards shift was not nearly as significant as in this case. The LPIV case also related to a fire object, and affected more than one object (all affected objects were shifted by the same amount, while still retaining their original trigger area as well).

(Just for reference about the "shift downwards" - unless there's something even weirder than I thought going on here, the extra fire trigger area is definitely linked to the fire trap above the pillar, not one of the ones on the sides.)

If anyone's aware of anywhere else this may happen (in both this case and the LPIV case, it's been relating to fire in levels that do contain fire objects), let me know.

[namida]

Okay, I'm 90% sure I've found the cause of this now - certianly Fun 9 / Tricky 26's case is fixed. I'll do some more testing soon, but I think it's sorted.

Although cases so far have only been noticed with fire objects, it could theoretically affect any object that uses the main trigger map (ie: any object that can affect a lemming that walks into it, apart from water).

[namida]

So, for the next version, I'm working on removing the limit of 32 entrances in a level, and instead allowing any amount (up to the number of allowed objects, which is currently 128; I'm hoping to expand that too, but possibly not yet). Current level format (which would need to be revised anyway to allow more than 128 objects) only allows up to 32 entries in the window order data, but very few (if any) levels use the window ordering anyway, apart from those converted from Cheapo; in the absence of window ordering data in the level, it just works on the object ID order and although it's currently limited to 32, this is just an engine limitation and not limited in any way by the level format; thus this is the easiest thing to expand first.

In terms of allowing more than 128 objects / 1000 terrains / 128 steels; the latter two would only require a level format that supports it, but having no maximum on number of objects would also require modifications to the engine as well as modifications to level format; the way trigger areas are currently handled limits it to 255 functional objects (extra ones can theoretically exist, but would be treated as fake if they aren't windows, water, receivers, one-way arrows or pre-placed lemmings).


I don't see myself ever using more than 32 entrances in a level (I can't even think off-hand of any case where I've used more than 4, and even that's rare - most of my levels use one or two), and I'd think there'd be very few cases where more entrances would be a more suitable option than pre-placed lemmings, but it never hurts to have the option there.


EDIT: Okay, added that, and as futureproofing, I've also revised the way the trigger area map is handled, so it can now handle up to 65535 objects in a level (and like the old system, objects beyond this won't crash the game or not appear at all; they'll just act as fake if they're not one of the aforementioned objects that doesn't need a trigger area on the main trigger area map). For now, this will most likely be a purely behind-the-scenes change, though perhaps I'll work on implementing the support for a larger number of pieces soon...


EDIT: Eh. Started working on such a thing, because why not. Initially new format will support (in addition to everything currently supported) object/terrain IDs above 255, an unlimited number of pieces (instead of 128 each for objects/steels, and 1000 for terrains), and an unlimited number of entries in the window ordering (instead of 32 max). It's also more open-ended to allow me to add other stuff to it later without having to revise the whole thing, if need be. It's closely based off the current format, but with just enough modifications to allow for these things.


EDIT: Okay, implemented in the editor (not yet in the player). Loading and saving perfectly. For the majority of levels, the flexible piece count rather than fixed also results in a much smaller filesize (though I haven't yet looked into what the results are once compressed) - compared to the old format where all levels are always 10KB exactly; "Chocblocked!" (first Bumpy level in the LPIV demo) is not even 1KB in the new format, while the largest and highest-piece-count level so far is 7KB.

EDIT: Tested compressed. About a 20% smaller size when compressed for Chocblocked; while the difference is negligable on the other level (less than 1%).

Now, to add support to the player (including in the Level Dump option)...


EDIT: Fully supported by the player now. As of the next release, you'll no longer be limited to 1000 terrains and 128 each of objects and steels; nor to a maximum of 256 objects and 256 terrains in a graphic set (the graphic set format already supports more pieces than this, but until now the level format didn't).

The next question is - while I'm here, I should probably apply the same futureproofing to the level format that I have to the graphic set format, of taking into account potential higher-resolution usage.

[namida]

Alright, got everything working now. Made a few other tweaks to futureproof for higher-resolution levels.

Note that the old NeoLemmix 2KB level format (which has been deprecated for a very long time now) is going to have support removed from the player in the next version. Actual DOS / traditional Lemmix levels will continue to be supported, but NeoLemmix extensions to the format will not. I don't know if any levels in this format even exist anymore, but if they do, they should be upgraded to the either 10KB format or the new variable-sized format as soon as possible - this can be done quickly from NeoCustLemmix or a dumping-enabled Flexi player (provided the levels are in DAT files, not just via LookForLVLFiles) by pressing F4 on the title screen, or using the editor's "Mass Convert" feature (just convert from NeoLemmix to NeoLemmix; this works perfectly fine as a way of upgrading to the latest format).

The editor will retain support for these for a while longer, but I plan to remove it from that too sooner or later.



New level format will be a reduction in filesize on most levels; though it may be an increase on some that have a very large number of pieces. Old file size was always 10240 bytes regardless of level contents; new format is 177 bytes + 21 bytes per object/steel + 17 bytes per terrain + 3 bytes if there's any window ordering info + 2 bytes per window ordering info entry. This would mean that a level would need around 500 pieces (assuming there's no, or very little, window ordering info) to reach 10240 bytes.

[PIGSgrame]

A question about the Neo version of Mayhem 26 (The Steel Mines of Kessel): Are you sure this level is still possible without any Blockers? In the solution I found for the DOS version years ago, Blockers are not only needed to position the bombers, but also to actually keep back the crowd from hazards.

[namida]

I did test it at the time when I made that change, though I haven't continued to test it every time there's been mechanic changes, so I can't off-hand guarantee it's possible now; only that it was possible at the time I made the change. I definitely remember it was much harder than in DOS, and actually felt like a Mayhem level rather than just a long level.

I'll test that later today.

EDIT: Tested it. It's possible, though as mentioned before, it's a lot harder than on DOS, or even on Amiga. Probably still not as hard as that level on Mac, from what I hear. I was able to save 91% (one lemming more than required); I don't think any higher than that is possible.

[namida]

I've noticed 4 fairly major bugs recently, which I'll try to fix for the next update:

> Replays / frameskips may go out of sync if the release rate is changed on the same frame as a lemming enters the level
> Multiple skills can be assigned during a single frame (including the same skill twice or mutually incompatible skills) by use of replays or backwards frameskips
> Platformers need better terrain checks on the final brick, they may sometimes move one pixel into terrain
> The release rate sometimes doesn't display correctly after reverse frame jumps or 10-second skips during replays (purely cosmetic, it still functions fine)

The first two are the most significant, they can often occur by accident and have major impacts on gameplay (especially the first one). The third one is fairly rare, and requires either precision or specific terrain setups to acheive (excluding intentionally setting it up via destructive skills, I've noticed a total of two levels where it can happen; one of GigaLem's community pack contributions, and one LPIV level that wasn't included in the demo), but is still fairly important IMO. The last one is purely a cosmetic issue, albeit one that can be very annoying.

The 4th one is introduced in a recent version (as a side effect of some optimization of frame-skipping), while the other three have most likely been there for quite some time but gone unnoticed (or at least unreported) until now.